Читать книгу Praxishandbuch SAP Gateway - Johannes Gerbershagen - Страница 6
Оглавление1 Das Grundkonzept von SAP Gateway
In diesem Kapitel lernen Sie die grundlegenden Prinzipien von SAP Gateway kennen.
1.1 SAP-Schnittstellentechnologien
SAP Gateway ist neben der RFC-Programmierschnittstelle (Remote Function Call) mit den darauf basierenden IDOC- und BAPI-Programmierschnittstellen eine weitere Schnittstellentechnologie der SAP. Sie ermöglicht die Anbindung von Nicht-ABAP-Systemen an SAP-Systeme über das Internet Communication Framework.
Browserapplikationen für Mobil- und Desktopgeräte sind dabei eine Hauptzielgruppe. Im Unterschied zum Web Dynpro ist die Schnittstelle aber nicht auf Browserapplikationen beschränkt. Sie können diese Programmierschnittstelle praktisch in jeder modernen Programmiersprache verwenden, die das HTTP-Protokoll unterstützt.
Nachfolgend möchte ich die SAP-Gateway-Schnittstelle mit der älteren RFC-Technologie vergleichen.
Neu eingeführt wurde in SAP Gateway:
Direkte Browserunterstützung: Mit der RFC-Programmierschnittstelle müssen Sie zuerst einen Webserver entwickeln, der die HTTP-Anfragen in RFC-Aufrufe konvertiert und umgekehrt. Die SAP-Gateway-Schnittstelle unterstützt Browserapplikationen direkt.
Unterstützung von mobilen Endgeräten: Die Browserapplikationen, die sich der SAP-Gateway-Schnittstelle bedienen, lassen sich ohne großen Mehraufwand an die kleineren Bildschirmgrößen von mobilen Endgeräten anpassen. Ebenso ist es mit dieser Schnittstelle möglich, Apps für das Android- bzw. iOS-Betriebssystem zu entwickeln.
Internetprotokolle: Die SAP-Gateway-Schnittstelle ist auf populären Internetprotokollen aufgebaut (siehe Abschnitt 1.4). Diese sind weit verbreitet und daher vielen Entwicklern – auch mit wenig SAP-Erfahrung – vertraut. Im Vergleich zur proprietären RFC-Schnittstelle beschränken Sie sich mit den Internetprotokollen nicht allein auf die Prozessorarchitekturen, Betriebssysteme und Programmiersprachen, für die die SAP eine RFC-Bibliothek anbietet.
Semantische Datenmodelle: Statt einzelner Funktionsbausteine stellt Ihnen die SAP-Gateway-Schnittstelle Datenmodelle mit umfangreichen Abfrageoptionen bereit.
Folgende Aspekte bietet das SAP Gateway nicht:
Bidirektionale Kommunikation: Die RFC-Schnittstelle unterstützt sowohl den Client- als auch den Servermodus (bidirektional). Die SAP-Gateway-Schnittstelle unterstützt nur den Clientmodus.
Sitzungen: Die SAP-Gateway-Schnittstelle arbeitet zustandslos. Damit kann keine zustandsbasierte Kommunikation wie in der RFC-Schnittstelle aufgebaut werden.
Die Zustandslosigkeit ist ein Hauptmerkmal der SAP-Gateway-Schnittstelle. Bei der RFC-Technologie können Sie sich für eine zustandsbasierte oder -lose Kommunikation entscheiden. Vorteil der zustandslosen Kommunikation ist die Kontextunabhängigkeit. Der Kontext, aus dem eine Funktion in der zustandslosen Kommunikation aufgerufen wurde, spielt keine Rolle. Nachteile sind u.a.:
Der SAP-Sperrmechanismus kann Datenbanksätze nicht mehr für die gesamte Bearbeitungsdauer sperren. Hierfür werden andere Technologien benötigt.
Die Clientapplikation kann den Abschluss einer SAP-LUW (Logical Unit of Work) nicht mehr steuern. Der Server schließt die SAP-LUW automatisch nach jeder Anfrage.
1.2 SAP Gateway und OData-Services
Die SAP-Gateway-Schnittstelle stellt REST-konforme OData-Services bereit. Diese Services kommunizieren mittels Open Data Protocol (OData) (siehe Abschnitt 1.4.2). Die Implementierung der Client- und Serverarchitekturen erfolgt mithilfe eines speziellen Programmiermodells, das ABAP-RESTful-Programmiermodell oder ABAP-Programmiermodell für SAP Fiori genannt wird.
1.3 ABAP-RESTful-Programmiermodell
Unter dem ABAP-RESTful-Programmiermodell versteht man die Entwicklung von REST-konformen Client- und Serverapplikationen. REST (Representational State Transfer) ist ein Paradigma für die Gestaltung der Maschine-zu-Maschine-Kommunikation über das HTTP-Protokoll. Dieses Paradigma umfasst die folgenden Prinzipien:
Client-Server-Architektur: Ein oder mehrere Server stellen HTTP-Dienste bereit, die der Client bei Bedarf anfragt. Der Server ist in diesem Fall das SAP-System.
Zustandslosigkeit: Jede Nachricht, die vom Server zum Client gesendet wird, ist unabhängig von der vorherigen Kommunikation. Der Server hält keine Zustandsinformationen vor.
Einheitliche Schnittstelle: Jede Ressource enthält einen eindeutigen Uniform Resource Identifier, kurz URI (Adresse). Nachrichten können in unterschiedlichen Formaten (XML, JSON, HTML etc.) ausgetauscht werden, enthalten aber dieselben Informationen.Ressourcen können über HTTP-Methoden erstellt (POST), verändert (PATCH), gelöscht (DELETE) oder gelesen (GET) werden.
Im Vergleich zu klassischen SAP-GUI- oder Web-Dynpro-Anwendungen sind die Zustandslosigkeit sowie die Trennung von Anwendungs- und Präsentationslogik zu nennen. Die Anwendungslogik stellen Sie als API (Application Programming Interface, dt. Programmierschnittstelle) bereit, und das Programmiermodell für die Präsentationslogik können Sie frei wählen (UI5, Java etc.), je nachdem, welche Endgeräte (Desktop-PCs, Tablets, Smartphones) Sie unterstützen wollen. Sie sind damit nicht an die SAP GUI oder an Webbrowser auf Desktop-PCs gebunden.
1.4 Kommunikationsprotokolle
In diesem Abschnitt möchte ich Ihnen die beiden Protokolle vorstellen, die den Kommunikationsfluss zwischen SAP Gateway und den Klienten (Clients) regeln. Dabei möchte ich nicht die vollständige Spezifikation mit all ihren Details wiedergeben, sondern das grobe Konzept, das für Sie als Anwendungsentwickler relevant ist.
1.4.1 HTTP-Protokoll
Das HTTP-Protokoll beschreibt den Kommunikationsfluss zwischen Client und Server (SAP Gateway), die mittels TCP/IP-Netzwerk miteinander kommunizieren, indem der Client Anfragen stellt, die der Server beantwortet. Die Anfragen des Clients beinhalten:
die HTTP-Version,
eine Methode (GET, POST, PUT, PATCH, DELETE, HEAD),
die Ressource (Request-URI),
Kopfzeilen (optional) sowie
den Nachrichteninhalt (optional).
Der Server reagiert auf die angefragte Methode wie folgt:
GET: Liefert die anfragte Ressource zurück, ohne weitere Änderungen vorzunehmen. Der Nachrichteninhalt der Anfrage wird nicht beachtet.
POST: Fügt eine Ressource in die Datenbank ein.
PUT: Fügt eine Ressource in die Datenbank ein bzw. überschreibt eine bestehende Ressource. POST und PUT unterscheiden sich in der Angabe der Request-URI (siehe Abschnitt 1.4.2).
PATCH: Verändert eine oder mehrere Eigenschaften der angegebenen Ressource.
DELETE: Löscht die angegebene Ressource.
HEAD: Liefert die Metainformationen (Kopfzeilen ohne Nachrichteninhalt) der anfragten Ressource.
Die Antwort des Servers enthält:
die HTTP-Version,
einen Statuscode mit zugehöriger Statusmeldung,
Kopfzeilen (optional) sowie
den Nachrichteninhalt (optional).
Die Kopfzeilen bestehen aus Schlüssel-Werte-Paaren. Sie enthalten Anmeldeinformationen, Zeichensätze, Datenformate usw. Die Nachrichteninhalte (engl. Payloads) können aus beliebigen Text- bzw. Binärdaten bestehen.
Statuscodes sind fest definierte Zahlen, die nach folgendem Muster gruppiert werden:
200–399: die Anfrage wurde erfolgreich verarbeitet
400–499: die Anfrage ist syntaktisch fehlerhaft (Client-Fehler)
500–599: Server-Fehler
Der Statuscode 400 »BAD REQUEST« bedeutet beispielsweise, dass die Anfrage nicht der erwarteten Form entspricht. Den Statuscode 501 »NOT IMPLEMENTED« erhalten Sie, wenn der Server die angefragte Aktion nicht implementiert. Eine detaillierte Liste aller Statuscodes können Sie dem RFC 2068, Abschnitt 10, der IETF entnehmen (https://www.rfc-editor.org/rfc/rfc2068.html#section-10).
1.4.2 OData-Protokoll
Das OData-Protokoll ist ein standardisiertes REST-konformes Protokoll zur Beschreibung von Entitätsdatenmodellen (Entity Data Models – kurz EDM), das auf dem HTTP-Protokoll basiert. Ein Entitätsdatenmodell besteht aus Entitäten, Eigenschaften, Relationen, Entitätsmengen, Aktionen und Funktionen1:
Mit Entität ist eine Instanz eines Entitätstyps gemeint. Jede Entität bekommt eine eindeutige ID (Entitäts-ID).
Entitätstypen sind Datenstrukturen, vergleichbar mit ABAP-Dictionary-Strukturen, die aus primitiven Eigenschaften (Feldern) bestehen, einen eindeutigen Schlüssel besitzen und die die Relationen zu anderen Entitäten beschreiben.
Jede primitive Eigenschaft hat einen bestimmten Typ, einen sogenannten EDM-Coretyp (Zeichenkette, numerischer Wert, Datums-, Uhrzeitangabe oder Binärdaten).
Entitätsmengen: fassen einzelne Entitäten desselben Entitätstyps zusammen.
Aktionen und Funktionen führen Operationen auf einem Teil des Datenmodells durch. Funktionen haben keine Seiteneffekte und können mit anderen Funktionen oder Aktionen kombiniert werden. Aktionen können Datenmodifikationen hervorrufen und lassen sich nicht mit anderen Aktionen kombinieren.
Eine Ressource im Sinne der REST-Prinzipien stellt eine Entität, eine Eigenschaft, eine Entitätsmenge oder eine Operation dar. PUT- und POST-Requests auf OData-Ressourcen unterscheiden sich in der Angabe der Ressource: Bei PUT-Requests verwenden Sie die Entitäts-ID und bei POST-Requests die Entitätsmenge.
Die SAP hat die Datenformate XML oder JSON gewählt, um Entitätsdatenmodelle über das HTTP-Protokoll zu übertragen.
Bei XML (Extensible Markup Language) werden mittels sogenannter Knoten Datenhierarchien aufgebaut. Listing 1.1 enthält ein simples XML-Dokument, das den Aufbau von XML verdeutlicht.
<?xml version="1.0" encoding="UTF-8"?> <Programmiersprachen> <Sprache> <Name>ABAP</Name> <Urheber>SAP SE</Urheber> </Sprache> <Sprache> <Name>C</Name> <Urheber>Dennis Ritchie</Urheber> </Sprache> </Programmiersprachen>
Listing 1.1: XML-Beispieldokument
Die Kopfzeile <?xml version="1.0" encoding="UTF-8"?> enthält die Information, dass es sich um ein XML-Dokument in der Version 1.0 und mit dem Zeichensatz UTF-8 handelt. Die zweite Zeile eröffnet mit dem Befehl <Programmiersprachen> den ersten Knoten. Dieser wird am Schluss mit dem Befehl </Programmiersprachen> geschlossen. Mit dem Befehl <Sprache> wird ein Knoten für eine einzelne Programmiersprache geöffnet, welcher mit dem Befehl </Sprache> wieder geschlossen wird. Der Knoten für die Programmiersprache enthält wiederum Knoten mit dem Namen sowie dem Urheber.
JSON (JavaScript Object Notation) ist ein Datenformat zur Darstellung von Entitätstypen und -mengen in Textform. Im JSON-Kontext spricht man von Objekten und Arrays. Ein Array ist vergleichbar mit einer internen Tabelle in ABAP, während ein Objekt eine Liste von Schlüssel-Werte-Paaren darstellt (vergleichbar mit einer ABAP-Struktur).
Listing 1.2 enthält das XML-Dokument aus Listing 1.1, aber diesmal im JSON-Format.
{ "Programmiersprachen": [ { "Name": "ABAP", "Urheber": "SAP SE" }, { "Name": "C", "Urheber": "Dennis Ritchie" } ] }
Listing 1.2: Beispieldokument aus Listing 1.1 in JSON
Arrays und Objekte erkennen Sie an den eckigen bzw. geschweiften Klammern. Die einzelnen Elemente sind immer durch Kommata getrennt.
Sowohl XML als auch JSON eignen sich dafür, Daten beliebig zu schachteln. JSON ist durch das Fehlen von Knoten oft kompakter, dafür gehen Teile der Semantik verloren.
