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#9385Was 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:
- Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)
- GeSHi ©
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.