Hilfe! Pakete und Paketschnittstellen...
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo zusammen!
Vielleicht kann mir mal jemand von euch auf die Sprünge helfen??
Ich habe einen eigenen Namensraum (z.B. /ENNO/ ) mit unterschiedlichen Projekten: ABC, 123, XYZ.
Jedes Projekt soll unterschiedliche Pakete haben z.B. USER, SYSTEM und TEST
Für jedes Projekt lege ich dann ein Paket an mit entsprechenden Unterpaketen:
/ENNO/ABC
-> /ENNO/ABC_USER
-> /ENNO/ABC_SYSTEM
-> /ENNO/ABC_TEST
Dem Paket /ENNO/USER möchte ich Programme für Anwender zuordnen, Paket /ENNO/SYSTEM Systemprogramme usw.
Dann gibt es noch ein Paket /ENNO/ALLGEMEIN. Hierin befinden sich allgemein gültige Objekte, die in allen anderen /ENNO/-Projekten verwendetet werden dürfen.
Nun habe ich dazu folgende Vision:
1.
Ich kann das Programm /ENNO/SYSTEM_SCHUBIDU nur in dem Paket /ENNO/SYSTEM anlegen
2.
In irgendeiner Prüfung (Paketprüfung, Code Inspector) wird gemeckert, sobald in dem Paket /ENNO/ABC Objekte aus anderen /-Objekten verwendet werden.
Ausnahme: /ENNO/SYSTEM
Was ich versucht habe:
zu 1.
Ich habe in der SE03 Administration -> Namenskonventionen anzeigen/ändern? mir den Namensraum /ENNO/ABC reserviert und dem Paket /ENNO/ABC zugeordnet.
Leider wurde meine Erwartung, dass ich das Programm /ENNO/TEST nicht im Paket /ENNO/ABC anlegen kann, nicht erfüllt. Auch eine Paketprüfung oder eine Prüfung mit dem Code Inspector hat keine Meldungen ausgeworfen.
zu 2.
Hier steige ich einfach nicht durch:
http://help.sap.com/saphelp_nw73ehp1/he ... ameset.htm
Da ist die Rede von Schnittstellenpaketen, Strukturpaketen, virtuellen Standard-Paketschnittstellen, Filter-Paketschnittstellen, Anbieterpaket und Verwenderpaket und und und.
Keine Ahnung, wie das alles zusammen hängt.
Ich habe nun immerhin heraus gefunden, dass es sinnvoll ist, /ENNO/ABC als Strukturpaket anzulegen und dann die USER, SYSTEM und TEST-Pakete als Unterpakete zuzuordnen.
Hier kann ich auch /ENNO/ALLGEMEIN als "Existierendes Paket aufnehmen".
Aber wie bilde ich nun die von mir gewünschten Abhängigkeiten ab?
Wäre super, wenn mir da jemand weiter helfen könnte!
Gruß
Enno
Vielleicht kann mir mal jemand von euch auf die Sprünge helfen??
Ich habe einen eigenen Namensraum (z.B. /ENNO/ ) mit unterschiedlichen Projekten: ABC, 123, XYZ.
Jedes Projekt soll unterschiedliche Pakete haben z.B. USER, SYSTEM und TEST
Für jedes Projekt lege ich dann ein Paket an mit entsprechenden Unterpaketen:
/ENNO/ABC
-> /ENNO/ABC_USER
-> /ENNO/ABC_SYSTEM
-> /ENNO/ABC_TEST
Dem Paket /ENNO/USER möchte ich Programme für Anwender zuordnen, Paket /ENNO/SYSTEM Systemprogramme usw.
Dann gibt es noch ein Paket /ENNO/ALLGEMEIN. Hierin befinden sich allgemein gültige Objekte, die in allen anderen /ENNO/-Projekten verwendetet werden dürfen.
Nun habe ich dazu folgende Vision:
1.
Ich kann das Programm /ENNO/SYSTEM_SCHUBIDU nur in dem Paket /ENNO/SYSTEM anlegen
2.
In irgendeiner Prüfung (Paketprüfung, Code Inspector) wird gemeckert, sobald in dem Paket /ENNO/ABC Objekte aus anderen /-Objekten verwendet werden.
Ausnahme: /ENNO/SYSTEM
Was ich versucht habe:
zu 1.
Ich habe in der SE03 Administration -> Namenskonventionen anzeigen/ändern? mir den Namensraum /ENNO/ABC reserviert und dem Paket /ENNO/ABC zugeordnet.
Leider wurde meine Erwartung, dass ich das Programm /ENNO/TEST nicht im Paket /ENNO/ABC anlegen kann, nicht erfüllt. Auch eine Paketprüfung oder eine Prüfung mit dem Code Inspector hat keine Meldungen ausgeworfen.
zu 2.
Hier steige ich einfach nicht durch:
http://help.sap.com/saphelp_nw73ehp1/he ... ameset.htm
Da ist die Rede von Schnittstellenpaketen, Strukturpaketen, virtuellen Standard-Paketschnittstellen, Filter-Paketschnittstellen, Anbieterpaket und Verwenderpaket und und und.
Keine Ahnung, wie das alles zusammen hängt.
Ich habe nun immerhin heraus gefunden, dass es sinnvoll ist, /ENNO/ABC als Strukturpaket anzulegen und dann die USER, SYSTEM und TEST-Pakete als Unterpakete zuzuordnen.
Hier kann ich auch /ENNO/ALLGEMEIN als "Existierendes Paket aufnehmen".
Aber wie bilde ich nun die von mir gewünschten Abhängigkeiten ab?
Wäre super, wenn mir da jemand weiter helfen könnte!
Gruß
Enno
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Tabelle TRESN (oder heißt die Pflegeview dazu V_TRESN?) per SM30 zu pflegen dürfte da helfen.
Da kannst due für jede Objektart einen Namensbeginn eintragen und zuordnen, zu welchem Paket die Objekte gehören müssen.
(Natürlich müssen die Eintragungen pro Objektart überschneidungsfrei sein.
Das prüft der Pflegedialog.)
Außerdem solltest Du für alle Objektarten, die zur Typisierung verwendet werden können (TABL, DTEL, TTYP, VIEW, CLAS, INTF) die gleichen Regeln definieren.
Darauf weist Dich der Pflegedialog auch hin (zumindest für einige Kombinationen von Objektarten).
Da sowohl ENQU als auch VIEW in der DD25L stehen, solltest Du aber auch für ENQU die gleichen Zuordnungen wie für die o.g. Objektarten pflegen. (Darauf weist der Pflegedialog m.E. nicht hin).
D.h., wenn Du für ENQU /ENNO/ESYSTEM verwenden willst, solltest DU auch für VIEW 8usw.) /ENNO/ESYSTEM für das gleiche Paket reservieren, auch wenn Du /ENNO/ESYSTEM gar nicht für VIEW etc. verwenden willst.
Nachteilig ist hier, dass Du zum einen die Zuordnung nur über den Namensbeginn von Objekten treffen kannst.
Außerdem, dass das nur für TADIR-Objekte geht.
Du kannst also in FUGR /ENNO/SYSTEM_ABC_XYZ immer noch einen Funktionsbaustein /ENNO/USER_DEF_VWX_123 anlegen.
(Bei allen anderen Teilobjekten hängt m.E. der Name eines Teilobjekts vom Namen des übergeordneten Objekts ab.)
Des weiteren ist immer ein explizit angegebenes Paket nötig, du kannst also per TRESN nicht sagen, dass der Paketname mit /ENNO/SYSTEM_ beginnen muss, es aber egal ist, welches der Pakete /ENNO/SYSTEM_* zugeordnet wird.
$TMP geht aber immer noch, egal was Du in die TRESN schreibst.
Frank
Da kannst due für jede Objektart einen Namensbeginn eintragen und zuordnen, zu welchem Paket die Objekte gehören müssen.
(Natürlich müssen die Eintragungen pro Objektart überschneidungsfrei sein.
Das prüft der Pflegedialog.)
Außerdem solltest Du für alle Objektarten, die zur Typisierung verwendet werden können (TABL, DTEL, TTYP, VIEW, CLAS, INTF) die gleichen Regeln definieren.
Darauf weist Dich der Pflegedialog auch hin (zumindest für einige Kombinationen von Objektarten).
Da sowohl ENQU als auch VIEW in der DD25L stehen, solltest Du aber auch für ENQU die gleichen Zuordnungen wie für die o.g. Objektarten pflegen. (Darauf weist der Pflegedialog m.E. nicht hin).
D.h., wenn Du für ENQU /ENNO/ESYSTEM verwenden willst, solltest DU auch für VIEW 8usw.) /ENNO/ESYSTEM für das gleiche Paket reservieren, auch wenn Du /ENNO/ESYSTEM gar nicht für VIEW etc. verwenden willst.
Nachteilig ist hier, dass Du zum einen die Zuordnung nur über den Namensbeginn von Objekten treffen kannst.
Außerdem, dass das nur für TADIR-Objekte geht.
Du kannst also in FUGR /ENNO/SYSTEM_ABC_XYZ immer noch einen Funktionsbaustein /ENNO/USER_DEF_VWX_123 anlegen.
(Bei allen anderen Teilobjekten hängt m.E. der Name eines Teilobjekts vom Namen des übergeordneten Objekts ab.)
Des weiteren ist immer ein explizit angegebenes Paket nötig, du kannst also per TRESN nicht sagen, dass der Paketname mit /ENNO/SYSTEM_ beginnen muss, es aber egal ist, welches der Pakete /ENNO/SYSTEM_* zugeordnet wird.
$TMP geht aber immer noch, egal was Du in die TRESN schreibst.
Frank
Hallo Frank,
danke für deine ausführliche Antwort!
Aber:
1. steht hier deutlich geschrieben, dass man die Objekte für reservierten Namensraum nicht mehr einzeln eintragen muss
Namenskonventionen für Entwicklungsnamensräume (mit reserviertem Namensraumpräfix) können Sie objekttypübergreifend (für alle namensraumfähigen Objekttypen) über den neuen Pflege-View CTSRESNAME vornehmen.
2. Habe ich genau das mit der TRESN probiert und einen Eintrag R3TR PROG /AKN/ENNO erzeugt. Ich konnte aber ein Programm /AKN/xyz anlegen... ;(
Kann es sein, dass man da noch irgendwelche Systemparameter setzen muss, damit das greift?
Gruß Enno
danke für deine ausführliche Antwort!
Aber:
1. steht hier deutlich geschrieben, dass man die Objekte für reservierten Namensraum nicht mehr einzeln eintragen muss
Namenskonventionen für Entwicklungsnamensräume (mit reserviertem Namensraumpräfix) können Sie objekttypübergreifend (für alle namensraumfähigen Objekttypen) über den neuen Pflege-View CTSRESNAME vornehmen.
2. Habe ich genau das mit der TRESN probiert und einen Eintrag R3TR PROG /AKN/ENNO erzeugt. Ich konnte aber ein Programm /AKN/xyz anlegen... ;(
Kann es sein, dass man da noch irgendwelche Systemparameter setzen muss, damit das greift?
Gruß Enno
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Jetzt hast Du verraten, dass es gar nicht um den Namensraum /ENNO/ ging 
Als ich mich das letzte Mal mit der Reservierung von Objektnamen für bestimmte Pakete beschäftigt habe (das ist schon eine Weile her), gab es CTSRESNAME noch nicht. TRESN gan es jedoch auch vor 20 Jahren schon.
Aus Deinem ersten Beitrag ging nur hervor, dass Du für Objekte mit bestimmten Namen die Zuordnung zum jeweils passenden Paket willst, nicht dass Du für alle nicht reservierten Namen das Anlegen von Objekten verhindern willst.
Kann an das nicht darüber regeln, dass Du die Beerechtigung für S_DEVELOP nur für bestimmte generische Objektnamen vergibst?
Ansonsten gibt es da auch noch Userexits vor Aufnahme von Objekten in einen Auftrag/eine Aufgabe.
Wenn man da alles verbietet, was man nicht haben will, bleibt eigentlich auch nur noch das Anlegen mit $TMP. (Mal abgesehen davon, dass ein böswilliger Entwickler, der seinen selbst geschriebenen Code im System ausführen darf oder andere User zur Ausführung seines Codes "überreden" kann, praktisch SAP_ALL hat.)
Frank
Als ich mich das letzte Mal mit der Reservierung von Objektnamen für bestimmte Pakete beschäftigt habe (das ist schon eine Weile her), gab es CTSRESNAME noch nicht. TRESN gan es jedoch auch vor 20 Jahren schon.
Aus Deinem ersten Beitrag ging nur hervor, dass Du für Objekte mit bestimmten Namen die Zuordnung zum jeweils passenden Paket willst, nicht dass Du für alle nicht reservierten Namen das Anlegen von Objekten verhindern willst.
Kann an das nicht darüber regeln, dass Du die Beerechtigung für S_DEVELOP nur für bestimmte generische Objektnamen vergibst?
Ansonsten gibt es da auch noch Userexits vor Aufnahme von Objekten in einen Auftrag/eine Aufgabe.
Wenn man da alles verbietet, was man nicht haben will, bleibt eigentlich auch nur noch das Anlegen mit $TMP. (Mal abgesehen davon, dass ein böswilliger Entwickler, der seinen selbst geschriebenen Code im System ausführen darf oder andere User zur Ausführung seines Codes "überreden" kann, praktisch SAP_ALL hat.)
Frank
Zuletzt geändert von Frank Dittrich am 04.02.2014 22:28, insgesamt 1-mal geändert.
Will ich auch nicht. Ich will nur, dass die Zuordnung "Objektname" zu "Paket" gewährleistet ist.Frank Dittrich hat geschrieben:Aus Deinem ersten Beitrag ging nur hervor, dass Du für Objekte mit bestimmten Namen die Zuordnung zum jeweils passenden Paket willst, nicht dass Du für alle nicht reservierten Namen das Anlegen von Objekten verhindern willst.
nein. Ich will ja alle Objekte anlegen können. Nur eben zum richtigen Paket.[/quote]Frank Dittrich hat geschrieben:Kann an das nicht darüber regeln, dass Du die Beerechtigung für S_DEVELOP nur für bestimmte generische Objektnamen vergibst?
Das ist noch ein gute Idee!! das prüfe ich noch mal![/quote]Frank Dittrich hat geschrieben:Ansonsten gibt es da auch noch Userexits vor Aufnahme von Objekten in einen Auftrag/eine Aufgabe.
Ich probiere gerade dem Code Inspector per eigener Prüfroutine beizubringen, dass die Zuordnung Objekt - Paket passen muss. Mal sehen.
Danke und gute Nacht!!
Hallo Enno,
es gibt eine Blog-Serie von Tobias Trapp im SCN die die grundlegenden Konzepte beschreiben.
http://scn.sap.com/blogs/ttrapp/2011/12 ... the-basics
http://scn.sap.com/community/abap/blog/ ... t-packages
http://scn.sap.com/community/abap/blog/ ... d-cohesion
http://scn.sap.com/community/abap/blog/ ... age-checks
Vielleicht hilft Dir das ja weiter.
Viele Grüße,
Tapio
es gibt eine Blog-Serie von Tobias Trapp im SCN die die grundlegenden Konzepte beschreiben.
http://scn.sap.com/blogs/ttrapp/2011/12 ... the-basics
http://scn.sap.com/community/abap/blog/ ... t-packages
http://scn.sap.com/community/abap/blog/ ... d-cohesion
http://scn.sap.com/community/abap/blog/ ... age-checks
Vielleicht hilft Dir das ja weiter.
Viele Grüße,
Tapio
...entwickelnder Berater...beratender Entwickler
Danke, schaue ich mir mal an. Vielleicht ist das einleuchtender als die Doku...
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
1317
Views
Views
Pakete anlegen / auslesen
von Gast » 15.09.2005 15:10 • Verfasst in Material Management & Produktionsplanung
von Gast » 15.09.2005 15:10 • Verfasst in Material Management & Produktionsplanung
2
Antw.
Antw.
279
Views
Views
0
Antw.
Antw.
932
Views
Views
3
Antw.
Antw.
8405
Views
Views
11
Antw.
Antw.
4235
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 16 Stunden von ralf.wenzel 104 / 10185
vor 16 Stunden von ralf.wenzel 104 / 10185
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 16 Stunden von ralf.wenzel 104 / 10185
vor 16 Stunden von ralf.wenzel 104 / 10185