Zertifizierung von ABAP AddOns durch SAP möglich

Zertifizierung von ABAP AddOns durch SAP möglich

Hallo ABAP Freunde,

hier mal nur so als Hinweis, dass bei SAP eine Zertifizierung von ABAP AddOns, die man an andere SAP Kunden weiterverkaufen will, möglich ist. Dies erhöht die Wahrnehmung im Markt und die Akzeptanz bei Kunden.

Damit das klappt braucht man folgendes:
- eine eigene ABAP Entwicklungslizenz
- einen eigenen Namensraum (kein Z* oder Y*)
- Keine Modifikationen am SAP Standard
- Nur lesender Zugriff auf SAP Tabellen
- Verpacken und Ausliefern des AddOns mit dem SAP AddOn Assembly Kit (AAK).

Dieses AAK gibt's im Rahmen des Zertifizierungsprozesses und wird für das Verpacken und die Auslieferung an Kunden genutzt. Der Kunde spielt dann keine Transporte mehr ein, sondern nutzt die SAP Standardtransaktionen SAINT und SPAM um das AddOn und verfügbare Hotpackages/Upgrades einzuspielen.

Weitere Details zur AddOn Zertifizierung gibt's auf:
http://www.sdn.sap.com/irj/servlet/prt/ ... ration.pdf
(sorry für den langen Link... )

Oder meldet euch direkt bei uns: icc@sap.com


Servus,
Christoph

--
http://sdn.sap.com/sdn/icc.sdn

babap hat geschrieben:Ich habe dazu aber noch ein paar weitergehende Fragen.

Ich auch. Ich bin nur noch nicht dazu gekommen, sie mal systematisch aufzuschreiben.
Auch jetzt habe ich kaum die Zeit dazu.
Also werde ich wohl später noch mal etwas schreiben.

Soviel ich weiß erhält man das Namensraumpräfix erst dann, wenn man die Anwendung vorzeigen kann.

Das kann ich mir nicht vorstellen.
Ich weiß nicht mehr, in welchem OSS-Hinweis die Beantragung ... beschrieben ist, aber der OSS-Hinweis 104010 verweist auf diesen Hinweis.
Ich glaube, es war nur eine Entwickler-Lizenz nötig.
Und man nuss evtl. irgendwie begründen/glaubhaft machen können, dass man den Namensraum braucht.
Die Zuteilung erfolgt aber problemlos. Ich kann mir also nicht vorstellen, dass es da nennenswerte Hürden gibt.

(Dann müsste man alles wieder umbenennen und umstricken)

Ja, und das ist nicht ganz trivial.
Erst recht nicht, wenn man sein im Kundennamensraum entwickeltes "AddOn" schon ein paar Jahre an diverse Kunden ausgeliefert hat.
Gibt es da inzwischen eigentlich schon irgendetwas Vorzeigbares an Umstellungs-Tools von SAP?
Bisher hört man nur gelegentlich mal Gerüchte zu dem Thema, s. z.B.
http://www.abapforum.com/forum/viewtopi ... =9385#9385
Was können die Tools, was können sie nicht?
Was kostet deren Einsatz?

Ich gehe mal davon aus, daß man eigene Datentabellen, Customizingtabellen, Stukturen, Views, Tabellentypen, Datenelemente und Domänen in beliebiger Vielfalt nutzen kann.

Mit Sicherheit. So viele eben in den Namensraum passen ;) Bei Nummernkreisobjekten kann es je nach Länge des Prefix eng werden.

Darf man "legale" User-Exits in den SAP-Anwendungen benutzen?

Das ist wirklich die Frage.
Bei CALL CUSTOMER-FUNCTION wird es schon schwierig.
Sauber per Transport bekommt man das wohl nicht hin.
Man könnte allenfalls ein /PREFIX/-Include ausliefern und den Kunden per Installations-Anleitung mitteilen, welchen User-Exit sie evtl. aktivieren müssen, wie sie den /PREFIX/-Include in den bereits für eigene Erweiterungen genutzten ZX*-Include einbauen müssen ...

Dennoch bleibt genug Raum für Probleme:
Wird der /PREFIX/- oder der Kundneneigene Quelltext zuerst in den ZX*-Include eingebaut?
Was, wenn der FB einen CHANGING-Parameter hat, den AddOn und Kunde anders versorgen wollen/müssen?
Was, wenn Kunde oder AddOn eine RAISE-Anweisung im Code haben, so dass der andere Code nicht mehr prozessiert wird ...

Und mit BADIs wird es nicht unbedingt einfacher.
Es gibt etliche, bei denen nur jeweils eine Implementation aktiv sein kann, also nicht sowohl die des Kunden als auch die des AddOn-Anbieters. (Ist bei Methoden, die nur einen CHANGING-Parameter haben, ja auch irgendwie nachvollziehbar.)

Welche Konzepte gibt es da seitens SAP, entsprechende Konflikte/mögliche Kollisionen aufzulösen?

Selbst das BDT ist in dieser Hinsicht nicht besonders durchdacht.
Ein "problemloses Miteinander" von Kundenerweiterungen und Erweiterungen durch AddOns ist damit jedenfalls leider auch nicht möglich.
Dabei wäre es so einfach gewesen, es besser zu machen.

Darf man Customer-Includes in SAP-Tabellen (CI**) nutzen??

Notfalls muss man eben eine APPEND-Struktur /PREFIX/* an jede Tabelle/Struktur hängen, die das CI nutzt.
Dese APPEND-Strukturen können ja bei Bedarf alle die gleiche INCLUDE-Struktur verwenden, so dass man neue Felder nicht überall einzeln ändern muss.

Darf man Daten an SAP-Tabellen anhängen mit normalen Appends (ZA***) oder vielleicht /../../xyz??

Auf keinen Fall an ZA*... Und die Felder sollten dann auch nicht YY* oder ZZ* heißen, sondern mit /PREFIX/ beginnen.
Aber ob man dann noch zertifiziert wird, weiß ich nicht.

Es kann jedenfalls nichts schaden, ein möglichst aktuelles 6.x-System zu haben, um mal prüfen zu können, für welche Tabellen SAP inzwischen welche Erweiterungs-Kategorie vorgesehen hat.
An die REPOSRC eigene Felder anhängen zu wollen, ist auf jeden Fall böse.
Ebenso vermutlich eine APPEND-Struktur für DDIC-Struktur SYST, spätestens dann, wenn sie z.B. eine Komponente vom Typ STRING enthalten soll.
Auch wenn man sich an die Erweiterungs-Kategorie hält und z.B. nur flache Komponenten vom Typ C anhängt, kann es noch zu Problemen kommen.
Zum Beispiel, weil ein Kunde an die gleiche Tabelle jede Menge eigene Felder angehängt hat, so dass jetzt die maximal zulässige Tabellenbreite überschritten wird.

Darf man diese Appends und die CI's ausliefern??

die CI's und APPENDs im Kundennamensraum (Z*/Y*) wohl kaum.
APPENDS im /PREFIX/-Namensraum bestimmt.

Letztendlich stellt sich die Aufgabe, die benutzen SAP-Erweiterungen im Kundensystem "verletzungsfrei" einzufügen,

Ja.

was besonders dann spannend ist, wenn der Kunden ein paar von den benötigten Exits selbst schon angeschmissen hat

Bei der Namensraum-Umstellung, für deren technische Umsetzung ich verantwortlich war - http://www.abapforum.com/forum/viewtopi ... =9411#9411 - haben wir das Problem so gelöst, dass wir den Code, der bisher (solange das AddOn im Kundennamensraum ausgeliefert wurde) immer direkt in den ZX*-Include geschrieben wurde, so dass immer wieder ein Abgleich mit den kundeneigenen Modifikationen nötig war, in einen eigenen /PREFIX/-Include gesteckt haben.
Mit der Anweisung in der Upgrade-Doku, den /PREFIX/-Include so vorallen kundenspezifischen Erweiterungen in den ZX-Include einzubauen: Durch den Einbau am Anfang konnten wir sicher sein, dass der Code prozessiert wird.
Durch DO 1 TIMES ... ENDDO lassen sich EXIT- und CHECK-Anweisungen entschärfen, die sonst den kundenspezifischen Code mit übersprungen hätten.
RAISE- oder MESSAGE ... RAISING-Anweisungen sind dann natürlich innerhalb des /PREFIX/-Includes tabu.

(Hier handelte es sich um eine überschaubare Anzahl AddOn-Anwender, die das AddOn größtenteils auch schon im Kundenamensraum eingesetzt hatten.
Für eine Zertifizierung des AddOns durch SAP reicht dieses Vorgehen mit Sicherheit nicht.)

oder die CI's schon gefüllt hat.

Die würde ich weder direkt modifizieren noch ausliefern.

Aber das ist ein hochinteressantes Thema

Ja. Ich habe da auch noch ein paar interessante Fragen.
Vielleicht komme ich ja demnächst noch dazu.

babap hat geschrieben:Hallo,
Gast bescbreibt soeben alle meine aktuellen "Herausforderungen" (Probleme??? gibt es nicht!!).

Das war ich, aber obwohl ich eigentlich angemeldet war, ist der Beitrag dann "Gast"-Antwort verschickt worden.
Vielleicht war ich vor dem Absenden zu lange inaktiv.

Und ich glaaube noch nicht, dass das schon alle Herausforderungen waren.
Wenn doch, hast Du ziemliches Glück.
Ich muss mal sehen, dass ich diese Woche irgendwann noch Zeit für meine restlichen Fragen finde.

Ich habe die Aufgabe, eine von jemandem gehabte Idee in SAP umzusetzen.

Ich hab's fast fertig, aber ohne Prefix etc.

Ich habe versucht, die Nutzung von Exits und Includes zu kapseln.

Und ist das so (im Kundennamensraum) schon an andere Anwender ausgeliefert worden?
Um welches Release geht es, um wie viele Objekte welcher Objektarten ...
(also all die Fragen, die ich eigentlich immer stelle, wenn jemand Fragen bzgl. Partnernamensraum-Umstellung einer bestehenden Entwicklung hat - Du müsstest die Fragen eigentlich bei geeigneter Suche im abapforum finden, Schlüsselwort-Kanditaten wären z.B. 104010, /PREFIX/, Kundennamensraum)

Jetzt steht als nächstes wirklich die Zertifizierung an, leider habe ich mich bis jetzt nicht selbst darum gekümmert.

Sondern wer?

Hallo,

vielen Dank für dieses Posting.

ChristophClaus hat geschrieben:Hallo ABAP Freunde,

...
Dies erhöht die Wahrnehmung im Markt und die Akzeptanz bei Kunden.

Damit das klappt braucht man folgendes:
- eine eigene ABAP Entwicklungslizenz
- einen eigenen Namensraum (kein Z* oder Y*)
- Keine Modifikationen am SAP Standard
- Nur lesender Zugriff auf SAP Tabellen
- Verpacken und Ausliefern des AddOns mit dem SAP AddOn Assembly Kit (AAK).

...

Anzumerken wäre für alle anderen User noch, daß das AAK im Abonnement jährlich zu bezahlen ist und die erste Zertifizierung nochmal extra kostet (im niedrigsten 5-stelligen Bereich...), dafür kann man einmal im Jahr eine neue Version oder ein weiteres Produkt zertifizieren.

Sollte bei dem Paket noch eine Java-Anwendung dabeisein, muß sie auf der Web-AS-Umgebung laufen Also ist auch da die J2EE-Zertifizierung fällig (zum Preise von nur noch ...)

Nur nicht abschrecken lassen!!!
Gast

Re: Zertifizierung von ABAP AddOns durch SAP möglich

Hallo zusammen,

ich grabe mal dieses Uraltthema aus und wollte nachfragen ob es inzwischen zu diesem Thema ein paar Erfahrungen gibt? Wir stehen aktuell nämlich auch vor der Herausforderung, dass wir unsere AddOns vermutlich zertifizieren lassen dürfen (zum Glück schon im Parternernamensraum entwickelt, aber ob alle übrigen Voraussetzungen erfüllt sind, das wage ich zu bezweifeldn).

Viele Grüße
Chris

Re: Zertifizierung von ABAP AddOns durch SAP möglich

Hi!

Meines Wissens hat sich nicht wirklich was geändert, die SAP verlangt auch nach wie vor einen ziemlichen Batzen Geld für die Zertifizierung. Sofern man sich an die SAP Vorgaben hält, sollte die Zertifizierung kein Problem verursachen.

lg Fößleitner Johann