Paketbildung im Enterprise Core (SAP-Bibliothek - Werkzeuge der ABAP Workbench)

Paketbildung im Enterprise Core

Von Softwarekomponenten zu Strukturpaketen

Wie hängen Strukturpakete und Softwarekomponenten zusammen ?

Da die bisherigen Softwarekomponenten Pakete zusammenfassen, die stets gemeinsam ausgeliefert werden, bilden sie die Grundlage für die neue Paketarchitektur des R/3 Enterprise. Jede Softwarekomponente wird jeweils mit einem Strukturpaket direkt identifiziert.

Aus den Softwarekomponenten SAP_BASIS, SAP_ABA, SAP_HR und SAP_APPL gehen demzufolge die Strukturpakete BASIS, ABA, HR und APPL hervor.

Bei der Softwarekomponente SAP_APPL besteht darüber hinaus die Notwendigkeit, weitergehend zu unterscheiden und zwei zusätzliche Strukturpakete einzuführen:

Das Strukturpaket APPL_TOOLS enthält Objekte, die auch vom HR verwendet werden.

Die beiden Strukturpakete HR und APPL müssen entkoppelt sein, damit sie mit separaten Support Packages beliefert werden können.

Das Strukturpaket APPL_NU enthält Unicode-Ausnahmen, dh. also ABAP-Klassen, -Programme, Funktionsgruppen etc., die die Syntaxprüfung zur Unicode-Fähigkeit nicht unterstützen.

Die nachfolgende Abbildung veranschaulicht den Zusammenhang zwischen den Softwarekomponenten und den Strukturpakten und fasst noch einmal zusammen, wie Strukturpakete aus bestehenden Softwarekomponenten des R/3 Enterprise Core hervorgehen.

Diese Grafik wird im zugehörigen Text erklärt

Von Hauptpaketen zu Strukturpakten

Warum reichen gewöhnliche Pakete und Hauptpakete nicht aus ?

- Minderung des Organisationsaufwands durch Strukturpakete

Bei großen Softwareprojekten ist im allgemeinen von einer Vielzahl von Hauptpaketen auszugehen. Da die Verwendungsbeziehungen zwischen den einzelnen Hauptpaketen stets explizit definiert werden müssen, kann dies einen hohen Organisationsaufwand zur Folge haben.

Strukturpakete können - als Container für Hauptpakete - zur deutlichen Minderung dieses Aufwands beitragen. Denn Verwendungserklärungen können dann auf der Strukturpaket-Ebene definiert werden. Dies führt zu einer Verringerung der Anzahl der insgesamt benötigten Verwendungserklärungen zwischen Nutzer- und Anbieterpaketen.

- Zusätzliche Möglichkeiten durch Filterschnittstellen

Die besondere Bedeutung der Filter in Strukturpakten sei an einem Beispiel erläutert:

Nehmen wir zunächst an, es handle sich bei den Paketen APPL und HR nicht um Strukturpakete, sondern um Hauptpakete oder um gewöhnliche Pakete. Betrachten wir nun das Objekt O1 aus APPL (siehe Abbildung), welches im Paket P1 enthalten ist und andererseits vom Objekt O2 aus einem anderen Paket P2 verwendet werden soll. Dabei ist P2 ebenfalls Bestandteil von APPL.
Das Objekt O1 wird zunächst nach außen sichtbar gemacht, indem es in die Schnittstelle I1 aufgenommen wird. Dies erlaubt dem Nutzerpaket P2 eine Verwendungserklärung auf die Schnittstelle I1 von P1 anzulegen. In diesem Falle ist aber das Objekt O1 auch für das Paket P3 sichtbar und damit vor Zugriffen aus P3 nicht geschützt. Das Paket P3 gehört aber zu HR und Objekten aus HR sollte es nicht erlaubt sein, APPL-Objekte zu verwenden, sofern eine Entkopplung gewährleistet werden soll.
Genau hier kommen Strukturpakete in Spiel: denn sie erlauben es, sichtbare Objekte aus anderen Strukturpakete auszufiltern. Die Verwendung von Objekten, die unterschiedlichen Strukturpaketen angehören, muß also zunächst auf der Strukturpaket-Ebene geklärt sein.

Diese Grafik wird im zugehörigen Text erklärt

Verwendung von Objekten aus fremden Strukturpaketen

Strukturpakete wurden eingeführt, um im Rahmen des Entwicklungs- und Korrekturprozesses gewisse Regeln für die Verwendung von Objekten aus unterschiedlichen Paketen anzuwenden.
Eines der wesentlichen Ziele dieses Konzeptes ist es, die technische Unabhängigkeit der beiden Softwarekomponenten SAP_HR und SAP_APPL zu gewährleisten. Objekte, die im Strukturpaket HR enthalten sind, dürfen demzufolge keine Objekte verwenden, die dem Strukturpaket APPL angehören.

Initial ist jedes einzelne Strukturpakt vollständig unabhängig von jedem anderen Strukturpaket. Die Verwendung von Objekten aus anderen Strukturpaketen würde in diesem Falle bei einer Paketprüfung zu einem Fehler führen.
Die nachfolgende Tabelle stellt exemplarisch für den R/3 Enterprise Core zusammen, wie die Sichtbarkeit von Objekten in verschiedenen Strukturpaketen realisiert ist und welche Abhängigkeiten untereinander bestehen. Die nachfolgende Tabelle gibt also die konkrete Umsetzung des Strukturpaket-Konzeptes im R/3 Enterprise Core wieder.

Strukturpaket	Sichtbar ...	Darf Objekte verwenden aus ...
BASIS	in allen anderen Paketen	BASIS
ABA	in allen anderen Paketen mit Ausnahme von BASIS	BASIS oder ABA
HR	nur in HR	BASIS, ABA, APPL_TOOLS und HR
APPL	nur in APPL	BASIS, ABA, APPL_TOOLS und APPL
APPL_NU	nur in APPL_NU	BASIS, ABA, APPL_TOOLS, APPL_NU und APPL
APPL_TOOLS	in allen anderen Paketen mit Ausnahme von BASIS und ABA	BASIS, ABA und APPL_TOOLS

Die gegenseitigen Abhängigkeiten der Strukturpakete resultieren aus den Verwendungserklärungen der Nutzer-Strukturpakete auf die Paketschnittstellen der Anbieter-Strukturpakete.

Filter in Strukturpaketen

Bei den Filtern handelt es sich um spezielle Paketschnittstellen, die nur auf der Ebene der Strukturpakete definiert werden. Ein dient dazu, die sichtbaren Elemente, die zu einem Strukturpaket gehören, auf eine bestimmte Menge einzuschränken.

Falls also ein Client-Objekt O1 aus dem Strukturpaket S1 ein Server-Objekt O2 aus einem anderen Strukturpaket S2 verwendet, wird bei einer Paketprüfung geprüft, ob eine Verwendungserklärung von S1 auf die Filter-Paketschnittstelle von S2 vorliegt, in der das Objekt O2 enthalten sein sollte. Ist ein solcher Filter gar nicht erst definiert, dann gibt die Paketprüfung eine Fehlermeldung aus.

Beispiel

Um Objekte aus dem Strukturpaket BASIS innerhalb des Strukturpakets APPL zu nutzen, benötigt APPL eine Verwendungserklärung auf das Filter-Paketschnittstelle _BASIS_FILTER (siehe nachfolgende Tabelle)

Hinweis

Beachten Sie, daß die Existenz einer passenden Verwendungserklärung auf eine Paketschnittstelle daher zwar eine notwendige, jedoch nicht hinreichende Bedingung für eine legale Verwendung eines Server-Objektes aus einem anderen Strukturpaket ist.

Es muß schließlich noch gewährleistet sein, daß der Filter die Verwendung auch „passieren läßt". Es könnte auch vorkommen, daß das verwendete Objekt zwar in einer Schnittstelle des Anbieter-Strukturpakets sichtbar ist und zudem eine passende Verwendungserklärung seitens des Nutzer-Strukturpakets existiert, jedoch der Filter die Verwendung des betreffenden Objekts genau ausschließt.

Strukturpaket	Filterschnittstelle (technischer Name)	Beschreibung
BASIS	_BASIS_FILTER	Filter, der die Objekte von BASIS nach außen passieren läßt.
ABA	_ABA_FILTER	Filter, der die Objekte von ABA nach außen passieren läßt.
HR	_HR_FILTER	Filter, der die Objekte von HR nach außen passieren läßt.
APPL	_APPL_FILTER	Filter, der die Objekte von APPL nach außen passieren läßt.
APPL_NU	-	Keine Filterschnittstelle definiert.
APPL_TOOLS	_APPL_TOOLS_FILTER	Filter, der die Objekte von APPL_TOOLS nach außen passieren läßt.