Inhaltsverzeichnis
Custom Business Objects (CBOs) gehören zu den wichtigsten Erweiterungswerkzeugen in der SAP S/4HANA Cloud. Während der Zugriff in der Regel über OData-Services erfolgt, gibt es darüber hinaus auch weniger bekannte Wege, um CBO-Daten auszulesen. Dieser Beitrag zeigt die gängigen Ansätze – und stellt mit CL_CBO_DEVELOPER_ACCESS eine Alternative vor, die in bestimmten Szenarien eine schlanke und praktische Lösung sein kann.
Was sind CBOs?
Custom Business Objects (CBOs) sind benutzerdefinierte Datenobjekte, die sich in der Cloud über die gleichnamige Fiori-Anwendung erzeugen lassen. Sie stellen eine zentrale Erweiterungsmöglichkeit in der SAP S/4HANA Cloud dar und ermöglichen es, unternehmensspezifische Geschäftsdaten strukturiert abzulegen und in Standardprozesse zu integrieren. Vom Konzept her ähneln sie den Z-Tabellen der On-Premise-Welt, sind jedoch deutlich stärker in die Cloud-Plattform und deren Lifecycle-Management integriert.
Die Standardwege, ein CBO auszulesen
Eigene Entwicklungen können CBO-Daten, abhängig vom jeweiligen Cloud-Deployment-Modell, unterschiedlich nutzen.
Grundsätzlich erfolgt das Auslesen von CBOs über den automatisch generierten OData-Service des jeweiligen Objekts. Dieser Service wird beim Aktivieren des CBO erstellt und kann über einen API-Call angesprochen werden. Damit der Zugriff funktioniert, muss zunächst ein passendes Kommunikationsszenario angelegt werden, das den generierten OData-Service als Inbound-Service enthält.
In der Public Cloud ist der Zugriff auf CBOs ausschließlich über solche APIs bzw. OData-Services möglich. Ein direkter Datenbankzugriff ist nicht erlaubt. In der Private Cloud hingegen können Entwickler die CBO-Daten zusätzlich direkt im ABAP-Coding lesen, z. B. über die generierte Tabelle oder CDS-Views.
In diesem Beitrag zeige ich einen weiteren, weniger bekannten Weg, ein CBO auszulesen: die Nutzung der Klasse CL_CBO_DEVELOPER_ACCESS.
„Weniger bekannt“ bedeutet in diesem Zusammenhang: Zum Zeitpunkt des Verfassens dieses Beitrags liefert selbst eine Suche kaum praktische Beispiele zu dieser Klasse.
Die SAP-Hilfeseite beschreibt zwar die wichtigsten Funktionalitäten, in der praktischen Anwendung gibt es jedoch einige Fallstricke.
Beispielimplementierung mit CL_CBO_DEVELOPER_ACCESS
Nehmen wir an, Sie haben ein Custom Business Object erstellt, in dem Sie zu einem Material Gefahrgutdaten speichern. Das CBO „YY1_GEFAHRGUT_INFO“ enthält das Schlüsselfeld „MATERIAL“ sowie das Feld „DG_CLASS“ für die Gefahrgutklasse. Als Unterknoten werden in „TEXTS“ die sprachabhängigen Texte gepflegt.
Wir implementieren eine Methode GET_DG_DATA mit den Importparametern IV_MATERIAL (Materialnummer) und IV_LANGUAGE (Sprache) sowie den Exportparametern EV_DG_CLASS (Gefahrgutklasse) und EV_TEXT (Beschreibungstext).
Mithilfe der Methode cl_cbo_developer_access=>business_object erzeugen wir zunächst ein Data-Retrieval-Objekt für das gewählte CBO.
Im nächsten Schritt (z. B. in Zeile 9) schränken wir die Abfrage auf die gewünschte Materialnummer ein.
Als Ergebnis der Suche (z. B. in Zeile 14) erhalten wir genau eine Zeile zurück, da es sich bei „MATERIAL“ um das Schlüsselfeld handelt. Um an die tatsächlichen Daten zu gelangen, sind jedoch ein paar Zwischenschritte erforderlich:
Zunächst greifen wir mit ASSIGN data_object->* auf das referenzierte Datenobjekt zu. Anschließend weisen wir mit ASSIGN COMPONENT ... TO STRUCTURE ein konkretes Datenfeld (hier „DG_CLASS“) einem weiteren Feldsymbol zu.
Damit haben wir ausgehend vom Schlüsselfeld ein Datenfeld im CBO ermittelt. Im nächsten Schritt soll zusätzlich ein Eintrag aus dem Unterknoten „TEXTS“ gelesen werden – konkret die Beschreibung in der übergebenen Sprache.
Auch hier erzeugen wir wie zuvor ein Data-Retrieval-Objekt, geben diesmal jedoch den Child-Knoten „TEXTS“ mit an.
Beim Durchsuchen des Unterknotens gibt es allerdings eine Einschränkung:
Die Einträge sind über eine UUID miteinander verknüpft. Im Fall des Unterknotens wird die UUID des übergeordneten Knotens mit ausgegeben, was einen Vergleich ermöglicht. Zum Zeitpunkt der Implementierung war es jedoch nicht möglich, direkt nach dieser UUID zu filtern, da add_field_constraints für dieses Feld keine Ergebnisse liefert. Vermutlich hängt dies mit der speziellen Ausprägung des Datenelements zusammen.
Daher erfolgt an dieser Stelle ein Loop über alle Child-Knoten. Innerhalb des Loops wird die übergeordnete UUID mit der zuvor ermittelten UUID des Materialeintrags verglichen. Aufgrund dieser Einschränkung ist der Einsatz bei sehr großen Datenmengen nur bedingt zu empfehlen.
Einordnung und Fazit
Ob der Einsatz der Klasse CL_CBO_DEVELOPER_ACCESS sinnvoll ist, hängt stark vom Cloud-Deployment und vom konkreten Anwendungsfall ab.
In der SAP S/4HANA Public Cloud kann sie verwendet werden, um Daten eines CBO programmgesteuert auszulesen, ohne einen OData-Service direkt aufzurufen. Das ist besonders praktisch, wenn lediglich Lesezugriffe benötigt werden und die Datenmenge überschaubar bleibt, etwa bei CBOs mit flacher Struktur oder wenigen Unterknoten. In solchen Fällen kann sie das Entwicklerrepertoire sinnvoll ergänzen.
Da die Klasse primär für den internen Zugriff gedacht ist, sollte sie jedoch mit Bedacht eingesetzt werden. Für umfangreiche Datenmodelle oder Szenarien mit systemübergreifender Integration sind die generierten OData-APIs bzw. standardisierte Kommunikationsszenarien in der Regel die robustere und offiziell empfohlene Lösung.
