SAP ODATA-Grundlagen: ODATA-Services anlegen und testen 2026

ODATA ist das Standardprotokoll für den Datenzugriff in SAP. Es gehört zu den SAP ODATA-Grundlagen, neue Services anzulegen und zu testen. Wir zeigen Ihnen, wie Sie diese Aufgaben bewältigen. Mit Fokus auf den neuen Möglichkeiten von 2026.

Das Wichtigste im Überblick

• ODATA als SAP-Standard: HTTP-basiertes REST-Protokoll für Datenaustausch zwischen SAP-Backend und Fiori-Apps, basierend auf Entitätstypen (ähnlich ABAP-Strukturen) und EDM-Datentypen (z. B. Edm.DateTime mit Zeitzone UTC)
• Service-Erstellung: Zwei Hauptmethoden – SEGW-Projekt (manuell, für volle Kontrolle und Schreiboperationen) oder CDS Views mit @OData.publish: true (automatisch ab ABAP 7.50, nur Leseoperationen)
• CRUD-Operationen: 5 Standardmethoden (GET_ENTITYSET, GET_ENTITY, CREATE_ENTITY, UPDATE_ENTITY, DELETE_ENTITY) werden in der DPC_EXT-Klasse implementiert
• Neuerungen: ADT-Integration (Service Definition und Service Binding), SADL (Bündelung mehrerer CDS Views) sowie Zero Copy Connector (vereinfachte Bereitstellung von OData-Services).
• Best Practices: DPC_EXT (nicht DPC) nutzen, Boolean-Felder auf Edm.Boolean mappen, Datumsfelder im Frontend korrigieren (Zeitzone UTC → lokal), Nullwerte für optionale Felder erlauben

Was ist ODATA?

Das Open Data Protocol (ODATA) ist ein von Microsoft definiertes HTTP-basiertes Protokoll für den Datenzugriff zwischen kompatiblen Softwaresystemen. Im SAP-Umfeld ist Open DATA die Schnittstellentechnologie, um die Verbindung vom SAP-System zu den Fiori-Anwendungen im Browser herzustellen.

Mehr zu ODATA im Überblick mit allen Beiträgen gibt es hier.

OData-Service in SAP anlegen

SEGW-Projekt erstellen

1. Transaktion aufrufen:

Starten Sie die Transaktion SEGW (Gateway Service Builder).

2.Projekt anlegen:

• Name: Verwenden Sie die SAP-Namenkonvention, z. B. ZODATA_DEMO_SRV (Z + Präfix + _SRV).
• Beschreibung: Geben Sie eine kurze Erklärung ein (z. B. “OData-Service für Personendaten”).
• Paket: Wählen Sie ein Entwicklungspaket (z. B. $TMP für Testzwecke).

3.Struktur:
Nach dem Anlegen werden automatisch 4 Ordner generiert:

• Data Model (Entitätstypen, Assoziationen)
• Laufzeitartefakte (ABAP-Klassen: DPC, DPC_EXT, MPC)
• Service Implementation (Methoden)
• Metadata

Entitätstypen definieren

Es gibt zwei Optionen, um Entitätstypen anzulegen:

Option A: Manuelle Erstellung

• Rechtsklick auf Data Model → Neuer Entitätstyp.
• Felder manuell hinzufügen und mit ABAP-Typen mappen.

Option B: Import aus ABAP-Struktur (empfohlen)

1. ABAP-Struktur in SE11 anlegen:
Erstellen Sie eine Struktur, die Ihre Daten abbildet. Beispiel:

2. In SEGW importieren:

• Rechtsklick auf Data Model → Import → ABAP Dictionary Structure.
• Wählen Sie die Struktur ZPERSON aus.
• Übernehmen Sie die Felder und legen Sie den Schlüssel fest (z. B. PERNR).

Laufzeitobjekte generieren

1. EDM-Typen prüfen und anpassen:

• ABAP-Typen werden automatisch auf EDM-Typen gemappt.

Wichtige Anpassungen:

• ABAP_BOOLEAN (Char1) → manuell auf Edm.Boolean ändern (vermeidet Frontend-Mapping).
• Datumsfelder (D) → Edm.DateTime (Zeitzonenproblem beachten, siehe EDM-Datentypen verstehen).

2. Laufzeitobjekte generieren:

• Klicken Sie auf den Button „Laufzeitobjekte generieren“.
• Das System prüft die Konsistenz und erzeugt die ABAP-Klassen (DPC, DPC_EXT, MPC).

Entitätstypen in SEGW anlegen

ABAP-Struktur aus dem Dictionary importieren

1. Struktur vorbereiten (z. B. ZPERSON in SE11).

2. In SEGW importieren:

• Rechtsklick auf Data Model → Import → ABAP Dictionary Structure.
• Wählen Sie die Struktur ZPERSON aus.
• Übernehmen Sie die Felder.

 

Schlüssel für die Entität festlegen

• Wichtig: Der Schlüssel muss eindeutig sein.
• Empfehlung: Verwenden Sie so wenige Felder wie möglich (z. B. nur PERNR für eine Person).

Vorgehen:

• Wählen Sie im Import-Assistenten das Feld aus, das als Schlüssel dienen soll (z. B. PERNR).
• Bestätigen Sie die Auswahl.

Ihren ersten Entitätstypen haben Sie hiermit bereits angelegt. Er sollte nun im Ordner „Data Model“ unter „Entitätstypen“ sichtbar sein. Unter Ihrem Entitätstypen sehen Sie nun Eigenschaften und Navigationseigenschaften. Für diesen Fall sind erst einmal die Eigenschaften interessant: Mit einem Doppelklick können Sie sich ansehen, welche Felder mit welchen EDM-Typen Sie im Entitätstypen haben, welche Eigenschaften dazu gehören und zu welchem Feld Ihrer Struktur diese gemapped sind. Das Mapping von ABAP-Datentyp zu EDM-Typ wurde beim Erstellen automatisch vorgenommen.

EDM-Typen

Wie Sie sehen können, weichen die EDM-Typen etwas von den ABAP-Typen ab. Mit F4 (Suchhilfe) auf eines der EDM-Coretyp-Felder können Sie sich alle vorhandenen EDM-Typen anzeigen lassen:

In sehr vielen Fällen wird der ABAP-Datentyp auf den Edm.String-Typ abgebildet. Häufig passt das auch gut für die Datenübertragung. Allerdings habe ich festgestellt, dass zum Beispiel der ABAP Boolean als Char1 auch als String und nicht als Edm.Boolean abgebildet wird. Das korrigiere ich immer nachträglich. Ansonsten benötigen Sie ein zusätzliches Mapping sowohl im Frontend als auch im Backend, um mit dem Feld weiterarbeiten zu können.

Auch bei der Übertragung von Daten sollten Sie aufpassen: Im klassischen OData-V2-Umfeld, das unter anderem von SEGW verwendet wird, kommen für Datumsfelder in der Regel Edm.DateTime-Eigenschaften zum Einsatz. Neben dem eigentlichen Datum werden dabei auch eine Uhrzeit sowie Zeitzoneninformationen übertragen.

Wird ein ABAP-Datumsfeld (Typ D) aus dem Backend übertragen, ergänzt die OData-Laufzeit die fehlenden Zeitinformationen automatisch, typischerweise mit der Uhrzeit 00:00:00 und einer Zeitzonenangabe. Im Frontend sollten Datumswerte daher entsprechend verarbeitet und in das gewünschte Anzeigeformat umgewandelt werden.

Bei Schreiboperationen (Frontend → Backend) können Zeitzonenunterschiede dazu führen, dass sich das Datum um einen Tag verschiebt. Um solche Effekte zu vermeiden, sollten Datumswerte bereits im Frontend in das erwartete OData-Format konvertiert und unter Berücksichtigung der Zeitzone übergeben werden.

Achten Sie außerdem darauf, für optionale Eigenschaften die Einstellung „Nullwerte möglich“ zu aktivieren. Andernfalls erwartet der OData-Service bei CREATE- und UPDATE-Operationen zwingend einen Wert für das jeweilige Feld.

Nachdem alle Eigenschaften korrigiert sind, klicken Sie oben auf den Button „Laufzeitobjekte generieren“. Dieser prüft das Projekt auf Konsistenz und erzeugt die für die Datenübertragung benötigten Klassen mit den entsprechenden Schnittstellen:

OData-Service registrieren

Registrierung über /IWFND/MAINT_SERVICE

1. Gateway-System aufrufen:

Melden Sie sich am Gateway-System an (z. B. S4H_100).

2. Transaktion starten:

Rufen Sie die Transaktion /n/IWFND/MAINT_SERVICE auf.

3. Service hinzufügen:

• Klicken Sie auf „Service hinzufügen“.
• Wählen Sie das Backend-System aus, auf dem der OData-Service implementiert wurde.
  Falls Ihr System nicht in der Suchhilfe erscheint, sind noch Konfigurationen am System nötig.
• Suchen Sie Ihren Service (z. B. ZODATA_DEMO_SRV) und fügen Sie ihn hinzu.
• Wählen Sie ein Entwicklungspaket (z. B. $TMP).

 

4. Service ist registriert

Sollte Ihr System nicht in der Suchhilfe zu finden sein, sind noch Konfigurationen am System notwendig. Darauf werde ich in diesem Tutorial nicht näher eingehen. Nachdem Sie Ihr System ausgewählt haben, suchen Sie in der Liste Ihren Service und fügen diesen dann hinzu. Im folgenden Fenster spezifizieren Sie noch das Entwicklungspaket. Schon ist der Service erfolgreich registriert:

Besonderheiten bei CDS-basierten Services

CDS Views mit @OData.publish: true:

• Der Service wird automatisch generiert, muss aber trotzdem in /IWFND/MAINT_SERVICE registriert werden.
• Name: <CDS_View_Name>_CDS (z. B. ZCDS_PERSON_CDS).

SADL (Service Adaptation Definition Language):

• Ermöglicht die Einbindung von CDS Views in SEGW-Projekte und bietet:
• Benutzerdefinierte Servicenamen (nicht nur <CDS_View>_CDS).
• Bündelung mehrerer CDS Views in einem Service.

Neuerungen ab 2025 und 2026:

• Für S/4HANA Cloud: Service Definition/Binding kann direkt in ADT (ab ABAP Platform 7.54) erstellt werden – keine manuelle Registrierung in /IWFND/MAINT_SERVICE nötig.
• Für ERP-Systeme (z. B. ECC): Zero Copy Connector ermöglicht die automatische Exponierung von OData-Services ohne manuelle Registrierung im Gateway.
• Hinweis: Bei Verwendung von @OData.publish: true in CDS Views wird der Service automatisch generiert, muss aber trotzdem in /IWFND/MAINT_SERVICE registriert werden (Name: CDS_View_Name_CDS).

ODATA Services – Die 5 Standard-Methoden

Sie haben jetzt Ihren Entitätstypen angelegt und die Eigenschaften der Felder entsprechend Ihrer Wünsche angepasst. Nun wird es Zeit, die Datenübertragung zu ermöglichen. Dafür gibt es fünf Standard-Methoden. Im Folgenden werde ich alle 5 Methoden anhand unseres Beispiels besprechen und die Implementierung erklären. Achtung: Bei CDS Views mit @OData.publish: true werden die Leseoperationen (GET_ENTITYSET, GET_ENTITY) automatisch über SADL bereitgestellt. Für Schreiboperationen (CREATE_ENTITY, UPDATE_ENTITY, DELETE_ENTITY) ist ein SEGW-Projekt mit Referenz auf die CDS View erforderlich, um benutzerdefinierte Logik zu implementieren.

Dafür doppelklicken Sie auf den Ordner „Laufzeitartefakte“ im ODATA-Projekt (auf dem Backend-System) und öffnen die ABAP-Klasse, welche auf „DPC_EXT“ endet. Ganz wichtig ist hierbei, dass Sie diese Klasse nehmen.

In der Klasse, welche auf „DPC“ endet, finden Sie dieselben Methoden. Ihre Änderungen werden hier aber jedes Mal komplett überschrieben, wenn Sie die Laufzeitobjekte nach einer Änderung am Datenmodell neu generieren. Die „DPC_EXT“-Klasse ist eine Erweiterung der „DPC“-Klasse. Daher haben Sie hier die Möglichkeit, alle geerbten Methoden zu redefinieren.

Die fünf Service-Methoden werden aus der Klasse …_DPC geerbt und werden entsprechend in der Methoden-Übersicht der Klasse aufgeführt:

GET_ENTITYSET

GET_ENTITYSET liefert eine Menge von Entitäten zurück. Dies wird zum Beispiel häufig verwendet, um eine Liste von Elementen zu befüllen. In unserem Fall der SplitApp verwenden Sie den Service dafür, die Masterliste auf der linken Seite des Bildschirms zu befüllen. Hierfür rufen Sie den Service aus dem Frontend ohne Filter auf und steuern im Backend, welcher Benutzer welche Personen sehen soll.

Nachdem Sie in den Änderungsmodus gewechselt sind, können Sie die Methode GET_ENTITYSET für Ihren Entitätstypen redefinieren. Dadurch legen Sie in der Klasse DPC_EXT eine eigene Implementierung zu der geerbten Methode an:

Innerhalb dieser Methode können Sie nun die vom Frontend übergebenen Filter auslesen, die Anfragen im Backend verarbeiten und die Ergebnisse wieder in die Schnittstelle füllen.

Da in diesem Fall kein Filter benötigt wird, sparen Sie sich das an dieser Stelle. Aber keine Sorge, auf die Filter werde ich in den nächsten Services noch eingehen. Für die Methode GET_ENTITYSET steht die Tabelle et_entityset als Container für die Ergebnisdaten zur Verfügung. Diese müssen Sie also in dieser Methode befüllen.

Ich habe mir eine eigene Klasse für den Entitätstypen angelegt, die ich zum Befüllen der Schnittstelle verwenden werde. Theoretisch können Sie den Quellcode einfach in der Methode GET_ENTITYSET implementieren, aus meiner Sicht ist eine Trennung an dieser Stelle allerdings sauberer.

Die Tabelle et_entityset basiert auf dem Entitätstypen, der wiederum auf unserer ursprünglich angelegten Struktur basiert. Sie können also einfach einen Tabellentyp dieser Struktur als Rückgabe für diese Methode wählen und das et_entityset somit direkt befüllen. Sollten Sie nicht alle Felder aus der Struktur übernommen haben oder weitere Felder zum Entitätstypen hinzugefügt haben, wäre an dieser Stelle noch ein Mapping notwendig.

Ihre erste Service-Implementierung ist nun fertig gestellt. Aber funktioniert das auch alles so, wie Sie sich das vorstellen? Sie wollen Ihren neuen Service natürlich direkt testen, bevor Sie das Frontend dazu fertig gestellt haben. Hierfür loggen Sie sich wieder im Gateway-System ein und starten die Transaktion /n/iwfnd/maint_service.

Hier haben Sie die Möglichkeit, den Service über den SAP Gateway Client zu testen:

Hier ist automatisch die HTTP-Methode „GET“ und die zu unserem ODATA-Service passende Request-URI voreingestellt. Den ersten Test starten Sie, indem Sie die hinterlegten Einstellungen ausführen. Hat bis hierhin alles gut funktioniert, sollten Sie den Status Code 200 OK in einem grün hinterlegten Fenster sehen. Zusätzlich steht im Fenster rechts unten die Antwort, die alle von uns hinterlegten Entitätstypen enthält:

Sollte das bei Ihnen nicht funktioniert haben, probieren Sie die Transaktion /n/iwfnd/error_log aus. Hier finden Sie meist hilfreiche Debugging-Informationen, wenn ODATA-Aufrufe fehlgeschlagen sind.

Um die gerade implementierte Methode GET_ENTITYSET zu testen, müssen Sie lediglich die URL hinter dem _SRV ändern. Hier tragen Sie einfach das Set des eben von Ihnen erstellten Entitätstypen ein: PersonSet

Sie bekommen nun für jede Person, die Ihre Methode GET_ENTITYSET zurückliefert, einen Eintrag:

Falls Sie hierbei nicht den Code 200, sondern einen Fehler bekommen, empfehle ich zwei Möglichkeiten zum Debugging: Sie können direkt am Anfang der Methode GET_ENTITYSET einen externen Breakpoint setzen. Sollten Sie erst gar nicht bis dahin kommen, hilft wieder die Transaktion /n/iwfnd/error_log auf dem Gateway System. Sobald bei Ihnen auch der grüne Statuscode und die richtigen Personen im Ergebnis stehen, haben Sie es geschafft: Ihr GET_ENTITYSET funktioniert!

GET_ENTITY

GET_ENTITY liefert als Ergebnis eine einzelne Entity statt einer Ergebnismenge. Bei diesem Service muss der eindeutige Schlüssel mitgegeben werden, um die Entity zu identifizieren. Um die Methode zu implementieren, redefinieren Sie die Methode GET_ENTITY aus Ihrer DPC_EXT Klasse analog zum vorigen Vorgehen.

Innerhalb der Methode müssen Sie zuerst die mitgegebene ID auslesen. Die regulär übergebene ID ist in der Tabelle IT_KEYTAB als Key-Value-Pair zu finden. Der Schlüssel ist hierbei die Bezeichnung des jeweiligen Attributs – in diesem Fall „PERNR“, da Sie dies als Schlüssel Ihres Entitätstypen definiert haben. Der entsprechende Wert dazu steht dann im “Value” Attribut des Tabelleneintrages. Ich lese die PERNR in diesem Fall wie folgt aus:

Die Ergebnismenge aus dem Backend wird am Ende in den Export-Parameter er_entity geschrieben. Hierbei handelt es sich um eine Struktur vom Typ des ODATA-Entitätstypen. Für die Backend-Logik liegt es an Ihnen, den passenden Personensatz zur übergebenen Personalnummer aufzubereiten.

Zum Testen der Implementierung gehe ich wieder in den SAP Gateway Client auf meinem Gateway-System und passe die URL etwas an, sodass ich die entsprechende URL zu meinem Personenset übergebe: /sap/opu/odata/sap/ZFTENT_HOWTO_ODATA_SRV/PersonSet(‘12345678’).

Wenn alles fehlerfrei ist, bekomme ich den grünen Code 200 zurück und in dem XML-Dokument die Details zu meiner Person:

CREATE_ENTITY

CREATE_ENTITY soll einen neuen Datensatz im Backend anlegen. Dafür müssen vom Frontend alle relevanten Eigenschaften mitgegeben werden. Um die Logik zu implementieren, redefinieren Sie die Methode CREATE_ENTITY der DPC_EXT Klasse analog zu den vorigen Malen.

In der Methode suchen Sie diesmal nicht nach einem Key, sondern nach allen relevanten Informationen, um den neuen Datensatz anzulegen. Dafür wird Ihnen das Objekt io_data_provider mitgeliefert. Mit der Methode read_entry_data() bekommen Sie alle vom Frontend übergebenen Daten zurück.

Für den Export-Parameter er_entity müssen Sie eine Struktur vom Typ des ODATA-Entitätstypen mitgeben. Die ausgelesenen Daten können Sie nun im Backend verwenden, um einen entsprechenden Datensatz zu erstellen. Wichtig hierbei ist, dass Sie den Export-Parameter er_entity vor Ende der Methode befüllen, da ansonsten der HTTP-Fehlercode 500 zurückgegeben wird. Normalerweise werden einige Eigenschaften im Backend generiert und können nach Erstellung dann an das Frontend zurückgegeben werden. Da dies bei mir nicht der Fall ist, übergebe ich einfach dieselben Daten wieder zurück:

Zum Testen müssen Sie dementsprechend Informationen für den zu erstellenden Backend-Datensatz mitgeben. Im Gateway-Client können Sie sich dafür einfach behelfen: Verwenden Sie erst den vorhin beschriebenen GET_ENTITY-Aufruf, um einen Datensatz im rechten XML-Ergebnisfeld zu haben. Dann können Sie einfach rechts oben in der Leiste auf „Als Anf. verwenden“ anklicken, um die XML-Struktur im linken Feld zu sehen:

In der XML-Struktur auf der linken Seite löschen Sie nun alles zwischen dem <entry>- und dem <content>-Tag. Jetzt sollte der verbleibende Teil etwa so aussehen:

Den verbliebenen Datensatz können Sie anpassen, sodass er Ihrem neu einzufügenden Satz entspricht. Nun müssen Sie nur noch die HTTP-Methode auf „POST“ stellen und dieselbe URL wie schon für den Test vom GET_ENTITYSET verwenden: /sap/opu/odata/sap/ZFTENT_HOWTO_ODATA_SRV/PersonSet

Wenn alles funktioniert hat, sollten Sie jetzt den grünen HTTP-Statuscode 201 – Created sehen und den zurückgelieferten Datensatz im Ergebnis auf der rechten Seite:

UPDATE_ENTITY

Für die UPDATE_ENTITY-Methode übergeben Sie sowohl einen Schlüssel zur Identifizierung des Datensatzes als auch jede Menge Attribute für das Update. Dafür lesen Sie die it_keytab analog zur GET_ENTITY Methode aus und die übergebenen Daten analog zu CREATE_ENTITY. Nach welchem Schema Sie das Update nun in Ihrem Backend durchführen, ist Ihnen überlassen. Falls Sie sich das Auslesen aus der Keytab an dieser Stelle sparen wollen, finden Sie den Schlüssel auch in den ausgelesenen Attributen Ihrer Entität.

Sie könnten nun auch analog zu vorigen Methoden Rückmeldung zum Erfolg der Methode geben, aber auch ohne einen Rückgabewert zu befüllen, läuft der erfolgreiche HTTP-Request auf eine grüne 204:

Zum Testen im Gateway-Client habe ich mir analog zu CREATE_ENTITY einen Datensatz vorbereitet, die HTTP-Methode auf „Put“ gestellt und in der URL wieder eine ID mitgeliefert:

DELETE_ENTITY

Die letzte Methode im ODATA-Service, die wir redefinieren können, befasst sich mit dem Löschen eines Datensatzes. Hierfür müssen Sie lediglich eine ID übergeben. Das Vorgehen in der DELETE_ENTITY-Methode ist daher wieder ein Auslesen der it_keytab analog zu GET_ENTITY. Bei Bedarf können Sie auch hier wieder Informationen über den gelöschten Datensatz ans Frontend übergeben, andernfalls kommen Sie analog zum Update auf den HTTP-Code 204:

Zum Testen im Gateway-Client setzen Sie die HTTP-Methode auf „Delete“ und wählen die URL mit ID analog zu GET_ENTITY:

Nun haben Sie alle fünf grundlegenden OData-Methoden kennen gelernt, für unser Beispiel implementiert und im Gateway-Client getestet.

Warum DPC_EXT statt DPC?

Es stellt sich noch eine wichtige Frage: Warum wurden alle Anpassungen in der DPC_EXT-Klasse vorgenommen und nicht direkt in der DPC-Klasse?

DPC-Klasse:

• Wird bei Neugenerierung der Laufzeitobjekte überschrieben → alle Änderungen gehen verloren.

DPC_EXT-Klasse:

• Erweiterungsklasse der DPC-Klasse.
• Änderungen bleiben dauerhaft erhalten, auch nach Neugenerierung der Laufzeitobjekte.

O-Data-Services für CDS Views

Damit haben Sie den klassischen Weg kennengelernt, OData-Services mit dem SAP Gateway Service Builder (SEGW) zu erstellen und zu implementieren. In modernen SAP-Systemen steht jedoch mit CDS Views eine deutlich schlankere Alternative zur Verfügung: Sie können OData-Services direkt aus CDS Views generieren.

Hierfür verwenden wir in CDS Views die Annotation @OData.publish: true. Dadurch wird automatisiert ein OData-Service für die entsprechende CDS View generiert. Diesen Service müssen wir, wie oben beschrieben, nach der Erstellung einmalig über die Transaktion /n/iwfnd/maint_service mit dem Button „Service hinzufügen“ registrieren.

Der generierte Service trägt dabei denselben Namen wie die CDS View, ergänzt um den Zusatz „_CDS“. Den so angelegten Service kann man entweder direkt in Eclipse oder wie zuvor beschrieben über den Gateway-Client in der Transaktion /n/iwfnd/maint_service testen.

Soll ein Service mehrere CDS Views umfassen, können wir wie oben beschrieben in der SEGW einen OData-Service anlegen. Hierbei nutzen wir nun SADL (Service Adaptation Definition Language), was die Einbindung der entsprechenden Entitäten erheblich erleichtert.

Dieser Ansatz ermöglicht es uns außerdem, den Namen unseres OData-Services frei zu wählen, was über die Annotation direkt in der CDS View nicht möglich ist. Um SADL in unserem erstellten Service zu nutzen, klicken wir in der SEGW mit der rechten Maustaste auf unser Data Model und wählen unter Referenz die Option Datenquelle aus:

Hier können wir dann unsere CDS-Entität als Datenquelle hinterlegen und entscheiden, welche Elemente wir übernehmen möchten. Nach der Erstellung finden wir unter den Datenquellenreferenzen im Abschnitt „Exposures via SADL“ unsere CDS-Entity:

Im Anschluss daran folgen dieselben Schritte wie oben: Wir generieren die Laufzeitobjekte und fügen den Service entsprechend über die Transaktion /n/iwfnd/maint_service hinzu.

Was ist der aktuelle Stand von SAP OData 2026? 

SAP entwickelt die OData-Integration kontinuierlich weiter. Der Fokus liegt dabei auf einer vereinfachten Bereitstellung und Administration von OData-Services, vor allem im Umfeld von cloudbasiertem S/4HANA.   

Service Definition und Service Binding in ADT

Für CDS-basierte OData-Services können Service Definition und Service Binding mittlerweile direkt in den ABAP Development Tools (ADT) erstellt werden. Dadurch entfällt in vielen Szenarien die Entwicklung über den SAP Gateway Service Builder (SEGW). Dieser Ansatz ist in S/4HANA Cloud der empfohlene Weg.  

SADL für flexiblere OData-Services

Mit der Service Adaptation Definition Language (SADL) lassen sich CDS Views komfortabel als OData-Service bereitstellen. Gleichzeitig können mehrere CDS Views in einem gemeinsamen Service zusammengefasst und individuelle Servicenamen vergeben werden – Möglichkeiten, die mit @OData.publish: true allein nicht zur Verfügung stehen.  

Zero Copy Connector

In unterstützten ERP-Systemen ermöglicht der Zero Copy Connector die Bereitstellung von OData-Services ohne die klassische Gateway-Registrierung und reduziert dadurch den administrativen Aufwand. 

Best Practices für OData-Services 

Unabhängig davon, ob Sie OData-Services über SEGW oder auf Basis von CDS Views erstellen, haben sich einige Best Practices bewährt. Sie erleichtern die Entwicklung, vermeiden häufige Fehlerquellen und sorgen für eine bessere Wartbarkeit Ihrer Services. 

DPC_EXT statt DPC verwenden 

• Immer die DPC_EXT-Klasse für benutzerdefinierte Implementierungen verwenden. 
• Begründung: Änderungen in der DPC-Klasse gehen bei Neugenerierung der Laufzeitobjekte verloren. 

Schlüssel möglichst einfach halten 

• Verwenden Sie so wenige Felder wie möglich für den Schlüssel (z. B. nur PERNR statt PERNR + NAME). 
• Begründung: Vereinfacht die Identifikation von Entitäten und reduziert Komplexität. 

Boolean-Felder korrekt mappen 

• ABAP_BOOLEAN (Char1) → Edm.Boolean (nicht Edm.String). 
• Begründung:  
• Vermeidet zusätzliches Mapping im Frontend und Backend. 
• Ermöglicht direkte Verwendung in SAPUI5 (z. B. in Checkboxen). 

Datums- und Zeitzonenprobleme vermeiden 

• Problem: 
• Edm.DateTime überträgt Datum + Uhrzeit + Zeitzone (UTC). 
• Backend → Frontend: ABAP-Datum (z. B. SY-DATUM) wird zu Edm.DateTime mit 00:00:00 UTC konvertiert. 
• Frontend → Backend: Ohne Korrektur kann es zu Tagesverschiebungen kommen. 
• Lösung: 
• Frontend: Datum parsen und Zeitzone korrigieren (z. B. in SAPUI5 mit sap.ui.core.format.DateFormat). 
• Backend: Zeitzone vor dem Senden anpassen. 

Nullwerte richtig behandeln 

• Haken bei „Nullwerte möglich“ setzen für optionale Felder. 
• Begründung:  
• Ohne diesen Haken müssen immer Werte für das Feld übermittelt werden. 
• Vermeidet Fehler bei CREATE_ENTITY/UPDATE_ENTITY. 

Fazit 

Jetzt haben Sie gelernt, wie Sie OData-Services in SAP erstellen, implementieren, registrieren und testen. Neben der klassischen Entwicklung mit SEGW kennen Sie nun auch die Möglichkeiten CDS-basierter OData-Services und sind über wichtige Best Practices für eine wartbare und zukunftssichere Umsetzung im Bild.  

Wenn Ihnen der Artikel gefallen hat, schauen Sie doch gerne bei unserer ODATA-Grundlagenreihe vorbei! 

SAPUI5: OData-Grundlagen in der praktischen Verwendung 

Dieser Beitrag erschien bereits 2021. Der Artikel wurde am 28.07.2026 erneut geprüft und mit leichten Anpassungen aktualisiert.

FAQ

Was ist OData in SAP?

OData ist ein HTTP-basiertes Protokoll für den Datenaustausch zwischen SAP-Backend-Systemen und Frontend-Anwendungen wie SAP Fiori oder SAPUI5. Es ermöglicht das Lesen, Anlegen, Ändern und Löschen von Daten über standardisierte Schnittstellen.

Wie legt man einen OData-Service in SAP an?

Ein OData-Service kann klassisch über SEGW oder modern über CDS Views erstellt werden. In SEGW werden Entitätstypen, Datenmodelle und Laufzeitobjekte manuell gepflegt. Bei CDS Views kann ein Service über die Annotation @OData.publish: true automatisch erzeugt werden.

Welche Standardmethoden gibt es bei OData-Services?

Die fünf wichtigsten Methoden sind GET_ENTITYSET, GET_ENTITY, CREATE_ENTITY, UPDATE_ENTITY und DELETE_ENTITY. Sie entsprechen den klassischen CRUD-Operationen: Datensätze lesen, einzeln abrufen, anlegen, ändern und löschen.

Warum sollte man die DPC_EXT-Klasse verwenden?

Eigene Implementierungen sollten immer in der DPC_EXT-Klasse erfolgen. Die generierte DPC-Klasse wird bei einer Neugenerierung der Laufzeitobjekte überschrieben. Änderungen in der DPC_EXT-Klasse bleiben dagegen erhalten.

Wie testet man einen OData-Service in SAP?

OData-Services können über den SAP Gateway Client getestet werden, der über /IWFND/MAINT_SERVICE erreichbar ist. Dort lassen sich HTTP-Methoden wie GET, POST, PUT und DELETE ausführen. Bei Fehlern hilft die Transaktion /IWFND/ERROR_LOG bei der Analyse.