Best Pratices: Kundeneigene Pakethierarchie
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Moin,
ich suche mal wieder nach Best Practice-Verfahren. Wie macht ihr das mit euren kundeneigenen Paketen? Es wird ja in diverser Literatur empfohlen, eine Parallelhierarchie zur SAP-Hierarchie aufzubauen und Programme, die thematisch zu einem SAP-Paket passen, in das entsprechende Kundenpaket zu legen (dabei legt man natürlich nur die Pakete an, die man braucht).
Schreibt man also eine Log-Klasse, packt man die ins Paket ZBASIS/ZSZAL (weil das Log in BASIS/SZAL liegt). Für das, was nirgends reinpasst, legt man eine eigene Pakethierarchie an (so haben wir es beim Blutspendemodul gemacht)
Andere Kunden machen das anders. Womit habt ihr die besten Erfahrungen gemacht?
Gruß
Ralf
ich suche mal wieder nach Best Practice-Verfahren. Wie macht ihr das mit euren kundeneigenen Paketen? Es wird ja in diverser Literatur empfohlen, eine Parallelhierarchie zur SAP-Hierarchie aufzubauen und Programme, die thematisch zu einem SAP-Paket passen, in das entsprechende Kundenpaket zu legen (dabei legt man natürlich nur die Pakete an, die man braucht).
Schreibt man also eine Log-Klasse, packt man die ins Paket ZBASIS/ZSZAL (weil das Log in BASIS/SZAL liegt). Für das, was nirgends reinpasst, legt man eine eigene Pakethierarchie an (so haben wir es beim Blutspendemodul gemacht)
Andere Kunden machen das anders. Womit habt ihr die besten Erfahrungen gemacht?
Gruß
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Die meisten meiner Kunden machen das grob so - und wenn man mich fragt schlage ich das genau so vor, wobei ich die tolle Strukturierung der Module nur auf das Hauptmodul zeigen lasse. Also nur ZBASIS und nicht ZBASIS/SCAL
Wenn wir wissen, dass es sich um etwas Aufwändigeres handelt, wo diverse Codings und DDIC-Objekte dazugehören, legen wir ein eigenes Paket unterhalb des Hauptpakets an. Etwa ZCS_BLUTSPENDE als Unterpaket zu ZCS ( Customer service im weitesten Sinne, Patient = Hauptequipment, Arme, Beine und Blut sind Unterequipments ).
Wenn es dann noch größer wird wieder Unterpakete ZCS_BLUTSPENDE_INTERN und ZCS_BLUTSPENDE_API
Häufig finden sich so z.B. Pakete wie ZSD_ENHANCEMENTS wo dann alle Erweiterungen im SD-Bereich anzutreffen sind, egal ob es sich um Userexits (SMOD), Enhancements, BTEs, BADI-Implementierungen oder eine der vielen anderen Mögichkeiten handelt, die SAP so im Laufe der Jahre zur Verfügung gestellt hat.
Wenn wir wissen, dass es sich um etwas Aufwändigeres handelt, wo diverse Codings und DDIC-Objekte dazugehören, legen wir ein eigenes Paket unterhalb des Hauptpakets an. Etwa ZCS_BLUTSPENDE als Unterpaket zu ZCS ( Customer service im weitesten Sinne, Patient = Hauptequipment, Arme, Beine und Blut sind Unterequipments ).
Wenn es dann noch größer wird wieder Unterpakete ZCS_BLUTSPENDE_INTERN und ZCS_BLUTSPENDE_API
Häufig finden sich so z.B. Pakete wie ZSD_ENHANCEMENTS wo dann alle Erweiterungen im SD-Bereich anzutreffen sind, egal ob es sich um Userexits (SMOD), Enhancements, BTEs, BADI-Implementierungen oder eine der vielen anderen Mögichkeiten handelt, die SAP so im Laufe der Jahre zur Verfügung gestellt hat.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das heißt, du würdest unterhalb von ZBASIS kein Unterpaket anlegen?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Inzwischen ist es für mich auch relevant, dass man die Pakete wirklich "rein" zuordnet. Also, dass alles, was eine "Applikation" ist und alles, was dazu gehört, auch in EINEM Paket abgelegt wird.
So kann man dieses (Unter-) Paket nämlich separat als Repository in github ablegen. Aus diesem Grund bin ich auch inzwischen nicht mehr rigoros dafür, dass man nur EINE zentrale Klasse für "Irgendwas" hat( appl-Log z.B.), denn die Abhängigkeiten sind irgendwann nicht mehr handlebar.
Inzwischen würde ich für ALLES, was ich neu anfange auch ein separates Paket anlegen und dieses verwenden. Im Gegensatz zu "ach-da-passt-das-noch-los-rein-damit".
So kann man dieses (Unter-) Paket nämlich separat als Repository in github ablegen. Aus diesem Grund bin ich auch inzwischen nicht mehr rigoros dafür, dass man nur EINE zentrale Klasse für "Irgendwas" hat( appl-Log z.B.), denn die Abhängigkeiten sind irgendwann nicht mehr handlebar.
Inzwischen würde ich für ALLES, was ich neu anfange auch ein separates Paket anlegen und dieses verwenden. Im Gegensatz zu "ach-da-passt-das-noch-los-rein-damit".
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das heißt, du verzichtest auf jeden thematischen Zusammenhang zu SAP-Objekten, die mit deinen Objekten in einem Kontext stehen?
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
nein, das nicht. ich versuche schon, das zuzuordnen. Wobei das allerdings nicht immer so eindeutig ist.ralf.wenzel hat geschrieben: ↑03.03.2021 15:55Das heißt, du verzichtest auf jeden thematischen Zusammenhang zu SAP-Objekten, die mit deinen Objekten in einem Kontext stehen?
Wir haben bei der Produktentwicklung im eigenen Namensraum wenig direkten Bezug zu vorhandenen SAP-Projekten, daher wurde immer eine eigenständige Pakethierachie aufgebaut. Ich hatte dabei nur in Vergangenheit den Fehler gemacht, diese Hierarchie ähnlich wie eine Klassenhierarchie mit Spezialisierung in Unterpaketen aufzubauen, d.h. zum Beispiel:
ZAUSFUHR für allgemeine Funktionalitäten der Ausfuhr
ZAUSFUHR/ZAUSFUHR_DE Ausfuhranmeldung Deutschland
ZAUSFUHR/ZAUSFUHR_BE Ausfuhranmeldung Belgien
ZAUSFUHR/ZAUSFUHR_NL Ausfuhranmeldung Niederlande
usw.
Will man aber nun mit Paketprüfung und Paketschnittstellen arbeiten, um u.a. sicherzustellen, dass das Produkt Ausfuhranmeldung Belgien nicht Objekte des Pakets ZAUSFUHR_DE verwendet, so bekommt man massig Fehlermeldungen, da Objekte eines Unterpaketes grundsätzlich nicht auf Objekte des Oberpakets (mit übergreifender Funktionalität) zugreifen können. Ist blöd, aber halt von der SAP so ausgedacht. Daher sieht die Hierarchie jetzt eher so aus:
ZAUSFUHR Hauptpaket ohne Objekte
ZAUSFUHR/ZAUSFUHR_CORE allgemeine Funktionalitäten der Ausfuhr
ZAUSFUHR/ZAUSFUHR_DE Ausfuhranmeldung Deutschland
ZAUSFUHR/ZAUSFUHR_BE Ausfuhranmeldung Belgien
ZAUSFUHR/ZAUSFUHR_NL Ausfuhranmeldung Niederlande
usw.
Bin aber für Anregungen wie man es besser strukturiert offen...
ZAUSFUHR für allgemeine Funktionalitäten der Ausfuhr
ZAUSFUHR/ZAUSFUHR_DE Ausfuhranmeldung Deutschland
ZAUSFUHR/ZAUSFUHR_BE Ausfuhranmeldung Belgien
ZAUSFUHR/ZAUSFUHR_NL Ausfuhranmeldung Niederlande
usw.
Will man aber nun mit Paketprüfung und Paketschnittstellen arbeiten, um u.a. sicherzustellen, dass das Produkt Ausfuhranmeldung Belgien nicht Objekte des Pakets ZAUSFUHR_DE verwendet, so bekommt man massig Fehlermeldungen, da Objekte eines Unterpaketes grundsätzlich nicht auf Objekte des Oberpakets (mit übergreifender Funktionalität) zugreifen können. Ist blöd, aber halt von der SAP so ausgedacht. Daher sieht die Hierarchie jetzt eher so aus:
ZAUSFUHR Hauptpaket ohne Objekte
ZAUSFUHR/ZAUSFUHR_CORE allgemeine Funktionalitäten der Ausfuhr
ZAUSFUHR/ZAUSFUHR_DE Ausfuhranmeldung Deutschland
ZAUSFUHR/ZAUSFUHR_BE Ausfuhranmeldung Belgien
ZAUSFUHR/ZAUSFUHR_NL Ausfuhranmeldung Niederlande
usw.
Bin aber für Anregungen wie man es besser strukturiert offen...
Hab das mit den Paketschnittstellen nie richtig kapiert...
bzw. funktionierte immer anders, als ich das erwartet habe...
bzw. funktionierte immer anders, als ich das erwartet habe...
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Oha, ich darf gar nicht sagen, wie ich das mache...
Ich habe ein Paket Z001, und da wandert ALLES rein. 😁
Ich habe ein Paket Z001, und da wandert ALLES rein. 😁
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Wenn's thematisch zu Basis gehört schon. Nimm z.B. SCI Erweiterungen. Das ist ganz klar Basis --> es gehört in ZBASIS oder in ein Paket unterhalb von ZBASIS, z.B. ZBASIS_SCI.ralf.wenzel hat geschrieben: ↑03.03.2021 15:42Das heißt, du würdest unterhalb von ZBASIS kein Unterpaket anlegen?
Aber eben nicht ausgerichtet am Strukturbaum von SAP sondern an dem was in der Firma so an Eigenentwicklungen kommt.
Letztlich habe ich keine Lust mich durch hunderte Bäume und Unterpakete zu hangeln um rauszufinden zu welchem SAP-Pendant nun das SCI Krams gehört
Lieber ZBASIS als allgemeines Hauptpaket für alles was zur Basis allgemein gehört und nicht besonders etwas anderem zugeordnet werden soll und dann für alle "größeren" Sachen ein Paket direkt under dem Hauptpaket, so dass man bei der Strukturanzeige des Hauptpakets sieht was es denn alles gibt. Und innerhalb der Unterpakete dann "sinnvoll" weiter unterteilen wenn es zu groß wird.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Dann bleibt von deiner Aussageblack_adept hat geschrieben: ↑03.03.2021 18:24Wenn's thematisch zu Basis gehört schon. Nimm z.B. SCI Erweiterungen. Das ist ganz klar Basis --> es gehört in ZBASIS oder in ein Paket unterhalb von ZBASIS, z.B. ZBASIS_SCI.
Aber eben nicht ausgerichtet am Strukturbaum von SAP sondern an dem was in der Firma so an Eigenentwicklungen kommt.
nicht mehr viel übrig. Außer dass du alle kundeneigenen Pakete einem ZBASIS unterordnest, OHNE die SAP-Struktur darunter partiell abzubilden. Aber genau DAS ist ja die zentrale These vom von mir geschilderten Konzept: Man muss nix suchen, sondern einfach nur gucken, in welchem Paket die SAP den SCI-Krams abgelegt hat, dann weiß man auch, wo der eigene SCI-Krams liegt - nämlich im gleichnamigen Paket der Parallel-Paketstruktur.black_adept hat geschrieben: ↑03.03.2021 15:04Die meisten meiner Kunden machen das grob so - und wenn man mich fragt schlage ich das genau so vor
Das ist nicht "grob so", sondern etwas vollkommen anderes.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Doch - ist es. Nur dass der SAP-Hierarchiebaum recht tief sein kann und wir unsere Entwicklungen und der Kindern des Top-Nodes unterbringen.
SAP TOP-Node. Darunter hängen dann Pakete MM, SD, CS, CO, etc.
Und wir nennen unsere "Hauptpakete" ZMM, ZSD, ZCS analog zum SAP-Baum. Aber wir gehen dann erstmal nicht tiefer. Wenn SAP so was hat wie MM-PUR ( Einkauf evtl. ) würden wir i.a. kein ZMM_PUR anlegen, wenn da nur ab und an mal was zu machen ist sondern das in ZMM lagern. Wenn hingegen viele Entwicklungen in einem Paket gemacht würden was thematisch zu einem recht tief im SAP-Baum hängenden gehört ( MM-PUR-TOLL1-SUPERDUPER ) würden wir das dann auch direkt unter ZMM hängen und dann evtl. ZMM_PUR_DUPER nennen oder irgendwie so dass man weiß was da drin sein wird. Aber eben nicht so tief wie SAP.
Ausnahmen natürlich immer möglich.
Ich versuche es mal mit einer praxisnahen Analogie: Stell dir ein Paket vor wie ein Dimensionsloch mit begrenztem Volumen. Solange in das Dimensionsloch noch was reinpasst verwenden wir es. Aber wenn wir so viele Sachen in einem Bereich machen, dass es unübersichtlich wird ( Dimensionsloch kann nicht mehr alles aufnehmen ) erstellen wir halt ein neues Dimensionsloch - evtl. innerhalb des alten oder auch parallel dazu. Aber auch erst dann wenn es nötig wird.
SAP TOP-Node. Darunter hängen dann Pakete MM, SD, CS, CO, etc.
Und wir nennen unsere "Hauptpakete" ZMM, ZSD, ZCS analog zum SAP-Baum. Aber wir gehen dann erstmal nicht tiefer. Wenn SAP so was hat wie MM-PUR ( Einkauf evtl. ) würden wir i.a. kein ZMM_PUR anlegen, wenn da nur ab und an mal was zu machen ist sondern das in ZMM lagern. Wenn hingegen viele Entwicklungen in einem Paket gemacht würden was thematisch zu einem recht tief im SAP-Baum hängenden gehört ( MM-PUR-TOLL1-SUPERDUPER ) würden wir das dann auch direkt unter ZMM hängen und dann evtl. ZMM_PUR_DUPER nennen oder irgendwie so dass man weiß was da drin sein wird. Aber eben nicht so tief wie SAP.
Ausnahmen natürlich immer möglich.
Ich versuche es mal mit einer praxisnahen Analogie: Stell dir ein Paket vor wie ein Dimensionsloch mit begrenztem Volumen. Solange in das Dimensionsloch noch was reinpasst verwenden wir es. Aber wenn wir so viele Sachen in einem Bereich machen, dass es unübersichtlich wird ( Dimensionsloch kann nicht mehr alles aufnehmen ) erstellen wir halt ein neues Dimensionsloch - evtl. innerhalb des alten oder auch parallel dazu. Aber auch erst dann wenn es nötig wird.
Zudem gliedert es sich bei Kunden nicht nur an den Modulen auf, sondern in Projekten. Und damit ist die SAP-Struktur eh hinfällig. Plus: ich behaupte mal, dass kaum jemand die SAP-Struktur versteht geschweige denn einfach nur gucken muss, wo was liegt.
MMn sollte man darauf achten, auf jeden Fall möglichst frühzeitig ein neues "Dimensionsloch" zu öffnen, denn wenn erstmal Entwicklungen in ZBASIS drin sind, dann knobelt die so schnell niemand mehr auseinander und packt sie ZBASIS_HIER_GEHÖRTS_EIGENTLICH_HIN...
MMn sollte man darauf achten, auf jeden Fall möglichst frühzeitig ein neues "Dimensionsloch" zu öffnen, denn wenn erstmal Entwicklungen in ZBASIS drin sind, dann knobelt die so schnell niemand mehr auseinander und packt sie ZBASIS_HIER_GEHÖRTS_EIGENTLICH_HIN...
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Leider. Manchmal mache ich es zwar, aber das ist auch die Ausnahme.
Und wo wir schon gerade bei den Paketstrukturen bzw. den Inhalten eines Pakets sind. Was mir leider seit Jahr(zehnten) fehlt oder was ich noch nie gefunden habe ist so eine Art Link wie in den IMG-Bäumen, so dass man ein Paket/Objekt auch als Referenz aus einem anderen Paket sichtbar machen kann. Dann wäre ein Objekt welches an der Grenzschicht zwischen MM und CO liegt dann in beiden Paketen ZMM und ZCO sichtbar
Btw - kleiner Tipp, den ich auch erst seit kurzem kenne:
https://l3consulting.de/systemzugehoeri ... aenderung/
https://l3consulting.de/systemzugehoeri ... aenderung/
Vergleichbare Themen
4
Antw.
Antw.
2262
Views
Views
Alle Objekte aus Pakethierarchie in Transport übernehmen
von gago » 24.10.2016 10:51 • Verfasst in ABAP® Core
von gago » 24.10.2016 10:51 • Verfasst in ABAP® Core
3
Antw.
Antw.
652
Views
Views
14
Antw.
Antw.
7061
Views
Views
3
Antw.
Antw.
6436
Views
Views
kundeneigene Benutzerparameter anlegen
von meddok » 27.02.2006 12:51 • Verfasst in SAP - Allgemeines
von meddok » 27.02.2006 12:51 • Verfasst in SAP - Allgemeines
2
Antw.
Antw.
4384
Views
Views
Kundeneigene Felder in Kostenstellen-Stammdaten
von Walhalla » 06.04.2017 16:19 • Verfasst in Financials
von Walhalla » 06.04.2017 16:19 • Verfasst in Financials
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.