Zugriff auf ein Delegated Object im BOPF

BOPF ist ein modernes Framework mit dem Anwendungen auf dem ABAP-Stack entwickelt werden können. Ich habe es hier schon vorgestellt. Ein Delegated Object (DO) in BOPF ist eine elegante Möglichkeit, identische Funktionalität an mehreren Geschäftsobjekten zu haben, ohne sie redundant modellieren und entwickeln zu müssen. Der Zugriff auf den Inhalt eines DO über ABAP-Code ist allerdings nicht ganz so offensichtlich. ABAP Kurz-Dumps wie /BOBF/CX_FRW_FATAL sind die Folge, wenn man das scheinbar naheliegenste Vorgehen wählt. In diesem Beitrag möchte ich anhand eines kleinen Beispiels erläutern, wie der Zugriff von statten geht.

Exkurs: Delegation Konzept in BOPF

Bei der Delegation in BOPF werden Teile des Modells und der Funktionalität an ein separates Geschäftsobjekt, ein Delegated Object, delegiert. Dieses Geschäftsobjekt kann dann in zahlreiche andere Geschäftsobjekte eingebunden werden:

BOPF: Host Object und Delegated Object

BOPF verfolgt dabei einen “Black Box”- Ansatz. Das bedeutet, dass zur Designzeit das Host-Objekt nicht die Struktur des Delegated Object kennt und entsprechend in der Modellierungsumgebung auch nicht angezeigt wird. Erst zur Laufzeit werden die Komponenten des Delegated Object in die Struktur des Host-Objekts eingegliedert und verschmelzen somit zu einem Objekt.

Mit BOPF werden direkt ein paar Delegated Objects ausgeliefert, die direkt in die eigenen Geschäftsobjekte integriert und benutzt werden können: Adresse, Textsammlung, Attachment Folder, Geschäftspartner, Change Dokument.

Vorbereitung: Das Beispiel BO

Zur Demonstration der Lösung habe ich mir ein kleines Geschäftsobjekt gebaut:

BOPF: Veranschaulichung am Geschäftsobjekt

Dieses Personen-Geschäftsobjekt besteht lediglich aus einem Root-Knoten unter dem das DO Text-Collection eingebunden ist. In einer Determination auf Root-Ebene möchte ich nun ein paar Daten aus dem Delegated Object auslesen und in transiente Felder des Personen Root-Knoten schreiben.

Die Lösung: Zugriff auf das Delegated Object

Ein Delegated Object ist im Endeffekt nur ein anderes Geschäftsobjekt. Viele BOPF-Entwickler wissen, dass ein BO-übergreifender Zugriff (BO A möchte auf Daten von BO B zugreifen) nur über den Service Manager stattfinden kann. Daher ist ein häufiger erster Ansatz den Service Manager für das Delegated Object zu erzeugen. Allerdings lässt das Framework diese Instanziierung aus gutem Grund nicht zu und geht zur Laufzeit mit einem Kurz-Dump auf die Bretter.

Zur Laufzeit ist der Inhalt des Delegated Objects vollständig in die Struktur des Host-Objekts integriert und dementsprechend erfolgt der Zugriff auf den Inhalt über den Service Manager des Host-Objekts; der Zugriff über io_modify und io_read im Host-Objekt ist allerdings auch möglich. Ein Beispiel für einen solchen Zugriff ist im folgenden Code-Ausschnitt dargestellt:

Zugriff auf das delegated Object

Aber auch bei diesem Ansatz wird die Anwendung zur Laufzeit mit einem Kurz-Dump abbrechen. Zur Laufzeit werden auf Basis des Delegated Objects neue Knoten, Assoziationen, etc. im Host-Objekt erzeugt. Dadurch besitzen diese Elemente einen anderen technischen Schlüssel, als im Konstanten-Interface des DOs angegeben. Die Lösung für dieses Dilemma: Es muss ein Key-Mapping durchgeführt werden. Der Ablauf ist im folgenden Code-Ausschnitt dargestellt:

Beispielcode für Key-Mapping.

Zuerst holen wir uns das Konfigurations-Objekt des Host-Geschäftsobjekts. Dieses bietet eine Methode für das Content-Key-Mapping an. Dort wird eine Content-Kategorie angegeben, also ob wir den technischen Schlüssel eines Knoten, einer Assoziation oder Aktion konvertieren wollen. Des Weiteren geben wir den Schlüssel des zu konvertierenden Modellelements und den Wurzelknoten des Delegated Objects an. Zur Veranschaulichung ein Screenshot:

Notwendige Einstellung, um vom Hostobjekt auf Inhalte des Delegated Objects zuzugreifen.

Wenn man diesen kleinen Schritt bedacht hat, ist es problemlos möglich, vom Hostobjekt aus auf Inhalte des Delegated Objects zuzugreifen. Arbeitet man allerdings intensiv mit Delegated Objects und greift häufig auf verschiedene Inhalte dieser zu, empfiehlt es sich, sich generische Helper-Klassen zu schreiben, die diese Konvertierung übernehmen.

Hat Ihnen dieser Beitrag beim Umgang mit Delegated Objects geholfen? Oder haben sie noch weitere Fragen zu dem Thema, die ich in diesem Beitrag nicht beantwortet habe? Ich freue mich über ihre Kommentare.

Ingo Biermann

Als Management- und Technologieberater unterstütze ich seit mehr als 15 Jahren große und mittelständische Unternehmen in Fragen der IT-Strategie und bin unterwegs in unterschiedlichen SAP-Themen wie SAP S/4HANA, User Experience und SAP Entwicklung.

Sie haben Fragen? Kontaktieren Sie mich!