Best Pratices: Kundeneigene Pakethierarchie

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
18 Beiträge • Seite 1 von 2 (current) Nächste
18 Beiträge Seite 1 von 2 (current) Nächste

Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Das heißt, du würdest unterhalb von ZBASIS kein Unterpaket anlegen?
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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".

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Das heißt, du verzichtest auf jeden thematischen Zusammenhang zu SAP-Objekten, die mit deinen Objekten in einem Kontext stehen?


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
ralf.wenzel hat geschrieben:
03.03.2021 15:55
Das heißt, du verzichtest auf jeden thematischen Zusammenhang zu SAP-Objekten, die mit deinen Objekten in einem Kontext stehen?
nein, das nicht. ich versuche schon, das zuzuordnen. Wobei das allerdings nicht immer so eindeutig ist.

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von IHe (Specialist / 141 / 35 / 45 ) »
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...
Ingo Hoffmann

ECC|S/4HANA|BTP
dbh SAP Solutions

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Hab das mit den Paketschnittstellen nie richtig kapiert...
bzw. funktionierte immer anders, als ich das erwartet habe...

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Oha, ich darf gar nicht sagen, wie ich das mache...

Ich habe ein Paket Z001, und da wandert ALLES rein. 😁

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
ralf.wenzel hat geschrieben:
03.03.2021 15:42
Das heißt, du würdest unterhalb von ZBASIS kein Unterpaket anlegen?
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.
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
black_adept hat geschrieben:
03.03.2021 18:24
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.
Aber eben nicht ausgerichtet am Strukturbaum von SAP sondern an dem was in der Firma so an Eigenentwicklungen kommt.
Dann bleibt von deiner Aussage
black_adept hat geschrieben:
03.03.2021 15:04
Die meisten meiner Kunden machen das grob so - und wenn man mich fragt schlage ich das genau so vor
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.

Das ist nicht "grob so", sondern etwas vollkommen anderes.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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...

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
ewx hat geschrieben:
07.03.2021 20:55
Man 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...
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
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Best Pratices: Kundeneigene Pakethierarchie

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Btw - kleiner Tipp, den ich auch erst seit kurzem kenne:
https://l3consulting.de/systemzugehoeri ... aenderung/

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
IHe


Vergleichbare Themen

4
Antw.
1883
Views
Alle Objekte aus Pakethierarchie in Transport übernehmen
von gago » 24.10.2016 10:51 • Verfasst in ABAP® Core
3
Antw.
383
Views
Kundeneigene Felder
von Rabea1103 » 03.06.2021 08:41 • Verfasst in ABAP® für Anfänger
14
Antw.
6601
Views
Kundeneigene Fleder
von jonas1996 » 16.12.2013 08:53 • Verfasst in ABAP® für Anfänger
3
Antw.
4895
Views
LSMW / Kundeneigene Felder
von tgifch » 12.11.2004 11:26 • Verfasst in ABAP® Core
3
Antw.
6139
Views
kundeneigene Benutzerparameter anlegen
von meddok » 27.02.2006 12:51 • Verfasst in SAP - Allgemeines

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140