SAP Gateway und OData - s3-eu-west-1.amazonaws.com · Dieses Buch hilft Ihnen, über SAP Gateway Drittanwendungen mit Ihrem SAP-System »sprechen« zu lassen. ... die auf SAP NetWeaver

LeseprobeDieses Buch hilft Ihnen, über SAP Gateway Drittanwendungen mit Ihrem SAP-System »sprechen« zu lassen. In dieser Leseprobe erfah-ren Sie, wie Sie Schritt für Schritt eigene OData-Services erstellen und welche Werkzeuge Sie dafür nutzen können. Nach der Lektüre wissen Sie außerdem, wie Sie mit OData-Channel gewisse Frei- heiten bei der Serviceentwicklung gewinnen.

Carsten Bönnen, Volker Drees, André Fischer, Ludwig Heinz, Karsten Strothmann

SAP Gateway und OData809 Seiten, gebunden, 2. Auflage 2016 79,90 Euro, ISBN 978-3-8362-4019-2

www.sap-press.de/4051

»Einführung in die Erstellung von OData-Services mit SAP Gateway« »Vorwort« »Einleitung«

Inhaltsverzeichnis

Index

Die Autoren

Leseprobe weiterempfehlen

SAP-Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/sap-gateway-und-odata_4051/?GPP=lpn

mailto:?body=Leseproben-Empfehlung: �SAP Gateway und OData� von SAP PRESS, http://gxmedia.galileo-press.de/leseproben/4051/leseprobe_sappress_sap_gateway_und_odata.pdf&subject=Leseprobe: �SAP Gateway und OData�

183

Kapitel 5

In diesem Kapitel erläutern wir die einzelnen Schritte und Werkzeuge, die für die Erstellung von Gateway-Services erforderlich sind. Dabei behandeln wir sowohl die Entwick-lung als auch die Generierung von Gateway-Services.

5 Einführung in die Erstellung von OData-Services mit SAP Gateway

Wie Sie in Kapitel 2, »Einführung in OData«, und 3, »Architektur undIntegration«, gesehen haben, werden OData-Services im Business-Suite-Backend-System implementiert und als URI über den Gateway-Server publiziert, der einen Zugriff auf die Daten des Business-Suite-Systems ermöglicht.

Die Anzahl der OData-Services, die mit SAP Gateway als Teil desStandards ausgeliefert werden, ist klein. Dies wird sich auch inZukunft nicht ändern, da OData-Services von Natur aus sehr granularund auf einen bestimmten Anwendungsfall zugeschnitten sind.OData-Services, die auf der Gateway-Technologie basieren, werdendaher als Teil von SAP-Produkten wie SAP Fiori, SAP S/4HANA odermobilen SAP-Anwendungen ausgeliefert.

Bei der Entwicklung von Anwendungen ist es häufig so, dass ein gro-ßer Teil der gesamten Entwicklungszeit in die Erstellung der geeigne-ten OData-Services investiert werden muss. Daher ist ein gutes Ver-ständnis des Prozesses der Serviceerstellung besonders wichtig.

Das zentrale Werkzeug, um Services in SAP Gateway zu definierenund zu implementieren, ist der SAP Gateway Service Builder (ServiceBuilder), der mit der Transaktion SEGW gestartet wird. Nachdem Sieeinen Service im Service Builder erstellt und diesen auf dem Gate-way-Server publiziert haben, kann dieser direkt in jedem beliebigenKonsumenten verwendet werden. Der Service Builder bietet alleFunktionalitäten für die Gateway-Serviceentwicklung »aus einerHand« und wird ergänzt durch zusätzliche Support-Tools.

4019.book Seite 183 Montag, 11. Juli 2016 11:47 11


184

In bestimmten Fällen können Sie auch ausgewählte Schritte in ande-ren Tools ausführen und die Ergebnisse dann in den Service Builderimportieren (so z. B. die Nutzung eines OData-Modell-Editors für dieErstellung eines OData-Modells).

Das Hauptziel dieses Kapitels ist es, Ihnen einen Überblick über denProzess der Erstellung von OData-Services zu geben (siehe Abschnitt5.2), den wir dann in Kapitel 6, »Serviceentwicklung«, und Kapitel 7,»Servicegenerierung«, ausführlicher diskutieren. Dazu bieten wirIhnen in Abschnitt 5.1, »Serviceerstellung – Möglichkeiten«, einenkurze Übersicht über die einzelnen Schritte, die in den beiden Artender Serviceerstellung (Serviceentwicklung und Servicegenerierung)ausgeführt werden.

In Abschnitt 5.3, »SAP Gateway – Entwicklungswerkzeuge«, stellenwir Ihnen dann das wichtigste Werkzeug für die Serviceerstellungvor: den SAP Gateway Service Builder. Danach werden weitere Toolsbeschrieben, die für die Erstellung und Verwaltung von Gateway-Services eingesetzt werden.

In Abschnitt 5.4, »Serviceerstellung – Schritt für Schritt«, werden wiruns dann detailliert mit den drei Hauptschritten der Serviceerstel-lung befassen: Datenmodelldefinition, Serviceimplementierung undServiceverwaltung.

Außerdem betrachten wir folgende Themen der Serviceerstellung:das Redefinieren von bestehenden Business-Suite-Objekten und dieWiederverwendung und Erweiterung vorhandener Gateway-Servicesin Erweiterungsszenarien. Das Entwicklungsmodell, das der Entwick-lung von Services in SAP Gateway zugrunde liegt, ist der sogenannteOData-Channel. Diesen stellen wir Ihnen in Abschnitt 5.5 vor.

5.1 Serviceerstellung – Möglichkeiten

Es gibt zwei Möglichkeiten, um OData-Services mit SAP Gateway zuerstellen:

� ServiceentwicklungDer klassische Ansatz ist die Programmierung von Gateway-Ser-vices in ABAP. Die Programmierung in ABAP ist einerseits äußerstflexibel und ermöglicht die Erstellung von sehr effizienten Ser-


Serviceerstellung – Möglichkeiten 5.1

185

vices. Sie erfordert andererseits jedoch ein gewisses Maß an tech-nischem Know-how, ähnlich dem, das für die Entwicklung vonKlassen und RFC-Funktionsbausteinen benötigt wird.

� ServicegenerierungEin zweiter Weg ist die Generierung von Gateway-Services, beider es vier Arten gibt:

– Mapping einer Datenquelle: Hier können Sie einen Servicedurch das Mapping der CRUD-Q-Vorgänge einer Entitätsmengeauf die Methoden einer Datenquelle generieren. Dieses Vorge-hen wird für folgende Datenquellen unterstützt:

– RFC-Funktionsbausteine oder BAPIs mit dem RFC-/BOR-Gene-rator

– Suchhilfen (nur Read- und Query-Methode)

– Core Data Services (CDS) Views (nur Read- und Query-Methode)

– Redefinieren (Redefinition): Das Redefinieren erlaubt die Defi-nition eines Gateway-Service auf Basis einer existierendenDatenquelle oder eines existierenden Gateway-Service.(Beachten Sie: Diese Option wird im Service Builder als Überde-finieren bezeichnet.)

– Referenzierte Datenquellen: Exponieren eines oder mehrererCDS Views, Assoziationen und Aktionen als OData-Service

– Anlegen von CDS Views mit Eclipse: Durch eine einfacheAnmerkung (OData.publish: true) in einem CDS View könnenOData-Services auch ohne Verwendung des Service Buildersdirekt aus Eclipse heraus angelegt werden.

Vor- und NachteileDie Servicegenerierung führt üblicherweise schneller zu Ergebnissenund ist weniger aufwendig als die Serviceentwicklung. Die Generie-rung von Services ist jedoch nicht so flexibel wie die Serviceentwick-lung und daher vor allem für die Erstellung von einfachen Servicesgeeignet. Die Optimierung von generierten Services ist nur einge-schränkt möglich, wenn keine ABAP-Programmierung erfolgen soll.

In den meisten Fällen wird man sich für die Serviceentwicklung ent-scheiden, da die Vorteile den erhöhten Entwicklungsaufwand recht-fertigen. Der Entwicklung von OData-Services mit SAP Gatewayhaben wir mit Kapitel 6, »Serviceentwicklung«, einen ausführlichenPraxisteil gewidmet.



186

Die Generierung von Gateway-Services ist jedoch dann interessant,wenn Sie über geeignete Datenquellen verfügen, wie z. B. Suchhil-fen, GenIL-Objekte, Service-Provider-Objekte, BW Queries wie eineEasy Query oder aber geeignete RFC-Funktionsbausteine oder BAPIs.Auch die Generierung von Gateway-Services auf Basis der zuvorgenannten SAP-Business-Objekte stellen wir in einem eigenen Praxis-teil (Kapitel 7, »Servicegenerierung«) vor.

CDS Views Mit SAP S/4HANA können aber nun OData-Services auf Basis vonCDS Views generiert werden, die auch die Draft-Infrastruktur unter-stützen. Wie 1 in Abbildung 5.1 zeigt, wird dies die bevorzugte Artwerden, mit der in Zukunft OData-Services erstellt werden.

Abbildung 5.1 SAP-Gateway-Service-Erstellung für SAP Fiori – das neue Programmiermodell in SAP S/4HANA

HANA

Browser(Fiori-Launchpad)

Fiori-App

UI5

Frontend-Server

UI App(BSP Repo) LaunchpadGateway -Hub

(OData Service)

SAP NetWeaver 7.50 (ABAP-OData-Provider)

Gateway-OData-Provider(BEP)

Query(SADL)

DraftEngine(BOPF)

Backend Business Logic (Classes, BAPI, …)

CDS View Draft Table Appl. Table

Trusted RFC

HTTPSHTML/OData

Read & write

Read Write

Read & write

Write

1

2


Prozess der Serviceerstellung 5.2

187

Da OData-Services, die auf diese Weise erstellt wurden, auch diesogenannten Smart Templates für die Erstellung von Benutzerober-flächen unterstützen, wird es in der Mehrzahl der Anwendungssze-narien in SAP S/4HANA nicht mehr erforderlich sein, SAPUI5-Codezu entwickeln. Es wird genügen, hier geeignete CDS Views undBOPF-Objekte zu entwickeln.

Auch wenn OData-Services auf Basis von CDS Views generiert wur-den, ist es möglich, die Ausführung der Datenbankzugriffe auf Basisder Service Adaption Language (SADL) zu optimieren, indem mandie entsprechenden Schnittstellen-API des SADL-Frameworks imple-mentiert oder aber Anwendungslogik in der Erweiterungsklasse derDatenanbieterklasse mit ABAP-Code implementiert.

In Systemen, die auf SAP NetWeaver 7.50 beruhen, wird es aberauch weiterhin möglich sein, OData-Services zu entwickeln oderüber das Mapping einer Datenquelle zu implementieren, wie 2 inAbbildung 5.1 zeigt. Auf diese Weise werden Kunden in der Lagesein, bereits vorhandene Geschäftsprozesslogik in Form von ABAP-Klassen und RFC-Funktionsbausteinen für die Erstellung von OData-Services zu nutzen, auch wenn Sie SAP Business Suite EHP 8 oderaber SAP S/4HANA (on Premise) verwenden.

Unabhängig davon, ob Sie sich für die Entwicklung oder die Generie-rung von Services entscheiden, folgen Sie in beiden Fällen dem Ser-viceerstellungsprozess in SAP Gateway.

5.2 Prozess der Serviceerstellung

Dieser Abschnitt gibt Ihnen einen Überblick über die Vorgehens-weise bei der Serviceerstellung. Die Serviceerstellung wird dabei,bewusst vereinfacht, als eine Abfolge sequenzieller Schritte darge-stellt, das heißt als Wasserfallmodell.

In der Realität erfolgt die Ausführung der einzelnen Schritte nichtsequenziell, sondern vielmehr iterativ. Zum besseren Verständnisbeginnen wir mit der Darstellung der vereinfachten Vorgehens-weise, bevor wir den detaillierten Prozess eingehend vorstellen.

Der Prozess der Serviceerstellung teilt sich in drei Hauptphasen auf:Definition des Datenmodells, Serviceimplementierung und Servicever-



188

waltung. Je nachdem, ob Sie sich für die Generierung oder die Ent-wicklung eines Service entschieden haben, müssen Sie innerhalb die-ser Phasen unterschiedliche Schritte ausführen, es gibt jedoch auchSchritte, die sowohl bei der Entwicklung als auch bei der Generie-rung von Services ausgeführt werden müssen.

Bevor Sie mit der Erstellung eines Service beginnen können, mussdieser zunächst definiert werden. Hierbei werden Art und Umfangdes Service festgelegt. Dies geschieht idealerweise in Abstimmungmit dem Entwickler der Client-Applikation, so dass Sie wissen, wel-che Daten in der Anwendung benötigt werden und wie Sie diese ausdem Business-Suite-System erhalten. Sind diese Voraussetzungengeklärt, können Sie mit den drei Phasen des Serviceerstellungspro-zesses beginnen.

Datenmodell-definition

In der Phase der Datenmodelldefinition definieren Sie das Datenmo-dell Ihres Service. Dabei werden die notwendigen Artefakte wieEntitätstypen, Entitätsmengen, Assoziationen und weitere Kompo-nenten angelegt, die Ihr Service nutzen wird (die zuvor genanntenKomponenten wurden in Kapitel 2, »Einführung in OData«, nähererläutert). Nach der Definition des Datenmodells müssen zunächstdie Repository-Objekte generiert und im Business-Suite-Systemregistriert werden. Danach können Sie mit der nächsten Phase derServiceerstellung fortfahren, der Serviceimplementierung.

Serviceimplemen-tierungsphase

In der Phase der Serviceimplementierung werden die Methodenimplementiert, die von dem Service unterstützt werden sollen.Abhängig davon, ob dies durch Serviceentwicklung oder Servicege-nerierung geschieht, folgen Sie unterschiedlichen Implementie-rungspfaden:

� Bei der Serviceentwicklung werden die Methoden, die vom Ser-vice unterstützt werden, mithilfe von ABAP-Programmierungimplementiert.

� Bei der Servicegenerierung haben Sie die folgenden vier Möglich-keiten, einen Service zu generieren:

– Wenn Sie das Mapping einer Datenquelle verwenden, erfolgtdie Implementierung durch das Mapping der Vorgänge einerEntitätsmenge auf die Methoden eines RFC-Funktionsbau-steins, eines BOR-Objekts (Business Object Repository), einerSuchhilfe oder eines CDS Views.



189

– Im Fall der Redefinition gibt es keinen separaten Schritt für dieImplementierung des Service. Sie müssen lediglich den Daten-modellierungsschritt ausführen. Die Implementierung des Ser-vice wird dann auf Basis des Customizings generiert, das imDatenmodellierungsschritt durchgeführt wurde.

– Auch bei der Verwendung von referenzierten Datenquellen gibtes keinen Serviceimplementierungsschritt, da hier ein odermehrere Entitätsmengen oder Assoziationen eines CDS Viewsin das Datenmodell übernommen werden.

– Wenn Sie einen CDS View mit Eclipse anlegen und durch dieAnmerkung (OData.publish: true) als OData-Service im Back-end-System registrieren, gibt es ebenfalls keinen Serviceimple-mentierungsschritt. Hier erfolgt die Serviceimplementierungauf Basis der CDS-View-Definition.

Serviceverwal-tungsphase

In der dritten Phase des Prozesses der Serviceerstellung, der Service-verwaltung, wird der Service im Gateway-Server aktiviert, so dass erim Servicekatalog auffindbar ist. Dies bedeutet, dass der Service voneinem Client konsumiert werden kann.

Die drei Phasen – Datenmodelldefinition, Serviceimplementierungund Serviceverwaltung – sind in Abbildung 5.2 dargestellt.

Abbildung 5.2 Prozess der Serviceerstellung

Datenmodell-definition

Service-verwaltung

OData-Service-definition in

Transaktion SEGW

Import-Datenmodell

(EDMX)

Import-DDIC-Struktur/

Suchhilfe

Import-RFC-/BOR-Schnittstelle

Redefinitionvon Services(GenIL, SPI,

SAP BW,SAP Gateway,

OData)Codebasierte Implementierung

Codebasierte ErweiterungenMap-RFC/BOR-Operation, Suche,

Hilfe, CDS View

Serviceregistrierung undAktivierung auf dem Hub

Nutzung vonCDS Viewsals referen-

zierte Daten-quellen

ManuelleModell-

definition

Service-implementierung

= Serviceentwicklung

= Servicegenerierung



190

Dabei sind die Schritte, die in der Serviceentwicklung und in der Ser-vicegenerierung durchgeführt werden, mit unterschiedlichen Farbengekennzeichnet. Die Schritte, die sowohl bei der Serviceentwicklungals auch bei der Servicegenerierung durchgeführt werden, sind mitzwei Farben gekennzeichnet. Obwohl wir die beiden Methoden derServiceerstellung (Servicegenerierung und Serviceentwicklung)getrennt dargestellt haben, ist es möglich, beide Ansätze zu kombi-nieren.

So können Sie z. B. einen OData-Service erstellen, bei dem eine Enti-tätsmenge mithilfe des RFC-/BOR-Generators durch Mapping(Servicegenerierung) implementiert wird, während eine zweite Enti-tätsmenge durch ABAP-Programmierung (Serviceentwicklung)implementiert wird. Es ist auch möglich, einen Service auf Basiseiner BW Query zu generieren, der zunächst nur einen lesendenZugriff auf Daten ermöglicht. Diesen Service können Sie dann durchABAP-Code so erweitern, dass er auch einen ändernden Zugriff aufBusiness-Daten ermöglicht.

InkrementellerServiceerstellungs-

prozess

Wie bereits erwähnt, haben wir den Prozess der Serviceerstellungder Übersichtlichkeit halber zunächst klar strukturiert und alsAbfolge sequenzieller Schritte dargestellt. Dieses Wasserfallmodelleignet sich gut, um die drei verschiedenen Phasen der Serviceerstel-lung zu erläutern. In realen Entwicklungsprojekten wird man dieReihenfolge, in der die einzelnen Schritte ausgeführt werden, soanpassen, wie es für die Serviceerstellung am besten ist.

Lediglich bei der Serviceverwaltungsphase handelt es sich um eineTätigkeit, die nur einmal ausgeführt wird. Sobald ein Service imBackend registriert und im Gateway-Hub aktiviert (das heißt veröf-fentlicht) wurde, müssen diese Einstellungen in der Regel nicht mehrangepasst werden.

In allen anderen Phasen der Serviceerstellung sollten Sie hingegeneinen inkrementellen Ansatz verfolgen: Legen Sie einen Service an –oder Teile eines Service –, führen Sie diesen aus, und testen Sie ihn.Danach können Sie den Service so lange verändern, bis er schließlichallen Anforderungen genügt. Innerhalb des Prozesses der Erstellung



191

eines OData-Service können das Datenmodell und auch die Ser-viceimplementierung mehrfach geändert werden.

Ausnahmen

Die Publizierung eines Service ist eine einmalige Angelegenheit, wennnicht weitreichende Änderungen am Service vorgenommen werden. DieRegistrierung eines Service für weitere Business-Suite-Systeme ist ein Bei-spiel für solch eine weitreichende Änderung.

Änderungen in der Serviceimplementierung oder dem Datenmodell einesService, der bereits publiziert wurde, können in Entwicklungssystemenhingegen ohne zusätzliche Aktivitäten umgesetzt werden.

Beachten Sie: Da die Datenmodelle in Produktivsystemen aus Performan-cegründen gecacht werden, müssen bei Änderungen in der Datenmodell-definition die Caches im Backend und im Gateway-Server aktualisiertwerden.

Reihenfolge der Phasen ändern

Ein Ansatz, der in realen Entwicklungsprojekten oft genutzt wird,ist, dass man die Phasen der Serviceimplementierung und der Ser-viceverwaltung in umgekehrter Reihenfolge ausführt. Generiertman nach der Datenmodelldefinition zunächst das Service-Builder-Projekt und führt anschließend direkt den Schritt der Serviceverwal-tung aus, um den Service zu aktivieren, kann man zunächst dieMetadaten des Service (Servicedokument und Service-Metadaten-dokument) kontrollieren, obwohl der Service noch keine Funktiona-lität bietet. Anschließend kann man den Service-Stub inkrementellimplementieren.

Abbildung 5.3 stellt diesen inkrementellen Prozess der Serviceerstel-lung dar. Der Prozess basiert auf Abbildung 5.2; zusätzlich habenwir noch inkrementelle Schritte hinzugefügt. Die inkrementellenSchritte sind dabei durch die durchgezogenen Pfeile gekennzeich-net, die die Übergänge zwischen den Phasen der Datenmodellierungund der Serviceimplementierung darstellen. Die Phasen sind durchhorizontale Kästen dargestellt. Die gepunktete Linie zeigt dagegendie einmalige Aktivierung eines Service in der Phase der Service-verwaltung.



192

Abbildung 5.3 Inkrementeller Prozess der Serviceerstellung

5.3 SAP Gateway – Entwicklungswerkzeuge

SAP Gateway stellt eine Reihe von Werkzeugen zur Verfügung, umdie unterschiedlichen Anforderungen aus den Bereichen Entwick-lung, Test und Betrieb von OData-Services zu adressieren.

An dieser Stelle werden wir die Tools für den Betrieb von SAP Gate-way nicht näher erläutern und uns stattdessen auf die Tools fokussie-ren, die im Rahmen der Serviceentwicklung zum Einsatz kommen.Wir werden daher zunächst im folgenden Abschnitt den SAP Gate-way Service Builder näher betrachten. Anschließend werden wir inAbschnitt 5.3.2 weitere Tools vorstellen, die Sie beim Prozess derErstellung von OData-Services unterstützen und die in optimalerWeise auf das Zusammenspiel mit dem Service Builder abgestimmtsind. In Abschnitt 5.3.3 werden wir Ihnen dann die Eclipse-basiertenABAP Development Tools for SAP NetWeaver vorstellen, mit denenCDS Views erstellt werden können.

Data-Source-Service

redefinieren

Nutzung vonCDS Viewsals referen-

zierte Daten-quellen

Datenmodelldefinition

Serviceimplementierung

Serviceverwaltung

Einmalige Durchführung

Inkrementell

Map-RFC-/BOR-Operation

Serviceregistrierung undAktivierung auf dem Hub

Import-Datenmodell

(EDMX)

Import-DDIC-Struktur/

Suchhilfe

Import-RFC-/BOR-Schnittstelle

ManuelleModell-

definition

ABAP-Programmierung

OData-Servicedefinition


SAP Gateway – Entwicklungswerkzeuge 5.3

193

5.3.1 SAP Gateway Service Builder

Der Service Builder bietet dem Entwickler alle Funktionen, die fürdie Modellierung und die Entwicklung von OData-Services in SAPGateway erforderlich sind. Dies umfasst sowohl die Programmie-rung als auch die Generierung von OData-Services. Darüber hinausbietet der Service Builder einen direkten Zugriff auf zusätzlicheFunktionen, die für einen Entwickler interessant sind, wie z. B. dieServiceverwaltung und die Servicevalidierung. Der Service Builderunterstützt den gesamten Entwicklungszyklus (Development Life-cycle) eines OData-Service in SAP Gateway und kann über die Trans-aktion SEGW gestartet werden (siehe Abbildung 5.4).

Abbildung 5.4 SAP Gateway Service Builder

Dabei eignet sich der Service Builder sowohl für erfahrene Entwick-ler als auch für Anfänger in der ABAP-Programmierung und fürNicht-Entwickler. Erfahrenen Entwicklern bietet der Service Builderdie Möglichkeit der Entwicklung von Services durch ABAP-Program-mierung und damit ein Maximum an Flexibilität bei der Serviceim-plementierung. Für die Datenmodellierung können Entwickler denOData-Modeler des Service Builders nutzen, der den ABAP-Code derModell-Provider-Klasse generiert.

Anfänger in der ABAP-Programmierung und Nicht-Entwickler hinge-gen werden die Möglichkeiten der Servicegenerierung zu schätzenwissen, die die Erstellung von OData-Services erlauben, ohne dassder Entwickler hierfür auch nur eine Zeile ABAP-Code schreibenmuss.



194

Der Service Builder ermöglicht die Anzeige und Definition von OData-Services an zentraler Stelle. Dies umfasst die Laufzeitartefakte (Modell-Provider-Klasse (MPC), Daten-Provider-Klasse (DPC), Modell- und Ser-vicedefinition), OData-Artefakte (Entitätsmenge, Entitätstypen undAttribute) sowie die verwendeten Datenquellen und Modelle.

ProjektbasierteEntwicklung

Die Modellierungsumgebung des Service Builders unterstützt die pro-jektbasierte Entwicklung. Alle entwicklungsrelevanten Objekte wer-den in diesen Projekten zusammengefasst. Das Anlegen eines Projektsim Service Builder ist der Startpunkt für jede Art von Serviceerstellungmit dem Service Builder. Damit wird dem Serviceentwickler die Mög-lichkeit geboten, alle entwicklungsrelevanten Artefakte in Projektenan einer zentralen Stelle zu bündeln. Der Service Builder erlaubt esdem Entwickler darüber hinaus, wie in Abbildung 5.5 gezeigt, meh-rere Projekte zu öffnen und zu bearbeiten. In dem Beispiel wurden dieProjekte ZPRODUCT und ZSALESORDER geöffnet.

Abbildung 5.5 Projektbasierte Entwicklung



195

Achtung

Der Service Builder wird in dem System verwendet, in dem die BEP-Kom-ponente (Business Enablement Provisioning) installiert ist. Dies ist übli-cherweise das Business-Suite-System (siehe hierzu Kapitel 4, »Deploy-ment-Optionen, Installation und Konfiguration«, in dem wir die verschie-denen Deployment-Optionen dargestellt haben).

Die BEP-Komponente wird bis SAP NetWeaver 7.31 als Add-on IW_BEPausgeliefert. Mit SAP NetWeaver 7.40 SP02 ist die BEP-Komponente Teilder SAP-Basis und wird über die Softwarekomponente SAP_GWFND ausge-liefert. Daher ist es ohne besonderen Aufwand möglich, in auf SAP Net-Weaver 7.40 basierenden oder neueren Systemen mit dem Service Buil-der OData-Services zu entwickeln.

Da der Service Builder als Teil der BEP-Komponente in der Regel (abernicht zwingend) auf dem Business-Suite-System installiert ist, werdensowohl das Servicemodell (die Modell-Provider-Klasse, MPC) als auch dieServiceimplementierung (Daten-Provider-Klasse, DPC) auf diesem Systemdefiniert. Dies ist wichtig, um zu verstehen, welche ABAP-Repository-Objekte, wie z. B. Data-Dictionary-Elemente (DDIC), Strukturen undDatenelemente, referenziert werden können, wenn RFCs, BAPIs oderKlassenmethoden aufgerufen werden.

Bestmögliche Unterstützung

Mit dem Service Builder soll dem Entwickler die bestmöglicheUnterstützung bei der Erstellung von OData-Services geboten wer-den, sowohl programmatisch als auch über die Generierung vonOData-Services. Es gibt jedoch technische Restriktionen, was mitdem Service Builder modelliert, entwickelt oder generiert werdenkann. Bestimmte OData-Features müssen gegebenenfalls manuellimplementiert werden, und bestimmte Methoden sind gegebenen-falls nicht in einem redefinierten Business-Objekt verfügbar.

Das Ergebnis der Serviceentwicklung bzw. Servicegenerierung sindin jedem Fall ABAP-Klassen, die auf dem Programmiermodell desOData-Channels basieren (siehe Abschnitt 5.5). Entwickler habenjederzeit die Möglichkeit, den Sourcecode der ABAP-Klassen zu ana-lysieren, um die Funktionsweise eines Service besser zu verstehen.Dann können Sie den (generierten) Code gegebenenfalls anpassen,indem Sie die entsprechenden Methoden der Modell- bzw. derDaten-Provider-Klasse redefinieren, die ihre Funktionalität von denBasisklassen erben und bei der Neugenerierung eines Service imGegensatz zur Basisklasse nicht überschrieben werden.



196

5.3.2 Weitere Tools zur Unterstützung des Service-erzeugungsprozesses

Wie bereits erwähnt, ist das zentrale Tool für die Erstellung von Ser-vices der SAP Gateway Service Builder. Darüber hinaus bietet SAPGateway eine Reihe von Tools an, die den Entwicklungsprozess vonGateway-Services unterstützen. Mithilfe dieser Tools ist es z. B. mög-lich, Services frühzeitig zu testen oder die Kommunikation eines Ser-vice zu tracen. Aus diesem Grund geben wir Ihnen in diesem Abschnitteinen kurzen Überblick über einige dieser Funktionalitäten. Eine aus-führliche Darstellung der Entwicklungs- und Administrationswerk-zeuge von SAP Gateway finden Sie in Kapitel 14, »Lifecycle Manage-ment: Qualitätssicherung, Service-Deployment und Operations«.

SAP Gateway Client

Testen undTroubleshooting

Der SAP Gateway Client kann sowohl für das Testen als auch für dasTroubleshooting verwendet werden und ist ein im Gateway-Servereingebauter REST-Client. Der SAP Gateway Client kann aus dem SAPGUI heraus über die Transaktion /IWFND/_GWCLIENT gestartetwerden. Nachdem man einen Service auf dem Gateway-Server akti-viert hat, kann dieser dort umgehend mit dem SAP Gateway Clientgetestet werden, wie in Abbildung 5.6 gezeigt.

Abbildung 5.6 SAP Gateway Client – Anforderung erstellen



197

Hierzu wählt man zuerst die HTTP-Methode, wie z. B. GET, PUT, POST,PATCH, oder DELETE 1. Dann gibt man den URI seines Requests imEingabefeld Request-URI ein 2. Falls erforderlich, können auchbestimmte HTTP-Header gesetzt werden. Der Body des HTTP-Requests kann entweder manuell eingegeben werden, oder man lädtihn aus einer Datei hoch 3. Darüber hinaus ist es möglich, die Funk-tionalität Als Anf. Verwenden zu nutzen. Damit kann der Inhalteiner Update-Anforderung auf Basis der HTTP-Response einer Lese-anforderung 4 erzeugen. Der HTTP-Request kann nun ausgeführtwerden, wenn man Ausführen auswählt 5.

Eine besonders nützliche Funktionalität des SAP Gateway Clients ist,dass man Testfälle in einer Datenbank speichern kann. Der Testfall,der in Abbildung 5.6 gezeigt wird, ist einer von mehr als 70 Testfäl-len, die als Testgruppe mit dem Namen CORE_SAMPLES ausgeliefertwerden. Diese Testgruppe enthält Testfälle für die Standardtest-Gate-way-Services TEA_TEST_APPLICATION und RMTSAMPLEFLIGHT. Beach-ten Sie, dass die Testfälle der Testgruppe CORE_SAMPLES in Ihrem Sys-tem wie in Abbildung 5.7 angelegt werden müssen. Wählen Sie dazuim Menü des SAP Gateway Clients SAP Gateway Client 1 � Core

Samples anlegen 2.

Abbildung 5.7 Anlegen der Testfälle der Testgruppe CORE_SAMPLES

Wenn Sie einen HTTP-Request als Testfall gespeichert haben, kön-nen Sie anschließend den HTTP-Returncode festlegen, der bei derAusführung des HTTP-Requests vom Service zurückgeliefert werdensoll. Ein HTTP-Request kann dabei mehrere gültige Returncodeszurückliefern (z. B. 200, 401, 402 und 403). Aus diesem Grund kön-nen auch im SAP Gateway Client mehrere gültige Rückgabewertesowie Intervalle spezifiziert werden (z. B. 201 401–403).

Darüber hinaus ist es möglich, die Payload-Validierung zu nutzen.Dabei kann die Paylaod eines HTTP-Requests mit der erwarteten Pay-



198

load eines Service verglichen werden und nicht nur mit dem HTTP-Returncode.

Ein oder mehrere Testfälle können dann mit dem SAP Gateway Cli-ent ausgeführt werden. Die Ergebnisse werden in einer TabelleSAP Gateway Client – Mehrfachtest mithilfe von Ampeln ange-zeigt, wobei sowohl der erwartete als auch der tatsächliche HTTP-Returncode in der Tabelle aufgeführt werden.

Fehlerprotokoll

Das Fehlerprotokoll (Error Log) ist ein weiteres Tool, das für Entwick-ler bei der Fehlerbehandlung von großem Nutzen ist.

Das Fehlerprotokoll wird im Gateway-Server über die Transaktion/IWFND/ERROR_LOG aufgerufen. Im Business-Suite-System gibt esauch ein Backend-Fehlerprotokoll mit einer sehr ähnlichen Benutzer-oberfläche. Mithilfe des Backend-Fehlerprotokolls können Fehleranalysiert werden, die im Business-Suite-Backend-System auftreten.Das Backend-Fehlerprotokoll wird über die Transaktion /IWBEP/ERROR_LOG im Business-Suite-System aufgerufen.

Das Fehlerprotokoll ist gut mit dem SAP Gateway Client integriert.So ist es beispielsweise möglich, einen HTTP-Request, der von einemOData-Konsumenten versendet wurde und der zu einem Verarbei-tungsfehler führte, erneut auszuführen. Wählen Sie dazu wie inAbbildung 5.8 Wiedergabe � SAP Gateway Client.

Abbildung 5.8 Transaktion /IW_FND/ERROR_LOG



199

Logging und Tracing

Eine weitere Möglichkeit der Fehlerbehandlung bietet die Analysevon Protokolleinträgen, die für das SysLog und das Anwendungsproto-koll von SAP Gateway von einem OData-Service erzeugt werden. DasSysLog kann über die Transaktion SM21 aufgerufen werden, wäh-rend der Gateway-Anwendungsprotokoll-Viewer über Transaktion/IWFND/APPS_LOG aufgerufen werden kann.

SAP-Gateway-Statistikdaten

Bei der Entwicklung eines OData-Service oder einer Client-Anwen-dung ist der Entwickler an Performancedaten zu diesem Service inte-ressiert. Die Statistikdaten für einen HTTP-Request können im SAPGateway Client angezeigt werden, wenn man an den Request-URIden URL-Parameter ?sap-statistics=true anhängt oder wenn manden HTTP-Request-Header sap-statistics=true setzt. Das SAPGateway Framework stellt dem Client die Statistikdaten im HTTP-Header sap-statistics bereit. Die Antwortzeiten werden durch dasSAP Gateway Framework darüber hinaus für jeden eingehendenHTTP-Request im SAP-Gateway-Server gespeichert.

Performance kontrollieren

Auf Basis dieser Daten kann man über die Transaktion /IWFND/STATS (SAP-Gateway-Statistik, siehe Abbildung 5.9) auf die Statistik-daten auch einzelner Serviceaufrufe zugreifen. Die Statistikdatenwerden in regelmäßigen Abständen verdichtet, so dass die Perfor-mance jedes Service einfach ausgewertet werden kann. In Produk-tivsystemen ist diese Transaktion für den Administrator von großemNutzen, wenn dieser die Performance von OData-Services kontrollie-ren möchte.

Abbildung 5.9 Transaktion /IWFND/STATS

Über die Transaktion /IWFND/TRACES kann man nicht nur die Per-formance eines einzelnen Serviceaufrufs im SAP Gateway Server undBackend-System aufzeichnen, sondern man kann dies auch mit derPayload eines Serviceaufrufs tun (siehe Abbildung 5.10).



200

Abbildung 5.10 Transaktion /IWFND/TRACES – Payload-Trace

Mithilfe des Payload-Trace ist es möglich, sowohl die Payload zuüberwachen, die vom Client zum Server gesendet wird, als auch denInhalt der Response, die vom Server zurück an den Client geschicktwird. Die aufgezeichneten Daten können dann dazu verwendet wer-den, einen Request erneut an den Server zu senden.

Testfälle erstellen Mit den im Payload-Trace aufgezeichneten Daten ist es darüber hin-aus sehr einfach, Testfälle im SAP Gateway Client zu erstellen. Diesist vor allem im Support-Fall von großem Nutzen. Um den Payload-und den Performance-Trace zu verwenden, müssen diese in derTransaktion /IWFND/TRACES aktiviert werden.

Katalogservice

Jedes Gateway-System bietet einen Servicekatalog (Service Cata-log), über den man eine Liste aller Services eines Gateway-Serverserhalten kann (siehe Abbildung 5.11). Der Katalog ist ein OData-Ser-vice, und die Liste der verfügbaren Services kann man über die fol-gende URL abfragen:

http://<server>:<port>/sap/opu/odata/iwfnd/CATALOGSERVICE;v=2/CatalogCollection



201

Abbildung 5.11 Servicekatalog – Servicedokument

OpenSearchDer Katalogservice unterstützt das OpenSearch-Protokoll. Entwick-ler oder Entwicklungsumgebungen können daher Services über eineFreitextsuche anhand der Servicebeschreibung finden. Hierzu mussdie folgende URL aufgerufen werden:

http://<server>:<port>/sap/opu/odata/iwfnd/CATALOGSERVICE;v=2/Service Collection/OpenSearchDescription.xml

5.3.3 ABAP Development Tools for SAP NetWeaver und Core Data Services Views

Ein Core Data Services (CDS) View ist, wie der Name vermuten lässt,ein View, der dazu definiert werden kann, eine anwendungsspezifi-sche Projektion der darunterliegenden Geschäftsdaten zu erhalten.Dies ist erforderlich, da die Geschäftsdaten in der Regel über meh-rere Datenbanktabellen verteilt sind.

CDS stellt eine Spezifikation für eine SQL-basierte Datenbanksprache(Data Definition Language, DDL) bereit. Mit SAP HANA CDS undABAP CDS gibt es zwei Dialekte dieser Datenbanksprache. Währendmit SAP HANA CDS Views speziell für SAP HANA erstellt werden



202

können, müssen ABAP CDS Views mehrere unterschiedliche Daten-banken unterstützen. Diese unterschiedlichen Anforderungen sindvergleichbar mit den Anforderungen an die ABAP-Open-SQL-Syntax.Auch diese unterstützt nur diejenigen SQL-Artefakte, die von allenDatenbanken unterstützt werden, die für SAP NetWeaver ABAP frei-gegeben sind.

Weitergehende Informationen

Einen ausführlichen Vergleich zwischen ABAP CDS Views und SAP HANACDS Views finden Sie in folgendem Blog im SAP Community Network:

http://scn.sap.com/community/abap/blog/2015/07/20/cds--one-model-two-flavors

Werfen wir nun einen Blick auf den Code eines einfachen CDS Viewsin Listing 5.1, wie Sie ihn auch in der SAP-Online-Hilfe finden:

http://help.sap.com/saphelp_nw75/helpdata/de/7c/078765ec6d4e6b88b71bdaf8a2bd9f/content.htm

@AbapCatalog.sqlViewName: 'CUSTOMER_VW'DEFINE VIEW cust_book_view_entity AS SELECT FROM scustom

JOIN sbookON scustom.id = sbook.customid{

scustom.id,scustom.name,sbook.bookid

}

Listing 5.1 Beispiel für einen ABAP CDS View

Der CDS View cust_book_view_entity erzeugt einen Join auf Basisder beiden Datenbanktabellen sbook und scustom, die beide Teil desbekannten SFLIGHT-Datenmodells sind. Über den oben gezeigtenCDS View kann man nun über die in Listing 5.2 gezeigte ABAP-SQL-Anweisung zugreifen.

SELECT id name bookidFROM cust_book_view_entityINTO TABLE @DATA(result_data)WHERE ... .

Listing 5.2 Nutzung von CDS Views in ABAP-Code


Serviceerstellung – Schritt für Schritt 5.4

203

ABAP Develop-ment Tools for SAP NetWeaver

ABAP CDS Views können mithilfe der Eclipse-basierten ABAPDevelopment Tools for SAP NetWeaver und dem ABAP-CDS-Schlüssel-wort DEFINE VIEW erstellt werden.

Abbildung 5.12 ABAP-CDS-View-Entwicklung – Architektur

Hinweis

Der SQL View und die CDS-Entität werden im selben Namensraum imDDIC angelegt. Daher müssen die beiden Namen unterschiedlich sein. Indem in Listing 5.1 gezeigten CDS View hat daher der SQL View denNamen CUSTOMER_VW, wohingegen die CDS-Entität den Namen cust_book_view_entity trägt.

5.4 Serviceerstellung – Schritt für Schritt

Zu Beginn dieses Kapitels haben wir in Abschnitt 5.2 den Prozess fürdie Erstellung von Gateway-Services vorgestellt. Dieser Prozessbesteht aus den drei Phasen: Datenmodellierung, Serviceimplemen-tierung und Serviceverwaltung.

Abhängig davon, ob Sie sich für die Serviceentwicklung oder die Ser-vicegenerierung entscheiden, können Sie unterschiedliche Vorge-hensweisen wählen. Wir betrachten nun diese verschiedenen Vorge-hensweisen und die darin enthaltenen einzelnen Schritte eingehendaus technischer Sicht.

SAP AS ABAPABAP-Entwicklungswerkzeuge ABAP Dictionary

SQL View

CDS-Entität

Tabellen-definition

DDL Source

DDL EditorAnlegen Aktivieren

Definition

erzeugt

verweist

Speichern

Arbeitsschritte der Benutzer

@AbapCatalog.sqlViewName: 'SQL VIEW'

defineviewCDS_ENTITY…

…

asselectfrom…



204

5.4.1 Datenmodellierung im Service Builder

Die erste Phase bei der Erstellung eines Service in SAP Gateway istdie Datenmodellierung. In dieser Phase soll mithilfe des Service Buil-ders das OData-Datenmodell des Service modelliert werden, das alleArtefakte des OData-Service beschreibt, wie z. B. Entitätstypen, kom-plexe Typen, Attribute und Assoziationen.

Bei der Entwicklung eines Gateway-Service (Serviceentwicklung)oder bei der Generierung eines Gateway-Service mithilfe des Map-pings einer Datenquelle (eine der verschiedenen Möglichkeiten derServicegenerierung) startet man mit dem Anlegen eines Datenmo-dells.

Achtung

Wenn Sie die zweite Methode der Servicegenerierung wählen, also dieRedefinition eines vorhandenen Service, wird kein neues Datenmodelldefiniert, sondern das vorhandene Datenmodell des Service- oder Busi-ness-Objekts wird redefiniert. Die Servicegenerierung mittels Redefinitionwird in Abschnitt 5.4.5 beschrieben. Beachten Sie: Im Service Builderwird die Redefinition als »Überdefinieren« bezeichnet.

Fünf Möglich-keiten für die

Definition

Der Service Builder bietet Ihnen verschiedene Möglichkeiten, einDatenmodell zu definieren. Jede dieser Möglichkeiten adressiertdabei einen bestimmten Anwendungsfall:

� Die erste Möglichkeit zur Anlage eines Datenmodells ist, die ver-schiedenen Artefakte eines OData-Modells manuell im ServiceBuilder anzulegen. Diese Vorgehensweise wird in der Dokumen-tation als deklarative Modelldefinition bezeichnet. Entitätstypen,Assoziationen und Assoziationsmengen werden hierbei manuellmit dem Service Builder angelegt.

� Die zweite Möglichkeit ist, ein komplettes Datenmodell imEDMX-Format zu importieren, das entweder mit dem ODataModel Editor der SAP Web IDE oder mithilfe des Entity DataModelers von Microsoft Visual Studio angelegt wurde. Darüberhinaus kann das Service-Metadatendokument eines bestehendenOData-Service in den Service Builder importiert werden.

� Bei der dritten und vierten Möglichkeit wird ein Entitätstyp aufBasis einer Datenstruktur angelegt, die schon im Business-Suite-System existiert. Bei dieser für den ABAP-Entwickler sehr beque-



205

men Variante werden Entitätstypen entweder auf Basis von DDIC-Strukturen und Tabellen oder aber auf Basis von RFC-/BOR-Schnittstellen generiert.

� Des Weiteren gibt es die Möglichkeit, die (F4)-Hilfen zu nutzen,die im DDIC definiert wurden. Die (F4)-Hilfen können dabei, wieauch RFC-/BOR-Schnittstellen, als Datenquelle genutzt werdenund bieten eine Serviceimplementierung durch reines Mappingan, das heißt Servicegenerierung.

Im Folgenden werden wir alle fünf genannten Optionen detaillierterbeschreiben.

Deklaratives Anlegen eines Datenmodells

EntitätstypenEin Datenmodell kann manuell mit dem Service Builder angelegt wer-den. Diese Methode kann verwendet werden, um Entitätstypen anzu-legen, die auf manuell angelegten Attributen basieren. Die so ange-legten Attribute können auf existierenden DDIC-Typen basieren.

Um einen OData-Service von Grund auf in einem WYSIWYG-Stil(what you see is what you get) zu modellieren, sind jedoch OData-Modellierungstools, wie beispielsweise der OData Modell Editor derSAP Web IDE (siehe auch Kapitel 8, »SAPUI5-Applikationsentwick-lung«) und Microsoft Visual Studio, besser geeignet. In diesem Fallist es jedoch erforderlich, das so angelegte Modell in den ServiceBuilder zu importieren, wie im folgenden Absatz beschrieben wird.

Datenmodell aus Datei

Mit dieser Option kann ein Entwickler ein komplettes Datenmodellimportieren, das entweder in einer EDMX-Datei oder aber in einemMetadatendokument eines existierenden OData-Service gespeichertist. Dies beinhaltet die Definition sämtlicher OData-Artefakte, wiez. B. Entitätstypen, Entitätsmengen, Assoziationen und andere Kom-ponenten.

Wenn Sie ein Datenmodell in ein bereits existierendes Projekt im Ser-vice Builder importieren wollen, so bietet der Service Builder dieMöglichkeit des Reimports einer Datenmodelldatei. Dabei erscheintein Dialog, der dem Entwickler anzeigt, welche Artefakte dem Daten-modell hinzugefügt werden und welche gelöscht werden würden.



206

Import eines Datenmodells via DDIC-Import

DDIC-Typunter-stützung

Um schnell Entitätstypen und komplexe Typen in einem Datenmo-dell anzulegen, können die in einem Business-Suite-System bereitsvorhandenen Datenstrukturen genutzt werden. Dazu können die fol-genden DDIC-Typen in den Service Builder importiert werden:

� Views

� Datenbanktabellen

� Strukturen

Beautification

Wird ein Entitätstyp auf Basis eines DDIC-Typs angelegt, kann schon wäh-rend des Imports ein leicht verständlicher Name gewählt werden. Auch istes möglich, automatisch eine Default-Entitätsmenge anlegen zu lassen,wobei dem Namen des Entitätstyps die Endung »Set« angehängt wird.

Vor SP08 wird der Name des Entitätstyps vom Service Builder vorgeschla-gen. Dieser vorgeschlagene Name wird dabei vom Namen des DDIC-Typsabgeleitet, indem die Unterstriche entfernt werden. Die durch Unterstri-che getrennten Namensteile werden zu einem Namen in CamelCase-Notation zusammengesetzt. Wird beispielsweise vor SP08 eine Strukturmit dem Namen BAPI_EPM_PRODUCT_HEADER importiert, wird der ServiceBuilder als Namen des Entitätstyps BapiEpmProductHeader vorschlagen.Dieser kann durch einen sprechenderen Namen ersetzt werden.

Diese Namenskonvention wird auch für die Attribute der so generiertenEntitätstypen verwendet, so dass statt des originalen Feldnamens SUP-PLIER_NAME der Name der Eigenschaft im generierten Entitätstyp Sup-plierName lauten wird.

Insbesondere die Namen der Entitätsmengen und ihrer Attribute sollteneinfach zu verstehen sein. Dies ist wichtig, da es die Namen der Entitäts-mengen und ihrer Attribute sind, die ein externer Konsument sieht.

Während des Imports einer DDIC-Struktur oder auch direkt danach kannder Entwickler einen als Beautification bezeichneten Prozess starten. Hier-bei kann die Anzahl der Attribute eines Entitätstyps reduziert werden,indem diese einfach aus der Definition des Entitätstyps entfernt werden.Darüber hinaus ist es auch möglich, die generierten Namen einer Eigen-schaft zu ändern, um sie so verständlicher zu gestalten.

Die Reduzierung der Anzahl von Attributen auf das notwendige Maß unddas Umbenennen von Attributen, die nach außen sichtbar sind, sindessenziell, wenn es darum geht, Services zu erstellen, die einfach zu kon-sumieren sind. Das Publizieren von existierenden DDIC-Strukturen ohneverständliche Namen ist kontraproduktiv.

Das Thema Beautification wird eingehend in Abschnitt 7.4.1, »SAP BWEasy Query«, dargestellt.



207

Import eines Datenmodells via RFC/BOR

Funktionsmodul und BAPI-Parameter

Als weitere Möglichkeit für das Anlegen von Entitätstypen und Enti-tätsmengen bietet der Service Builder die Option, die Schnittstellen(Interfaces) von RFC-Funktionsbausteinen oder BAPIs zu importie-ren. Auch hier bietet der Service Builder einen Wizard an, der denEntwickler durch den Importprozess führt.

Die Verwendung von Schnittstellen von RFC-Funktionsbausteinenoder BOR-Objekten ist hilfreich, wenn diese Schnittstellen für denZugriff auf Daten aus dem Business-Suite-System verwendet werden.

Dabei kann die Implementierung durch ABAP-Programmierung (Ser-viceentwicklung) oder durch reines Mapping (Servicegenerierung)erfolgen. Beim Mapping können mithilfe des RFC-/BOR-Generatorsdie Vorgänge einer Entitätsmenge auf die Methoden einer RFC-/BOR-Schnittstelle gemappt werden.

Import einer Suchhilfe (F4-Hilfe)

Als fünfte Option bietet der Service Builder die Möglichkeit, Enti-tätstypen auf Basis existierender F4-Suchhilfen anzulegen. Ähnlichwie bei BOR-/RFC-Schnittstellen können hier Entitätstypen und Enti-tätsmengen auf Basis von Suchhilfen erzeugt werden. Der Assistenterstellt dabei auch das Mapping der Lesevorgänge (Query, Read), sodass kein separater Schritt für die Serviceimplementierung notwen-dig ist.

5.4.2 Serviceregistrierung im SAP-Business-Suite-System

Nachdem ein Datenmodell angelegt wurde, muss dieses noch regis-triert werden. Mit der Registrierung eines Service im Business-Suite-Backend-System wird das Ergebnis der Phase der Datenmodellierungpersistiert.

Dies bedeutet, dass nun Laufzeitobjekte, die für einen Gateway-Ser-vice benötigt werden, mit dem Service Builder generiert werden.Der Service Builder übernimmt dabei für den Entwickler auch dieKonfigurationsschritte, die notwendig sind, um den Service im Busi-ness-Suite-Backend-System zu registrieren.



208

Serviceregistrierung und Serviceverwaltung

Wie Sie in Abschnitt 5.1, »Serviceerstellung – Möglichkeiten«, gesehenhaben, beinhaltet die Phase der Serviceverwaltung innerhalb der Ser-viceerstellung die Aktivitäten, um den Service im Gateway-Server zuregistrieren und zu aktivieren. Dieser Prozess darf nicht mit der Service-registrierung im SAP-Business-Backend verwechselt werden, die nach derDatenmodelldefinition im Backend erfolgt.

In diesem Abschnitt werden wir uns auf die Serviceregistrierung im Busi-ness-Suite-Backend konzentrieren. In Abschnitt 5.4.4 werden wir die Ser-viceverwaltung vorstellen. Serviceregistrierung und Serviceverwaltungunterscheiden sich dabei wie folgt:

� Die Serviceregistrierung ist eine Aktivität im Rahmen der Serviceerstel-lung, die im SAP-Backend ausgeführt wird. Als Ergebnis der Service-registrierung werden die für die Implementierung nötigen Laufzeitarte-fakte im Backend-System generiert.

� Die Serviceverwaltung ist eine Aktivität, die im Gateway-Server ausge-führt wird. Hierbei wird der zuvor im Backend registrierte Service akti-viert, so dass er konsumiert werden kann.

Stub-Class-Erzeugung

Auf der Basis des Datenmodells werden vom Service Builder die kor-respondierende Modell- (MPC) und die Daten-Provider-Klasse (DPC)sowie deren Extensionsklassen generiert.

Die Basisklasse der Modell-Provider-Klasse enthält dabei den ABAP-Code, mit dem das Datenmodell des Service definiert wird. DieImplementierung der Serviceoperationen erfolgt in der Daten-Provi-der-Klasse. Die Extensionsklassen, die vom Service Builder generiertwerden, können dazu verwendet werden, die entsprechendenMethoden der generierten Basisklasse zu redefinieren, das heißt mitkundeneigenem Code zu implementieren. Während die Methodender Basisklassen der Daten-Provider-Klasse und der Modell-Provi-der-Klasse bei der Neugenerierung des Service-Builder-Projektsüberschrieben werden, ist dies bei den Extensionsklassen nicht derFall (weiterführende Informationen zum Thema Modell- und Daten-Provider-Klasse finden Sie in Abschnitt 5.5, »OData-Channel«).

Service-registrierung

Damit die Laufzeitartefakte als Service genutzt werden können, müs-sen einige Konfigurationsschritte ausgeführt werden. Die Ausfüh-rung dieser Schritte wird vom Service Builder unterstützt.



209

Wird ein Projekt im Service Builder zum ersten Mal generiert, mussder Entwickler die Namen der Modell- und Daten-Provider-Klassesowie deren Basisklassen festlegen (siehe Abbildung 5.13). Darüberhinaus muss der Entwickler den technischen Modellnamen (Techni-

cal Model Name) und den Name(n) des techn. Service (Technical

Service Name) festlegen. Letzterer wird beim Publizieren des Serviceim Gateway-Service als Servicename verwendet und kann nichtgeändert werden.

Abbildung 5.13 Dialog der Modell- und Servicedefinition (bei Anmeldung in deutscher Sprache)

Modell- und Daten-Provider-Klasse

Modell- und Daten-Provider-Klasse werden daher durch Customi-zing und nicht programmatisch zu einem Gateway-Service zusam-mengefügt. Diese Konfigurationsschritte werden, wie bereitserwähnt, für den Entwickler durch den Service Builder ausgeführt,wenn ein Projekt zum ersten Mal generiert wird. Der Prozess derModell- und Servicedefinition ist in Abbildung 5.14 dargestellt.

Neben der Modell-Provider-Klasse (siehe Abschnitt 5.5.1) undDaten-Provider-Klasse (siehe Abschnitt 5.5.2) werden zwei weitereRepository-Objekte für das Modell und den Service angelegt, wennder Service im Business-Suite-Backend-System registriert wird.



210

Abbildung 5.14 Service- und Modellregistrierung

5.4.3 Serviceimplementierung

Während der Phase der Serviceimplementierung werden die Metho-den eines Gateway-Service implementiert. Die Implementierungerfolgt dabei entweder durch ABAP-Programmierung oder durch dasMappen der Methoden eines RFC-Funktionsbausteins eines BAPIsoder einer Suchhilfe auf die Attribute eines OData-Modells.

Die Vorgänge, die für eine Entitätsmenge zur Laufzeit ausgeführtwerden können, umfassen Vorgänge zum Anlegen, Lesen, Aktuali-sieren und Löschen von Daten. Für diese werden die folgenden eng-lischen Bezeichnungen verwendet: CREATE, READ, UPDATE, DELETE undQUERY, die daher auch als CRUD-Q-Methoden bezeichnet werden.

An dieser Stelle ist es wichtig, darauf hinzuweisen, dass die Ser-viceimplementierungsphase nur für die Serviceentwicklung und nurfür eine der möglichen Optionen der Servicegenerierung relevant ist,nämlich für das Mapping einer Datenquelle. Für die Generierungvon Services durch Redefinition (im Service Builder als Überdefinie-ren bezeichnet) und für referenzierte Datenquellen (CDS Views)muss der Schritt der Implementierung von Services nicht ausgeführtwerden. Dies liegt daran, dass die Serviceimplementierung auf Basisdes Customizings generiert wird, das im Schritt der Modelldefinitionausgeführt wurde.

SAP Business Suite

SAP-Gateway-Service

Registrierter Service Registriertes Modell

Daten-Provider-Klasse

Modell-Provider-Klasse

Externer Servicename



211

Achtung

Die Servicegenerierung durch Redefinieren (Überdefinieren) wird inAbschnitt 5.4.5 und die Servicegenerierung durch referenzierte Daten-quellen in Abschnitt 5.4.6 näher beschrieben.

Im Folgenden geben wir Ihnen für die Szenarien einen kurzen Über-blick über die Phase der Serviceimplementierung, für die sie relevantist: die Serviceentwicklung und die Servicegenerierung durch Map-ping einer Datenquelle.

Serviceimplementierung durch ABAP-Programmierung

Wie Sie sich erinnern werden, wurde während der Serviceregistrie-rung am Ende der Datenmodellierungsphase eine Daten-Provider-Klasse erzeugt. Während der Phase der Serviceimplementierungwerden diejenigen Vorgänge (Methoden) implementiert, die vomGateway-Service unterstützt werden sollen.

Bei der Implementierung der Vorgänge durch ABAP-Programmie-rung muss der Entwickler die entsprechenden Methoden der Daten-Provider-Klasse (DPC_EXT) implementieren. Die Namen dieserMethoden werden Sie an die zuvor erwähnten CRUD-Q-Methodenerinnern:

� <ENTITY_SET_NAME>_CREATE_ENTITY

� <ENTITY_SET_NAME>_GET_ENTITY

� <ENTITY_SET_NAME>_UPDATE_ENTITY

� <ENTITY_SET_NAME>_DELETE_ENTITY

� <ENTITY_SET_NAME>_GET_ENTITYSET

CRUD-Q-Methoden

Der Service Builder bietet einen bequemen Zugriff auf diese Metho-den. Dazu muss der Knoten Serviceimplementierung wie in Abbil-dung 5.15 aufgeklappt werden.

Von hier aus ist eine einfache Navigation zu dem entsprechendenEintrag einer Entitätsmenge möglich, wobei alle CRUD-Q-Vorgängeder Entitätsmenge angezeigt werden. Durch die Auswahl von Zur

ABAP Workbench aus dem Kontextmenü gelangen Sie direkt in denClass Builder (Transaktion SE24), in dem Sie die Methode derModell-Provider-Klasse implementieren können, die dem Vorgangder Entitätsmenge entspricht.



212

Abbildung 5.15 Serviceimplementierung durch ABAP-Programmierung

Darüber hinaus kann es erforderlich sein, dass noch zusätzlicheMethoden in der Modell-Provider-Klasse redefiniert werden müs-sen, die nicht entitätsmengenspezifisch sind, wie die zuvor erwähn-ten CRUD-Q-Methoden (dies ist z. B. der Fall, wenn für den OData-Service die Unterstützung von Deep-Insert implementiert werdensoll).

Serviceimplementierung durch das Mappen von RFC-/BOR-Schnittstellen

Die Vorgehensweise bei der Implementierung durch das Mappingvon RFC-/BOR-Schnittstellen unterscheidet sich grundlegend vonder Implementierung durch ABAP-Programmierung.

Der Mapping-Prozess wird dadurch gestartet, dass der Entwickler imKontextmenü eines CRUD-Q-Vorgangs einer Entitätsmenge im Ver-zeichnis Serviceimplementierung (Service Implementation) dieOption Zu Datenquelle zuordnen (Map to Datasource) wählt,wie in Abbildung 5.16 gezeigt.

Das Mapping-Tool des Service Builders ermöglicht es dem Entwick-ler dann, Relationen zwischen den Schnittstellenparametern einesRFC-Funktionsbausteins oder BAPIs und den Attributen einer Enti-tätsmenge festzulegen.



213

Abbildung 5.16 Mappen des Vorgangs einer Entitätsmenge zu einer Datenquelle

CRUD-QDie Vorgänge CREATE, READ, UPDATE, DELETE und QUERY (CRUD-Q)einer Entitätsmenge können dabei separat gemappt werden. Dieeigentliche Serviceimplementierung, das heißt der ABAP-Code derMethoden der ABAP-Klasse, die die einzelnen CRUD-Q-Vorgängeimplementieren, wird dabei vom Service Builder auf Basis des zuvorbeschriebenen Mappings erzeugt.

Der Service Builder bietet dem Entwickler eine besondere Unterstüt-zung, wenn ein Entitätstyp durch den Import der Schnittstelle einesBOR-Objekts oder RFC-Funktionsbausteins angelegt wurde. In die-sem Fall schlägt der Service Builder ein geeignetes Mapping vor, wennSie auf Zuordnung vorschlagen klicken (siehe 1 in Abbildung 5.17).Wie in der Abbildung gezeigt, schlägt der Service Builder ein Mappingzwischen der Eigenschaft SoId der Entitätsmenge SalesOrderSet unddes Feldes SO_ID des Exportparameters SOHEADERDATA des RFC-Funk-tionsbausteins BAPI_EPM_SO_GET_LIST vor 2.

Dieser Mapping-Vorschlag konnte automatisch erstellt werden, dader Entitätstyp, auf dem die Entitätsmenge SalesOrderSet basiert,durch den Import des Schnittstellenparameters SOHEADERDATA

erzeugt wurde.



214

Abbildung 5.17 Mapping-Vorschläge – RFC-/BOR-Generator

Werden weitere Vorgänge der Entitätsmenge gemappt, prüft der Ser-vice Builder die bereits existierenden Mappings und leitet aus diesenVorschläge für die zusätzlich zu mappenden Vorgänge ab.

Wurde also zunächst der Query-Vorgang (GET_ENTITYSET) einer Enti-tätsmenge gemappt und möchte man nun noch den Read-Vorgang(GET_ENTITY) mappen, kann der Service Builder einen Vorschlag fürdie Attribute erstellen, die bereits in der GET_ENTITYSET-Methodegemappt wurden.

Serviceimplementierung durch das Mappen von CDS Views

Die Implementierung eines Service durch das Mappen eines CDSViews unterscheidet sich von der Vorgehensweise beim Mappeneiner RFC-/BOR-Schnittstelle.

Um den Assistenten für das Mapping zu starten, müssen Sie denMenüpunkt Zu Datenquelle zuordnen aus dem Kontextmenüeiner Entitätsmenge im Verzeichnis Serviceimplementierung aus-wählen, anstatt dies wie beim RFC-/BOR-Generator bei den einzel-nen Methoden (Read und Query) zu tun.

Der Mapping-Dialog im Service Builder erlaubt es Ihnen dann,sowohl ein Mapping zwischen den Eigenschaften eines CDS Viewsund den Eigenschaften einer Entitätsmenge (siehe Abbildung 5.18)



215

als auch ein Mapping zwischen der Navigationseigenschaft einerEntitätsmenge und der Assoziation eines CDS Views zu definieren(siehe Abbildung 5.19).

Abbildung 5.18 Mapping eines CDS Views – Eigenschaften

Abbildung 5.19 Mapping eines CDS Views – Assoziation

Serviceimplementierung durch das Mappen von F4-Suchhilfen

Die Vorgehensweise bei der Implementierung durch das Mappenvon (F4)-Suchhilfen ist sogar einfacher als die Mapping-Vorgängebeim RFC-/BOR-Generator und einem CDS View. Der Assistent fürden Import einer (F4)-Suchhilfe bietet nicht nur das Anlegen einerEntitätsmenge an, sondern führt auch direkt das Mapping für dieQuery- und Read-Vorgänge der Entitätsmenge durch (siehe Abbil-dung 5.20).



216

Abbildung 5.20 Assistent »Suchhilfe importieren« – automatisches Mapping der Read- und Query-Methode

Wie auch im Fall von CDS Views kann die Implementierung vonändernden CUD-Methoden entweder über eine codebasierte Imple-mentierung oder das Mappen von RFC-Funktionsbausteinen erfol-gen, die einen Schreibzugriff erlauben.

5.4.4 Serviceverwaltung

Die Phase der Serviceverwaltung besteht hauptsächlich aus den bei-den Schritten Serviceregistrierung und Aktivierung im Gateway-Ser-versystem.

Aktivierung undVerwaltung von

Services

Die Registrierung und Aktivierung von Services im Hub-System füh-ren Sie mit der Transaktion /IWFND/MAINT_SERVICE (Activate andMaintain Service) durch. Die Transaktion /IWFND/MAINT_SERVICEwird auch dafür verwendet, alle aktivierten Services im Gateway-Ser-ver zu pflegen. Services müssen gepflegt werden, wenn sie in zusätz-lichen Backend-Systemen registriert wurden oder deaktiviert wer-den sollen, z. B. weil sie nicht mehr benötigt werden. Da der ServiceBuilder der zentrale Einstiegspunkt für die Serviceentwicklung ist,wurde im Service Builder die Funktionalität implementiert, die esdem Entwickler erlaubt, die Transaktion für die Pflege von Servicesim Hub-System (IWFND/MAINT_SERVICE) direkt aus dem ServiceBuilder aufzurufen. Der Aufruf der Transaktion funktioniert auchremote, wenn der Service Builder im SAP-Backend aufgerufen wird.

Der Entwickler kann nun entweder ein Gateway-System aus derListe der Gateway-Systeme im Verzeichnis Serviceverwaltung aus-



217

wählen und aus dem Kontextmenü die Option Registrieren 1 oderauf den Button Bearb. 2 klicken (siehe Abbildung 5.21).

Abbildung 5.21 Aktivieren eines Service im SAP-Gateway-Hub aus dem Service Builder

5.4.5 Servicegenerierung mittels Redefinition

Wie in Abschnitt 5.1, »Serviceerstellung – Möglichkeiten«, darge-stellt, geht es bei dem Prozess der Redefinition um das Generiereneines Service auf Basis eines existierenden Business-Objekts. DieGenerierung erfolgt mithilfe eines Assistenten, bei dem die beidenPhasen der Datenmodelldefinition und der Implementierung zueiner Phase kombiniert werden, die Redefinition genannt wird.

Der so generierte Service muss nun im Gateway-Server aktiviert wer-den (Phase Serviceverwaltung) und kann dann konsumiert werden.Das Ziel der Redefinition ist es, Services mit geringem Aufwandanzulegen.

Bestehende Business-Objekte

In einem Business-Suite-System, wie z. B. SAP Customer RelationshipManagement (SAP CRM), SAP Product Lifecycle Management (SAPPLM) oder SAP Enterprise Asset Management (SAP EAM), gibt eseine Vielzahl verschiedenster Business-Objekte. Obwohl all dieseBusiness-Objekte für unterschiedliche Anwendungsfälle entwickeltwurden, definieren sie doch alle Objekte, Relationen, Aktionen undSuchen, die denen ähneln, die man im OData-Protokoll findet. Daherliegt es nahe, Generatoren zu entwickeln, mit denen man aus dengenannten Business-Objekten OData-Services generieren kann.



218

Erweiterbarkeit Es ist ebenfalls möglich, einen SAP-Gateway-Service auf Basis einesbereits bestehenden SAP-Gateway-Service mittels Redefinition zugenerieren. Dieses Szenario wird verwendet, wenn ein Kunde einenvon SAP ausgelieferten OData-Service erweitern möchte, z. B. denOData-Service einer SAP-Fiori-Anwendung. Die Erweiterbarkeit vonSAP-Fiori-Anwendungen wird detailliert in Kapitel 10, »Erweiterbar-keit«, beschrieben.

Third-Party-OData-Services

Redefinitions-Assistent

Neben der Integration bestehender SAP-Business-Objekte ist es auchmöglich, OData-Services von Drittherstellern zu integrieren. DiesesIntegrationsszenario weist jedoch einige technische Einschränkun-gen auf.

Der Assistent für die Generierung von OData-Services mithilfe derRedefinition (Überdefinition) unterscheidet sich kaum innerhalb dereinzelnen Integrationsszenarien. Wählen Sie eine der möglichenOptionen (basierend auf den installierten Add-ons) aus, startet einAssistent, der Sie durch die folgenden drei Schritte leitet:

1. Auswahl eines Business-Objekts

2. Auswahl der Artefakte der Datenquelle (Datenmodelldefinition)

3. Generierung von Laufzeitartefakten und Serviceregistrierung imBackend (Serviceimplementierung)

Der Assistent startet also mit der Phase der Definition des Datenmo-dells und führt anschließend automatisch die Schritte durch, die zurPhase der Serviceimplementierung gehören. Nachdem der Serviceim Business-Suite-System auf diese Weise registriert und implemen-tiert wurde, muss er nur noch im Gateway-Server aktiviert werden.

Die verschiedenen Integrationsszenarien, die in diesem Abschnittbeschrieben werden, basieren teilweise auf den in Tabelle 5.1 aufge-führten Add-ons. Wenn diese Add-ons in einem Business-Suite-Sys-tem installiert sind, erscheinen wie in Abbildung 5.22 im Kontext-menü des Service Builders die entsprechenden Menüeinträge.

Die meisten Integrationsszenarien sind remote aufrufbar. Das bedeu-tet, dass das zu konsumierende Business-Objekt (z. B. das SPI-Objekt)nicht notwendigerweise auch in dem System vorhanden sein muss,in dem die BEP-Komponente bzw. das spezifische Add-on für dasjeweilige Integrationsszenario installiert ist. Aus diesem Grund ist esprinzipiell möglich, die remotefähigen Integrationsszenarien auch



219

im Gateway-Server zu implementieren. In diesem Fall spricht manvon einem Hub-Deployment mit Entwicklung auf dem Hub.

Abbildung 5.22 Kontextmenüoptionen für das Anlegen eines Datenmodells durch Redefinition (Überdefinieren)

Im Folgenden stellen wir nun die verschiedenen Business-Objektenäher vor, die als Datenquellen dienen können.

Generic Interaction Layer (GenIL)

Bestehende Business-Logik integrieren

Die Integration mit dem Generic Interaction Layer (GenIL) aus SAPGateway bietet dem Entwickler die Möglichkeit, OData-Services aufBasis existierender GenIL-Objekte zu generieren. GenIL fungiert alsSchnittstelle für existierende Business-Logik und bietet die Option,auf verschiedene Business-Objekte über eine einheitliche Schnitt-

Name des Add-ons Integrationsszenario Remote aufrufbar

IW_GIL Generic Interaction Layer (GenIL)

IW_SPI Service Provider Infra-structure (SPI)

SAP_GWFND und IW_BEP Analytical Queries

SAP_GWFND oder IW_BEP und IW_FND

OData-Service (External)

SAP_GWFND oder IW_BEP OData-Service (SAP Gate-way)

Tabelle 5.1 Add-ons für die Generierung von Services auf Basis existierender Datenquellen



220

stelle zuzugreifen, und ist Teil des Business Object Layers (BOL), deraus den zwei folgenden Ebenen besteht:

� GenILDie untere der beiden Ebenen ist ein Dispatcher, der GenIL-Kom-ponenten und deren Modelle zur Laufzeit verwaltet und Anfragenvon darüberliegenden Komponenten auf diejenigen Komponen-ten verteilt, die die angefragten Objekte implementieren.

� BOLDiese zustandsbehaftete Ebene bietet einen performanten Zugriff,indem sie als Puffer für die Benutzeroberfläche dient und so wie-derholte Zugriffe auf die Schnittstellen zu den darunterliegendenBusiness-Objekten vermeidet.

Obwohl der BOL für den SAP CRM Web Client entwickelt wurde, istder GenIL nicht hierauf beschränkt und auch in anderen Integra-tionsszenarien einsetzbar. Ein Beispiel hierfür ist das Webservice-Tool, mit dem aus GenIL-Objekten SOAP-Webservices generiertwerden können, die den Zugriff auf GenIL-Objekte über das SOAP-Protokoll ermöglichen. Auf ähnliche Weise bietet Ihnen SAP Gate-way die Möglichkeit, OData-Services auf Basis von GenIL-Objektenzu generieren (siehe Abbildung 5.23).

Abbildung 5.23 Integration von GenIL mit SAP Gateway

GenIL

ModelleBackend-Anwendung/API

AnwendungsschichtErbt von CL_CRM_GENIL_ABSTR_COMPONENT

Implementiert <IF_GENIL_APPL_MODEL>

CRM Web Client

BOL SAP Gateway

R

R

RR

R



221

Die Knoten, Relationen und Queries des GenIL-Modells werdendabei, wie in Abbildung 5.24 gezeigt, auf entsprechende Entitäteneines OData-Modells gemappt.

Abbildung 5.24 Mapping zwischen GenIL und einem OData-Modell

Obwohl die Schichten BOL und damit auch GenIL für den SAP CRMWeb Client entwickelt wurden, wurde GenIL auch in anderen Busi-ness-Suite-Anwendungen wie SAP ERP Financials und SAP ERPHuman Capital Management (HCM) eingesetzt. Die Integration mitSAP Gateway ist im Add-on IW_GIL enthalten. Dieses muss lokal imBusiness-Suite-System (z. B. in SAP CRM) installiert werden underfordert seinerseits die Installation des Add-ons IW_BEP.

Achtung

Die GenIL-Integration ist nicht remote aufrufbar. Um Services nutzen zukönnen, die auf Basis von GenIL-Objekten generiert wurden, muss dasAdd-on IW_GIL im Business-Suite-System installiert sein, das seinerseitsdas Add-on IW_BEP oder ab 7.40 die Softwarekomponente SAP_GWFNDerfordert.

Service Provider Infrastructure (SPI)

Die Service Provider Infrastructure (SPI) wurde ursprünglich für dieAnwendung SAP PLM entwickelt. Bei SPI handelt es sich um ein Frame-work auf der Anwendungsebene, das verschiedene Konsumenten hat.

GenIL-Schicht

Knoten

Attributsstruktur

Schlüsselstruktur

Relationen

SAP-Gateway-Schicht

Entität

Attribute

Schlüssel

Navigationsattribute(Assoziationen)



222

Das SPI-Framework wird derzeit nicht nur von der Anwendung SAPPLM genutzt, für die es ursprünglich entwickelt wurde, sondern auchvon vielen weiteren Anwendungen der SAP Business Suite.

SPI-Objekte sind remote aufrufbar. Aus diesem Grund ist es nichtzwingend erforderlich, dass das Gateway-Add-on IW_SPI auf demBusiness-Suite-System installiert wird. Da das Add-on die RFC-Schnittstelle des SPI-Layers aufruft, kann es auch auf dem Gateway-Server installiert werden. Das Add-on IW_GIL muss, wie erwähnt,lokal auf dem Business-Suite-System (z. B. SAP CRM) installiert wer-den. Die Integration von SPI mit SAP Gateway ermöglicht es demEntwickler, SPI Application Building Blocks als OData-Services zupublizieren.

Weiterführende Informationen

Weiterführende Informationen zu diesem Thema finden Sie hier:

� SPI-Wiki im SCN: http://wiki.sdn.sap.com/wiki/display/SPI

� SAP-Online-Hilfe: http://help.sap.com/saphelp_crm70/helpdata/en/7c/0f77e9f297402aacb48ca7110c7f2a/frameset.htm

Analytische Queries

Analytische Queries sind die wichtigsten Werkzeuge für den Zugriffauf analytische Daten, die sich entweder in Business-Anwendungen,wie z. B. der SAP Business Suite, oder in Data-Warehouse-Systemenbefinden, wie z. B. SAP Business Warehouse (BW).

Während analytische Queries in der SAP Business Suite den Zugriffauf konsistente, operationale Daten ermöglichen, bieten analytischeQueries im BW-Hub den Zugriff auf konsistente, stark aggregierteDaten aus verschiedenen Unternehmensteilen.

Die Integration von SAP Gateway und SAP BW ermöglicht es Ihnen,die Inhalte von SAP BW über einen OData-Service zu publizieren,der auf Basis von multidimensionalen Ausdrücken (Multidimensio-nal Expressions, MDX) oder SAP BW Easy Query entwickelt wurde.Während die Verwendung der MDX-Queries bereits mit BW-Syste-men ab Release 7.0 möglich ist, benötigt man für die Integration vonBW Easy Query mindestens Release SAP BW 7.30. BW Easy Queriessind jedoch im Vergleich zu MDX-Queries einfacher zu verstehenund zu verwenden.



223

SAP BW Easy Query

SAP BW Easy Query bietet analytische Queries, die bestimmte Vor-aussetzungen erfüllen. Für jede BW Easy Query wird vom System einRFC-Funktionsbaustein erzeugt. Dies geschieht automatisch auf Basisder vorhandenen BW-Query-Definition. Auf Basis dieses RFCs kannein entsprechender OData-Service erzeugt werden.

Um eine analytische Query als SAP BW Easy Query freigeben zu kön-nen, muss der Entwickler die entsprechende Checkbox in denQuery-Attributen im BEx Query Designer (siehe Abbildung 5.25)aktivieren.

Abbildung 5.25 Definition einer Easy Query im BEx Query Designer

Danach erfolgt die Generierung eines RFC-Funktionsbausteins. Diegenerellen Merkmale einer SAP BW Easy Query sind, dass sichMerkmale in den Zeilen und die Kennzahlen in den Spalten befindenund freie Merkmale nicht auf OData gemappt werden.



224

Weiterführende Informationen

Weiterführende Informationen über SAP BW Easy Query können Sie inder SAP-Online-Hilfe finden. Wir empfehlen an dieser Stelle das folgendeDokument:

http://help.sap.com/saphelp_nw73/helpdata/en/b6/53d6c4e26a4504b8971c6e690d2105/frameset.htm

AnalytischeAnnotationen

Dimensionen, Dimensionsattribute und Maße werden als Attributeeines Entitätstyps dargestellt. Entitätstypen, die die Ergebnisse einerMDX- oder BW Easy Query darstellen, sind als sap:semantics=ag-gregate gekennzeichnet.

Tabelle 5.2 zeigt, wie BW-Objekte, z. B. Dimensionen, Dimensions-attribute und Maße, in OData dargestellt werden. Die Tabelle zeigtnur die wichtigsten Annotationen.

Externer OData-Service

OSCI Das Integrationsszenario OData Services Consumption and Integration(OSCI) zielt darauf ab, beliebige (auch Third-Party-) OData-Servicesaus SAP Gateway zu konsumieren und als Gateway-Services zu pub-lizieren. Mit SP07 von SAP Gateway 2.0 ist diese Funktionalität voll-ständig in den Service Builder integriert worden.

Die Integration muss auf dem Gateway-Serversystem implementiertwerden, wo auch das Add-on IW_BEP installiert werden muss. Dies istnotwendig, weil für die Konsumierung von OData-Services dieOData-Bibliothek benötigt wird, die sich nur auf dem Gateway-Ser-ver befindet. Darüber hinaus ist auch das Add-on IW_BEP für die Ent-wicklung des Service auf dem Gateway-Server erforderlich.

SAP-BW-Objekte OData-Repräsen-tation

SAP-Annotation

Cube of Type Query Entitätstyp sap:semantics=aggregate

Dimension Eigenschaft sap:aggregation-role=dimension

Dimensionsattribut Eigenschaft sap:attribute-for=<dimension name>

Maß Eigenschaft sap:aggregation-role=measure

Tabelle 5.2 Analytische Annotationen



225

Mit SAP NetWeaver ABAP 7.40 SP02 werden diese beiden Voraus-setzungen von jedem ABAP-System erfüllt, da bei diesen Systemendie Softwarekomponente SAP_GWFND die entsprechenden Funktiona-litäten enthält.

OData-Service (SAP Gateway)

Erweiterungs-konzept

Der Service Builder erlaubt Ihnen auch die Generierung von Ser-vices, die auf OData-Services in SAP Gateway basieren. Dieses Inte-grationsszenario ist Teil des Erweiterungskonzepts von SAP-Gate-way-Services und kann z. B. für die Erweiterung von Services genutztwerden, die von SAP mit SAP Fiori ausgeliefert werden.

Der redefinierte Service kann zum einen auf die Funktionen des Ori-ginalservice zugreifen und zum anderen um zusätzliche Attributeoder Entitätsmengen erweitert werden. Auf diese Weise ist auch eineErweiterung von Services möglich, die auf Basis der zuvor beschrie-benen Integrationsszenarien entwickelt wurden. Das Vorgehen beider Erweiterung eines von SAP ausgelieferten Gateway-Service undeiner SAPUI5-Anwendung zeigen wir anhand der SAP-Fiori-Refe-renz-App »Approve Purchase Orders« in einer detaillierten Schritt-für-Schritt-Anleitung in Abschnitt 10.3, »SAP-Fiori-Anwendungenerweitern«.

5.4.6 Servicegenerierung mit referenzierten Datenquellen

Mit der Verfügbarkeit von SAP HANA kam es zu einem Paradigmen-wechsel hinsichtlich der Art und Weise, wie Geschäftsanwendungenvon SAP entwickelt werden. Der Zugriff auf Daten in SAP S/4HANAbasiert auf CDS und OData. Dies ist möglich, da CDS nicht nur reineLeseszenarien unterstützt, sondern auch transaktionale, analytischeSzenarien und Szenarien, die auf Suchen beruhen.

Smart TemplatesMithilfe von CDS können Datenmodelle über Annotationen seman-tisch angereichert und durch Smart Templates konsumiert werden.Smart Templates sind »schlau«, da sie beispielsweise in der Benutzer-oberfläche ein Eingabefeld bereitstellen, wenn eine Eigenschaft alssap:updatable gekennzeichnet ist. CDS Views können auch sehrleicht erweitert werden. Mit der Option Referenzierte Datenquel-

len kann der ABAP Entwickler in der Transaktion SEGW dynami-sche OData-Services generieren (siehe Abbildung 5.26).



226

Abbildung 5.26 CDS View als referenzierte Datenquelle in der SEGW

Das bedeutet, dass sich ein OData-Service, der über eine referen-zierte Datenquelle generiert wurde, automatisch an die Definitiondes zugrunde liegenden CDS Views anpasst. Im Service Builder kannder Entwickler die Entitäten und Assoziationen auswählen, die Teildes generierten Service sein sollen.

5.4.7 Servicegenerierung mit Eclipse mit der Option »OData.publish:true«

Ähnlich wie bei den referenzierten Datenquellen im Service Builderkönnen in den ABAP Development Tools in Eclipse aus CDS ViewsOData-Services mithilfe der Option OData.publish:true generiertwerden. Durch das einfache Setzen einer einzelnen AnnotationOData.publish:true im DDL-Quellcode des CDS Views wird aufBasis des CDS Views ein OData-Service im SAP-Backend-Systemregistriert. Technisch wird eine Modell-Provider-Klasse im SAP-Backend generiert und mit einer generischen Daten-Provider-Klasseals OData-Service registriert. Um den OData-Service zu publizieren,muss der Entwickler oder der Administrator den im SAP-Backendregistrierten Service mithilfe der Transaktion /IWFND/MAINT_SER-VICE im SAP-Gateway-Hub aktivieren.

Im Gegensatz zu allen anderen bislang vorgestellten Möglichkeiten,OData-Services zu generieren, wird hier der Service Builder nichtverwendet.


OData-Channel 5.5

227

Es ist geplant, dass OData-Services, die über die Option OData.pub-lish:true publiziert wurden, nicht nur Read-only-Szenarien unter-stützen sollen. Dazu werden parallel zu dem OData-Service entspre-chende BOPF-Objekte generiert. Die so generierten OData-Servicessollen dann auch die Möglichkeit bieten, schreibend auf SAP-Anwendungsdaten zuzugreifen.

5.5 OData-Channel

Nachdem wir die grundlegenden Konzepte der verschiedenen Mög-lichkeiten für die Erstellung von Gateway-Services beschriebenhaben, stellen wir nun das Konzept der OData-Channel-Programmie-rung vor. Diese Einführung ist essenziell für das Verständnis vonKapitel 6, »Serviceentwicklung«, in dem wir die Entwicklung vonOData-Services detailliert beschreiben werden.

Der OData-Channel ermöglicht Ihnen die Entwicklung von Servicesdurch die Definition von Objektmodellen und die Registrierung derentsprechenden Laufzeit, die in der Daten-Provider-Klasse imple-mentiert wurde. Der Vorteil des OData-Channels ist, dass er Ihnengewisse Freiheiten bei der Entwicklung von Services bietet. So kön-nen komplette DDIC-Informationen und lokale Schnittstellen in derSAP Business Suite genutzt werden, um Gateway-Services zu entwi-ckeln.

Darüber hinaus können Query-Optionen auch im Business-Suite-Backend genutzt werden. Dies bedeutet, dass nur die Daten, die vomOData-Client abgefragt wurden, auch aus dem Business-Suite-Systemgelesen und zurück zum Client geschickt werden. Das Ergebnis sindhoch optimierte Services mit einer optimalen Performance, da nurein Minimum an Daten an den Client gesendet wird.

Vier Komponenten von Gateway-Services

Gateway-Services bestehen aus der Sicht des OData-Programmier-modells aus vier Komponenten:

� der Implementierung einer Modell-Provider-Klasse und derenBasisklasse, die die Modelldefinition zur Laufzeit darstellt

� der Implementierung einer Daten-Provider-Klasse und derenBasisklasse, die zur Laufzeit aufgerufen wird, um die Datenanfra-gen auszuführen



228

� dem technischen Servicenamen, der zusammen mit dem techni-schen Modellnamen für die Registrierung des Service im Business-Suite-System genutzt wird

� dem technischen Modellnamen, der zusammen mit dem techni-schen Servicenamen für die Registrierung des Service im Business-Suite-System genutzt wird

Der technische Servicename und der technische Modellname wer-den zusammen mit den Klassennamen auf Basis des Projektnamensim Service Builder automatisch vorgeschlagen.

5.5.1 Modell-Provider-Klasse

Die Modell-Provider-Klasse (Model Provider Class, MPC) ist eineABAP-Klasse, die die Definition des Datenmodells zur Laufzeit er-zeugt. Aus diesem Grund werden alle Modellinformationen, die manim Projekt definiert hat, in der Modell-Provider-Basisklasse generiert.Die Basisklasse der Modell-Provider-Klasse muss deshalb immer dannneu generiert werden, wenn Sie die Modelldefinition in Ihrem Projektändern.

Die Modell-Provider-Klasse ist wichtig, da alles, was man im Service-Metadatendokument eines Service findet, in der Modell-Provider-Klasse auch durch ABAP-Programmierung implementiert wurde(siehe Abbildung 5.27).

Abbildung 5.27 Modell-Provider-Klasse


OData-Channel 5.5

229

KlassenGenau betrachtet, wird die Modelldefinition in zwei verschiedenenKlassen generiert:

� Der Basisklasse 1 (mit dem Suffix _MPC): Technisch wird die Basis-klasse von der folgenden Superklasse 2 abgeleitet: /IWBEP/CL_MGW_PUSH_ABS_MODEL.

� Der Modell-Provider-Klasse 3 (mit dem Suffix _MPC_EXT): DieModell-Provider-Klasse ist die Klasse, die über den technischenModellnamen im Backend registriert wird. In der Modell-Provi-der-Klasse kann man wählen, welche Methoden redefiniert undwelche Methoden von der Basisklasse übernommen werden.

In den meisten Fällen besteht für den Entwickler kein Grund, dieModell-Provider-Klasse zu ändern, die durch den Service Buildergeneriert wurde. Die Ausnahme von dieser Regel ist, wenn Sie einenGateway-Service bauen möchten, der Features besitzt, die derzeitnicht mit dem Service Builder implementiert werden können. In die-sem Fall kann der Entwickler Methoden in, z. B. die DEFINE-Methode 4, der Modell-Provider-Klasse redefinieren.

Modell-Provider-Klasse im Detail

Normalerweise ist es nicht erforderlich, dass der Entwickler Methoden inder Modell-Provider-Klasse redefiniert, die vom Service Builder auf Basisdes OData-Datenmodells generiert wurden. Dennoch schauen wir unsdie Methoden genauer an, die vom Service Builder generiert wurden, umdas darunterliegende Framework besser zu verstehen.

Die DEFINE-Methode in der Basisklasse der Modell-Provider-Klasse, dievom Service Builder generiert wird, enthält Aufrufe für die entitätstypspe-zifischen define_<entity_type>-Methoden. Darüber hinaus enthält dieDEFINE-Methode einen Aufruf der define_Association-Methode, diedie Assoziationen, Assoziationsmengen, Referential Constraints und Navi-gationsattribute erzeugt.

Die Methode GET_LAST_MODIFIED ist wichtig für die Kommunikationzwischen dem Business-Suite-Backend-System und dem Gateway-Server,wenn die Modell-Provider-Klasse im Backend geändert wurde. In diesemFall wird ein Refresh der gecachten Metadaten des Service im Gateway-Server initiiert. Diese Methode sollte nicht manuell geändert werden.

In den entitätstypspezifischen DEFINE-Methoden generiert der ServiceBuilder den ABAP-Code, der die Teile des OData-Modells erzeugt, das dieEntitätstypen und die Entitätsmengen generiert, die auf diesem Enti-tätstyp basieren.



230

Die Attribute eines Entitätstyps werden durch das folgende Coding er-zeugt, und die Attribute, die als Schlüsselfelder markiert wurden, werdenim Code als Schlüsselfelder gesetzt.

lo_property = lo_entity_type->create_property( iv_property_name = 'ProductID'iv_abap_fieldname = 'PRODUCT_ID' ).lo_property->set_is_key( ).

Schlussendlich wird der Entitätstyp an eine DDIC-Struktur gebunden, undeine oder mehrere Entitätsmengen werden angelegt. Beachten Sie: Wennein Entitätstyp an eine existierende DDIC-Struktur gebunden wird, kanner Conversion Exits und die Feldbezeichner der Datenelemente aus demDDIC nutzen. Der mittlere Feldbezeichner mit einer Länge von 15 Zei-chen eines Datenelements wird dabei als Default-Wert für die SAP-spezi-fische Annotation sap:label verwendet.

...lo_entity_type->bind_structure( iv_structure_name ='BAPI_EPM_PRODUCT_HEADER' iv_bind_conversions = 'X' )....lo_entity_set = lo_entity_type->create_entity_set( 'Products' )

In der Methode DEFINE_ASSOCIATION finden Sie den generierten Code,der die Assoziationen, Assoziationsmengen, Referential Constraints undNavigationsattribute des OData-Modells definiert.

5.5.2 Daten-Provider-Klasse und Basisklasse

Die Daten-Provider-Klasse (DPC) ist eine ABAP-Klasse, die alleMethoden bereitstellt, um OData-Aufrufe zu beantworten. Sie wirdzur Laufzeit aufgerufen, um diese weiteren Aufrufe auszuführen.Daher sprechen wir auch von der Laufzeitrepräsentation der Ser-viceimplementierung. Die Daten-Provider-Klasse führt unter ande-rem die Operationen CREATE, READ, UPDATE, DELETE und QUERY aus.

Daten-Provider-Klasse undBasisklasse

Wie im Fall der Modell-Provider-Klasse findet man die Daten-Provi-der-Klasse (Data Provider Extension Class 1) mit der Endung _DPC_EXT und eine Basisklasse (Data Provider Class 2) mit der Endung _DPC. Die Daten-Provider-Klasse erbt von der Basisklasse (siehe Abbil-dung 5.28). Die Daten-Provider-Klasse ist die Klasse, die über dentechnischen Servicenamen registriert wird, das heißt, sie ist dieKlasse, die in einem OData-Service ausgeführt wird.

Entitätsmengen-typische

Methoden

An dieser Stelle ist es wichtig zu erwähnen, dass es neben den enti-tätsmengenspezifischen Methoden 3 auch Methoden gibt, die nichtspezifisch für eine einzelne Entitätsmenge sind.


OData-Channel 5.5

231

Abbildung 5.28 Interface der Daten-Provider-Klasse

Daten-Provider-Klasse im Detail

Für jede Entitätsmenge werden vom Service Builder Methoden angelegt,die vom Framework aufgerufen werden, wenn ein CREATE-, READ-,UPDATE- oder DELETE-Vorgang (CRUD) für die Entitätsmenge aufgerufenwird. Für eine Entitätsmenge mit dem Namen <ENTIYSET> werden die inTabelle 5.3 aufgeführten Methoden angelegt.

Darüber hinaus gibt es weitere Methoden, die nicht nur für eine einzelneEntitätsmenge gelten, sondern für alle Entitätsmengen, die sogenanntennicht entitätsmengenspezifischen Methoden.

Beispiele hierfür sind die Methoden, die die Ausführung von $EXPAND-oder Deep-Insert-Ausdrücken übernehmen, oder die Methoden, die auf-

Name der DPC-Methode HTTP-Verb Ziel

<ENTITYSET>_CREATE_ENTITY POST Entitätsmenge

<ENTITYSET>_DELETE_ENTITY DELETE Entität

<ENTITYSET>_GET_ENTITY GET Entität

<ENTITYSET>_GET_ENTITYSET GET Entitätsmenge

<ENTITYSET>_UPDATE_ENTITY UPDATE Entität

Tabelle 5.3 Entitätsmengenspezifische CRUD-Methoden



232

gerufen werden, wenn ein Funktionsimport aufgerufen wird. Lassen Sieuns daher einen Blick auf diese Beispiele werfen:

� GET_EXPANDED_ENTITY, GET_EXPANDED_ENTITYSETDie Ausführung von $expand-Ausdrücken wird vom SAP GatewayFramework out of the box generisch angeboten, wenn Ihr Modellgeeignete Navigationsattribute enthält und das Handling der Navigati-onsattribute implementiert wurde. Es wird jedoch oft Situationengeben, in denen man die Ausführung der $expand-Aufrufe selbstimplementieren möchte. Ein Beispiel hierfür sind RFC-Funktionsbau-steine wie BAPI_EPM_SO_GET_LIST. Dieser Funktionsbaustein liestzusammen mit den Kopfdaten eines Verkaufsauftrags auch dessen Ein-zelposten. Wird nun die Entitätsmenge, die die Kopfdaten der Ver-kaufsaufträge enthält, so aufgerufen, dass aufgrund des $expand-Aus-drucks zugleich auch die Einzelposten des Verkaufsauftrags gelesenwerden sollen, würden unnötige Zugriffe auf die Datenbank erfolgen,da die Einzelposten schon beim Lesen der Header-Daten aus derDatenbank gelesen wurden.

� CREATE_DEEP_ENTITYDas Gegenstück zum Schlüsselwort $expand ist die Deep-Insert-Anweisung, bei deren Aufruf die CREATE_DEEP_ENTITY-Methode aus-geführt wird. Ein typisches Beispiel hierfür ist der Fall, bei dem zusam-men mit einem Verkaufsauftrag zwingend auch mindestens ein Einzel-posten angelegt werden muss.

� EXECUTE_ACTIONDie EXECUTE_ACTION-Methode ist ebenfalls nicht entitätsmengenspe-zifisch. Diese Methode wird aufgerufen, wenn ein Funktionsimport ineinem OData-Service ausgeführt werden soll. Funktionsimporte ermög-lichen die Ausführung von lesenden und schreibenden Szenarien.

� Funktionsimporte können in einem Business-Szenario eingesetzt wer-den, wenn Daten gelesen oder geschrieben werden müssen und dieseFunktionen nicht durch den Aufruf von CRUD-Q-Methoden abgebil-det werden können.

5.5.3 Technische Überlegungen zur OData-Channel-Entwicklung

Die OData-Channel-Entwicklung kann entweder in der SAP BusinessSuite oder auf dem Gateway-Server stattfinden, wie in Abbildung5.29 dargestellt. Wo aber auch immer Sie entwickeln möchten, dieBEP-Komponente muss in dem entsprechenden System installiertwerden, oder Sie müssen ein System verwenden, das auf SAP Net-Weaver 7.40 SP2 oder höher basiert.


Zusammenfassung 5.6

233

Abbildung 5.29 OData-Channel-Entwicklung auf dem Hub oder in der SAP Business Suite

5.6 Zusammenfassung

Das Anlegen von OData-Services folgt dem bereits vorgestellten Pro-zess der Erzeugung von Gateway-Services. Dieses Vorgehen wirdvon SAP empfohlen und durch den Service Builder optimal unter-stützt.

In diesem Kapitel haben wir Ihnen zunächst das Tooling und den Ent-wicklungsprozess vorgestellt, um Ihnen ein Basis-Know-how für dietechnisch anspruchsvollen Schritt-für-Schritt-Anleitungen zur Ser-viceentwicklung und Servicegenerierung in Kapitel 6, »Serviceent-wicklung«, und Kapitel 7, »Servicegenerierung«, zu vermitteln. InKapitel 6 werden Sie die Vorteile des OData-Channel-Programmier-modells nutzen können, das wir in diesem Kapitel vorgestellt haben.

SAP Business Suite

RFC

RFC BOR BW WF

Consumers

HTTPS

SAP Gateway Hub

OData-Laufzeit & OData-Designzeit & Service Provider Runtime

GW_CORE and IW_FND orSAP_GWFND

IW_BEP or SAP_GWFND

RFC

Consumers

SAP Gateway Hub

OData-Laufzeit

GW_CORE and IW_FND orSAP_GWFND

SAP Business Suite

RFC BOR BW WF

OData-Designzeit & Service-Provider-Laufzeit

IW_BEP or SAP_GWFND

Entwicklung auf dem Hub Entwicklung in der SAP Business Suite


17

2

Vorwort

Die letzten Jahre sind durch ein exponentiell steigendes Daten-wachstum geprägt. Jeder Einzelne produziert inzwischen kontinuier-lich digitale Daten, und wir sind es gewohnt, zu jeder Zeit auf alleunsere Daten zugreifen zu können. Genau da beginnt die digitaleTransformation. Tatsächlich wurden 90 % aller heute verfügbarenDaten in den letzten zwei Jahren generiert. Diese Datenmenge sollsich bis 2020 verzehnfachen.

Die Digitalisierung verändert zunehmend und nachhaltig, wie wirGeschäfte machen. Sie verändert die Wertschöpfung, also die Artund Weise, wie Unternehmen mit ihren Kunden und Partnerninteragieren und sich in bestehenden und neuen Märkten positionie-ren und behaupten. Dies betrifft die komplette Wertschöpfungsketteeines Unternehmens, bis hin zum einzelnen Lieferanten.

Um von der disruptiven Kraft der digitalen (R)Evolution profitierenzu können, braucht es konsequente und kontinuierliche Innovation –sowohl in der unternehmerischen Organisationsstruktur als auch inProzessen und IT-Systemen. In der digitalen Wirtschaft von heutekönnen Unternehmen, unabhängig von ihrer Größe, nur dannerfolgreich sein, wenn sie ihre Geschäftsmodelle evaluieren, über-denken und anpassen. Die Software, mit der diese Anpassungenaktiv vorangetrieben werden, damit sie für die digitale Zukunftgerüstet sind, spielt hier die Schlüsselrolle

Eine Software, um Innovationen im Unternehmen aktiv voranzutrei-ben, ist SAP Gateway. SAP Gateway ist eine auf marktüblichen Stan-dards basierende Technologie, die den einfachen Zugriff von Gerä-ten, Plattformen und ganzen Umgebungen auf SAP-Softwareermöglicht und damit die Umsetzung völlig neuer Geschäftsmodelleerlaubt. Das Framework ermöglicht es, innovative Lösungen mitintuitiven Benutzeroberflächen zu entwickeln und so SAP-Geschäfts-software in sozialen, kollaborativen Umgebungen auf mobilen End-geräten einzubinden. SAP-Applikationen lassen sich über beliebigeProgrammiersprachen und -modelle verbinden, ohne dass Sie überumfangreiches SAP-Wissen verfügen müssen. Ermöglicht wird dies


Vorwort

18

durch die konsequente Verwendung von REST-Diensten und desOData/ATOM-Protokolls.

Die Markteinführung von SAP Gateway im Jahr 2011 verbesserte dieMöglichkeiten für Benutzer im Hinblick auf Erweiterbarkeit undKonnektivität unserer SAP-Lösungen signifikant. Sie können mitihren bevorzugten Werkzeugen neue Applikationen bauen und aus-liefern, ohne dabei die bestehende IT-Landschaft verändern zu müs-sen. Heute ist der Markterfolg von SAP Gateway bewiesen: Mehr als15.000 Kunden nutzen diese Software.

Aber nicht nur Kunden setzen auf SAP Gateway. Große Teile vonSAP S/4HANA basieren auf dem SAP-Gateway-Framework und bie-ten OData-Dienste für SAPUI5-basierte Anwendungen von SAPS/4HANA an.

Mit dieser zweiten Auflage von SAP Gateway und OData halten Siedas Referenzwerk für SAP Gateway in Händen. Sie werden über-rascht sein, was Sie mit SAP Gateway erreichen können, selbst wennSie keine Erfahrung mit SAP-Programmiersprachen haben sollten.Sie werden nicht nur die Prinzipien, Standards und Technologienkennenlernen, sondern auch erfahren, warum SAP Gateway die per-fekte Grundlage bildet, um sich den Herausforderungen der digitalenTransformation von heute zu stellen.

Ich wünsche Ihnen eine spannende Lektüre.

Bernd Leukert Mitglied des Vorstands der SAP SE, Produkte & Innovation


19

3

Einleitung

Es ist gerade einmal 25 Jahre her, dass wir anfingen, im World WideWeb zu surfen. Zu ungefähr der gleichen Zeit begannen wir auch,Mobiltelefone im Alltag zu verwenden. Damals dachten nur wenigeMenschen daran, diese beiden Technologien zusammenzubringen.Noch weniger Menschen rechneten damit, dass die Kombinationdieser beiden Technologien so populär werden würde, wie sie heuteist.

Wenn Sie sich noch an diese Zeit erinnern, werden Sie wissen, dasses Firmen wie Google oder Amazon noch gar nicht gab. Geräte wieiPods, iPhones oder iPads waren noch nicht einmal erfunden. SelbstNokia – viele Jahre einer der Marktführer in der Mobiltelefonsparte –begann gerade erst, sich in diesem Bereich zu etablieren. Wenn Siesich also an die letzten 20 Jahre erinnern können (und wir gehendavon aus, dass manche von Ihnen dies können), ist es leicht zusehen, wie schnell sich der IT-Bereich entwickelt.

Springen wir ins Hier und Jetzt: Heute können wir nicht nur mitunserem PC im Web surfen, wir können dafür auch unser Smart-phone, Tablet, Fernsehgerät oder die Spielekonsole nutzen und nocheiniges mehr. Aus eben diesem Grund stehen wir allerdings vor derHerausforderung, dass wir heute Geschäftsanwendungen für einegefühlt endlose Anzahl an Geräten bzw. Kanälen anbieten müssen.Verschärfend kommt hinzu, dass wir dabei nicht nur technologischeEntwicklungen berücksichtigen müssen, sondern auch sozialeTrends.

In diesem Buch geht es um ein Produkt, das sich dieser Herausforde-rung für SAP-Business-Suite-Anwendungen erfolgreich stellt: SAPGateway. Das Buch nimmt Sie mit auf eine Reise, auf der Sie allesüber SAP Gateway lernen. Wenn Sie SAP Gateway noch nicht ken-nen, sollten Sie diese Reise am besten unternehmen, indem Sie dasBuch vom ersten bis zum letzten Kapitel lesen. Wenn Ihnen aller-dings schon einige Konzepte und Technologien vertraut sind, kön-nen Sie auch andere Reiserouten wählen: Wir haben das Buchbewusst so geschrieben, dass ein Springen zwischen den Kapiteln


Einleitung

20

möglich ist. Um dies noch zu vereinfachen, haben wir das Buch nichtnur in Kapitel strukturiert, sondern zusätzlich auch in mehrere über-greifende Teile.

Teil I: Einstieg

Der erste Teil des Buches besteht aus vier Kapiteln, die sich denGrundlagen von SAP Gateway widmen. Hier sollten Sie Ihre Reisebeginnen, wenn Sie sich über SAP Gateway und verwandte Konzeptewie OData informieren möchten.

Einführung inSAP Gateway

Kapitel 1 ist eine grundlegende Einführung in SAP Gateway underklärt die Motivation, die hinter der Entwicklung des Produktssteht. Das Kapitel schließt mit einer Positionierung des Produkts imKontext anderer SAP-Produkte.

Einführung inOData

OData ist der Industriestandard, den SAP Gateway nutzt. DiesenStandard schauen wir uns in Kapitel 2, »Einführung in OData«, imDetail an.

Architektur undIntegration

Kapitel 3 führt in die Architektur von SAP Gateway ein und beleuch-tet auch die Backend-Konzepte sowie die Integration mit anderenSAP-Schnittstellen.

Deployment-Optionen,

Installation undKonfiguration

Kapitel 4, »Deployment-Optionen, Installation und Konfiguration«,schließt den ersten Teil des Buches mit einer Diskussion der Deploy-ment-Optionen für SAP Gateway ab, die heute in echten, produkti-ven Systemlandschaften zu finden sind.

Teil II: Erstellung von Services

Als erfahrener Reisender, der sich gut mit SAP Gateway und ODataauskennt, haben Sie vielleicht den ersten Teil des Buches komplettübersprungen. Andere Leser wiederum haben den ersten Teil desBuches komplett durchgearbeitet. Gleichgültig, was auf Sie zutrifft,in diesem zweiten Teil werden Sie alles lernen, was Sie über dieErstellung von Services in SAP Gateway wissen müssen.

Erstellung vonOData-Services

mit SAP Gateway

Kapitel 5, »Einführung in die Erstellung von OData-Services mit SAPGateway«, erklärt die Ende-zu-Ende-Entwicklungswerkzeuge undden Entwicklungszyklus, um SAP-Gateway-Services zu erstellen. Esführt Sie in die zwei hauptsächlichen Methoden zur Serviceerstel-


Einleitung

21

lung ein: Serviceentwicklung und Servicegenerierung. Dieses Kapitelist die Basis für die weiteren Kapitel in Teil II.

Service-entwicklung

Serviceentwicklung ist das Thema in Kapitel 6, »Serviceentwick-lung«. In diesem Kapitel lernen Sie, wie Sie Services im SAP-Backendmit ABAP entwickeln. Dabei konzentriert sich das Kapitel auf diepraxisbezogenen Aspekte bei der Erstellung von OData-Services.

ServicegenerierungKapitel 7, »Servicegenerierung«, stellt die zweite Methode derErstellung von Services vor: die Servicegenerierung. Es erklärt dieGenerierung von OData-Services im SAP-Backend.

Teil III: Anwendungsentwicklung

Wie jede Münze zwei Seiten hat, hat auch SAP Gateway zwei Seiten:Bereitstellung (Provisioning, Backend-Services und ihre Entwicklung)und Konsumierung (Consumption, Verwendung und Gebrauch vonBackend-Services in Anwendungen). Während sich der zweite Teildes Buches auf die Bereitstellung konzentriert, ist der dritte Teil aufdie Konsumierung ausgerichtet. Die verschiedenen Kapitel in diesemTeil zeigen aus unterschiedlichen Perspektiven, wie flexibel SAPGateway ist und wie Sie OData-Services in verschiedenen Anwen-dungen konsumieren können.

SAPUI5-Applika-tionsentwicklung

In Kapitel 8 geht es um SAPUI5-Anwendungsentwicklung und SAPFiori. SAPUI5 ist eine Sammlung von Bibliotheken, die Entwicklernutzen können, um Anwendungen zu bauen, die in einem Browserlaufen, der HTML5 unterstützt. Bei SAP Fiori handelt es sich um eineGruppe von Business-Anwendungen, die SAPUI5 nutzen.

SAP Web IDEUm Anwendungen bauen zu können, brauchen Sie eine spezifischeEntwicklungsumgebung. Kapitel 9 widmet sich der Entwicklungs-umgebung für SAP Fiori: der SAP Web IDE.

ErweiterbarkeitKapitel 10, »Erweiterbarkeit«, beschäftigt sich erneut mit SAP Fiori,allerdings liegt der Schwerpunkt in diesem Kapitel auf der Ende-zu-Ende-Erweiterbarkeit und wie man sie anwendet. Das Kapitel decktaußerdem ab, wie OData-Dienste erweitert werden können.

Entwicklung mobiler Apps

Eine der am häufigsten gestellten Fragen im Kontext der Anwen-dungsentwicklung ist die, wie mobile Anwendungen gebaut werdenkönnen. Kapitel 11, »Entwicklung mobiler Apps«, beantwortet diese


Einleitung

22

Frage und führt durch einige Beispiele der Anwendungsentwicklungfür mobile Anwendungen.

Social-Media-Applikations-entwicklung

Kapitel 12, »Social-Media-Applikationsentwicklung«, hat sich denAnwendungen für soziale Medien verschrieben. Hier lernen Sie, wieSie Anwendungen entwickeln, die die Möglichkeiten der sozialenMedien Facebook, Twitter und Sina Weibo in Kombination mitOData und SAP Gateway nutzen.

Entwicklung vonUnternehmens-

anwendungen

In Kapitel 13, »Entwicklung von Unternehmensanwendungen«,schließen wir den dritten Teil des Buches mit Beispielen der Konsu-mierung von OData-Services mit Anwendungen wie Microsoft Exceloder Microsoft SharePoint ab.

Teil IV: Administration

LifecycleManagement

Der vierte Teil des Buches behandelt die Administration von SAPGateway. Zusätzlich zum Deployment von SAP Gateway ist es wich-tig zu verstehen, wie die Software verteilt, das heißt ausgerollt, wird,wie mit Fehlern zu verfahren ist etc. All diese Themen werden inKapitel 14, »Lifecycle Management: Qualitätssicherung, Service-Deployment und Operations«, besprochen.

Sicherheit Theoretisch sollte Sicherheit in Kapitel 14 mitbehandelt werden,allerdings ist dieses Thema so wichtig und so umfangreich, dass wirbeschlossen haben, ihm ein eigenes Kapitel zu widmen. Kapitel 15beschäftigt sich mit der Sicherheit von SAP Gateway, von derAuthentifizierung über die Autorisierung bis hin zum Single Sign-on(SSO).

Teil V: Roadmap

Aktuelle undzukünftige

Entwicklungen

Im letzten Teil unseres Buches findet sich nur Kapitel 16, »Aktuelleund zukünftige Entwicklungen«, das einen Blick auf zukünftigeTrends bietet. Wir werfen dabei einen tiefen Blick in die Kristallku-gel zu Themen wie dem Internet der Dinge (Internet of Things) undGamification.

Zusätzlich zu allen Informationen in diesem Buch haben wir Textver-sionen der Programmierbeispiele erstellt. Diese finden Sie auch aufder Webseite zum Buch unter http://www.sap-press.de/4051 überden Kasten Materialien zum Buch.


Auf einen Blick

TEIL I Einstieg

1 Einführung in SAP Gateway ........................................ 29

2 Einführung in OData .................................................. 65

3 Architektur und Integration ........................................ 121

4 Deployment-Optionen, Installation und Konfiguration ...................................................... 141

TEIL II Serviceerstellung

5 Einführung in die Erstellung von OData-Services mit SAP Gateway ........................................................ 183

6 Serviceentwicklung ..................................................... 235

7 Servicegenerierung ..................................................... 355

TEIL III Anwendungsentwicklung

8 SAPUI5-Applikationsentwicklung ............................... 441

9 SAP Web IDE ............................................................. 461

10 Erweiterbarkeit ........................................................... 491

11 Entwicklung mobiler Apps .......................................... 539

12 Social-Media-Applikationsentwicklung ....................... 573

13 Entwicklung von Unternehmensanwendungen ........... 603

TEIL IV Administration

14 Lifecycle Management: Qualitätssicherung, Service-Deployment und Operations .......................... 647

15 Sicherheit ................................................................... 679

TEIL V Ausblick

16 Aktuelle und zukünftige Entwicklungen ...................... 727


7

Inhalt

Vorwort .................................................................................... 17Einleitung .................................................................................. 19Danksagungen .......................................................................... 23

TEIL I Einstieg

1 Einführung in SAP Gateway .................................... 29

1.1 Moderne Geschäftsanwendungen ........................... 301.1.1 Benutzeroberflächen .................................. 311.1.2 Infrastruktur .............................................. 40

1.2 SAP Gateway für moderne Geschäfts-anwendungen ......................................................... 43

1.3 Installation und Deployment ................................... 491.3.1 Installation ................................................ 501.3.2 Deployment .............................................. 52

1.4 SAP Gateway im Kontext anderer relevanter SAP-Produkte ......................................................... 551.4.1 SAP Gateway for Microsoft ........................ 561.4.2 SAP Enterprise Portal ................................. 571.4.3 SAP Mobile Platform ................................. 591.4.4 SAP HANA ................................................ 611.4.5 SAP Process Integration (PI) and

SAP Process Orchestration (PO) ................. 611.4.6 SAP Business Warehouse (BW) .................. 621.4.7 SAP Fiori ................................................... 631.4.8 SAP API Management ............................... 63

1.5 Zusammenfassung ................................................... 64

2 Einführung in OData ............................................... 65

2.1 OData und REST ..................................................... 652.1.1 Was ist REST? ............................................ 652.1.2 Was ist OData? .......................................... 69

2.2 Struktur eines OData-Service .................................. 742.2.1 Servicedokument ....................................... 772.2.2 Service-Metadatendokument ..................... 81


Inhalt

8

2.3 OData-Operationen ................................................ 842.3.1 Create = Anlegen ....................................... 842.3.2 Read = Lesen ............................................. 852.3.3 Update = Ändern ....................................... 872.3.4 Delete = Löschen ....................................... 88

2.4 OData-Abfrageoptionen .......................................... 882.4.1 Filtern und Projizieren

($filter und $select) .................................... 902.4.2 Sortieren ($orderby) ................................... 942.4.3 Konsumentenseitiges Blättern

($top, $skip und $inlinecount) ................... 952.4.4 Zählen ($count) .......................................... 992.4.5 Expandieren ($expand) ............................... 1002.4.6 Formatieren ($format) ................................ 104

2.5 OData in SAP-Lösungen .......................................... 1062.5.1 Mobile-Productivity-Applikationen ............ 1082.5.2 SAP Fiori .................................................... 1092.5.3 SAP Jam ..................................................... 1092.5.4 SAP Enterprise Portal ................................. 1102.5.5 SAP Gateway for Microsoft ........................ 1102.5.6 SAP Solution Manager ............................... 1112.5.7 SAP HANA ................................................. 1112.5.8 SAP S/4HANA ............................................ 1142.5.9 SAP-zertifizierte Partnerlösungen ............... 114

2.6 OData-Funktionen von SAP Gateway ...................... 1142.7 Was ist neu in OData 4.0? ....................................... 116

2.7.1 Neues JavaScript-Object-Notation-Format ....................................................... 117

2.7.2 Verbesserte Abfragemöglichkeiten ............. 1172.7.3 Cross-Service-Navigation ............................ 1192.7.4 Actions und Functions ................................ 1192.7.5 Vocabularies und Annotationen ................. 120


3 Architektur und Integration .................................... 121

3.1 Gateway-Prinzipien ................................................. 1213.2 Architektur .............................................................. 123

3.2.1 Konsumentenschicht .................................. 1263.2.2 SAP-Gateway-Schicht ................................. 127


Inhalt

9

3.2.3 SAP-Business-Suite-Schicht ....................... 1293.2.4 Evolution der Add-on-Struktur .................. 131

3.3 Integration mit anderen SAP-Technologien ............. 1343.3.1 Remote Function Call ................................ 1353.3.2 Business Object Repository ........................ 1353.3.3 Service Provider Infrastructure ................... 1363.3.4 SAP BW InfoCubes .................................... 1363.3.5 Multidimensional Expressions .................... 1373.3.6 SAP BW Easy Query .................................. 1373.3.7 Generic Interaction Layer ........................... 1373.3.8 SAP Business Process Management ........... 1383.3.9 SAP Business Workflow ............................. 1383.3.10 Core Data Services ..................................... 139


4 Deployment-Optionen, Installation und Konfiguration ................................................... 141

4.1 Einführung in das Deployment von SAP Gateway .... 1414.1.1 Hub-Deployment mit Entwicklung im

SAP-Business-Suite-System ........................ 1444.1.2 Hub-Deployment mit Entwicklung auf

dem Hub ................................................... 1464.1.3 Embedded Deployment ............................. 1494.1.4 Vergleich der Deployment-Optionen ......... 1504.1.5 Gemischte Deployment-Optionen ............. 152

4.2 Vorbereitung für Installation und Konfiguration ...... 1534.3 Schnellstartanleitung .............................................. 156

4.3.1 Schritt 1: Deployment der SAP-Gateway-Add-ons für ältere SAP NetWeaver ............ 158

4.3.2 Schritt 2: Aktivierung von SAP Gateway ..... 1584.3.3 Schritt 3: Erstellung eines

SAP-Systemalias ........................................ 1584.3.4 Schritt 4: Erstellung des SAP-Gateway-

Alias .......................................................... 1604.3.5 Schritt 5: Aktivierung des OPU-Knotens .... 1614.3.6 Schritt 6: Überprüfen der Einstellungen ..... 162

4.4 Installation und Konfiguration im Detail ................. 1644.4.1 Installation der SAP-Gateway-Add-ons ...... 1654.4.2 Grundlegende Konfigurations-

einstellungen ............................................. 165


Inhalt

10

4.4.3 OData-Channel-Konfiguration .................... 1684.4.4 Verbindung von SAP Gateway zur SAP

Business Suite ............................................ 1714.4.5 Business-Enablement-Provisioning-

Konfiguration ............................................. 1754.4.6 Smoke-Tests ............................................... 175


TEIL II Serviceerstellung

5 Einführung in die Erstellung von OData-Services mit SAP Gateway .......................... 183

5.1 Serviceerstellung – Möglichkeiten ............................ 1845.2 Prozess der Serviceerstellung ................................... 1875.3 SAP Gateway – Entwicklungswerkzeuge .................. 192

5.3.1 SAP Gateway Service Builder ...................... 1935.3.2 Weitere Tools zur Unterstützung des

Serviceerzeugungsprozesses ....................... 1965.3.3 ABAP Development Tools for SAP

NetWeaver und Core Data Services Views ......................................................... 201

5.4 Serviceerstellung – Schritt für Schritt ........................ 2035.4.1 Datenmodellierung im Service Builder ........ 2045.4.2 Serviceregistrierung im SAP-Business-

Suite-System .............................................. 2075.4.3 Serviceimplementierung ............................. 2105.4.4 Serviceverwaltung ...................................... 2165.4.5 Servicegenerierung mittels Redefinition ...... 2175.4.6 Servicegenerierung mit referenzierten

Datenquellen ............................................. 2255.4.7 Servicegenerierung mit Eclipse mit der

Option »OData.publish:true« ..................... 2265.5 OData-Channel ....................................................... 227

5.5.1 Modell-Provider-Klasse .............................. 2285.5.2 Daten-Provider-Klasse und Basisklasse ....... 2305.5.3 Technische Überlegungen zur OData-

Channel-Entwicklung ................................. 2325.6 Zusammenfassung ................................................... 233


Inhalt

11

6 Serviceentwicklung ................................................. 235

6.1 Definition des Datenmodells ................................... 2366.1.1 Erstellung eines Projekts ............................ 2376.1.2 Erstellen des Datenmodells ........................ 241

6.2 Serviceregistrierung im SAP-Business-Suite-System .................................................................... 268

6.3 Service-Stub-Erzeugung .......................................... 2746.4 Serviceadministration .............................................. 2776.5 Iterative Serviceimplementierung und

Modellerweiterung ................................................. 2826.5.1 Feed (GET_ENTITYSET) .............................. 2846.5.2 Lesen eines Eintrags (GET_ENTITY) ............ 2896.5.3 Abfrageoptionen ....................................... 2936.5.4 Navigationsattribute .................................. 3026.5.5 Create-, Update- und Delete-Methoden .... 3106.5.6 Funktionsimporte ...................................... 3196.5.7 Medienressourcen ..................................... 3276.5.8 Expand/Self-Expand ................................... 3366.5.9 Deep Insert ............................................... 3456.5.10 Batch ......................................................... 350


7 Servicegenerierung .................................................. 355

7.1 Generierung auf Basis einer RFC-/BOR-Schnittstelle ............................................................ 3587.1.1 Datenmodelldefinition ............................... 3617.1.2 Serviceregistrierung:

Anlegen eines Stubs .................................. 3677.1.3 Serviceverwaltung ..................................... 3677.1.4 Serviceimplementierung:

SalesOrderHeaderSet ................................. 3707.1.5 Serviceimplementierung:

SalesOrderLineItemSet .............................. 3857.1.6 Fazit .......................................................... 396

7.2 Generierung über Suchhilfen ................................... 3967.3 Generierung über CDS Views .................................. 399

7.3.1 Modellierte Datenquellen(Modeled Data Sources) ............................ 405


Inhalt

12

7.3.2 Referenzierte Datenquellen (Referenced Data Sources) ......................... 411

7.4 Generierung über Redefinition ................................ 4167.4.1 SAP BW Easy Query ................................... 4197.4.2 Service Provider Infrastructure (SPI) ........... 430


TEIL III Anwendungsentwicklung

8 SAPUI5-Applikationsentwicklung .......................... 441

8.1 Web-Applikations-Entwicklung ............................... 4428.2 Einführung in SAP Fiori und SAPUI5 ........................ 443

8.2.1 SAP Fiori .................................................... 4448.2.2 SAPUI5 ...................................................... 448

8.3 SAPUI5 installieren .................................................. 4508.4 SAPUI5-Anwendung erstellen ................................. 452

8.4.1 Manuelle Erstellung ................................... 4538.4.2 Erstellung mit Eclipse ................................. 455


9 SAP Web IDE ........................................................... 461

9.1 Installation und Zugriff ............................................ 4629.1.1 Installation on Premise über die lokale

Version ...................................................... 4629.1.2 On-Demand-Zugriff über SAP HANA

Cloud Platform ........................................... 4679.2 Verbindung zu SAP Gateway ................................... 470

9.2.1 Verbindung der lokalen Installation mit SAP Gateway ....................................... 471

9.2.2 Verbindung zwischen SAP Web IDE auf der SAP HANA Cloud Platform und SAP Gateway ....................................... 472

9.3 OData-Beispielservices ............................................ 4749.4 SAPUI5-Anwendungsentwicklung ........................... 4769.5 SAP-Fiori-Referenz-Apps ......................................... 4829.6 OData-Modell-Editor .............................................. 485

9.6.1 OData-Modell-Editor aktivieren ................. 4859.6.2 Dateien im OData-Modell-Editor

importieren ................................................ 4879.7 Zusammenfassung ................................................... 489


Inhalt

13

10 Erweiterbarkeit ....................................................... 491

10.1 Redefinition und Erweiterung von OData-Services ....................................................... 49110.1.1 Redefinition .............................................. 49210.1.2 Erweiterbarkeit auf Feldebene ................... 49710.1.3 Erweiterbarkeit auf Strukturebene ............. 498

10.2 Erweiterbarkeit von SAPUI5-Anwendungen ............ 49910.3 SAP-Fiori-Anwendungen erweitern ......................... 501

10.3.1 OData-Service erweitern ........................... 50310.3.2 Erweiterung der SAPUI5-

Anwendung ............................................... 52710.4 Zusammenfassung ................................................... 537

11 Entwicklung mobiler Apps ...................................... 539

11.1 Übersicht ................................................................ 54111.2 Native mobile Applikationen .................................. 54211.3 Hybride mobile Applikationen ................................ 543

11.3.1 Voraussetzungen ....................................... 54411.3.2 Download und Installation ........................ 54711.3.3 SAP-HANA-Cloud-Platform-Mobile-

Service-App anlegen .................................. 55811.3.4 Entwicklung einer hybriden App ................ 562


12 Social-Media-Applikationsentwicklung ................. 573

12.1 PHP ........................................................................ 57412.2 Facebook ................................................................ 57912.3 Twitter .................................................................... 58612.4 Sina Weibo ( ) ............................................. 59012.5 Zusammenfassung ................................................... 602

13 Entwicklung von Unternehmensanwendungen ...... 603

13.1 SAP Gateway for Microsoft ..................................... 60413.1.1 Installation von SAP Gateway

for Microsoft ............................................. 605


Inhalt

14

13.1.2 SAP Gateway for Microsoft Excel 2010 Add-in ....................................................... 612

13.1.3 SAP Gateway for Microsoft Outlook 2010 Add-in ....................................................... 619

13.2 Microsoft Excel ........................................................ 62713.2.1 PowerPivot ................................................ 62713.2.2 $format=xlsx .............................................. 630

13.3 Microsoft SharePoint/Office 365 ............................. 63113.4 Microsoft LightSwitch ............................................. 63713.5 Microsoft Active Server Pages (ASP) .NET ................ 64213.6 Zusammenfassung ................................................... 643

TEIL IV Administration

14 Lifecycle Management: Qualitätssicherung, Service-Deployment und Operations ...................... 647

14.1 Testen ..................................................................... 64814.1.1 Testen von SAP-Gateway-Services .............. 64914.1.2 Testen einer Client-Applikation .................. 65414.1.3 Best Practices für das Testen von

SAP Gateway ............................................. 65614.2 Service-Deployment ................................................ 658

14.2.1 Transport von Repository-Objekten zwischen SAP-Business-Suite-Systemen ...... 660

14.2.2 Transport der Repository-Objekte und Customizing-Einträge zwischen SAP-Gateway-Serversystemen .................... 662

14.2.3 Versionierung ............................................. 66514.2.4 Transaktion »Services aktivieren und

verwalten« ................................................. 66614.3 Operations .............................................................. 667

14.3.1 Periodische Säuberungsaufgaben ................ 66814.3.2 Monitoring-Überblick ................................ 669


15 Sicherheit ................................................................ 679

15.1 Sicherheit von Netzwerk und Kommunikation ......... 67915.1.1 Transportsicherheit .................................... 680

15.2 Validierung von Eingabedaten ................................. 685


Inhalt

15

15.2.1 Absicherung gegen Cross-Site Scripting (XSS) ......................................................... 686

15.2.2 Maßnahmen gegen CSRF-Angriffe ............. 68715.3 Benutzerverwaltung und Berechtigungen ................ 69115.4 Single Sign-on und Authentifizierungs-

mechanismen ......................................................... 69315.4.1 Basic Authentication .................................. 69615.4.2 SAP-Anmeldetickets mit SAP Enterprise

Portal ........................................................ 69715.4.3 Client-Zertifikate ....................................... 69815.4.4 SAML 2.0 Browser Protocol ....................... 70015.4.5 OAuth ....................................................... 70215.4.6 Kerberos: Integrated Windows

Authentication .......................................... 70415.5 Empfohlene Authentifizierungsmechanismen .......... 704

15.5.1 HTML5-Webanwendung ........................... 70515.5.2 Desktop-Anwendungen ............................. 70715.5.3 Mobile Anwendungen (direkter Zugriff) ..... 70815.5.4 SAP Mobile Platform ................................. 71015.5.5 Cloud ........................................................ 71215.5.6 Webserver ................................................. 71415.5.7 Business-to-Consumer ............................... 714

15.6 Read Access Logging ............................................... 72015.7 Zusammenfassung ................................................... 724

TEIL V Ausblick

16 Aktuelle und zukünftige Entwicklungen ................. 727

16.1 Cloud Computing: HCI OData Provisioning ............. 72716.1.1 Cloud-Plattformen ..................................... 72916.1.2 Geschäftsnetzwerke (Business Networks) ... 73016.1.3 Infrastruktur und Lifecycle Management .... 730

16.2 Gamification ........................................................... 73216.3 Internet der Dinge (Internet of Things, IoT) ............. 73416.4 API-Management ................................................... 73516.5 Zusammenfassung ................................................... 736


Inhalt

16

Anhang ............................................................................ 737

A Weiterführende Konzepte .................................................. 737

B SAP Gateway und SAP API Management ........................... 769

C Die Autoren ....................................................................... 797

Index .......................................................................................... 801


801

Index

$batch 684, 722$format=xlsx 630

A

ABAP Core Data Services � CDS ViewABAP Development Tools for SAP

NetWeaver 399ABAP-Repository-Eintrag 240Abfrage 85Abfrageoptionen 293

$expand 336$filter 294$inlinecount 297, 299$orderby 301$select 293$skip 297$top 297

Abfragespracheanalytische Abfrageoptionen 118Filterung expandierter Entitäts-

mengen 118Access-Token 581Agentry SAP Framework 763, 764aktualisierbar 245analytische App 445Anforderungen an Benutzer-

oberflächenBeweglichkeit 36Innovation 34Integration 37Sicherheit 38TCO 38Unterbrechungsfreiheit 39Verfügbarkeit 35Wartung 38

anlegbar 244Annotationsmodell für referenzierten

Service 239Anwendungsprotokoll-Viewer 673Apache 545API

analysieren 794anlegen 778Definition 769

API (Forts.)Entwickler 772erzeugen 772konfigurieren 783Management 735Portal 773testen 782veröffentlichen 786verwenden 788

Append-Struktur anlegen 504Application Programming Interface

� APIApplikations-Log 670Assoziation 75Atom 104AtomPub 69Attribut 75Authentifizierung 693, 696

anonymer Zugriff 715B2C 714Basic Authentication 696Cloud 712Kerberos 704mobile Anwendung 708OAuth 702SAML 718SAML 2.0 Browser Protocol 700SAP Mobile Platform 710SAP-Anmeldeticket und SAP Enter-

prise Portal 697Webapplikation 705Webserver 714X.509-Client-Zertifikat 698

Autorisierung, Konfiguration 169

B

BAPI 355Basisklasse 230, 270Batch 350Beautification 427Benachrichtigung 744

Pull 745Push 745

Benutzerverwaltung 691


802

Index

Berechtigung 691BEx Query Designer 63BOL 220BOR-Objekt 262Bower 545Breakpoint 751Build Hybrid Companion

App screen 555Business Application Programming

Interface � BAPIBusiness Enablement Provisioning

(BEP) 175Business Object Layer � BOLBusiness-Suite-Schicht 125, 129

C

Cascading Stylesheets Level 3 (CSS3) 448

CCMS 669, 670CDS 139CDS View 201, 355, 357, 399Cloud

Anwendung 728Geschäftsnetzwerk 730Infrastruktur und Lifecycle

Management 730Plattform 729Service 728

Cloud Computing 42Consumer Adaptation 122Conversion Exit 378Cordova 545Core Data Service � CDSCross-Service-Navigation 119Cross-Site Request Forgery

(CSRF) 687Cross-Site Scripting (XSS) 686CRUD-Q 270CSRF-Token 688CSS 442CUD-Methode 310

Create 310Delete 318Update 314

D

Dateisystem 479Datenmodell

DDIC 256Definition 73deklaratives 241EDMX 251erstellen 241Import aus DDIC 256Import über BOR/RFC 261Import über EDMX-Datei 251RFC/BOR 261

Datenmodelldefinition 204DDIC importieren 206deklaratives Modell 204, 205EDMX importieren 204Modell erzeugen 241Projekt erzeugen 237RFC/BOR importieren 207

Daten-Provider-Klasse 209, 230, 270Extensionsklasse aktivieren 312

Datensicherheit 679DDIC-Import, Beautification 206DDL Source 401Deep Insert 345Delete 67Delta Query Protocol 761Delta-Request-Log-Komponente 763Delta-Support 761Deployment 52, 142

Einführung 141eingebettetes 52, 143, 149, 151Hub 53Installation und Konfiguration 151Kosten 151Option »Kombination« 152Option »Vergleich« 150Performance 151Wartung 151

Developer Portal 788Digital Transformation 35, 770DPC � Daten-Provider-KlasseDrosselung 742


803

Index

E

Easy Query 222, 355, 419Service aktivieren 425Service-Neugenerierung 429

Eclipse 452edm:Action 120edm:Function 120EDMX 486Eingabedaten validieren 679, 685Embedded Deployment 52, 143,

149, 151Enterprise Procurement Model

CRUD-Q 475read-only 475

Entität 75Entitätsdatenmodell 82Entitätsmenge 75, 78, 242, 521

benennen 247ergänzen 516erstellen 247

Entitätstyp 75, 242erstellen 242erweitern 497, 511SUPPLIER 303

Entwicklung mobiler Apps 539Entwicklung von Unternehmens-

anwendungen 603Microsoft Excel 627Microsoft LightSwitch 637Microsoft Office 365 631Microsoft SharePoint 631

E-Procurement 718Error Log � FehlerprotokollErstellung, deklarative 241Extension Include 497Extensionsklasse 269

F

Facebook 573, 579Applikation testen 585Basiseinstellung 580Entwickler-Account anlegen 579

Fact-Sheet-App 445Feed 284Fehlerprotokoll 198, 669, 671, 748,

750, 753filterbar 245

Freitext-Suche 113Funktionsimport 319, 322

G

Gamification 33, 732Gateway Productivity Accelerator

(GWPA) 451, 467Gateway-Komponente

GW_CORE 50IW_BEP 51IW_FND 50, 51IW_FNDGC 51IW_GIL 51, 52IW_HDB 51IW_PGW 51IW_SCS 51IW_SPI 51SAP_GWFND 50

Gateway-Konsument 126Gateway-Prinzip 122Gateway-Schicht 125, 127Generic Channel 129GenIL 54, 219, 355GET 66GET_ENTITYSET 284Git Repository 469GUID 683

H

HCI OData Provisioning 727HEADERDATA 265, 266, 287, 292Hello World 453HTML 442HTML5 448HTML5/SAPUI5 441, 443, 448,

469, 540Anwendung anlegen 452Browser 443Erstellung mit Eclipse 455erweitern 499, 527Framework 452Installation 450iView 58manuelle Erstellung 453Master-Detail-Kapsel-

Applikation 562


804

Index

HTML5/SAPUI5 (Forts.)Master-Detail-Kapsel-Offline-

Applikation 562Mindestanforderung 449SAP Web IDE 476Starter-Kapsel-Applikation 562

HTML5-/SAPUI5-App 541HTML5-/SAPUI5-Entwicklung 542Hub-Deployment 659

Entwicklung auf dem Hub 146, 151Entwicklung im Business-Suite-

System 144, 151Hybrid-App

Test im Android-Emulator 567Test mit Cordova-Fassade 566

hybride App 543entwickeln 562Voraussetzungen 544

hybride Container-App 541hybride Entwicklung 541

I

ICF-Service 166IDE 127Identity Provider (IdP) 694Industrietrend

Gamification 732Internet der Dinge 734

Infrastructure as a Service (IaaS) 42Infrastruktur 40Installation 50Installation und Konfiguration

Business Enablement Provisioning (BEP) 175

OData-Channel 168Profilparameter 167Smoke-Test 175

Internet Communication Framework (ICF) 696

Internet Communication Manager (ICM) 696

Internet der Dinge 734IW_GIL 134IW_PGW 134IW_SPI 134

J

Java Development Toolkit (JDK) 545Java SE 7 464JavaScript 442, 448Jetty 458JSON 104, 117

K

Kapsel CLI 545Kerberos 704Konsumentenschicht 124, 126

M

Mandantenfeld 258MDS 405MDX � Multidimensionaler AusdruckMedienressource 327Microsoft ASP.NET 642Microsoft Excel 604, 627

Entwicklung 627PowerPivot 627

Microsoft LightSwitch 604, 637Entwicklung 637

Microsoft LightSwitch Designer 640Microsoft Office 365 604, 631,

632, 636Microsoft SharePoint 604Middle Tier � MittelschichtMIME-Typ 327, 329Mittelschicht 125Modeled Data Source � MDSModell-Provider-Klasse 209, 228, 269Model-View-Controller 448, 500Monitoring 669MPC � Modell-Provider-KlasseMultidimensionaler Ausdruck 63,

222Multiple Origin Composition

(MOC) 737, 740MVC � Model-View-ControllerMy Inbox-App 134MySQL 575


805

Index

N

Nachrichtenfenster 272native Applikation 541native mobile Applikation 542Navigationsattribut 75, 302, 519.NET 642NuGet 608Nullwerte möglich 245

O

OASIS 71OAuth 589, 702OData 61

Beispielservice 474, 475Client-Bibliothek 74Designprinzip 73Einführung 65mobile Applikation 108Protokoll 73SAP 106SAP Business Suite on

SAP HANA 112SAP Enterprise Portal 110SAP Fiori 109SAP HANA 111SAP Jam 109SAP S/4HANA 114SAP Solution Manager 111Server 480Service erweitern 491Servicedokument 77Serviceentwicklung 235Service-Metadatendokument 81Service-Redefinition 492vs. OData 4.0 117

OData 4.0 116Actions und Functions 119Annotation 120Cross-Service-Navigation 119JSON-Format 117Query-Sprache 117Roadmap 116Vocabularies und Annotationen 120vs. OData 2.0 117

OData Software Development Kit für PHP 575

OData.publish true 226OData-Abfrageoperation 88

Expansion 100Filtern und Projizieren 90Formatierung 104konsumentenseitiges Blättern 95Sortieren 94Zählen 99

OData-Batch-Verarbeitung 350OData-Channel

Einstellungen 173Entwicklung 232Konfiguration 168

OData-Modell-Editor 485aktivieren 485grafischer Viewer 487modellbasierter Codeassistent 487schemabasierter Codeassistent 486

OData-Operation 84Create 84Delete 88Query 85single Read 86Update 87

OData-Service 74aktivieren 277erweitern 503Queries 282redefinieren 506registrieren 277, 507Servicedokument 74Service-Metadatendokument 74Struktur 74

Offline-Szenario 761OpenUI5 442Operation

Anwendungsprotokoll 668periodischer Auftrag 668täglicher Job 668Tipps zur Fehlersuche 677

Orion 469


806

Index

P

p2 464Patch 67Performance-Trace 670, 674, 755Perl 575PHP 574

Download 575Proxy-Klasse 576

Platform as a Service (PaaS) 42Policy Designer 783POST 66PowerPivot 627, 629ProductCollection 247PUT 67, 87

Q

Query 85Query-Sprache 117Quota 784

R

RAL 720RDS 411Read Access Logging � RALRedefinition 416, 491

bestehender Gateway-Service 418Easy Query 419externer OData-Service 418GenIL 417Operational Data Provisioning 417SAP BW 417SPI 417, 430, 431

Referenced Data Source � RDSreferenzierte Datenquelle � RDSRepository-Objekt 662

Transport 660, 662REST 65

einheitliche Schnittstelle 69Link 68Mehrfachrepräsentation einer

Ressource 69URI 67zustandslose Kommunikation 69

RFC-/BOR-Generator 185, 355RFC-/BOR-Generierung

Create 378, 391

RFC-/BOR-Generierung (Forts.)Datenmodelldefinition 361Delete 384, 394Prozess 360Query 370Serviceimplementierung 370, 385Serviceverwaltung 367Single Read 376, 387Stub-Erzeugung 367Update 382, 393

RFC-Destination 171RFC-Funktionsbaustein 262Routing 738

S

SADL 408SAML 700SAML 2.0 Browser Protocol 700SAP API Management 63, 769

Architektur 771Developer Portal 788SAP-Gateway-Services

konsumieren 772SAP AppBuilder 461SAP Ariba 730SAP Business Suite 59, 174SAP Business Suite on SAP HANA 61,

112SAP BW 62, 63SAP Developer Center 49SAP Enterprise Portal 57, 58,

110, 697SAP Fiori 109, 441, 443, 491

Applikationsschicht 447Apps-Referenzbibliothek 483Architektur 445, 446Ausführungstyp 483Designer 482Einführung 444Entwickler 482erweitern 501Manage Products 484Referenz-App 482SAP Web IDE 447Service 483Smart Business Cockpit 113Startseite 444


807

Index

SAP Gateway 121Add-on 142Add-on-Struktur 131Aktivierung 158, 172Anforderungen an Anwendungen 47Architektur 121, 123Customizing 165Datenquelle 121Deployment 52, 141Einführung 19, 29für moderne Geschäfts-

anwendungen 43Installation 50, 141Java 60Konfiguration 141, 164, 165Lifecycle Management 647Monitoring 669OData-Funktionen 114Operations 647, 667SAP API Management 769SAP NetWeaver 7.40 52SAP S/4HANA 114Schnellstart 156Service-Deployment 647Service-Enablement 160Sicherheit 679Softwareanforderung 52, 154Testen 647Versionierung 665verwandte Produkte 55weiterführende Konzepte 737

SAP Gateway Client 196, 649SAP Gateway for Microsoft 56,

110, 604Cloud 57Erweiterung und

Update Manager 609Installation 605Voraussetzungen 605

SAP Gateway for Microsoft Excel 2010 612

SAP Gateway for Microsoft Outlook 2010 619

SAP Gateway Productivity Accelerator for Microsoft (GWPAM) 604

SAP Gateway Service Builder 235SAP HANA 61, 111SAP HANA Cloud Connector 469

SAP HANA Cloud Platform 447, 452, 462, 476, 729, 775Dokumentation 467Verbindung zu SAP Gateway 472Zugriff auf die SAP Web IDE 467

SAP HANA Cloud Platform Cockpit 469

SAP HANA Live 113SAP HCP � SAP HANA Cloud PlatformSAP HCPms

App 558Gerätekonfiguration 565

SAP Hybrid-App Toolkit Companion 544

SAP Hybrid-App Toolkit Connector 544

SAP Jam 109SAP Mobile Platform 59, 60, 541SAP Mobile Platform SDK 544, 547SAP NetWeaver 7.00 168SAP NetWeaver 7.01 168SAP NetWeaver 7.02 168SAP NetWeaver 7.31 168SAP NetWeaver 7.40 52, 168SAP Process Integration 61SAP River RDE 461SAP S/4HANA 61, 112, 114

cloudbasiert 114on Premise 114SAP Gateway 114

SAP Service Marketplace 155SAP Solution Manager 111, 670, 674SAP Solutions for the Internet of

Things 735SAP Support Portal 49SAP Web IDE 447, 452, 461

Hybrid-App 563Installation 462lokale Installation (on Premise) 462lokale Installation

mit SAP Gateway 471on Demand über SAP HCP 467Plug-in 544Projekt anlegen 528SAPUI5-Anwendungs-

entwicklung 476Verbindung zu

SAP Gateway 470, 472


808

Index

SAP Web IDE Hybrid-App Toolkit Add-on 543aktivieren 556Download 549installieren 550starten 557

SAP-Anmeldeticket 697SAP-Demosystem 474SAP-Gateway-Add-on

Deployment 158Installation 165

SAP-Gateway-Alias erstellen 160SAP-Systemalias

erstellen 158für Applikationen 172

Schnittstellenparameter 264Security Assertion Markup Language

� SAMLService Adaptation Definition

Language � SADLService austauschen 531Service Builder 130, 183, 193, 196,

235, 278, 485Service Catalog 478Service mit SAP-Annotationen 239Service mit vokabularbasierten

Annotationen 239Service Provider 131, 695Service Provider Infrastructure 221,

355, 430, 434Service URL 479Serviceadministration 277Service-Builder-Werkzeug

Fehlerprotokoll 198Katalogservice 200

Service-Deployment 658Serviceentwicklung 184, 235

Datenmodelldefinition 236Navigationsattribut 302Serviceadministration 277Serviceimplementierung 282Serviceregistrierung 268Stub erzeugen 274

Serviceerstellung 187Datenmodelldefinition 188

ServiceerzeugungDatenmodelldefinition 204Serviceimplementierung 210Serviceverwaltung 216

Servicegenerierung 185, 358Redefinition 217, 416RFC/BOR 358

Serviceimplementierung 210, 274, 282RFC-Generierung 212, 215Serviceentwicklung 211

Serviceredefinition 217analytische Query 222GenIL 219Service Provider Infra-

structure (SPI) 221Serviceregistrierung 268Serviceverwaltung 216Sicherheit 679Sina Weibo 573, 590

Benutzer-Account anlegen 591PHP SDK 598

Single read 289Single Sign-on 693

SAP NetWeaver 699SMP � SAP Mobile PlatformSOAP 771Social Media 573

Entwicklung 573Facebook 579PHP 574Sina Weibo 590Strategie 574Twitter 586

Soft State Based Query Result Cache 766

Software as a Service (SaaS) 42sortierbar 245Source URI 327SPI � Service Provider InfrastructureSQL View 403SQRC 766SuccessFactors 109Suchhilfe 356Systemalias 279

Transport 663, 665


809

Index

T

technischer Modellname 209, 271, 279

technischer Servicename 271, 279test.html 484Testen 648

Best Practice 656Service 649

testFLP.html 483testFLPService.html 484Throttling 742Timeless Software � zeitlose Softwaretransaktionale App 445Twitter 573, 586

Account anlegen 586OData-Tweet 590SDK 586TwitterOAuth-Bibliothek 587

U

UI 30UI-Element

ausblenden 530hinzufügen 532, 535

Umgebungsvariable 544URI 67

V

Versionierung 659, 665Virenscanner-Schnittstelle 691Visual Studio Microsoft

LightSwitch 637

W

Workspace 478

X

X.509-Client-Zertifikat 698XAMPP 575Xcode 547XML 672

Z

zeitlose Software 121zentrale Benutzerverwaltung 691


Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne emp-fehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstellung von der E-Book-Fassung des vorgestellten Buches abweichen können. Diese Leseprobe istin all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungs-rechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Carsten Bönnen arbeitete seit 2001 bei SAP in der Betreuung des Visual Composers und später als Product Manager für die UI-Strategie. Inzwischen ist er Director of Technology Strategy für das Strategic Alliance Management Microsoft.

Volker Drees ist Produktexperte für SAP Gateway im Bereich SAP HANA Platform I/O Gate-way und hat umfangreiche Erfahrung in den Bereichen ABAP-Entwicklung, ERP-Implemen-tierung, SAP CRM, Mobile Sales, Mobile Asset Management und Mobile Infrastructure.

André Fischer ist seit der Einführung des Produktes im Jahre 2011 im Produktmanagement von SAP Gateway tätig. Mit mehr als 20 Jahren Erfahrung in verschiedenen SAP-Technologi-en ist André Fischer für viele SAP-Kunden und Partner ein geschätzter Ansprechpartner.

Ludwig Heinz leitet seit Anfang 2014 die IT-Abteilung bei dem europaweit agierenden Recycling-Unternehmen Theo Steil GmbH. Er war von 2006 bis 2013 für die itelligence AG tätig und arbeitete dort seit 2011 eng mit SAP an der Verbesserung von SAP Gateway.

Carsten Strothmann leitet die global agierende SAP-Gateway-CPS-Organisation (Customer and Product Success) bei SAP und kümmert sich weltweit um ausgewählte Kundenprojekte, Enablement-Themen und eine intensive Einbringung der Kundenperspektive in die Quali-tätssicherung von SAP Gateway.

Carsten Bönnen, Volker Drees, André Fischer, Ludwig Heinz, Karsten Strothmann

SAP Gateway und OData809 Seiten, gebunden, 2. Auflage 2016 79,90 Euro, ISBN 978-3-8362-4019-2

www.sap-press.de/4051

SAP-Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/sap-gateway-und-odata_4051/?GPP=lpn

https://www.facebook.com/rheinwerkverlag

https://plus.google.com/118435207805510651040

http://twitter.com/rheinwerkverlag

Documents

SAP Gateway und OData - s3-eu-west-1.amazonaws.com · Dieses Buch hilft Ihnen, über SAP Gateway Drittanwendungen mit Ihrem SAP-System »sprechen« zu lassen. ... die auf SAP NetWeaver