Verwendung des Operational Data Provisioning Framework von SAP
Drittanbietersoftware mittels OData-Zugriff
In diesem Blogartikel beleuchten wir, welche Vorteile das ODP-Framework für die Datenextraktion bietet, wie es eine deltafähige Datenübertragung ermöglicht und welche verschiedenen SAP-Datenquellen eingebunden werden können. Darüber hinaus wird erklärt, warum die direkte Nutzung von ODP-BAPIs durch Drittanbieter nicht mehr erlaubt ist und wie OData-Zugriffe ab SAP NetWeaver 7.5 als zukunftssichere Alternative eingesetzt werden können.
Das Operational Data Provisioning (ODP) Framework ermöglicht die Extraktion von Daten aus verschiedensten SAP-Quellsystemen. Der große Vorteil in der Verwendung dieses Frameworks besteht u.a. darin, dass die Daten:
- Bereits transformiert und für eine Verwendung im Berichtswesen aufbereitet sind
- Komprimiert übertragen werden
- Aus der Quelle wahlweise komplett oder nur die Änderungen abrufbar sind, sofern das Datenmodell eine Delta-Übertragung unterstützt
- Über ein „Subscriber/Subcription“-Modell für mehrere Zielsysteme mit unterschiedlichen Selektionsbedingungen parallel abgefragt werden können
Für die Datenbereitstellung können verschiedene Quellobjekte genutzt werden. Nachfolgend ein paar Einsatzszenarien, die über das ODP-Framework abgebildet werden können:
- Über sogenannte Extraktoren (DataSources) können die Daten direkt aus den Anwendungstabellen einer SAP Business Suite oder einem SAP S/4HANA abgerufen werden. Neben Eigenentwicklungen, stehen in Form von BI-Content, modulspezifische Extraktoren (SD, MM, FI, CO, …) zur Verfügung, die einen Abruf von Stamm- und Bewegungsdaten ermöglichen.
- Im Kontext von SAP S/4HANA können Daten auch über CDS-Views (Core Data Services) „datenbanknah“ modelliert und über Annotationen in der Datendefinition für die Extraktion durch das ODP-Framework konfiguriert werden. CDS-View meets ABAP – cimt ag | IT-Consulting
- In einem SAP Business Warehouse können Daten aus einem InfoProvider ebenfalls über das ODP-Framework abgerufen werden. Analog zu den anderen Einsatzszenarien ist hierbei ebenfalls ein Datenabruf im Delta möglich.
Die Herausforderung
Da die Programmlogik über verschiedene BAPI von extern steuerbar ist, wurde diese Funktionalität von verschiedenen Herstellern, die SAP-Schnittstellen anbieten, in deren Produkte integriert. Mit der Veröffentlichung des Hinweises 3255746 hat SAP jedoch darauf hingewiesen bzw. präzisiert*, dass eine direkte Verwendung der ODP zugehörigen BAPI nicht zulässig ist und ausschließlich SAP-eigenen Produkten vorbehalten ist.
Als Alternativen werden die Verwendung von SAP Datasphere oder der Zugriff auf das ODP-Framework in Verbindung mit OData empfohlen. Diese Zugriffsmöglichkeit ist vollumfänglich ab Netweaver 7.5 verfügbar und ermöglicht die Verwendung aller über das ODP-Framework nutzbarer Datenquellen (ODP Kontexte). Unter anderem kann auf ABAP CDS-Views, Extraktoren aus SAP ECC oder S/4, Business Warehouse Infoprovider und HANA Calculation Views zugegriffen werden.
(* Diese Aussage findet sich bereits in FAQ für das ODP-Framework, das die SAP im Jahr 2017 veröffentlicht hat.)
Lösungsskizze für die Verwendung des ODP-Frameworks über OData
Nachfolgend wird, unter Berücksichtigung des Hinweises 3255746, ein konformer Zugriff auf das ODP-Framework mit dem ETL-Werkzeug Talend beschrieben. In dem konkreten Szenario soll der Standard-Extraktor für die Übertragung von Kundenstammdaten 0CUSTOMER_ATTR verwendet werden.
Konfiguration SAP
Im Gegensatz zu einer direkten Verwendung mit einem Drittprodukt über RFC, muss für den Zugriff über OData für den Extraktor zunächst in SAP im Gateway Service Builder ein entsprechender Service angelegt werden. Die Konfiguration wird dialoggestützt durchlaufen und die Vorschlagswerte können direkt übernommen werden. Im Ergebnis ist ein Service angelegt, der auf Basis des zugrundeliegenden Extraktors Feldstruktur, Filtermöglichkeiten und die dazugehörigen URLs beinhaltet über die der Datenabruf gesteuert werden kann.
Nach dem Aktivieren des Services kann der Datenabruf über einen API-Tester geprüft werden. Über den Aufruf der Service-URLs wird gesteuert, ob ein der Extraktor die Daten komplett abruft, ein Deltaprozess initialisiert wird, oder ausschließlich Datensatzänderungen übertragen werden. Mit der Initiierung des Deltaprozesses, wird durch das ODP-Framework ein Subscriber und eine Subscription angelegt. Hierüber werden alle weiteren Abrufe gesteuert und protokolliert.
Analog zu der Verwendung der Extraktoren in Verbindung mit einem SAP Business Warehouse, werden alle Abrufe mit Zeitstempel, dem Modus sowie Anzahl und Inhalt der übertragenden Daten in dem ODQ-Monitor (ODQ = Operational Delta Queue) mitprotokoliert.
Im Kern gibt es vier Service-URLs, die alle Optionen zur Abrufsteuerung eines Extraktors über das ODP-Framework abbilden. Über eine Basis-URL erfolgt der Abruf der Daten. Durch die Verwendung von Query- bzw. Header-Parametern kann bestimmt werden, ob ein Komplettabruf der Daten erfolgen, eine Deltaverarbeitung initiiert oder ein Deltaabruf erfolgen soll.
Eine weitere Service-URL erlaubt den erneuten Abruf von Daten eines vorherigen Requests. Die Möglichkeit besteht solange, wie der jeweilige Abruf im ODQ-Monitor protokolliert ist. Üblicherweise ist für die Protokollierung die Ausführung eines ABAP-Reports (ODQ_CLEANUP) eingeplant, der die Protokolle unter Berücksichtigung einer Aufbewahrungsfrist entfernt. Request, die außerhalb der Aufbewahrungsperiode liegen, werden entfernt und können dementsprechend nicht mehr verwendet werden, um einen Datenabruf noch einmal zu wiederholen.
Neben den Services für den Datenabruf, gibt es zwei weitere URLs für die Statusabfrage und das Beenden einer Deltaverarbeitung. Letzteres bedeutet, dass die Subscription beendet wird und darüber keine weiteren Datenabrufe möglich sind.
Initiierung des Deltaprozesses
- Einschränkung der Ausgabestruktur über Query-Parameter, Auswahl der Felder KUNNR, NAME1, LAND1, ORT01, STRAS
- Filter auf Länderschlüssel „DE“
- Start des Deltaprozessen durch Angabe des Header-Parameters mit Wert „odata.track-changes“
- Einstellung der Paketgröße für größere Datenvolumina, Header-Parameter mit Wert „odata.maxpagesize=nnnn“
Abbildung 1: Init-Request/Response API-Tester
- Im ODQ-Monitor wird ein Subscriber/Subscription angelegt und der Abruf unter Berücksichtigung der Selektionsbedingung als Initiierung des Deltaverfahrens protokolliert.
Abbildung 2: Init-Prozess im SAP ODQ-Monitor
- In der Response wird ein Deltatoken bereitgestellt, der die Referenz für den folgenden Abruf verwendet werden muss, um damit alle Datensatzänderungen abfragen zu können.
Abbildung 3: Init-Response mit Deltatoken / Response, API-Tester
Initiierung des Deltaprozesses
- Einschränkung der Ausgabestruktur über Query-Parameter, Auswahl der Felder KUNNR, NAME1, LAND1, ORT01, STRAS
- Filter auf Länderschlüssel „DE“
- Start des Deltaprozessen durch Angabe des Header-Parameters mit Wert „odata.track-changes“
- Einstellung der Paketgröße für größere Datenvolumina, Header-Parameter mit Wert „odata.maxpagesize=nnnn“
Abbildung 1: Init-Request/Response API-Tester
- Im ODQ-Monitor wird ein Subscriber/Subscription angelegt und der Abruf unter Berücksichtigung der Selektionsbedingung als Initiierung des Deltaverfahrens protokolliert.
Abbildung 2: Init-Prozess im SAP ODQ-Monitor
- In der Response wird ein Deltatoken bereitgestellt, der die Referenz für den folgenden Abruf verwendet werden muss, um damit alle Datensatzänderungen abfragen zu können.
Abbildung 3: Init-Response mit Deltatoken / Response, API-Tester
- Weiterer Abruf von Daten über dieselbe Service-URL und denselben Parametern für die Feldstruktur und Filter.
- Wichtig: Der Filter muss mit der verwendeten Konfiguration aus der Initialisierung des Deltaverfahrens übereinstimmen.
- Um Änderungen nach dem Initiierung abzurufen, wird der bereitgestellte Deltatoken aus dem vorherigen Request als Query-Parameter angegeben.
- Für ein Deltaabruf wird ein Kundenstamm im SAP-System geändert (hier: Änderung der Hausnummer von „1a“ auf „221“).
Abbildung 4: Änderung SAP Kundenstamm
- Die Response enthält den geänderten Kundenstamm mit der neuen Hausnummer.
Abbildung 5: Delta-Request/Response mit Deltatoken, API-Tester
- Im ODQ-Monitor wird für den existierenden Subscriber/Subscription ein Delta-Request protokolliert (2. Zeile).
Abbildung 6: Delta-Prozess im SAP ODQ-Monitor
Konfiguration Talend
In Talend kann die zuvor über den API-Tester demonstrierte Logik abgebildet werden. Die Steuerung der Abrufe mit den zur Verfügung stehen Modi (Komplett, Delta-Init, Delta) kann durch die Verwendung von Standardkomponenten implementiert werden. Als Kernkomponenten kommen tRESTClient und tExtractJSONFields zum Einsatz.
Für das Szenario Abruf von Kundenstammdaten sind zwei Talend-Jobs angelegt. Ein Job agiert als Master und steuert der Konfiguration das Basis-URL für den Datenabruf. In Abhängigkeit der verwendeten Kontextparameter, wird die Request-URL aufgebaut, um Daten aus dem Extraktor komplett abzurufen, den Delta-Prozess zu initiieren, oder nur Datensatzänderungen zu verarbeiten.
Abbildung 7: Talend Master-Job
Die erstellten Basis-URL wird dann an den Detail-Job übergeben. Dort erfolgt das Abschicken des Request und das Parsen sowie Auswertung der Response. In der Response gibt es neben JSON-Array mit den Daten, weitere JSON-Elemente mit Steuerinformationen.
Das Element „__next“ beinhaltet die URL auf ein folgendes Datenpaket. Solange dieses JSON-Element ein Bestandteil der Response ist, wird die dort vorhandene URL iterativ für den nächsten Aufruf verwendet. Ist das Element nicht mehr in der Response enthalten, wird die Schleife verlassen und es folgt das Parsten des JSON-Array mit den Daten.
Das Element „__delta“ beinhaltet einen Deltatoken, der für den folgenden Abruf als Query-Parameter verwendet werden muss und dementsprechend weggesichert wird (hier: In Form einer Datei). In Abhängigkeit des gewählten Modi, wird der Deltatoken im Master-Job wieder eingelesen um die Request-URL zu konfigurieren.
Abbildung 8: Talend Detail-Job
Neben dieser einfachen Variante mit der Verwendung von Dateien zum Sichern, können natürlich auch beliebige andere Datenziele verwendet werden.
Weitere Hinweise / Tipps
1. Delta-Init
Für die Verarbeitung größerer Datenmengen, sollte der Umfang für die Initiierung möglichst klein gehalten werden. Die kann dadurch abgebildet werden, dass ein Großteil der Daten zunächst komplett und in Form einzelner Datenscheiben mittels der Definition von Filtern als Query-Parameter abgerufen werden. Dies setzt voraus, dass es Felder gibt, über die die Daten partitionierbar sind.
Besp. Es sollen Belegpositionen einschließlich aus dem Jahr 2020 verarbeitet werden. Anstatt den Deltaprozess ab dem Geschäftsjahr 2020 zu initiieren und damit eine große Datenmenge mit einer hohen Anzahl an Pakten verarbeiten zu müssen, werden die Jahre 2020..2023 als einzelne Komplettabrufe verarbeitet. Der Deltaprozess wird über einen Filter auf das Geschäftsjahr >= 2024 somit auf einer kleineren Datenbasis initiiert.
2. Delta ohne Datenübertragung
Diese Funktionalität ist für die Verwendung des ODP-Frameworks über OData leider nicht Verfügbar (siehe auch SAP Hinweis 3419332)
3. Korrekturen
Sollte sich das SAP-System anders verhalten bzw. Fehler auftreten, prüfen Sie bitte, ob es entsprechende Korrekturhinweise gibt. Folgendes wurde im Rahmen von Kundenprojekten bereits beobachtet:
- Nach der Initiierung eines Deltaprozesses, wird mit dem folgenden Abruf ein neuer Deltaprozess initiiert anstatt nur noch Datensatzänderungen zu übertragen.
- Die Ausführung des ABAP-Reports für das bereinigen der Protokolle (ODQ_CLEANUP) wird als erfolgreich angezeigt, die Requests außerhalb des Aufbewahrungszeitraums werden aber nicht gelöscht und das Log zeigt Fehlermeldungen.
- Protokolle, die auf Basis von OData-Requests, werden nicht gelöscht.
Neugierig geworden?
Interessieren Sie sich für die Verwendung des Operational Data Provisioning Framework von SAP? Dann kommen Sie gerne auf uns zu! Mit unserem breiten Wissen zu SAP-Produkten und Integrationstechnologien können wir mit Ihnen gemeinsam neue Prozesse umsetzen und optimieren.
Jetzt registrieren und keine Veranstaltungen mehr verpassen.
