OData
Das OData-Protokoll ist ein REST-konformes, HTTP-basiertes Datenzugriffsprotokoll.
OData benutzt Industriestandards wie JSON und XML.
OData wurde in Zusammenarbeit mit Microsoft als herstellerübergreifendes Verfahren entwickelt, um die Datenintegration und Zusammenarbeit zwischen verschiedenen Softwaresystemen zu erleichtern.
Durch standardisierte Schnittstellen mit einheitlicher Semantik wird Konsumenten ein erleichterter Datenaustausch ermöglicht.
Der Resource Oriented Architecture (ROA) folgend werden Operationen über HTTP-Methoden auf adressierbare Ressourcen (Uniform Resource Identifiers – URIs) ausgeführt.
Ein Designprinzip von ROA ist die zustandslose Kommunikation, bei der der Server keinen Sitzungszustand vorhält. Dieser wird bei Bedarf vom Client vorgehalten.
Dabei enthalten OData-Implementationen folgende Basiskomponenten :
- Datenmodell
OData-Implementationen enthalten ein Datenmodell (in Form einer XML-Struktur) - OData-Protokoll
Ein auf REST-Prinzipien basierendes Protokoll, welches neben der Möglichkeit CRUD-Operationen (CREATE, READ, UPDATE, DELETE) durchzuführen, weitere Anweisungen, beispielweite zur Formatierung des Outputs oder der Steuerung von Sortierungen, Filtern oder der Navigation vorhält. - OData-Services
Ein OData-Service ist die tatsächliche Implementierung des ODataprotokolls mit dem Datenmodell. - SAP-Gateway
Das SAP Gateway, anfänglich als AddOn verfügbar, ist seit SAP-ERP 7.4 fester Bestandteil des Kernels.
Das Gateways bildet eine Kommunikationsschicht zwischen der Webanwendung und dem SAP-Backend und Kommunikationsschnittstelle für SAP-Daten und Funktionen. Auf ihm können z.B. OData-Services verarbeitet werden.
Das Gateway kann in einer Embedded-Konfiguration als Teil des ERP-Systems auf dem Backend-Server installiert werden.
Unter S/4 HANA läuft die Kommunikation aller Anwendungstypen, die als transaktionale Anwendungen implementiert sind, und nach der Entgegennahme durch den Web Dispatcher in Richtung Backend verlaufen, über das SAP Gateway.
Systemalias festlegen
SAP Gateway kann auf einem Hub-System ausgeführt werden,
um eine Verbindung zu mehreren ABAP-Backend-Systemen herzustellen.
In unserer Konfiguration liegt das SAP-Gateway-Hub-System und das ABAP-Backend-System auf der gleichen Maschine.
Mit anderen Worten, das System, das für die Verarbeitung und Speicherung der Daten einer eingehenden Anforderung verantwortlich ist,
ist das gleiche wie die Gateway-Instanz.
Für die Festlegung der Verbindung zwischen beiden System richten wir einen System-Alias ein.
Dazu rufen wir
- die Transaktion SPRO auf,
- wählen wir SAP Reference IMG
3. Navigieren wir zu
SAP NetWeaver
->SAP Gateway
->OData Channel
->Konfiguration
->Verbindungseinstellungen
->SAP Gateway zu SAP-System
->SAP System Alias verwalten
und wählen Sie das Aktivitätssymbol.
4. Legen Sie den Alias an, so dass folgendes Bild entsteht :
5. Geben wie die folgenden Details ein, wie im nächsten Screenshot gezeigt
(geben Sie Ihre Systemdaten in den Spalten System-ID und Client an.)
Die Service Definition geschieht durch Generieren der Schnittstellen in der Transaktion SEGW.
Es gibt mehrere Wege die Beschreibung der Schnittstellen ins System zu bringen.
Neben dem händischen Anlegen der Schnittstellenobjekte (z.B. Entitäten, Assoziationen oder Entitätsmengen) gibt es die Möglichkeit, vorbereitete Beschreibungen zu verwenden.
Es werden folgende Wege angeboten :
- DDIC-Objekte (Abap-Dictionary-Struktur)
- XML-Beschreibungen (Datenmodell aus Datei)
- Schnittstellenbeschreibungen vorhandener Funktions- oder BOR-Bausteine (RFC/BOR-Interface)
Am offensichtlichsten zeigt die Definition über eine XML-Beschreibung des Datenmodells die Fähigkeiten des OData-Protokolls.
Wir werden deshalb zunächst über einen grafischen Editor das Datenmodell erstellen.
Hinweis : Die Web IDE Full Stack Edition enthält den OData Model Editor.
In der Personal Edition der Web IDE wird dieser derzeit nicht unterstützt.
Entwickler, die keinen Zugang zu einer Web IDE auf der SCP haben,
können hierzu OGee, ein Plugin für Eclipse verwenden.
Die Entitäten und Beziehungen können über den grafischen Editor abgebildet werden.
Über den Eclipse-Export-Assistenten kann das Ergebnis in Form einer XML-Datei gespeichert werden.
Im SAP-Jargon heißt das XML-Format EDMX.
Im nächsten Schritt kann die EDMX-Datei über den SAP Gateway Service Builder zur Generierung der Service-Schnittstellen geladen werden
(Menüpunkt : Importieren aus XML-Datei).
Nach Klick auf Fertig stellen wird das Datenmodell angelegt.
Auf Basis des Datenmodells können Sie das Verhalten des Services steuern. Sie legen fest, für wie sich Spalten von Entitäten verhalten sollen.
So können Sie z.B. festlegen, wie SmartControls einer SAPUI5-Anwendung mit dem Backend interagieren können.
Sie können festlegen, ob die Spalten einer Anfrage filterbar oder sortierbar sein sollen.
Weiterhin können Sie das Verhalten der Entitätsmengen über die Pflege des Datenmodells beeinflussen.
Sie legen fest, welche Bearbeitungsmethoden generiert werden. Sie können darüber festlegen, ob Entitätsmengen aktualisierbar bzw. löschbar sein sollen.
Auch können Sie hier festlegen, ob Abfrage-Ergebnisse filter- oder sortierbar sein sollen.
Durch das Generieren (Laufzeit erzeugen) werden Klassen mit einer festgelegten Namenskonvention erzeugt.
Diese können Sie mit den Namenskonventionen Ihres Unternehmens abgleichen.
Für jede Entität werden vier Klassen mit den Endungen
<_MPC_EXT>
<_MPC>
<_DPC_EXT>
<_DPC> erzeugt.
…_MPC ist die Model-Provider-Klasse. Sie enthält die Methoden der Model-Definition.
…_MPC_EXT ist eine Ableitung der Model-Provider-Klasse. Sie enthält benutzerdefinierte Implementationen der Model-Provider-Klasse.
…_DPC ist die Data-Provider-Klasse. Sie enthält die Methoden für die CRUD-Methoden.
…_DPC_EXT enthält benutzerdefinierte Implementationen der Data-Provider-Klasse.
Diese Stubs sind für sich nicht lauffähig.
Um die Methoden, für die Sie eine Verarbeitung benötigen zu implementieren, müssen Sie diese redefinieren.
Über ->Entitätsmenge-> (z.B. Create) können Sie das Kontextmenu öffnen und in den Class-Builder der ABAP-Workkbench wechseln.
Wechseln Sie hierzu durch Kontextmenu->Zur ABAP Workbench auf die Workbench.
Markieren Sie die gewünschte Methode, wechseln in den Änderungsmodus und klicken auf den Button Redefinieren.
In der neu entstandenen Methode unterhalb von Redefinierte Methoden können Sie Ihre Implementation vornehmen.
Die Aktivierung der implementierten Service-Klassen geschieht im Central-Hub-System.
Rufen Sie hierzu die Transaktion /IFWND/MAINT_SERVICE auf.
In dieser Transaktion können Sie über Service Hinzufügen den Service zu Ihrem Systemalias hinzufügen.
Über den Button ICF-Knoten gelangen Sie in die Transaktion SICF, wo Sie den ICF-Knoten aktivieren und testen können.
Sie finden den Knoten unter /sap/opu/odata/sap/servicename.
Testen über Transaktion SICF.
Nachdem Sie den ICF-Knoten aktiviert haben, können Sie den Service über das Kontext-Menu->Service testen aufrufen.
Test im SAP Gateway Central Hub
Über den Button SAP Gateway Client können Sie den Service im Central Hub testen. Dieser ruft die Transaktion /IWFND/GW_CLIENT auf.
Sie haben an dieser Stelle erweiterte Möglichkeiten zum Testen.
So können Sie dem Serviceaufruf Parameter (Query-Options) für die Darstellung (format=xml, format=json) oder für die Ausgabe von Annotationen (z.B. $metadata?sap-documentation=all) mitgeben.
