SAP OData V4: Der Schlüssel zur modernen SAP-Integration

Sap Odata V4 revolutioniert die Art und Weise, wie externe Anwendungen mit SAP-Systemen interagieren. Als fortschrittliches Framework ermöglicht es die Entwicklung robuster, sicherer und performanter Services, die den Datenzugriff und die Datenmanipulation vereinfachen. Dieser Artikel taucht tief in die Welt von SAP OData V4 ein und beleuchtet dessen Vorteile, die Erstellung und Registrierung von Services sowie die Implementierung im DPC Extension.

Was ist SAP OData V4?

SAP OData V4 ist ein Standard für die Erstellung von RESTful APIs, der es ermöglicht, Daten und Funktionen aus SAP-Systemen für externe Konsumenten zugänglich zu machen. Im Kern ist ein OData-Service eine Art von API, die SAP bereitstellt. Im Gegensatz zu älteren Versionen ist OData V4 darauf ausgelegt, die Datenmenge zu reduzieren, die Übertragungsgeschwindigkeit zu erhöhen und eine verbesserte Paging-Technik zu bieten. Dies macht es zu einer idealen Wahl für die moderne Anwendungsentwicklung, insbesondere im Hinblick auf die Anbindung von Fiori-Anwendungen oder mobilen Lösungen.

Die Version V4 unterscheidet sich signifikant von früheren Iterationen, wie z.B. OData V2. Diese Unterschiede manifestieren sich in der Art und Weise, wie Services erstellt werden (z.B. über SEGW), in der Implementierung der Datenprovider-Klassen (DPC Ext Methods), in der Codierung, der Service-Registrierung, der URI-Struktur, dem JSON-Format und dem Debugging.

Die Erstellung eines OData V4 Services mit SEGW

Während OData V4 ursprünglich code-basiert implementiert wurde, bietet die Einführung in NW 7.50 die Möglichkeit, Services über den SAP Gateway Service Builder (SEGW) zu erstellen.

1. Neues Projekt in SEGW: Starten Sie die Transaktion SEGW und erstellen Sie ein neues Projekt. Wählen Sie im Projektkontext “OData V4” als Projekttyp aus.

   SAP Gateway Service Builder – Projekt Erstellung

2. Vergleich V4 vs. V2: Ein Blick auf die Benutzeroberfläche von SEGW verdeutlicht die Unterschiede zwischen V4 und V2 bei der Service-Erstellung.

   SAP OData V4 vs V2 Übersicht

3. Entity Types und Properties: Definieren Sie die Datenstrukturen (Entity Types) und deren Eigenschaften (Properties). Diese ähneln Tabellenstrukturen und Feldern in SAP.

   SAP OData V4 Entity Type DefinitionSAP OData V4 Entity Properties

4. Navigation Properties für komplexe Strukturen: Für hierarchische Daten wie Header-Artikel oder Artikel mit Seriennummern definieren Sie Navigation Properties. Diese ermöglichen die Navigation zwischen verschiedenen Entitäten.

   SAP OData V4 Navigation Property Header zu Items

   Hier zeigt die Navigation Property “Items” des Headers auf den Entitätstyp “Item”. Die Markierung “Collection” bedeutet, dass ein Header mehrere Items haben kann. Ähnlich funktioniert die Verknüpfung von Item zu Serialnummer.

5. Entity Sets und Bindings: Definieren Sie Entity Sets, die als Sammlungen von Entitäten fungieren, und erstellen Sie Bindungen zu den zuvor definierten Navigation Properties.

   SAP OData V4 Entity Sets und Bindings

6. Aktivierung und DPC Extension: Aktivieren Sie das Projekt und geben Sie den Namen für die MPC (Model Provider Class) und DPC (Data Provider Class) Extension an.

   Nach der Aktivierung wird ein Service wie ZAPI_GET_PLANTSLOC erstellt.

Registrierung und Veröffentlichung des Services

Die Registrierung und Veröffentlichung eines OData V4 Services erfolgt in zwei Schritten. Bei einer getrennten Gateway- und Backend-Landschaft (z.B. SAP ECC und Fiori) wird der Service im Backend (ECC) registriert und im Gateway (Fiori) veröffentlicht. Bei integrierten Systemen erfolgen beide Schritte im selben System.

Schritt 1: Service registrieren

Nutzen Sie die Transaktion /iwbep/v4_admin (SAP Backend Service Administration) in Ihrem SAP Backend-System.

1. Servicegruppe erstellen: Erstellen Sie eine Servicegruppe, die logisch zusammengehörige Services bündelt. Ein Beispiel wäre ZDIS_TRANSFER_POSTING für alle Transfer-Posting-Prozesse (wie z.B. MIGO) im Distributionsbereich.

   SAP OData V4 Servicegruppe erstellenSAP OData V4 Servicegruppen Übersicht

2. Service zuordnen: Geben Sie den Servicenamen und die MPC/DPC Extension Klassen an. Standardmäßig wird der Service einer Standard-Servicegruppe zugeordnet. Verschieben Sie ihn in die von Ihnen erstellte Servicegruppe.

   SAP OData V4 Service und Klassen ZuordnungSAP OData V4 Service in Servicegruppe verschiebenSAP OData V4 Service erfolgreich Servicegruppe zugeordnet

   Nach diesen Schritten ist der Service registriert.

   SAP OData V4 Service erfolgreich registriert

Schritt 2: Servicegruppe veröffentlichen

Nutzen Sie die Transaktion /iwfnd/v4_admin (SAP Gateway Service Administration) in Ihrem SAP Gateway-System (z.B. Fiori oder ein dediziertes Gateway-System).

1. System Alias konfigurieren: Über die Routing-Konfiguration wird ein System-Alias mit einer RFC-Destination eingerichtet, die die Verbindung zwischen dem SAP Backend und dem Gateway-System herstellt.

2. Servicegruppe veröffentlichen: Klicken Sie auf “Publish Service Group”. Geben Sie den System-Alias (die für das Gateway-System erstellte Alias-Konfiguration) und den Namen Ihrer Servicegruppe an und klicken Sie auf “Get service groups”.

   SAP OData V4 Publish Service Group Dialog

   Der Service und die Gruppe werden erfolgreich in das Gateway-System importiert. Veröffentlichen Sie die Gruppe und sperren Sie die Konfiguration in einem Transportauftrag.

   SAP OData V4 Publish Service Group bestätigt

3. Service testen: Nach der Veröffentlichung können Sie über die Schaltfläche “Metadata” die Metadateninformationen des Services einsehen oder über “Service test” den Service direkt im SAP Gateway testen (z.B. mit /IWFND/GW_CLIENT).

   Metadaten:
   SAP OData V4 Metadaten Ansicht

   Fehlerbehebung bei Virenscan: Falls ein Fehler bezüglich des Virenscans auftritt, navigieren Sie zur Transaktion /IWFND/VIRUS_SCAN, wählen Sie die entsprechende Option für V4 aus und aktivieren Sie sie, um den Virenscan zu umgehen.

   SAP OData V4 Virus Scan FehlerbehebungSAP OData V4 Virus Scan Konfiguration

Implementierung im DPC Extension

Die DPC Extension-Klasse ist der Ort, an dem Sie Ihre Geschäftslogik für den OData-Service implementieren. OData V4 bietet verschiedene Schnittstellen (Interfaces), die von der DPC Extension implementiert werden können:

Der OData-Framework ruft basierend auf der Service-Entitätsstruktur zuerst die entsprechende Methode der Advanced Interface auf. Wenn keine benutzerdefinierte Überschreibung gefunden wird, ruft diese Methode eine Methode der Basic Interface auf. Sie können die Methoden implementieren, um Ihre spezifischen Anforderungen zu erfüllen.

SAP OData V4 DPC Extension Methoden

Import-Parameter in den Interface-Methoden

Jede Interface-Methode verfügt über zwei wichtige Import-Parameter:

• IO_REQUEST: Bietet Zugriff auf Informationen, die zur Bearbeitung der Anfrage benötigt werden.
• IO_RESPONSE: Dient zur Rückgabe von Geschäftsdaten an das SAP Gateway Framework und zur Information des Frameworks, welche Verarbeitungsschritte von der Service-Implementierung selbst gehandhabt wurden.

ToDo- und Done-Listen

Die “ToDo”- und “Done”-Flags informieren das Framework über den Status der Verarbeitung:

• ToDo-Flags: Zeigen an, welche Aktionen von der Implementierung erwartet werden. Wenn beispielsweise ein GET-Aufruf mit filterbaren Werten erfolgt, wird das “Filter”-Flag mit ‘X’ gesetzt.

  SAP OData V4 ToDo Liste Filter

  Bei POST-Aufrufen können die ToDo-Flags variieren und hängen vom Typ der überschriebenen Interface-Methode ab.

  SAP OData V4 ToDo Liste POST

• Done-Flags: Werden am Ende der Verarbeitung gesetzt, um dem OData-Framework mitzuteilen, welche Schritte die Implementierung abgeschlossen hat.

Häufig verwendete Methoden

Hier sind einige gängige und nützliche Methoden, die Sie verwenden können:

Für IO_REQUEST:

• GET_ENTITY_SET: Liest den Namen des Entity Sets, um den Fluss zu validieren und zu steuern.
• GET_FILTER_OSQL_WHERE_CLAUSE: Liest die WHERE-Klausel (hauptsächlich in CDS-Views verwendet).
• GET_FILTER_PROPS_WITH_RANGES: Stellt die im Aufruf übergebenen Filterfelder bereit.
• GET_FILTER_RANGES_FOR_PROP: Liest die Filterwerte.
• GET_KEY_DATA: Liest Schlüsseldaten, falls übergeben (nützlich bei 1-2 filterbaren Feldern in einem GET-Aufruf).
• GET_TODOS: Ruft die ToDo-Flags ab.
• GET_SKIP: Ruft den Skip-Wert ($skip) für die Paging-Funktion ab.
• GET_TOP: Ruft den Top-Wert ($top) für die Paging-Funktion ab.
• GET_BUSI_DATA: Liest die Eingabe-JSON bei POST- oder Create-Aufrufen.

Für IO_RESPONSE:

• SET_BUSI_DATA: Setzt die Geschäftsdaten und aktualisiert die Service-Ausgabe.
• SET_IS_DONE: Setzt die Done-Flags.
• SET_COUNT: Wird verwendet, um die Gesamtzahl der Datensätze zu senden.
• GET_MESSAGE_CONTAINER: Ruft den Message Container für Nachrichten ab, um Fehlermeldungen für das Exception-Objekt zu sammeln. Gibt eine Objektinstanz zum Sammeln der Nachrichten zurück.
• ADD_RUNTIME_STATISTICS: Sendet die Anwendungszeit bei GET-Aufrufen.

Beispiel-Code-Zeilen:

io_request->get_entity_set( IMPORTING ev_entity_set_name = DATA(lv_entity_set_name) ).
io_request->get_todos( IMPORTING es_todo_list = lst_todo_list ).
io_request->get_busi_data( IMPORTING es_busi_data = li_busidata ). " li_busidata ist vom Typ der Entitätsstruktur

" ----- Verarbeitung von li_busidata -----

lst_done_list-busi_data = abap_true.
lst_done_list-deep_busi_data = abap_true. " Wenn eine tiefe Entität existiert (kann To-Do-Liste überprüft werden)

io_response->set_busi_data( EXPORTING is_busi_data = li_busidata ). " Setzt die Service-Ausgabe
io_response->set_is_done( lst_done_list ). " Setzt die Done-Listen-Flags

lo_response_fnl ?= io_response.
lo_response_fnl TYPE REF TO /iwbep/cl_v4_response_info_pro.
lo_response_fnl->finalize( ). " Kann in POST-Aufrufen verwendet werden, um das V4 Response Framework zu informieren.

Ausnahmebehandlung (Exception Handling)

Für die Fehlerbehandlung wird die Ausnahmeklasse /IWBEP/CX_GATEWAY verwendet.

DATA(lo_message) = im_response->get_message_container( ).
lo_message->add_t100(
  EXPORTING
    iv_msg_type   = -type " Message Type
    iv_msg_id     = -id " Message Class
    iv_msg_number = -number " Message Number
).

DATA(lo_exp) = NEW /iwbep/cx_gateway(
  http_status_code = '404' " HTTP-Fehlercode entsprechend der Situation übergeben
  message_container  = lo_message
).
RAISE EXCEPTION lo_exp.

Verfügbare HTTP-Fehlercodes (Public Section der Exception-Klasse /IWBEP/CX_GATEWAY):

Testen von OData V4 über SAP Gateway

Die URI-Struktur für OData V4 unterscheidet sich von OData V2:

V2 Beispiel:
/sap/opu/odata/SAP/zdis_get_po/POHeaderS?$expand=POHeaderToPOItem,POHeaderToReturnMsg&$filter=PoNumber eq '3000000477'&$format=json

V4 Beispiel:
/sap/opu/odata4/sap/zdis_get_master_data/default/sap/zapi_get_plantsloc/0001/PlantStorageLocationDetailsSet?$filter=(Plant eq '1000' or Plant eq '2000') and CompanyCode eq 'CC01'

Im V4-Format muss die Servicegruppe zusammen mit dem Servicenamen in der URI übergeben werden.

V4 JSON-Beispiel (POST):

{
  "PostingDate" : "2019-10-02", // Datumsformat für Typ Edm.Date
  "UserId" : "DUMMY",
  "OrderNumber" : "1234567890",
  "Message" : "",
  "Items" : [
    {
      "ItemNumber" : "0001",
      "ProjectNumber" : "F.01.000289",
      "Plant" : "1000",
      "StogareLocation" : "1100",
      "Material" : "MM18",
      "Quantity" : 1,
      "MovementType" : "101",
      "SpecialStockIndicator" : "Q",
      "Batch" : "",
      "ValuationType" : "",
      "UnitOfMeasure" : "KG",
      "Serials" : [
        {
          "SerialNumber" : ""
        }
      ]
    },
    {
      "ItemNumber" : "0002",
      "ProjectNumber" : "F.01.000289",
      "Plant" : "1000",
      "StogareLocation" : "1100",
      "Material" : "MM19",
      "Quantity" : 1,
      "MovementType" : "301",
      "SpecialStockIndicator" : "",
      "Batch" : "",
      "ValuationType" : "",
      "UnitOfMeasure" : "LB",
      "Serials" : [
        {
          "SerialNumber" : ""
        }
      ]
    }
  ]
}

Debugging von OData V4

Um OData V4-Services zu debuggen, setzen Sie Breakpoints an folgenden Stellen:

• Im SAP Gateway System: Auf der Aufrufseite des Backend-RFC (/IWBEP/CL_V4_REMOTE_PROXY~CALL_BEP).
• Im SAP Backend System: In Ihrer implementierten DPC Extension-Methode (z.B. beim Aufruf des Backend-RFC /IWBEP/FM_V4_HANDLE_REQUEST).

Vorhandene V4-Services suchen

Sie können bestehende V4-Services in Ihrem System über die folgenden Tabellen einsehen:

• /IWBEP/I_V4_MSRV – OData V4 Service Registry
• /IWBEP/I_V4_MSGA – OData V4 Service Group Assignment

Fazit

SAP OData V4 ist ein mächtiges Werkzeug für die moderne SAP-Integration. Es bietet eine effiziente und sichere Methode, um SAP-Daten für externe Anwendungen bereitzustellen. Die Erstellung, Registrierung und Implementierung von OData V4 Services erfordert ein Verständnis der SEGW-Funktionalitäten, der Service-Administrations-Transaktionen und der DPC Extension-Methoden. Durch die Nutzung der fortschrittlichen Funktionen von OData V4 können Unternehmen die Interoperabilität ihrer Systeme verbessern und innovative Lösungen entwickeln. Die Verwendung von Cloud-basierten API-Proxy-Techniken kann zusätzliche Sicherheit durch Authentifizierungsmethoden wie OAuth2 oder SAML SSO bieten und eine Plattform für das Tracing von Datenverkehr und die Überwachung der Service-Performance schaffen.