17. August 2015
Ringo Liebscher
0

SAP-Zugriff ohne Schmerz – REST-Webservices für SAP

In Unternehmen mit SAP-Systemen besteht häufig die Anforderung, auch anderen Anwendungen den Zugriff auf die darin gepflegten Daten zu ermöglichen. In einer Reihe von Fällen sollen Lese- und Schreiboperationen sofort – synchron – ausgeführt werden. Wenn zusätzlich ein geringer Overhead oder die Zugriffsmöglickeit für unterschiedliche Client-Anwendungen (Desktop, Web, Mobile, Cloud) gefragt sind, dann sind REST-Webservices eine favorisierte Schnittstellentechnologie.

Das ist REST

Ein REST-Service modelliert eine Reihe von Geschäftsobjekttypen (z.B Instandhaltungs-auftrag) und bietet für jeden Geschäftsobjekttyp die dafür benötigten Operationen an (z.B. Anlegen, Ändern oder Lesen). Mit REST-Services wird es möglich, Anwendungen auf quasi jedem internetfähigen Endgerät den Zugriff auf Daten eines SAP-Systems zu gestatten. Dies passiert so sicher und nachvollziehbar wie es das Internet erlaubt – etablierte Sicherheitsmechanismen wie SSL, SAML-Token, SAP User und Berechtigungsrollen können genutzt werden.

OData hilft

Das REST-Paradigma legt nicht alle Details fest, die für die Kommunikation einer Client-Anwendung mit dem Datenservice benötigt werden. Ein etablierter Standard zur Festlegung dieser Punkte ist das Open Data Protocol (OData), das ursprünglich von Microsoft stammt und heute von zahlreichen IT-Unternehmen inklusive SAP unterstützt und verwendet wird.
Das OData-Protokoll legt fest, nach welchem URL-Schema ein Client bei einem REST-Service einen Lese- oder Schreibzugriff auf bestimmte Objekte anfordert und Parameter übergibt. Dabei können „Extrawünsche“ etwa nach Filterung, Sortierung, Selektion, der Bündelung von Abfragen oder einem bestimmten Ergebnisformat übermittelt werden, so dass nur die benötigten Daten in einem geeigeneten Format (z.B. JSON) zur Client-Anwendung wandern.

Mindestvoraussetzung ist SAP NetWeaver 7.0

Aktuelle Releases des SAP NetWeaver Application Servers ABAP bringen die Software-komponente SAP Gateway für REST-Services standardmäßig mit. Ältere Systeme bis zum Release 7.0 können dafür ertüchtigt werden, indem aktuelle Support Packages und Add-Ons installiert werden. Somit können REST-Schnittstellen für SAP ERP, CRM, BI und alle anderen auf dem NetWeaver ABAP basierenden SAP-Produkte entwickelt werden.
In vielen Fällen kann das laufende SAP-System die eingehenden Serviceaufrufe ohne zusätzliche Ressourcen verarbeiten. Wenn jedoch häufige Anfragen von Hunderten oder Tausenden Clients eingehen oder ein Service aus dem öffentlichen Internet erreichbar ist, dann ist aus Performance- und Sicherheitsgründen eine angepasste Architektur mit einem zusätzlichen SAP NetWeaver Application Server erforderlich.

Entwicklungswerkzeuge an Bord

Die grundlegend benötigten Entwicklungswerkzeuge sind – wie bei SAP-Systemen üblich – auch im Fall von REST-Services im SAP-System integriert.
In der ersten Entwicklungsphase wird modelliert, welche Geschäftsobjekttypen mit welchen Attributen über den Service zugreifbar werden. Dabei können Datentypen aus dem Data Dictionary sowie remotefähige Funktionsbaustein-Schnittstellen als Vorlagen einbezogen werden. Entscheidend für einen gut verwendbaren Service ist jedoch, die teilweise sehr umfangreichen, komplexen und schwer verständlichen SAP-internen Datenstrukturen nicht ein zu eins nach außen zu publizieren. Die Auswahl der Geschäftsobjekttypen und Attribute im REST-Service kann genau in dem Umfang erfolgen, wie es für die externen Anwendungen benötigt wird, inklusive einer leichter verständlichen Benennung. Das Werkzeug dafür ist der „Gateway Service Builder“. Das damit geschaffene Servicemodell lässt sich später jederzeit anpassen.

 

SAP Gateway Service Builder

Abbildung 1: SAP Gateway Service Builder

 

Mit dem Gateway Service Builder wird auch ein Großteil der erforderlichen Laufzeitobjekte (Klassen und Methoden) generiert. Es bleibt aber die Aufgabe des Serviceentwicklers, die Datenzugriffe für die benötigten Operationen jedes Geschäftsobjekttyps zu implementieren. Üblich sind die Standardoperationen Anlegen, Ändern, Einzelabruf, Listenabruf und Löschen, soweit in der externen Anwendung benötigt. Für jede dieser Operationen muss eine Methode implementiert werden, die vom Gateway Framework als leere Vorlage angelegt wurde. Das geschieht wie üblich im Object Navigator SE80.
Als Unterstützung für die Implementierung steht der RFC/BOR-Generator bereit, mit dem u.a. aus existierenden RFC-Funktionsbausteinen und Suchhilfen der Code für eine grundlegende Lese- bzw. Schreiboperation generiert werden kann. In realen Projekten reicht die Verwendung des Generators jedoch in aller Regel nicht aus. In den meisten Fällen ist die Ergänzung mit manuellem Coding erforderlich, beispielsweise für Filterkriterien, Fehlerbehandlung, korrekte Behandlung von Tabellenparametern, zeitbezogene Abfragen anhand von Änderungsbelegen oder die Bereitstellung ergänzender Daten, die z. B. vom verwendeten BAPI-Funktionsbaustein noch nicht geliefert wurden.

Iterativ und selbstbeschreibend

Ein Vorteil der REST-Services mit SAP Gateway besteht darin, dass schnell eine erste Version des REST-Service nach außen bereitgestellt werden kann, so dass die Entwickler der Client-Anwendung bereits parallel zur Serviceentwicklung damit arbeiten können. Nach und nach können das Servicemodell und die bereit gestellten Operationen weiter ergänzt werden. Bei Änderungen nach der Produktivsetzung kann eine neue Serviceversion eingeführt werden, die parallel zur ersten Version betrieben wird.

 

Beispiel für die iterative Serviceentwicklung inkl. Serviceversionen

Abbildung 2: Beispiel für die iterative Serviceentwicklung inkl. Serviceversionen

 

Entsprechend dem OData-Standard beschreibt sich der entwickelte Datenservice zu jeder Zeit selbst: Die modellierten Objekte, ihre Attribute und Beziehungen können von jedem OData-Client mit einer speziellen Metadaten-Abfrage abgerufen werden. Aus der Antwort im XML-Format können viele Tools und Frameworks die Klassen eines passenden REST-Clients generieren, der Aufrufe an die vom SAP-System angebotene Schnittstelle sendet.

Test und Betrieb

Die SAP-Gateway-Komponente enthält eine Testumgebung für REST-Services. Mit dieser können Serviceaufrufe definiert, abgesendet und die Antwort überprüft werden. Einmal formulierte Testfälle können gespeichert und jederzeit wieder ausgeführt werden. Allerdings überprüft dieses Werkzeug nur den HTTP-Statuscode der Antwort, nicht jedoch die gelieferten Dateninhalte. Es lässt sich also automatisiert feststellen, ob der Service auf eine Anfrage mit dem erwarteten Statuscode reagiert. Die Vollständigkeit und Korrektheit der gelieferten Daten bzw. der im SAP-System erzeugten Datenobjekte muss dagegen mit anderen Mitteln geprüft werden.

 

SAP Gateway Client mit dem Ergebnis der Ausführung von gespeicherten Testfällen

Abbildung 3: SAP Gateway Client mit dem Ergebnis der Ausführung von gespeicherten Testfällen

 

Zur Betriebsumgebung der SAP-Gateway-Komponente gehören außerdem Anwendungs- und Fehlerlogs sowie verschiedene Traces, mit denen Serviceaufrufe und Fehler detailliert nachvollzogen werden können.

Bibliotheken für die Client-Entwicklung

Für die Kommunikation mit einem SAP-System ist neben dem REST-Service das entsprechende Gegenstück erforderlich, der REST-Client auf der Seite der Anwendung, welche Datenzugriffe ausführen soll. Dessen Entwicklung wird durch eine Reihe von Frameworks unterstützt, die unter anderem für die Plattformen .NET, Java, JavaScript verfügbar sind. Eine Auflistung geeigneter Frameworks ist auf der Website odata.org zu finden.

Stolpersteine gibt es trotzdem

Ohne Schmerz funktioniert der SAP-Zugriff per REST nur dann, wenn man einige Stolpersteine überspringt. Probleme können beispielsweise durch fehlendes Domänen-Wissen, überzogene Erwartungen an den RFC/BOR-Generator, große Datenmengen und unbedachte Implementierung oder durch Eigenheiten des SAP-Gateway-Frameworks entstehen. Mit etwas Erfahrung lassen sich diese Probleme jedoch umschiffen und eine absolut produktivtaugliche und flexible Schnittstelle schaffen.

Fazit

REST-Services sind keine Universalwaffe für den Datenzugriff auf SAP-Systeme. Mit ihrer plattformübergreifenden Nutzbarkeit, der Verwendung des offenen OData-Standards, der Flexibilität von Servicemodellen und der soliden Betriebsumgebung sind sie jedoch eine gute Lösung, wenn synchroner Datenzugriff, Entwicklungsgeschwindigkeit und Flexibilität für zukünftige Erweiterungen gefragt sind.

Ringo Liebscher arbeitet als Senior Consultant in Projekten mit den Arbeitsschwerpunkten SAP-Integration und mobile SAP-Anwendungen.

Xing 

TeilenTweet about this on TwitterShare on Facebook0Share on Google+0Share on LinkedIn0