19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Das offene Framework SAP Gateway ermöglicht Ihnen eine Anbindung von Nicht-ABAP-Systemen an SAP-Systeme. Es zielt insbesondere auf Browserapplikationen wie beispielsweise SAP-Fiori-Apps für Mobil- und Desktopgeräte. Mit dem Open Data Protocol (OData) können Sie nahezu jede moderne Programmiersprache einsetzen und diese in Ihre SAP-Umgebung einbinden.
Nach einer Einführung in das grundlegende Konzept und die Konfiguration von SAP Gateway führt Sie dieses Praxishandbuch anhand eines Flugdatenmodells durch die serverseitige ABAP-Entwicklung, mit der Sie die Programmierschnittstellen bereitstellen sowie die korrekte Weiterverarbeitung und Speicherung der Daten implementieren. Anschließend widmen Sie sich der clientseitigen UI5-Entwicklung, mithilfe derer Sie die Programmierschnittstellen in Benutzeroberflächen integrieren. Die leichte Zugänglichkeit macht SAP Gateway anfällig für die Einschleusung schädlicher SQL-Statements. Daher legt der Autor zum Abschluss ein besonderes Augenmerk auf das Thema Sicherheit. Wichtige Aspekte sind etwa die Wahrung der Datenkonsistenz sowie das Absichern von OData-Services mit diversen Berechtigungen.
Das Buch wendet sich insbesondere an ABAP- und Web-Entwickler, aber auch an SAP-Berater mit Programmiererfahrung.
- Basis des Programmiermodells ABAP RESTful
- SAP-seitige Implementierung des OData-Protokolls
- Schnittstelle für UI5-Apps
- Praxisnahe Tipps für Entwicklung, Test und Debugging
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 93
Veröffentlichungsjahr: 2021
Ähnliche
Johannes Gerbershagen
Praxishandbuch SAP® Gateway
Johannes GerbershagenPraxishandbuch SAP® Gateway
ISBN:978-3-96012-077-3 (E-Book)
Lektorat:Anja Achilles
Korrektorat:Bernhard Edlmann Verlagsdienstleistungen, Raubling
Coverdesign:Philip Esch
Coverfoto:© freshidea | Nr. 121769509 – stock.adobe.com
Satz & Layout:Johann-Christian Hanke
1. Auflage 2021
© Espresso Tutorials GmbH, Gleichen 2021
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch die Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Johannes Gerbershagen:
Qualitätsmanagement in der ABAP-Entwicklung unter SAP
®
Johannes Gerbershagen:
SAP
®
-Praxishandbuch ABAP Core Data Services (CDS)
Tobias Steckenborn:
Schnelleinstieg in SAP
®
Cloud Platform Workflow
Martin Metz & Sebastian Mayer:
Schnelleinstieg in SAP
®
GRC Access Control
Jörg Böke:
Schnelleinstieg in SQLScript für SAP HANA
®
Viktor Laufer, Rüdiger Deppe:
ABAP-Programmierung unter SAP S/4HANA
®
Vorwort
In diesem Buch finden Sie Wissenswertes rund um das Thema SAP Gateway. Dieses Framework stellt die Webschnittstelle für SAP-Systeme dar, um darüber Programmierschnittstellen (API) basierend auf den REST-Prinzipien zu veröffentlichen. In diesen Kontext fällt auch die clientseitige Entwicklung mit dem populären UI5-Framework. Beide Themen werden unter dem Überbegriff ABAP-RESTful-Programmiermodell (RAP in ABAP) bzw. ABAP-Programmiermodell für SAP Fiori zusammengefasst. RAP in ABAP wird zwar oft im Zusammenhang mit der Business-Suite SAP S/4HANA bzw. der SAP Business Technology Platform (ehemals Cloud Platform) vermarktet, doch lässt es sich auch in On-Premise-Installationen und ohne SAP S/4HANA nutzen.
Sie finden die Themen gegliedert in die serverseitige ABAP-Entwicklung, mit der Sie die Programmierschnittstellen bereitstellen sowie die korrekte Weiterverarbeitung und Speicherung der Daten implementieren, und in die clientseitige UI5-Entwicklung, mithilfe derer Sie die Programmierschnittstellen in Benutzeroberflächen integrieren.
Da es sich bei UI5 um eine JavaScript-Bibliothek handelt, sind Vorkenntnisse in JavaScript hilfreich.
Quellcode-Beispiele
Dieses Buch enthält viele Quellcode-Beispiele. Um die Lesbarkeit in Ihrem E-Book-Lesegerät zu verbessern und den Zeilenumbruch korrekt darzustellen, empfehlen wir, den Quellcode im Querformat zu betrachten oder die Schriftgröße kleiner zu zoomen.
Codebeispiele zum Download
Die in diesem Buch vorgestellten Codebeispiele habe ich Ihnen im GitHub-Repository https://github.com/germanysources/sap_gateway zur Verfügung gestellt.
In den Text sind Kästen eingefügt, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen Personen weiblichen und diversen Geschlechts.
Hinweis zum Urheberrecht
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
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"?>
