OData und SAP Gateway -...

LeseprobeIn dieser Leseprobe lernen Sie die einzelnen Schritte und Werkzeuge kennen, die fr die Erstellung von Gateway-Services erforderlich sind. Dabei wird sowohl die Entwicklung als auch die Generierung von Gateway-Services behandelt.

Carsten Bnnen, Volker Drees, Andr Fischer, Ludwig Heinz, Karsten Strothmann

OData und SAP Gateway681 Seiten, gebunden, Juni 2014 69,90 , ISBN 978-3-8362-2538-0

www.sap-press.de/3417

Einfhrung in die Erstellung von OData-Services mit SAP Gateway

Inhaltsverzeichnis

Index

Die Autoren

Leseprobe weiterempfehlen

Wissen aus erster Hand.

http://www.sap-press.de/3417?GPP=lpnmailto:?body=Leseproben-Empfehlung:%20OData%20und%20SAP%20Gateway%20von%20SAP%20PRESS,%20http://gxmedia.galileo-press.de/leseproben/3417/leseprobe_sappress_odata_sap_gateway.pdf&subject=Leseprobe:%20OData%20und%20SAP%20Gateway

179

In diesem Kapitel erlutern wir die einzelnen Schritte und Werkzeuge, die fr die Erstellung von Gateway-Services erforderlich sind. Dabei behandeln wir sowohl die Entwick-lung als auch die Generierung von Gateway-Services.

5 Einfhrung in die Erstellung von OData-Services mit SAP Gateway

Wie Sie in Kapitel 2, Einfhrung in OData, und 3, Architektur und Integration, 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 ermglicht.

Die Anzahl der OData-Services, die mit SAP Gateway als Teil des Standards ausgeliefert werden, ist klein. Dies wird sich auch in Zukunft nicht ndern, da OData-Services von Natur aus sehr granular und auf einen bestimmten Anwendungsfall zugeschnitten sind. OData-Services, die auf der Gateway-Technologie basieren, werden daher als Teil von SAP-Produkten wie SAP Fiori oder mobilen SAP-Anwendungen ausgeliefert.

Bei der Entwicklung von Anwendungen ist es hufig 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-stndnis des Prozesses der Serviceerstellung besonders wichtig.

Das zentrale Werkzeug, um Services in SAP Gateway zu definieren und zu implementieren, ist der SAP Gateway Service Builder (Service Builder), der mit der Transaktion SEGW gestartet wird. Nachdem Sie einen Service im Service Builder erstellt und diesen auf dem Gate-way-Server publiziert haben, kann dieser direkt in jedem beliebigen Konsumenten verwendet werden. Der Service Builder bietet alle

180

Einfhrung in die Erstellung von OData-Services mit SAP Gateway5

Funktionalitten fr die Gateway-Serviceentwicklung aus einer Hand und wird ergnzt durch zustzliche Support-Tools.

In bestimmten Fllen knnen Sie hiermit auch ausgewhlte Schritte in anderen Tools ausfhren und die Ergebnisse dann in den Service Builder importieren (so z. B. die Nutzung des OData-Modelers fr die Erstellung eines OData-Modells).

Das Hauptziel dieses Kapitels ist es, Ihnen einen berblick ber den Prozess der Erstellung von OData-Services zu geben, den wir dann in Kapitel 6, Serviceentwicklung, und Kapitel 7, Servicegenerie-rung, ausfhrlicher diskutieren. Dazu bieten wir Ihnen in Abschnitt 5.1, Serviceerstellung berblick, einen kurze bersicht ber die einzelnen Schritte, die in den beiden Arten der Serviceerstellung (Serviceentwicklung und Servicegenerierung) ausgefhrt werden.

In Abschnitt 5.2, SAP Gateway Entwicklungswerkzeuge, stellen wir Ihnen dann das wichtigste Werkzeug fr die Serviceerstellung vor: den SAP Gateway Service Builder. Danach werden weitere Tools beschrieben, die fr die Erstellung und Verwaltung von Gateway-Services eingesetzt werden.

In Abschnitt 5.3, Serviceerstellung Schritt fr Schritt, werden wir uns dann detailliert mit den drei Hauptschritten der Serviceerstel-lung befassen: Datenmodelldefinition, Serviceimplementierung und Serviceverwaltung.

Auerdem betrachten wir folgende Themen der Serviceerstellung: das Redefinieren von bestehenden Business-Suite-Services und die Wiederverwendung vorhandener Gateway-Services in Mash-ups. Das Entwicklungsmodell, das der Entwicklung von Services in SAP Gateway zugrunde liegt, ist der sogenannte OData-Channel. Diesen stellen wir Ihnen in Abschnitt 5.4, OData-Channel, vor.

5.1 Serviceerstellung berblick

Der vorliegende Abschnitt gibt Ihnen einen berblick ber die Vor-gehensweise bei der Serviceerstellung. Die Serviceerstellung wird dabei bewusst vereinfacht als eine Abfolge sequenzieller Schritte dar-gestellt, das heit als ein sogenanntes Wasserfallmodell.

181

Serviceerstellung berblick 5.1

In der Realitt erfolgt die Ausfhrung der einzelnen Schritte nicht sequenziell, sondern vielmehr iterativ. Zum besseren Verstndnis beginnen wir mit der Darstellung der vereinfachten Vorgehens-weise, bevor wir den detaillierten Prozess eingehend vorstellen.

Es gibt zwei Mglichkeiten, um OData-Services mit SAP Gateway zu erstellen:

ServiceentwicklungDer klassische Ansatz ist die Programmierung von Gateway-Ser-vices in ABAP. Die Programmierung in ABAP ist einerseits uerst flexibel und ermglicht die Erstellung von sehr effizienten Ser-vices. Sie erfordert andererseits jedoch ein gewisses Ma an tech-nischem Know-how, hnlich dem, das fr die Entwicklung von Klassen und RFC-Funktionsbausteinen bentigt wird.

ServicegenerierungEin zweiter Weg ist die Generierung von Gateway-Services, bei der es drei Arten gibt:

RFC-/Suchhilfe-Generierung: Hierbei knnen Sie einen Service mit dem RFC/BOR-Generator oder auf Basis einer Suchhilfe erstellen.

Redefinieren (Redefinition): Das Redefinieren erlaubt die Defi-nition eines Gateway-Service auf Basis einer existierenden Datenquelle oder eines existierenden Gateway-Service.(Beachten Sie: Diese Option wird im Service Builder als ber-definieren bezeichnet.)

Model Composition: Der als Model Composition bezeichnete Prozess erlaubt ein Mash-up existierender Gateway-Services. Als Ergebnis erhlt man einen neuen Service, ohne dass der oder die bestehenden Services verndert werden mssen.(Beachten Sie: Diese Option wird im Service Builder als Berck-sichtigen bezeichnet.)

Von den beiden genannten Mglichkeiten fhrt die Servicegenerie-rung blicherweise schneller zu Ergebnissen und ist weniger auf-wendig. Die Generierung von Services ist jedoch nicht so flexibel wie die Serviceentwicklung und daher vor allem fr die Erstellung von einfachen Services geeignet. Die Optimierung von generierten Services ist nur eingeschrnkt mglich, wenn keine ABAP-Program-mierung erfolgen soll.

182


In den meisten Fllen wird man sich fr die Serviceentwicklung ent-scheiden, da die Vorteile den erhhten Entwicklungsaufwand recht-fertigen. Der Entwicklung von OData-Services mit SAP Gateway haben wir mit Kapitel 6, Serviceentwicklung, einen ausfhrlichen Praxisteil gewidmet.

Die Generierung von Gateway-Services ist jedoch dann interessant, wenn Sie ber geeignete Datenquellen verfgen, wie z. B. GenIL-Objekte, Service-Provider-Objekte, BW Queries wie eine Easy Query oder aber geeignete RFC-Funktionsbausteine oder BAPIs.

Auch die Generierung von Gateway-Services auf Basis der zuvor genannten SAP-Business-Objekte stellen wir in einem eigenen Praxis-teil (Kapitel 7, Servicegenerierung) vor.

Serviceerstellungs-prozess

Unabhngig davon, ob Sie sich fr die Entwicklung oder die Generie-rung von Services entscheiden, folgen Sie in beiden Fllen dem Ser-viceerstellungsprozess in SAP Gateway. Dieser Prozess teilt sich in drei Hauptphasen auf: Definition des Datenmodells, Serviceimplementierungund Serviceverwaltung. Je nachdem, ob Sie sich fr die Generierung oder die Entwicklung eines Service entschieden haben, mssen Sie innerhalb dieser Phasen unterschiedliche Schritte ausfhren, es gibt jedoch auch Schritte, die sowohl bei der Entwicklung als auch bei der Generierung von Services ausgefhrt werden mssen.

Bevor Sie mit der Erstellung eines Service beginnen knnen, muss dieser zunchst definiert werden. Hierbei werden Art und Umfang des Service festgelegt. Dies geschieht idealerweise in Abstimmung mit dem Entwickler der Client-Applikation, sodass Sie wissen, wel-che Daten in der Anwendung bentigt werden und wie Sie diese aus dem Business-Suite-System erhalten. Sind diese Voraussetzungen geklrt, knnen 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 wie Entittstypen, Entittsmengen, Assoziationen und weitere Kompo-nenten angelegt, die Ihr Service nutzen wird (die zuvor genannten Komponenten wurden in Kapitel 2, Einfhrung in OData, nher erlutert). Nach der Definition des Datenmodells mssen zunchst die Repository-Objekte generiert und im Business-Suite-System registriert werden. Danach knnen Sie mit der nchsten Phase der Serviceerstellung fortfahren, der Serviceimplementierung.

183


Serviceimplemen-tierungsphase

In der Phase der Serviceimplementierung werden die Methoden des Service implementiert, die von dem Service untersttzt werden sol-len. Abhngig davon, ob dies durch Serviceentwicklung oder Ser-vicegenerierung geschieht, folgt man unterschiedlichen Implemen-tierungspfaden.

Bei der Serviceentwicklung werden die Methoden, die vom Ser-vice untersttzt werden, mithilfe von ABAP-Programmierung implementiert.

Bei der Servicegenerierung haben Sie die folgenden drei Mglich-keiten, einen Service zu generieren:

Wenn Sie den RFC-/BOR- bzw. Suchhhilfe-Generator verwen-den, erfolgt die Implementierung durch das Mapping der Vor-gnge einer Entittsmenge auf die Methoden eines RFC-Funk-tionsbausteins, eines BOR-Objekts (Business Object Repository) oder einer Suchhilfe.

Im Fall der Redefinition gibt es keinen separaten Schritt fr die Implementierung des Service. Sie mssen lediglich den Daten-modellierungsschritt ausfhren. Die Implementierung des Ser-vice wird dann auf Basis des Customizings generiert, das im Datenmodellierungsschritt durchgefhrt wurde.

Auch bei der Modellerzeugung gibt es keinen Serviceimple-mentierungsschritt, da hier ein oder mehrere Services in ein neues Modell eingebunden wurden.

Serviceverwal-tungsphase

In der dritten Phase des Prozesses der Serviceerstellung, der Service-verwaltung, wird der Service im Gateway-Server aktiviert, sodass er im Servicekatalog auffindbar ist. Dies bedeutet, dass der Service von einem Client konsumiert werden kann.

Die drei Phasen Datenmodelldefinition, Serviceimplementierung und Serviceverwaltung sind in Abbildung 5.1 dargestellt. Dabei sind die Schritte, die in der Serviceentwicklung und in der Servicege-nerierung durchgefhrt werden, mit unterschiedlichen Farben gekennzeichnet. Die Schritte, die sowohl bei der Serviceentwicklung als auch bei der Servicegenerierung durchgefhrt werden, sind mit zwei Farben gekennzeichnet.

Obwohl wir die beiden Methoden der Serviceerstellung (Servicege-nerierung und Serviceentwicklung) getrennt dargestellt haben, ist es mglich, beide Anstze zu kombinieren.

184


Abbildung 5.1 Prozess der Serviceerstellung

So knnen Sie z. B. einen OData-Service erstellen, bei dem eine Entittsmenge mithilfe des RFC-/BOR-Generators durch Mapping (Servicegenerierung) implementiert wird, whrend eine zweite Entittsmenge durch ABAP-Programmierung (Serviceentwicklung) implementiert wird.

Inkrementeller Serviceerstellungs-

prozess

Wie bereits erwhnt, haben wir den Prozess der Serviceerstellung der bersichtlichkeit halber zunchst klar strukturiert und als Abfolge sequenzieller Schritte dargestellt. Dieses Wasserfallmodell eignet sich gut, um die drei verschiedenen Phasen der Serviceerstel-lung zu erlutern.

In realen Entwicklungsprojekten wird man die Reihenfolge, in der die einzelnen Schritte ausgefhrt werden, so anpassen, wie es fr die Serviceerstellung am besten ist.

Lediglich bei der Serviceverwaltungsphase handelt es sich um eine Ttigkeit, die nur einmal ausgefhrt wird. Sobald ein Service im Backend registriert und im Gateway-Hub aktiviert (das heit verf-fentlicht) wurde, mssen diese Einstellungen in der Regel nicht mehr angepasst werden.

Datenmodell-definition

Service-verwaltung

OData-Service-definition in

Transaktion SEGW

ABAP-Programmierung

Serviceregistrierung und Aktivierung auf dem Hub

Service-implementierung

= Serviceentwicklung

= Servicegenerierung

Manuelle Modell-

Definition

Import-Datenmodell

(EDMX)

Import-DDIC-Struktur /

Suchhilfe

Import-RFC-/BOR-Schnittstelle

Mapping von RFC-/BOR-Methoden oder Mapping von Suchhilfen

Redefinition von Services (GenIL, SPI,

SAP BW, SAP Gateway,

OData)

Model Composition (Einbinden

von Gateway- Services)

185


In allen anderen Phasen der Serviceerstellung sollten Sie hingegen einen inkrementellen Ansatz verfolgen: Legen Sie einen Service an oder Teile eines Service , fhren Sie diesen aus, und testen Sie ihn. Danach knnen Sie den Service so lange verndern, bis er schlielich allen Anforderungen gengt. Innerhalb des Prozesses der Erstellung eines OData-Service knnen das Datenmodell und auch die Ser-viceimplementierung mehrfach gendert werden.

Ein Ansatz, der in realen Entwicklungsprojekten oft genutzt wird, ist, dass man die Phasen der Serviceimplementierung und der Ser-viceverwaltung in umgekehrter Reihenfolge ausfhrt. Generiert man nach der Datenmodelldefinition zunchst das Service-Builder-Projekt und fhrt anschlieend direkt den Schritt der Servicever-waltung aus, um den Service zu aktivieren, kann man zunchst die Metadaten des Service (Servicedokument und Service-Metadaten-dokument) kontrollieren, obwohl der Service noch keine Funktio-nalitt bietet. Anschlieend kann man den Service Stub inkremen-tell implementieren.

Abbildung 5.2 stellt diesen inkrementellen Prozess der Serviceer-stellung dar. Der Prozess basiert auf Abbildung 5.1; zustzlich haben wir noch inkrementelle Schritte hinzugefgt. Die inkremen-tellen Schritte sind dabei durch die durchgezogenen Pfeile gekenn-zeichnet, die die bergnge zwischen den Phasen der Datenmodel-lierung und der Serviceimplementierung darstellen. Die Phasen sind durch horizontale Ksten dargestellt. Die gepunktete Linie zeigt dagegen die einmalige Aktivierung eines Service in der Phase der Serviceverwaltung.

Ausnahmen

Die Publizierung eines Service ist eine einmalige Angelegenheit, sofern nicht weitreichende nderungen am Service vorgenommen werden. Die Registrierung eines Service fr weitere Business-Suite-Systeme ist ein Bei-spiel fr solch eine weitreichende nderung.

nderungen in der Serviceimplementierung oder dem Datenmodell eines Service, der bereits publiziert wurde, knnen in Entwicklungssystemen hingegen ohne zustzliche Aktivitten umgesetzt werden.

Beachten Sie:

Da die Datenmodelle in Produktivsystemen aus Performancegrnden gecacht werden, mssen bei nderungen in der Datenmodelldefinition die Caches im Backend und im Gateway-Server aktualisiert werden.

186


Abbildung 5.2 Inkrementeller Prozess der Serviceerstellung

5.2 SAP Gateway Entwicklungswerkzeuge

SAP Gateway stellt eine Reihe von Werkzeugen zur Verfgung, um die unterschiedlichen Anforderungen aus den Bereichen Entwick-lung, Test und Betrieb von OData-Services zu adressieren.

An dieser Stelle werden wir die Tools fr den Betrieb von SAP Gate-way nicht nher erlutern und uns stattdessen auf die Tools fokussie-ren, die im Rahmen der Serviceentwicklung zum Einsatz kommen. Wir werden daher zunchst im folgenden Abschnitt 5.2.1 den SAP Gateway Service Builder nher betrachten. Anschlieend werden wir in Abschnitt 5.2.2, Weitere Werkzeuge neben dem Service Buil-der: Tools zur Untersttzung beim Serviceerzeugungsprozess, die weiteren Tools vorstellen, die Sie beim Prozess der Erstellung von OData-Services untersttzen und die in optimaler Weise auf das Zusammenspiel mit dem Service Builder abgestimmt sind.

Data SourceService

redefinieren

Model Composition (Einbinden

von Gateway- Services)

Datenmodelldefinition

Serviceimplementierung

Serviceverwaltung

Einmalige Durchfhrung

Inkrementell

Map-RFC-/BOR-Operation

Service-Registrierung und Aktivierung auf dem Hub

Import-Datenmodell

(EDMX)

Import-DDIC-Struktur /

Suchhilfe

Import-RFC-/BOR-Schnittstelle

Manuelle Modell-

definition

ABAP-Programmierung

OData-Service-definition

187

SAP Gateway Entwicklungswerkzeuge 5.2

5.2.1 SAP Gateway Service Builder

Der Service Builder bietet dem Entwickler alle Funktionen, die fr die Modellierung und die Entwicklung von OData-Services in SAP Gateway erforderlich sind. Dies umfasst sowohl die Programmie-rung als auch die Generierung von OData-Services. Darber hinaus bietet der Service Builder einen direkten Zugriff auf zustzliche Funktionen, die fr einen Entwickler interessant sind, wie z. B. die Serviceverwaltung und die Servicevalidierung. Der Service Builder untersttzt den gesamten Entwicklungszyklus (Development Lifecy-cle) eines OData-Service in SAP Gateway und kann ber die Transak-tion SEGW gestartet werden (siehe Abbildung 5.3).

Abbildung 5.3 SAP Gateway Service Builder

Dabei eignet sich der Service Builder sowohl fr erfahrene Entwick-ler als auch fr Anfnger in der ABAP-Programmierung und Nicht-Entwickler.

Erfahrenen Entwicklern bietet der Service Builder die Mglichkeit der Entwicklung von Services durch ABAP-Programmierung und damit ein Maximum an Flexibilitt bei der Serviceimplementierung. Fr die Datenmodellierung knnen Entwickler jedoch den OData-Modeler des Service Builders nutzen, der den ABAP-Code der Modell-Provider-Klasse generiert.

188


Anfnger in der ABAP-Programmierung und Nicht-Entwickler hinge-gen werden die Mglichkeiten der Servicegenerierung zu schtzen wissen, die die Erstellung von OData-Services erlauben, ohne dass der Entwickler hierfr auch nur eine Zeile ABAP-Code schreiben muss.

Der Service Builder ermglicht die Anzeige und Definition von OData-Services an zentraler Stelle. Dies umfasst die Laufzeitartefakte (Modell-Provider-Klasse (MPC), Daten-Provider-Klasse (DPC), Modell- und Servicedefinition), OData-Artefakte (Entittsmenge, Entittstypen und Attribute) sowie die verwendeten Datenquellen.

Projektbasierte Entwicklung

Die Modellierungsumgebung des Service Builders untersttzt die pro-jektbasierte Entwicklung. Alle entwicklungsrelevanten Objekte wer-den in diesen Projekten zusammengefasst. Das Anlegen eines Projekts im Service Builder ist der Startpunkt fr jede Art von Serviceerstel-lung mit dem Service Builder. Damit wird dem Serviceentwickler die Mglichkeit geboten, alle entwicklungsrelevanten Artefakte in Pro-jekten an einer zentralen Stelle zu bndeln. Der Service Builder erlaubt es dem Entwickler darber hinaus, wie in Abbildung 5.4gezeigt, mehrere Projekte zu ffnen und zu bearbeiten. In dem Bei-spiel wurden die Projekte ZGWSAMPLE und ZPRODUCT geffnet.

Abbildung 5.4 Projektbasierte Entwicklung

189


Mit dem Service Builder soll dem Entwickler die bestmgliche Untersttzung bei der Erstellung von OData-Services geboten wer-den, sowohl programmatisch als auch ber die Generierung von OData-Services.

Es gibt jedoch technische Restriktionen, was mit dem Service Builder modelliert, entwickelt oder generiert werden kann. Bestimmte OData-Features mssen gegebenenfalls manuell implementiert wer-den, und bestimmte Methoden sind gegebenenfalls nicht in einem redefinierten Business-Objekt verfgbar.

Das Ergebnis der Serviceentwicklung bzw. Servicegenerierung sind in jedem Fall ABAP-Klassen, die auf dem Programmiermodell des OData-Channels basieren. Entwickler haben jederzeit die Mglich-keit, den Sourcecode der ABAP-Klassen zu analysieren, um die Funk-tionsweise eines Service besser zu verstehen. Dann knnen sie den (generierten) Code gegebenenfalls anpassen, indem sie die entspre-chenden Methoden der Modell- bzw. der Daten-Provider-Klasse redefinieren, die ihre Funktionalitt von den Basisklassen erben und bei der Neugenerierung eines Service im Gegensatz zur Basisklasse nicht berschrieben werden.

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 Teil der SAP-Basis und wird ber die Softwarekomponente SAP_GWFND ausge-liefert. Daher ist es ohne besonderen Aufwand mglich, in auf SAP Net-Weaver 7.40 basierenden Systemen mit dem Service Builder OData-Ser-vices zu entwickeln.

Da der Service Builder als Teil der BEP-Komponente in der Regel (aber nicht zwingend) auf dem Business-Suite-System installiert ist, werden sowohl das Servicemodell (die Modell-Provider-Klasse, MPC) als auch die Serviceimplementierung (Daten-Provider-Klasse, DPC) auf diesem System definiert. Dies ist wichtig, um zu verstehen, welche ABAP-Repository-Objekte, wie z. B. Data-Dictionary-Elemente (DDIC, z. B. Strukturen und Datenelemente), referenziert werden knnen, wenn RFCs, BAPIs oder Klassenmethoden aufgerufen werden.

190


5.2.2 Weitere Werkzeuge neben dem Service Builder: Tools zur Untersttzung beim Serviceerzeugungsprozess

Wie bereits erwhnt, ist das zentrale Tool fr die Erstellung von Ser-vices der SAP Gateway Service Builder.

Darber hinaus bietet SAP Gateway eine Reihe von Tools an, die den Entwicklungsprozess von Gateway-Services untersttzen. Mithilfe dieser Tools ist es z. B. mglich, Services frhzeitig zu testen oder die Kommunikation eines Service zu tracen.

Aus diesem Grund geben wir Ihnen in diesem Abschnitt einen kur-zen berblick ber einige dieser Funktionalitten. Eine ausfhrliche Darstellung der Entwicklungs- und Administrationswerkzeuge von SAP Gateway finden Sie in Kapitel 13, Lifecycle Management: Qua-littssicherung, Service-Deployment und Operations.

Integrierte Testumgebung

Testen und Troubleshooting

Der Gateway-Client kann sowohl fr das Testen als auch fr das Troubleshooting verwendet werden und ist ein im Gateway-Server eingebauter REST-Client.

Der Gateway-Client kann aus dem SAP GUI heraus ber die Transak-tion /IWFND/_CLIENT gestartet werden. Nachdem man einen Service auf dem Gateway-Server aktiviert hat, kann dieser dort umgehend mit dem Gateway-Client getestet werden, wie in Abbil-dung 5.5 gezeigt.

Hierzu whlt man zuerst die HTTP-Methode, wie z. B. GET, PUT, POST, PATCH, oder DELETE 2. Dann gibt man die URI seines Requests im Eingabefeld Request URI ein 3. Falls erforderlich, knnen auch bestimmte HTTP-Header gesetzt werden. Der Body des HTTP-Requests kann entweder manuell eingegeben werden oder man ldt ihn aus einer Datei hoch 4. Darber hinaus ist es mglich, die Funk-tionalitt Als Anf. Verwenden zu nutzen. Damit kann der Inhalt einer Update-Anforderung auf Basis der HTTP-Response eine Lesean-forderung 5 erzeugen. Der HTTP-Request kann nun ausgefhrt wer-den, wenn man Ausfhren auswhlt 1.

Eine besonders ntzliche Funktionalitt des Gateway-Clients ist, dass man Testflle in einer Datenbank speichern kann.

191


Abbildung 5.5 Gateway-Client Anforderung erstellen

Der Testfall, der in Abbildung 5.5 gezeigt wird, ist einer von mehr als 70 Testfllen, die als Testgruppe mit dem Namen CORE_SAMPLES aus-geliefert werden. Diese Testgruppe enthlt Testflle fr die Standard-test-Gateway-Services TEA_TEST_APPLICATION und RMTSAMPLEFLIGHT. Beachten Sie, dass die Testflle der Testgruppe CORE_SAMPLES in Ihrem System wie in Abbildung 5.6 angelegt werden mssen.

Abbildung 5.6 Anlegen der Testflle der Testgruppe CORE_SAMPLES

Wenn Sie einen HTTP-Request als Testfall gespeichert haben, kn-nen Sie anschlieend den HTTP-Returncode festlegen, der bei der Ausfhrung des HTTP-Requests vom Service zurckgeliefert werden soll. Ein HTTP-Request kann dabei mehrere gltige Returncodes

HTTP Request Body

Execute Button HTTP-Methode Request-URI-Eingabefeld

HTTP-Response

192


zurckliefern (z. B. 200, 401, 402 und 403). Aus diesem Grund kn-nen auch im Gateway-Client mehrere gltige Rckgabewerte sowie Intervalle spezifiziert werden (z. B. 201 401-403).

Ein oder mehrere Testflle knnen dann mit dem Gateway-Client ausgefhrt werden. Die Ergebnisse werden in einer Tabelle SAP NetWeaver Gateway Mehrfachtest mithilfe von Ampeln ange-zeigt, wobei sowohl der erwartete als auch der tatschliche HTTP-Returncode in der Tabelle aufgefhrt werden.

Fehlerprotokoll

Das Fehlerprotokoll (Error Log) ist ein weiteres Tool, das fr Entwick-ler bei der Fehlerbehandlung von groem Nutzen ist.

Das Fehlerprotokoll wird im Gateway-Server ber die Transaktion/IWFND/ERROR_LOG aufgerufen. Im Business-Suite-System gibt es auch ein Backend-Fehlerprotokoll mit einer sehr hnlichen Benutzer-oberflche. Mithilfe des Backend-Fehlerprotokolls knnen Fehler analysiert 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 Gateway-Client integriert. So ist es beispielsweise mglich, einen HTTP-Request, der von einem OData-Konsumenten versendet wurde, erneut auszufhren. Whlen Sie dazu wie in Abbildung 5.7 Wiedergabe Gateway Client.

Abbildung 5.7 Transaktion /IW_FND/ERROR_LOG

193


Logging und Tracing

Eine weitere Mglichkeit der Fehlerbehandlung bietet die Analyse von Protokolleintrgen, die fr das SysLog und das Anwendungspro-tokoll von SAP Gateway von einem OData-Service erzeugt werden. Das SysLog kann ber die Transaktion SM21 aufgerufen werden, whrend der Gateway-Anwendungsprotokoll-Viewer ber Transak-tion /IWFND/APPS_LOG aufgerufen werden kann.

Katalogservice

Jedes Gateway-System bietet einen Servicekatalog (Service Cata-log), ber den man eine Liste aller Services eines Gateway-Servers erhalten kann (Abbildung 5.8). Der Katalog ist ein OData-Service, und die Liste der verfgbaren Services kann man ber die folgende URL abfragen:

http://:/sap/opu/odata/iwfnd/CATALOGSERVICE/Catalog Collection

Abbildung 5.8 Servicekatalog Servicedokument

OpenSearchDer Katalogservice untersttzt das OpenSearch-Protokoll. Entwick-ler oder Entwicklungsumgebungen knnen daher Services ber eine Freitextsuche anhand der Servicebeschreibung finden. Hierzu muss die folgende URL aufgerufen werden:

http://:/sap/opu/odata/iwfnd/CATALOGSERVICE/Service Collection/OpenSearchDescription.xml

194


5.3 Serviceerstellung Schritt fr Schritt

Zu Beginn dieses Kapitels haben wir den Prozess fr die Erstellung von Gateway-Services vorgestellt. Dieser Prozess besteht aus den drei Phasen: Datenmodellierung, Serviceimplementierung und Ser-viceverwaltung.

Abhngig davon, ob Sie sich fr die Serviceentwicklung oder die Ser-vicegenerierung entscheiden, knnen Sie unterschiedliche Vorge-hensweisen whlen. Wir betrachten nun diese verschiedenen Vorge-hensweisen und die darin enthaltenen einzelnen Schritte eingehend aus technischer Sicht. Aufgrund der vielfltigen Mglichkeiten wer-den wir in diesem Abschnitt wiederholt auf Abbildung 5.1 verweisen.

5.3.1 Datenmodellierung im Service Builder

Die erste Phase bei der Erstellung eines Service in SAP Gateway ist die Datenmodellierung. In dieser Phase soll mithilfe des Service Buil-ders das OData-Datenmodell des Service modelliert werden, das alle Artefakte des OData-Service beschreibt, wie z. B. Entittstypen, kom-plexe Typen, Attribute und Assoziationen.

Bei der Entwicklung eines Gateway-Service (Serviceentwicklung) oder bei der Generierung eines Gateway-Service mithilfe des RFC-/BOR- bzw. Suchhilfe-Generators (eine der drei verschiedenen Mg-lichkeiten der Servicegenerierung) startet man mit dem Anlegen eines Datenmodells.

Der Service Builder bietet seit SP08 eine fnfte Mglichkeit, um ein Datenmodell zu definieren. Jede dieser Mglichkeiten adressiert dabei einen bestimmten Anwendungsfall.

Fnf Mglich-keiten fr die

Definition eines OData-Modells

Die erste Mglichkeit zur Anlage eines Datenmodells ist, die ver-schiedenen Artefakte eines OData-Modells manuell im Service Builder anzulegen. Diese Vorgehensweise wird in der Dokumen-

Achtung

Wenn man die zweite Methode der Servicegenerierung whlt, die Rede-finition eines vorhandenen Service, wird kein neues Datenmodell defi-niert, sondern das vorhandene Datenmodell des Service- oder Business-Objekts wird redefiniert. Die Servicegenerierung mittels Redefinition wird in Abschnitt 5.3.5 beschrieben.Beachten Sie: Im Service Builder wird die Redefinition als berdefinieren bezeichnet.

195

Serviceerstellung Schritt fr Schritt 5.3

tation als deklarative Modelldefinition bezeichnet. Entittstypen, Assoziationen und Assoziationsmengen werden hierbei manuell mit dem Service Builder angelegt.

Die zweite Mglichkeit ist, ein komplettes Datenmodell im EDMX-Format zu importieren, das entweder mit dem OData Model Editor des SAP Gateway Productivity Accelerators (GWPA) oder mithilfe des Entity Data Modelers von Microsoft Visual Stu-dio angelegt wurde. Darber hinaus kann das Service-Metadaten-dokument eines bestehenden OData-Service in den Service Buil-der importiert werden.

Bei der dritten und vierten Mglichkeit wird ein Entittstyp auf Basis einer Datenstruktur angelegt, die schon im Business-Suite-System existiert. Bei dieser fr den ABAP-Entwickler sehr beque-men Variante werden Entittstypen entweder auf Basis von DDIC-Strukturen und Tabellen oder aber auf Basis von RFC-/BOR-Schnittstellen generiert.

Mit SP8 gibt es die Mglichkeit, die (F4)-Hilfen zu nutzen, die im DDIC definiert wurden. Die (F4)-Hilfen knnen dabei, wie auch RFC-/BOR-Schnittstellen, als Datenquelle genutzt werden und bie-ten eine Serviceimplementierung durch reines Mapping an, das heit Servicegenerierung.

Im Folgenden werden wir alle fnf genannten Optionen detaillierter beschreiben.

Deklaratives Anlegen eines Datenmodells

EntittstypenEin Datenmodell kann manuell mit dem Service Builder angelegt wer-den. Diese Methode kann verwendet werden, um Entittstypen anzu-legen, die auf manuell angelegten Attributen basieren. Die so angeleg-ten Attribute knnen auf existierenden DDIC-Typen basieren.

Um einen OData-Service von Grund auf in einem WYSIWYG-Stil zu modellieren, sind jedoch OData-Modellierungstools, wie beispiels-weise der SAP Gateway Productivity Accelerator (siehe auch Kapitel 8,SAP Gateway Productivity Accelerator und SAP Gateway fr Micro-soft) und Microsoft Visual Studio, besser geeignet. In diesem Fall ist es jedoch erforderlich, das so angelegte Modell in den Service Buil-der zu importieren, wie im folgenden Absatz beschrieben wird.

196


Datenmodell aus Datei

Mit dieser Option kann ein Entwickler ein komplettes Datenmodell importieren, das entweder in einer EDMX-Datei oder aber in einem Metadatendokument eines existierenden OData-Service gespeichert ist. Dies beinhaltet die Definition smtlicher OData-Artefakte, wie z. B. Entittstypen, Entittsmengen, Assoziationen und andere Kom-ponenten.

Import eines Datenmodells via DDIC-Import

DDIC-Typunter-sttzung

Um schnell Entittstypen und komplexe Typen in einem Datenmo-dell anzulegen, knnen die in einem Business-Suite-System bereits vorhandenen Datenstrukturen genutzt werden. Dazu knnen die nachfolgend genannten DDIC-Typen in den Service Builder impor-tiert werden:

Views

Datenbanktabellen

Strukturen

Achtung

Wenn man ein Service-Metadatendokument oder ein EDMX-Dokument mit dem Service Builder in ein System importiert, das lter als SAP Gate-way 2.0 SP7 ist, wrde ein bereits existierendes Datenmodell berschrie-ben. Mit SP07 bietet der Service Builder nun die Mglichkeit des Reim-ports einer Datenmodelldatei.

Beautification

Wird ein Entittstyp auf Basis eines DDIC-Typs angelegt, kann ab SP08 schon whrend des Imports ein leicht verstndlicher Name gewhlt wer-den. Auch ist es mglich, automatisch eine Default-Entittsmenge anle-gen zu lassen, wobei dem Namen des Entittstyps die Endung Set ange-hngt wird.

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

197


Import eines Datenmodells via RFC/BOR

Funktionsmodul und BAPI-Parameter

Eine vierte Mglichkeit fr das Anlegen von Entittstypen und Enti-ttsmengen bietet der Service Builder mit der Option, die Schnittstel-len (Interfaces) von RFC-Funktionsbausteinen oder BAPIs zu impor-tieren. Auch hier bietet der Service Builder einen Wizard an, der den Entwickler durch den Importprozess fhrt.

Die Verwendung von Schnittstellen von RFC-Funktionsbausteinen oder BOR-Objekten ist hilfreich, wenn diese Schnittstellen fr den Zugriff 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 knnen mithilfe des RFC-/BOR-Generators die Vorgnge einer Entittsmenge auf die Methoden einer RFC-/BOR-Schnittstelle gemappt werden.

Import einer Suchhilfe (F4-Hilfe)

Mit SP08 bietet der Service Builder eine weitere Mglichkeit, um Enti-ttstypen auf Basis existierender DDIC-Objekte anzulegen. Wie bei

Diese Namenskonvention wird auch fr die Attribute der so generier-ten Entittstypen verwendet, sodass statt des originalen FeldnamensSUPPLIER_NAME der Name der Eigenschaft im generierten Entittstyp SupplierName lauten wird.

Insbesondere die Namen der Entittsmenge und ihrer Attribute sollten einfach zu verstehen sein. Dies ist wichtig, da es die Namen der Entitts-mengen und ihrer Attribute sind, die ein externer Konsument sieht.

Whrend des Imports einer DDIC-Struktur oder auch direkt danach kann der Entwickler einen als Beautification bezeichneten Prozess starten. Hier-bei kann die Anzahl der Attribute eines Entittstyps reduziert werden, indem diese einfach aus der Definition des Entittstyps entfernt werden. Darber hinaus ist es auch mglich, die generierten Namen einer Eigen-schaft zu ndern, um sie so verstndlicher zu gestalten.

Die Reduzierung der Anzahl von Attributen auf das notwendige Ma und das Umbenennen von Attributen, die nach auen sichtbar sind, sind essenziell, wenn es darum geht, Services zu erstellen, die einfach zu kon-sumieren sind. Das Publizieren von existierenden DDIC-Strukturen ohne verstndliche Namen ist kontraproduktiv.

Das Thema Beautification wird eingehend in Abschnitt 7.2.1, SAP BW Easy Query, dargestellt.

198


BOR-/RFC-Schnittstellen knnen Entittstypen und Entittsmengen auf Basis von Suchhilfen erzeugt werden. Die Serviceimplementierung kann auch hier durch reines Mapping der Lesevorgnge (Query, Read) einer Entittsmenge auf die Suchhilfe generiert werden.

5.3.2 Serviceregistrierung im SAP-Business-Suite-System

Nachdem ein Datenmodell angelegt wurde, muss dieses noch regist-riert werden. Mit der Registrierung eines Service im Business-Suite-Backend-System wird das Ergebnis der Phase der Datenmodellierung persistiert.

Dies bedeutet, dass nun Laufzeitobjekte, die fr einen Gateway-Ser-vice bentigt werden, mit dem Service Builder generiert werden. Der Service Builder bernimmt dabei fr den Entwickler auch die Konfigurationsschritte, die notwendig sind, um den Service im Busi-ness-Suite-Backend-System zu registrieren.

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 enthlt dabei den ABAP-Code, mit dem das Datenmodell des Service definiert wird. Die

Serviceregistrierung und Serviceverwaltung

Wie Sie in Abschnitt 5.1, Serviceerstellung berblick, gesehen haben, beinhaltet die Phase der Serviceverwaltung innerhalb der Serviceerstel-lung die Aktivitten, um den Service im Gateway-Server zu registrieren und aktivieren. Dieser Prozess darf nicht mit der Serviceregistrierung im SAP-Business-Backend verwechselt werden, die nach der Datenmodell-definition im Backend erfolgt.

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

Die Serviceregistrierung ist eine Aktivitt im Rahmen der Serviceerstel-lung, die im SAP-Backend ausgefhrt wird. Als Ergebnis der Servicere-gistrierung werden die fr die Implementierung ntigen Laufzeitarte-fakte im Backend-System generiert.

Die Serviceverwaltung ist eine Aktivitt, die im Gateway-Server ausge-fhrt wird. Hierbei wird der zuvor im Backend registrierte Service akti-viert, sodass er konsumiert werden kann.

199


Implementierung der Serviceoperationen erfolgt in der Daten-Provi-der-Klasse. Die Extensionsklassen, die vom Service Builder generiert werden, knnen redefiniert, das heit mit kundeneigenem Code implementiert werden. Whrend die Methoden der Basisklassen der Daten-Provider-Klasse und der Modell-Provider-Klasse bei der Neu-generierung des Service-Builder-Projekts berschrieben werden, ist dies bei den Extensionsklassen nicht der Fall (weiterfhrende Infor-mationen zum Thema Modell- und Daten-Provider-Klasse finden Sie in Abschnitt 5.4, OData-Channel).

Service-registrierung

Damit die Laufzeitartefakte als Service genutzt werden knnen, ms-sen einige Konfigurationsschritte ausgefhrt werden. Die Ausfh-rung dieser Schritte wird vom Service Builder untersttzt.

Wird ein Projekt im Service Builder zum ersten Mal generiert, muss der Entwickler die Namen der Modell- und Daten-Provider-Klasse sowie deren Basisklassen festlegen. Darber hinaus muss der Ent-wickler den technischen Modellnamen (Technical Model Name) und den Name(n) des techn. Service (Technical Service Name) fest-legen. Letzterer wird beim Publizieren des Service im Gateway-Ser-vice als Servicename verwendet und kann nicht gendert werden.

Abbildung 5.9 Dialog der Modell- und Servicedefinition (im deutschen System)

Achtung

Im Englischen werden die Basisklassen als Model Provider Class und Data Provider Class bezeichnet (Abbildung 5.10) und im Deutschen als Modell-Provider-Klasse und Daten-Provider-Klasse als deren sogenannte Exten-sion Classes (Abbildung 5.9).

200


Da sich die Bezeichnungen im englischen System stark unterschei-den, zeigen wir Ihnen zur Orientierung in Abbildung 5.10 den eng-lischsprachigen Dialog.

Abbildung 5.10 Modell- und Servicedefinition mit dem Service Builder (im englischen System)

Modell- und Daten-Provider-

Klasse

Modell- und Daten-Provider-Klasse werden daher durch Customi-zing und nicht programmatisch zu einem Gateway-Service zusam-mengefgt. Diese Konfigurationsschritte werden, wie bereits erwhnt, fr den Entwickler durch den Service Builder ausgefhrt, wenn ein Projekt zum ersten Mal generiert wird. Der Prozess der Modell- und Servicedefinition ist in Abbildung 5.11 dargestellt.

Abbildung 5.11 Service- und Modellregistrierung

SAP Business Suite

SAP-Gateway-Service

Registrierter Service Registriertes Modell

Daten-Provider-Klasse

Modell-Provider-Klasse

Externer Servicename

201


Neben der Modell-Provider-Klasse (siehe Abschnitt 5.4.1, Model Provider Class) und Daten-Provider-Klasse (siehe Abschnitt 5.4.2, Daten-Provider-Klasse und Basisklasse) werden zwei weitere Repo-sitory-Objekte fr das Modell und den Service angelegt, wenn der Service im Business-Suite-Backend-System registriert wird.

5.3.3 Serviceimplementierung

Whrend der Phase der Serviceimplementierung werden die Metho-den eines Gateway-Service implementiert. Die Implementierung erfolgt dabei entweder durch ABAP-Programmierung oder durch das Mappen der Methoden eines RFC-Funktionsbausteins eines BAPIs oder einer Suchhilfe auf die Attribute eines OData-Modells.

Die Vorgnge, die fr eine Entittsmenge zur Laufzeit ausgefhrt werden knnen, umfassen Vorgnge zum Anlegen, Lesen, Aktuali-sieren und Lschen von Daten. Fr diese werden die folgenden eng-lischen Bezeichnungen verwendet: CREATE, READ, UPDATE, DELETE und QUERY, die daher auch als CRUD-Q-Methoden bezeichnet werden.

An dieser Stelle ist es wichtig, darauf hinzuweisen, dass die Ser-viceimplementierungsphase nur fr die Serviceentwicklung und nur fr zwei der mglichen Optionen der Servicegenerierung relevant sind, nmlich fr die RFC-/BOR-Generierung und die Suchhilfen.

Fr die Generierung von Services durch Redefinition (im Service Builder als berdefinieren bezeichnet) muss der Schritt der Imple-mentierung von Services nicht ausgefhrt werden. Dies liegt daran, dass die Serviceimplementierung auf Basis des Customizings gene-riert wird, das im Schritt der Modelldefinition ausgefhrt wurde. Hier wurden die Methoden eines SAP-Business-Objektes auf die Vor-gnge (Methods) einer Entittsmenge gemappt.

Im Folgenden geben wir Ihnen fr die Szenarien einen kurzen ber-blick ber die Phase der Serviceimplementierung, fr die diese Phase relevant ist: die Serviceentwicklung und die Servicegenerierung mit dem RFC-/BOR-Generator und dem Suchhilfe-Generator.

Achtung

Die Servicegenerierung durch Redefinieren (berdefinieren) wird in Abschnitt 5.3.5, Servicegenerierung mittels Redefinition, nher beschrieben.

202


Serviceimplementierung durch ABAP-Programmierung

Wie Sie sich erinnern werden, wurde whrend der Serviceregistrie-rung am Ende der Datenmodellierungsphase eine Daten-Provider-Klasse erzeugt.

Whrend der Phase der Serviceimplementierung werden diejenigen Vorgnge (Methoden) implementiert, die vom Gateway-Service untersttzt werden sollen.

Bei der Implementierung der Vorgnge durch ABAP-Programmie-rung muss der Entwickler die entsprechenden Methoden der Daten-Provider-Klasse (DPC_EXT) implementieren. Diese Methoden werden Sie an die zuvor erwhnten CRUD-Q-Methoden erinnern:

_CREATE_ENTITY

_GET_ENTITY

_UPDATE_ENTITY

_DELETE_ENTITY

_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.12 aufgeklappt werden.

Abbildung 5.12 Serviceimplementierung durch ABAP-Programmierung

Von hier aus ist eine einfache Navigation zu dem entsprechenden Eintrag einer Entittsmenge mglich, wobei alle CRUD-Q-Vorgnge der Entittsmenge angezeigt werden.

203


Durch die Auswahl von Zur ABAP Workbench aus dem Kontext-men gelangt man direkt in den Class Builder (Transaktion SE24), in dem man die Methode der Modell-Provider-Klasse implementieren kann, die dem Vorgang der Entittsmenge entspricht.

Darber hinaus kann es erforderlich sein, dass noch zustzliche Me-thoden in der Modell-Provider-Klasse redefiniert werden mssen, die nicht entittsmengenspezifisch sind wie die zuvor erwhnten CRUD-Q-Methoden (dies ist z. B. der Fall, wenn fr den OData-Ser-vice die Untersttzung von Deep-Insert implementiert werden soll).

Serviceimplementierung durch das Mappen von RFC-/BOR-Schnittstellen

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

Der Mapping-Prozess wird dadurch gestartet, dass der Entwickler im Kontextmen eines CRUD-Q-Vorgangs einer Entittsmenge im Ver-zeichnis Serviceimplementierung (Service Implementation) die Option Zu Datenquelle zuordnen (Map to Datasource) whlt, wie in Abbildung 5.13 gezeigt.

Abbildung 5.13 Mappen des Vorgangs einer Entittsmenge zu einer Datenquelle

Das Mapping-Tool des Service Builders ermglicht es dem Entwick-ler dann, Relationen zwischen den Schnittstellenparametern eines RFC-Funktionsbausteins oder BAPIs und den Attributen einer Enti-ttsmenge festzulegen.

204


CRUD-Q Die Vorgnge CREATE, READ, UPDATE, DELETE und QUERY (CRUD-Q) einer Entittsmenge knnen dabei separat gemappt werden.

Die eigentliche Serviceimplementierung, das heit der ABAP-Code der Methoden der ABAP-Klasse, die die einzelnen CRUD-Q-Vor-gnge implementieren, wird dabei vom Service Builder auf Basis des zuvor beschriebenen Mappings erzeugt.

Der Service Builder bietet dem Entwickler eine besondere Unter-sttzung, wenn ein Entittstyp durch den Import der Schnittstelle eines BOR-Objekts oder RFC-Funktionsbausteins angelegt wurde. In diesem Fall schlgt der Service Builder ein geeignetes Mapping vor.

Wie in Abbildung 5.14 gezeigt, schlgt der Service Builder ein Map-ping zwischen der Eigenschaft SoId der Entittsmenge SalesOrder-HeaderSet und des Feldes SO_ID des Exportparameters SOHEADERDATAdes RFC-Funktionsbausteins BAPI_EPM_SO_GET_LIST vor.

Abbildung 5.14 Mapping-Vorschlge RFC-/BOR-Generator

Dieser Mapping-Vorschlag konnte automatisch erstellt werden, da der Entittstyp, auf dem die Entittsmenge SalesOrderHeaderSetbasiert, durch den Import des Schnittstellenparameters SOHEADER-DATA erzeugt wurde.

Werden weitere Vorgnge der Entittsmenge gemappt, prft der Ser-vice Builder die bereits existierenden Mappings und leitet aus diesen Vorschlge fr die zustzlich zu mappenden Vorgnge ab.

Wurde also zunchst der Query-Vorgang (GET_ENTITYSET) einer Enti-ttsmenge gemappt und mchte man nun noch den Read-Vorgang (GET_ENTITY) mappen, kann der Service Builder einen Vorschlag fr

205


die Attribute erstellen, die bereits in der GET_ENTITYSET-Methode gemappt wurden.

Serviceimplementierung durch das Mappen von F4-Suchhilfen

Die Vorgehensweise bei der Implementierung durch das Mappen von (F4)-Suchhilfen entspricht im Wesentlichen dem Mapping-Vor-gang beim RFC-/BOR-Generator. Da es sich bei (F4)-Suchhilfen um rein lesende Zugriffe handelt, knnen naturgem nur die Query- und Read-Vorgnge einer Entittsmenge gemappt werden.

5.3.4 Serviceverwaltung

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

Aktivierung und Verwaltung von Services

Die Registrierung und Aktivierung von Services im Hub-System fh-ren Sie mit der Transaktion /IWFND/MAINT_SERVICE (Activate and Maintain Service) durch. Die Transaktion /IWFND/MAINT_SERVICE wird auch dafr verwendet, alle aktivierten Services im Gateway-Ser-ver zu pflegen. Services mssen gepflegt werden, wenn sie in zustz-lichen Backend-Systemen registriert wurden oder deaktiviert wer-den sollen, z. B. weil sie nicht mehr bentigt werden.

Abbildung 5.15 Registrierung eines Service im Hub aus dem Business-Suite-System

206


Da der Service Builder der zentrale Einstiegspunkt fr die Serviceent-wicklung ist, wurde im Service Builder die Funktionalitt implemen-tiert, die es dem Entwickler erlaubt, die Transaktion fr die Pflege von Services im Hub-System (IWFND/MAINT_SERVICE) direkt aus dem Service Builder aufzurufen. Der Aufruf der Transaktion funktio-niert auch remote, wenn der Service Builder im SAP-Backend aufge-rufen wird.

Der Entwickler kann nun entweder ein Gateway-System aus der Liste der Gateway-Systeme im Verzeichnis Serviceverwaltung aus-whlen (Abbildung 5.15) oder auf den Button Bearb. klicken.

5.3.5 Servicegenerierung mittels Redefinition

Wie in Abschnitt 5.1, Serviceerstellung berblick, dargestellt, geht es bei dem Prozess der Redefinition um das Generieren eines Service auf Basis eines existierenden Business-Objekts. Die Generie-rung erfolgt mithilfe eines Wizards, bei dem die beiden Phasen der Datenmodelldefinition und der Implementierung zu einer 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 Aufwand anzulegen.

Bestehende Busi-ness-Objekte

In einem Business-Suite-Systemen, wie z. B. SAP Customer Relation-ship Management (SAP CRM), SAP Product Lifecycle Management (SAP PLM), SAP Enterprise Asset Management (EAM) und SAP HANA, existiert eine Vielzahl verschiedenster Business-Objekte. Obwohl all diese Business-Objekte fr unterschiedliche Anwen-dungsflle entwickelt wurden, definieren sie doch alle Objekte, Rela-tionen, Aktionen und Suchen, die denen hneln, die man im OData-Protokoll findet. Daher liegt es nahe, Generatoren zu entwickeln, mit denen man aus den genannten Business-Objekten OData-Services generieren kann.

Achtung

Neben der Integration bestehender SAP-Business-Objekte ist es auch mglich, OData-Services von Drittherstellern zu integrieren. Dieses Inte-grationsszenario wird in Kapitel 7, Servicegenerierung, besprochen, in dem die Generierung von Services detailliert erklrt wird.

207


Redefinitions-/berdefinitions-Assistent

Der Wizard fr die Generierung von OData-Services mithilfe der Redefinition (berdefinition) unterscheidet sich kaum zwischen den einzelnen Integrationsszenarien. Whlt man eine der mglichen Optionen (basierend auf den installierten Add-ons) aus, startet ein Wizard, der Sie durch die folgenden drei Schritte leitet:

1. Auswahl eines Business-Objektes

2. Auswahl der Artefakte der Datenquelle (Datenmodelldefinition)

3. Generierung von Laufzeitartefakten und Serviceregistrierung im Backend (Serviceimplementierung)

Der Assistent startet also mit der Phase der Definition des Datenmo-dells und fhrt anschlieend automatisch die Schritte durch, die zur Phase der Serviceimplementierung gehren. Nachdem der Service im 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 Abschnitt beschrieben werden, basieren teilweise auf den in Tabelle 5.1 aufge-fhrten Add-ons. Wenn diese Add-ons in einem Business-Suite-Sys-tem installiert sind, erscheinen wie in Abbildung 5.16 im Kontext-men des Service Builders die entsprechenden Meneintrge.

Die meisten Integrationsszenarien sind remote aufrufbar. Dies bedeutet, 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 integrationsszenarios-pezifische Add-on installiert ist. Aus diesem Grund ist es prinzipiell mglich, die remotefhigen Integrationsszenarien auch im Gateway-Server zu implementieren. In diesem Fall spricht man von einem Hub-Deployment mit Entwicklung auf dem Hub.

Name des Add-ons Integrationsszenario Remote aufrufbar

IW_GIL Generic Interaction Layer (GenIL)

IW_SPI Service Provider Interface (SPI) X

IW_BEP Analytical Queries X

IW_HDB SAP HANA X

Tabelle 5.1 Add-ons fr die Generierung von Services auf Basis existierender Datenquellen

208


Abbildung 5.16 Kontextmenoptionen fr das Anlegen eines Datenmodells durch Redefinition (berdefinieren)

Im Folgenden stellen wir nun die verschiedenen Business-Objekte nher vor, die als Datenquellen dienen knnen.

Generic Interaction Layer (GenIL)

Bestehende Business-Logik

integrieren

Die Integration mit dem Generic Interaction Layer (GenIL) aus SAP Gateway bietet dem Entwickler die Mglichkeit, OData-Services auf Basis existierender GenIL-Objekte zu generieren. GenIL fungiert als Schnittstelle fr existierende Business-Logik und bietet die Option, auf verschiedene Business-Objekte ber eine einheitliche Schnitt-stelle zuzugreifen, und ist Teil des Business Object Layers (BOL), der aus den zwei folgenden Ebenen besteht:

GenILDie untere der beiden Ebenen ist ein Dispatcher, der GenIL-Kom-ponenten und deren Modelle zur Laufzeit verwaltet und Anfragen von darberliegenden Komponenten auf diejenigen Komponen-ten verteilt, die die angefragten Objekte implementieren.

IW_BEP and IW_FND OData-Service (External) X

IW_BEP OData-Service (SAP Gateway) X

Name des Add-ons Integrationsszenario Remote aufrufbar

Tabelle 5.1 Add-ons fr die Generierung von Services auf Basis existierender Daten-quellen (Forts.)

209


BOLDiese zustandsbehaftete Ebene bietet einen performanten Zugriff, indem sie als Puffer fr die Benutzeroberflche dient und so wie-derholte Zugriffe auf die Schnittstellen zu den darunterliegenden Business-Objekten vermeidet.

Obwohl der BOL fr den SAP CRM Web Client entwickelt wurde, ist der GenIL nicht hierauf beschrnkt und auch in anderen Integrati-onsszenarien einsetzbar. Ein Beispiel hierfr ist das Webservice-Tool, mit dem aus GenIL-Objekten SOAP-Webservices generiert werden knnen, die den Zugriff auf GenIL-Objekte ber das SOAP-Protokoll ermglichen.

Auf hnliche Weise bietet SAP Gateway Ihnen die Mglichkeit, OData-Services auf Basis von GenIL-Objekten zu generieren (Abbil-dung 5.17).

Abbildung 5.17 Integration von GenIL mit SAP Gateway

GenIL

ModelleBackend-Anwendung / API

AnwendungsschichtErbt von CL_CRM_GENIL_ABSTR_COMPONENT

Implementiert

CRM Web Client

BOL SAP Gateway

R

R

RR

R

210


Die Knoten, Relationen und Queries des GenIL-Modells werden dabei, wie in Abbildung 5.18 gezeigt, auf entsprechende Entitten eines OData-Modells gemappt.

Abbildung 5.18 Mapping zwischen GenIL und einem OData-Modell

Obwohl der BOL und damit auch der GenIL fr den SAP CRM Web Client entwickelt wurden, wurde GenIL auch in anderen Business-Suite-Anwendungen wie SAP ERP Financials und SAP ERP Human Capital Management (HCM) eingesetzt. Die Integration mit SAP Gateway ist im Add-on IW_GIL enthalten. Dieses muss lokal im Busi-ness-Suite-System (z. B. in SAP CRM) installiert werden und erfordert seinerseits die Installation des Add-ons IW_BEP.

Service Provider Interface (SPI)

Das Service Provider Interface (SPI) wurde ursprnglich fr die Anwendung SAP PLM entwickelt. Bei SPI handelt es sich um ein

GenIL-Schicht

Knoten

Attributsstruktur

Schlsselstruktur

Relationen

SAP-Gateway-Schicht

Entitt

Attribute

Schlssel

Navigationsattribute(Assoziationen)

Achtung

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

211


Framework auf der Anwendungsebene, das verschiedene Konsumen-ten hat. Das SPI-Framework wird derzeit nicht nur von der Anwen-dung SAP PLM genutzt, fr die es ursprnglich entwickelt wurde, son-dern auch von vielen weiteren Anwendungen der SAP Business Suite.

SPI-Objekte sind remote aufrufbar. Aus diesem Grund ist es nicht zwingend erforderlich, dass das Gateway-Add-on IW_SPI auf dem Business-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 erwhnt lokal auf dem Business-Suite-System (z. B. SAP CRM) installiert wer-den. Die Integration von SPI mit SAP Gateway ermglicht es dem Entwickler, SPI Application Building Blocks als OData-Services zu publizieren.

Analytische Queries

Analytische Queries sind die wichtigsten Werkzeuge fr den Zugriff auf analytische Daten, die sich entweder in Business-Anwendungen, wie z. B. der SAP Business Suite, oder in Data-Warehouse-Systemen befinden, wie z. B. SAP Business Warehouse (BW).

Whrend analytische Queries in der SAP Business Suite den Zugriff auf konsistente, operationale Daten ermglichen, bieten analytische Queries im BW-Hub den Zugriff auf konsistente, stark aggregierte Daten aus verschiedenen Unternehmensteilen.

Die Integration von SAP Gateway und SAP BW ermglicht es Ihnen, die Inhalte von SAP BW ber einen OData-Service zu publizieren, der auf Basis von multidimensionalen Ausdrcken (Multidimen-sional Expressions, MDX) oder SAP BW Easy Queries entwickelt wurde.

Whrend die Verwendung der MDX-Queries bereits mit BW-Syste-men ab Release 7.0 mglich ist, bentigt man fr die Integration von

Weiterfhrende Informationen

Weiterfhrende Informationen ber dieses Thema finden Sie hier:

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

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

212


BW Easy Queries mindestens Release SAP BW 7.30. BW Easy Queries sind jedoch im Vergleich zu MDX-Queries einfacher zu ver-stehen und zu verwenden.

SAP BW Easy Queries

SAP BW Easy Queries sind analytische Queries, die bestimmte Vor-aussetzungen erfllen. Fr jede BW Easy Query wird vom System ein RFC-Funktionsbaustein erzeugt. Dies geschieht automatisch auf Basis der vorhandenen BW-Query-Definition. Auf Basis dieses RFCs kann ein entsprechender OData-Service erzeugt werden.

Um eine analytische Query als SAP BW Easy Query freigeben zu knnen, muss der Entwickler die entsprechende Checkbox in den Query-Attributen im BEx Query Designer (Abbildung 5.19) akti-vieren.

Abbildung 5.19 Definition einer Easy Query im BEx Query Designer

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

213


Analytische Annotationen

Dimensionen, Dimensionsattribute und Mae werden als Attribute eines Entittstyps dargestellt. Entittstypen, die die Ergebnisse einer MDX- oder BW Easy Query darstellen, sind als sap:semantics=agg-regate gekennzeichnet.

Tabelle 5.2 zeigt, wie BW-Objekte, z. B. Dimensionen, Dimensionsat-tribute und Mae, in OData dargestellt werden. Die Tabelle zeigt nur die wichtigsten Annotationen.

SAP HANA

SAP HANA ist eine hochperformante In-Memory-Datenbank. Abhngig von dem zugrunde liegenden Release der SAP Business Suite bzw. des BW-Systems, sind unterschiedliche Integrationsszena-rien denkbar.

Mit dem neuesten Release SAP NetWeaver 7.40 knnen diese Sys-teme auch auf SAP HANA selbst laufen, das heit, dass SAP HANA die ursprnglich vorhandene relationale Datenbank ersetzt. Diese Integrationsszenarien lauten im Einzelnen: SAP ERP on HANA, SAPCRM on HANA und SAP BW on HANA.

Aber auch ltere Releases knnen von der Rechenleistung der HANA-Datenbank profitieren. In einem sogenannten Side by Side Scenario ist es mglich, die Daten zwischen den zwei Systemen in


Weiterfhrende Informationen ber SAP BW Easy Queries knnen Sie in der SAP-Online-Hilfe finden. Wir empfehlen an dieser Stelle das folgende Dokument:

http://help.sap.com/saphelp_nw73/helpdata/en/b6/53d6c4e26a4504b89 71c6e690d2105/frameset.htm

SAP-BW-Objekte OData-Reprsentation SAP-Annotation

Cube of Type Query Entitittstyp sap:semantics=aggregate

Dimension Eigenschaft sap:aggregation-role=dimension

Dimensionsattribut Eigenschaft sap:attribute-for=

Ma Eigenschaft sap:aggregation-role=measure

Tabelle 5.2 Analytische Annotationen

214


Echtzeit zu kopieren. Dieses Szenario heit SAP Gateway with SAPHANA.

In beiden Fllen, dem Szenario SAP on SAP HANA und dem Side-by-Side-Szenario, werden Daten in HANA-Artefakten gespeichert und knnen als OData-Services publiziert werden. Die-ses Vorgehen ist in Abbildung 5.20 dargestellt.

Abbildung 5.20 SAP HANA und SAP Gateway Integrationsszenarien

HANA-Views Mithilfe des Integrations-Frameworks ist es mglich, Daten aus HANA-Informationsmodellen, die sich in einer separaten HANA-Datenbank befinden, durch SAP Gateway als OData-Service zu verf-fentlichen. Das Integrations-Framework von SAP Gateway erlaubt die Implementierung von Read-only-Szenarien fr die folgenden HANA-Objekte:

attributive views

analytical views

calculation views

Die Anbindung von SAP Gateway an SAP HANA in einem SAP Gate-way with SAP HANA Scenario basiert auf einer Secondary Database Connection, die in der Tabelle DBCONN gepflegt wird. Dieses Integ-rationsszenario ist derzeit nicht in den Service Builder integriert und

SRM SCM ERPPLMCRM

SAP Business Suite

SAP Gateway

SAPHANA

OData-Client

OData

Sync

SAP BW

SRM SCM ERPPLMCRM

SAP Business Suite (auf Basis von 7.40)

SAP Gateway

OData-Client

OData

SAP BW

Easy Query MDX Easy Query MDX

SAP HANA

SAP Gateway mit SAP HANASAP Business Suite auf SAP HANA

215


erfordert eine manuelle Implementierung einer Modell-Provider-Klasse durch ABAP-Programmierung. Diese Modell-Provider-Klasse muss anschlieend manuell als Service zusammen mit einer generi-schen Daten-Provider-Klasse registriert werden.

Da die ADBC-Schnittstelle (ABAP Database Connectivity) nur die in der Tabelle DBCONN eingetragenen Benutzer verwendet und kein Single Sign-on (SSO) mglich ist, kann das HANA-Konzept der Ana-lytical Privileges nicht verwendet werden. Als Workaround wurden auf ABAP-Seite zustzliche Autorisierungsprfungen implementiert.

Das Integrations-Framework fr SAP HANA ist fr frhere Versionen von SAP NetWeaver im Add-on IW_HDB enthalten. Beginnend bei SAP NetWeaver 7.40 SP02, sind diese Funktionalitten in der Soft-warekomponente SAP_GWFND enthalten.

Eine native Art der Integration kann erreicht werden, wenn das Busi-ness-Suite-System auf Basis von SAP NetWeaver AS ABAP 7.40 luft, da dieses Release fr den Betrieb mit SAP HANA optimiert wurde. Mit SAP NetWeaver 7.40 wurden neue Features hinzugefgt, die ein einfaches Konsumieren von bestehenden HANA-Artefakten in Ihrem ABAP-Code erlauben.

Nun ist es mglich, nativ von ABAP-Applikationen auf HANA-Attri-bute-Views zuzugreifen, indem man das neue DDIC-Objekt ExternalView using Open SQL verwendet. Darber hinaus knnen die Modell-informationen dieser neuen Objekte auch im Service Builder genutzt werden. Dazu kann ein externer DDIC-View in ein Datenmodell importiert werden (wie in Abschnitt 5.3.1, Datenmodellierung im Service Builder, beschrieben).

Externer OData-Service

OSCIDas Integrationsszenario OData Services Consumption and Integra-tion (OSCI) zielt darauf ab, beliebige (auch 3rd Party) OData-Services aus SAP Gateway zu konsumieren und als Gateway-Services zu pub-lizieren. Mit SP07 von SAP Gateway 2.0 ist diese Funktionalitt voll-


Weiterfhrende Informationen ber die Entwicklung basierend auf SAP NetWeaver AS ABAP und SAP HANA finden Sie hier http://scn.sap.com/docs/DOC-35518.

216


stndig in den Service Builder integriert. In SP06 muss hierfr die Transaktion /IWBEP/OCI_SRV_GEN gestartet werden.

Die Integration muss auf dem Gateway-Serversystem implementiert werden, wo auch das Add-on IW_BEP installiert werden muss. Dies ist notwendig, weil fr die Konsumierung von OData-Services die OData-Bibliothek bentigt wird, die sich nur auf dem Gateway-Ser-ver befindet. Darber hinaus ist auch das Add-on IW_BEP fr die Ent-wicklung des Service auf dem Gateway-Server erforderlich.

Mit SAP NetWeaver ABAP 7.40 SP02 werden diese beiden Voraus-setzungen von jedem ABAP-System erfllt, da bei diesen Systemen die Softwarekomponente SAP_GWFND die entsprechenden Funktiona-litten enthlt.

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 Integ-rationsszenario ist Teil des Erweiterungskonzeptes von SAP Gateway Services und kann z. B. fr die Erweiterung von Services genutzt werden, die von SAP mit SAP Fiori ausgeliefert werden.

Der redefinierte Service kann zum einen auf die Funktionen des Orginalservice zugreifen und zum anderen um zustzliche Attribute oder Entittsmengen erweitert werden. Auf diese Weise ist auch eine Erweiterung von Services mglich, die auf Basis der zuvor beschrie-benen Integrationsszenarien entwickelt wurden. Das Vorgehen bei der Erweiterung eines Gateway-Services zeigen wir in einer detail-lierten Schritt-fr-Schritt-Anleitung in Kapitel 7, Servicegenerie-rung. Weitere Informationen finden Sie auch in der SAP-Online-hilfe (Suche nach Extending an OData Service Using Service Builder).

5.3.6 Servicegenerierung via Model Composition

Wie bereits erwhnt, kann aus mehreren existierenden Gateway-Ser-vices ber ein Mash-up ein neuer Service generiert werden. Dieser Vorgang wird auch Model Composition genannt.

Das Ergebnis ist ein neuer Service, der angelegt werden kann, ohne die bestehenden Services zu verndern. Es ist mglich, jeden Gate-

217

OData-Channel 5.4

way-Service zu redefinieren, unabhngig davon, auf welche Weise er erstellt wurde. Dies bedeutet, dass Model Composition auch fr ltere Services verwendet werden kann, die per Hand entwickelt wurden, oder aber auch fr jeden anderen Service, der mit dem Ser-vice Builder gebaut wurde. So kann beispielsweise im Service Builder ein Service entwickelt werden, der den manuell entwickelten Service GW_DEMO oder RMTSAMPLEFLIGHT enthlt, obwohl diese Services nicht mit dem Service Builder generiert wurden.

Ein typisches Einsatzszenario fr Model Composition ist die Erweite-rung von Services, die auf SAP BW, GenIL-, SPI- oder HANA-Objek-ten oder auf externen OData-Services basieren.

Ein Beispiel wre ein Service, der das Anlegen eines Kaufauftrags (Purchase Order) ermglicht, wobei der Benutzer Zugriff auf die Kaufhistorie (Purchase Order History) des betreffenden Kunden hat. Die Kaufhistorie kann ber eine entsprechende SAP BW Easy Query ermittelt werden, whrend auch ein zweiter Service angelegt werden kann, mit dem Kaufauftrge erstellt werden knnen.

Ein weiteres Beispiel ist die Integration von Daten, die aus SAP HANA gelesen werden, mit einem Service, der einen schreibenden Zugriff auf die entsprechenden Daten in der SAP Business Suite erlaubt.

5.4 OData-Channel

Nachdem wir die grundlegenden Konzepte der verschiedenen Mg-lichkeiten fr die Erstellung von Gateway-Services beschrieben haben, stellen wir nun das Konzept der OData-Channel-Programmie-rung vor. Diese Einfhrung ist essenziell fr das Verstndnis von Kapitel 6, Serviceentwicklung, in dem wir die Entwicklung von OData-Services detailliert beschreiben werden.

Achtung

Model-Composition-Szenarien bentigen die Implementierung der Navi-gation durch Custom-Code auf dem Hub und damit auch die Installation des Add-ons IW_BEP auf dem Hub, wenn dieser auf einem Release SAP NetWeaver 7.31 oder frher basiert.

218


Der OData-Channel ermglicht Ihnen die Entwicklung von Services durch die Definition von Objektmodellen und die Registrierung der entsprechenden Laufzeit, die in der Daten-Provider-Klasse implemen-tiert wurde. Der Vorteil des OData-Channels ist, dass er Ihnen gewisse Freiheiten bei der Entwicklung von Services bietet. So knnen kom-plette DDIC-Informationen und lokale Schnittstellen in der SAP Busi-ness Suite genutzt werden, um Gateway-Services zu entwickeln.

Darber hinaus knnen Query-Optionen auch im Business-Suite-Backend genutzt werden. Dies bedeutet, dass nur die Daten, die vom OData-Client abgefragt wurden, auch aus dem Business-Suite-System gelesen und zurck zum Client geschickt werden. Das Ergebnis sind hoch optimierte Services mit einer optimalen Performance, da nur ein Minimum von 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 deren Basisklasse, die die Modelldefinition zur Laufzeit darstellt

der Implementierung einer Daten-Provider-Klasse und deren Basisklasse, die zur Laufzeit aufgerufen wird, um die Datenanfra-gen auszufhren

dem technischen Servicenamen, der fr die Registrierung des Ser-vice im Business-Suite-System dient

dem technischen Modellnamen, der fr die Registrierung des Ser-vice im Business-Suite-System dient

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

5.4.1 Model Provider Class

Die Model Provider Class (Modell-Provider-Klasse) ist eine ABAP-Klasse, die die Definition des Datenmodells zur Laufzeit erzeugt. Aus diesem Grund werden alle Modellinformationen, die man im Projekt definiert hat, in der Modell-Provider-Basisklasse generiert. Die Basis-klasse der Modell-Provider-Klasse muss deshalb immer dann neu generiert werden, wenn Sie die Modelldefinition in Ihrem Projekt ndern.

219

OData-Channel 5.4

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.21).

Abbildung 5.21 Modell-Provider-Klasse

Genau betrachtet, wird die Modelldefinition in zwei verschiedenen Klassen generiert:

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

Der Modell-Provider-Klasse (mit dem Suffix _MPC_EXT). Die Modell-Provider-Klasse ist die Klasse, die ber den technischen Modellna-men im Backend registriert wird. In der Modell-Provider-Klasse kann man whlen, welche Methoden redefiniert und welche Methoden von der Basisklasse bernommen werden.

In den meisten Fllen besteht fr den Entwickler kein Grund, die Modell-Provider-Klasse zu ndern, die durch den Service Builder generiert wurde. Die Ausnahme von dieser Regel ist, wenn Sie einen Gateway-Service bauen mchten, der Features besitzt, die derzeit nicht mit dem Service Builder implementiert werden knnen. In die-

Modell-Provider-Basisklasse

Erbt von /IWBEP/CL_MGW_PUSH_ABS_MODEL

Superklasse der Modell-Provider-Extension-Klasse

berschreibt die Methode DEFINE

220


sem Fall kann der Entwickler Methoden in der Modell-Provider-Klasse redefinieren.

Modell-Provider-Klasse im Detail

Normalerweise ist es nicht erforderlich, dass der Entwickler Methoden in der Modell-Provider-Klasse redefiniert, die vom Service Builder auf Basis des OData-Datenmodells generiert wurden.

Dennoch schauen wir uns die Methoden genauer an, die vom Service Builder generiert wurden, um das darunterliegende Framework besser zu verstehen.

Die DEFINE-Methode in der Basisklasse der Modell-Provider-Klasse, die vom Service Builder generiert wird, enthlt Aufrufe fr die entittstypspe-zifischen define_-Methoden. Darber hinaus enthlt die DEFINE-Methode einen Aufruf der define_Association-Methode, die die Assoziationen, Assoziationsmengen, Referential Constraints und Navi-gationsattribute erzeugt.

Die Methode GET_LAST_MODIFIED ist wichtig fr die Kommunikation zwischen dem Business-Suite-Backend-System und dem Gateway-Server, wenn die Modell-Provider-Klasse im Backend gendert wurde. In diesem Fall wird ein Refresh der gecachten Metadaten des Service im Gateway-Server initiiert. Diese Methode sollte nicht manuell gendert werden.

In den entittstypspezifischen DEFINE-Methoden generiert der Service Builder den ABAP-Code, der die Teile des OData-Modells erzeugt, das die Entittstypen und die Entittsmengen generiert, die auf diesem Enti-ttstyp basieren.

Die Attribute eines Entittstyps werden durch das nachfolgend gezeigte Coding erzeugt, und die Attribute, die als Schlsselfelder markiert wur-den, werden im Code als Schlsselfelder 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 Entittstyp an eine DDIC-Struktur gebunden, und eine oder mehrere Entittsmengen werden angelegt. Beachten Sie: Wenn ein Entittstyp an eine existierende DDIC-Struktur gebunden wird, kann sie Conversion Exits und die Feldbezeichner der Datenelemente aus dem DDIC nutzen. Der mittlere Feldbezeichner mit einer Lnge von 15 Zei-chen eines Datenelements wird dabei als Default-Wert fr die SAP-spezi-fische Annotation sap:label verwendet.

...

lo_entity_type->

bind_structure( iv_structure_name =

221

OData-Channel 5.4

5.4.2 Daten-Provider-Klasse und Basisklasse

Die Daten-Provider-Klasse (DPC) ist eine ABAP-Klasse, die alle Methoden bereitstellt, um OData-Aufrufe zu beantworten. Sie wird zur Laufzeit aufgerufen, um diese weiteren Aufrufe auszufhren. Daher sprechen wir auch von der Laufzeitreprsentation der Ser-viceimplementierung. Die Daten-Provider-Klasse fhrt unter ande-rem die Operationen CREATE, READ, UPDATE, DELETE und QUERY aus.

Daten-Provider-Klasse und Basis-klasse

Wie im Fall der Modell-Provider-Klasse findet man die Daten-Provi-der-Klasse (Data Provider Extension Class) mit der Endung _DPC_EXTund eine Basisklasse (Data Provider Class) mit der Endung _DPC.

Die Daten-Provider-Klasse erbt von der Basisklasse (siehe Abbildung 5.22). Die Daten-Provider-Klasse ist die Klasse, die ber den techni-schen Servicenamen registriert wird, das heit, sie ist die Klasse, die in einem OData-Service ausgefhrt wird.

Abbildung 5.22 Interface der Daten-Provider-Klasse

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

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

Daten-Provider-Extension-Klasse

Erbt von der Daten-Provider-Klasse

Geerbte Methodenfr CRUD- und Ab-frageoperationen

222


An dieser Stelle ist es wichtig zu erwhnen, dass es neben den enti-ttsmengenspezifischen Methoden auch Methoden gibt, die nicht spezifisch fr eine einzelne Entittsmenge sind.

Entittsmengenty-pische Methoden

Daten-Provider-Klasse im Detail

Fr jede Entittsmenge werden vom Service Builder Methoden angelegt, die vom Framework aufgerufen werden, wenn ein CREATE-, READ-, UPDATE- oder DELETE-Vorgang (CRUD) fr die Entittsmenge aufgerufen wird. Fr eine Entittsmenge mit dem Namen werden die in Tabelle 5.3 aufgefhrten Methoden angelegt.

Name der DPC-Methode HTTP-Verb Ziel

_CREATE_ENTITY POST Entittsmenge

_DELETE_ENTITY DELETE Entitt

_GET_ENTITY GET Entitt

_GET_ENTITYSET GET Entittsmenge

_UPDATE_ENTITY UPDATE Entitt

Tabelle 5.3 Entittsmengenspezifische CRUD-Methoden

Darber hinaus gibt es weitere Methoden, die nicht nur fr eine einzelne Entittsmenge gelten, sondern fr alle Entittsmengen, die sogenannten nicht entittsmengenspezifischen Methoden.

Beispiele hierfr sind die Methoden, die die Ausfhrung von $EXPAND-oder Deep-Insert-Ausdrcken bernehmen, oder die Methoden, die auf-gerufen werden, wenn ein Funktionsimport aufgerufen wird. Lassen Sie uns daher einen Blick auf diese Beispiele werfen:

GET_EXPANDED_ENTITY, GET_EXPANDED_ENTITYSETDie Ausfhrung von $expand-Ausdrcken wird vom Gateway-Frame-work out of the box generisch angeboten, wenn Ihr Modell geeignete Navigationsattribute enthlt und das Handling der Navigationsattri-bute implementiert wurde. Es wird jedoch oft Situationen geben, in denen man die Ausfhrung der $expand-Aufrufe selbst implementie-ren mchte. Ein Beispiel hierfr sind RFC-Funktionsbausteine wie BAPI_EPM_SO_GET_LIST. Dieser Funktionsbaustein liest zusammen mit den Header-Daten eines Verkaufsauftrags auch dessen Einzelposten. Wird nun die Entittsmenge, die die Kopfdaten der Verkaufsauftrge enthlt, so aufgerufen, dass aufgrund des $expand-Ausdrucks zugleich auch die Einzelposten des Verkaufsauftrags gelesen werden sollen, wrden unntige Zugriffe auf die Datenbank erfolgen, da die Einzel-posten schon beim Lesen der Header-Daten aus der Datenbank gele-sen wurden.

223

OData-Channel 5.4

5.4.3 Technische berlegungen bezglich der OData-Channel-Entwicklung

Die OData-Channel-Entwicklung kann entweder in der SAP Business Suite oder auf dem Gateway-Server stattfinden, wie in Abbildung 5.23 dargestellt. Wo aber auch immer Sie entwickeln mchten, die BEP-Komponente muss in dem entsprechenden System installiert werden.

Abbildung 5.23 OData-Channel-Entwicklung auf dem Hub oder in der SAP Busi-ness Suite

CREATE_DEEP_ENTITYDas Gegenstck zum Schlsselwort $expand ist das Deep-Insert-State-ment, bei dessen Aufruf die CREATE_DEEP_ENTITY-Methode ausge-fhrt wird. Ein typisches Beispiel hierfr ist der Fall, bei dem zusammen mit einem Verkaufsauftrag zwingend auch mindestens ein Einzelposten angelegt werden muss.

EXECUTE_ACTIONDie EXECUTE_ACTION-Methode ist ebenfalls nicht entittsmengenspe-zifisch. Diese Methode wird aufgerufen, wenn ein Funktionsimport in einem OData-Service ausgefhrt werden soll. Funktionsimporte ermglichen die Ausfhrung von lesenden und schreibenden Szena-rien.

Funktionsimporte knnen in einem Business-Szenario eingesetzt wer-den, wenn Daten gelesen oder geschrieben werden mssen und diese Funktionen nicht durch den Aufruf von CRUD-Q-Methoden abgebildet werden knnen.

SAP Business Suite

RFC

RFC BOR BW WF

Konsumenten

HTTPS

SAP Gateway Hub

OData Runtime & OData Design Time & Service Provider Runtime

GW_CORE und IW_FND oderSAP_GWFND

IW_BEP oder SAP_GWFND

RFC

Konsumenten

SAP Gateway Hub

OData Runtime

GW_CORE und IW_FND oderSAP_GWFND

SAP Business Suite

RFC BOR BW WF

OData Design Time & Service Provider Runtime

IW_BEP oder SAP_GWFND

Entwicklung auf dem Hub Entwicklung in der SAP Business Suite

224


5.5 Zusammenfassung

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

In diesem Kapitel haben wir Ihnen zunchst das Tooling und den Entwicklungsprozess vorgestellt, um Ihnen ein Basis-Know-how fr die technisch anspruchsvollen Schritt-fr-Schritt-Anleitungen zur Serviceentwicklung und Servicegenerierung in Kapitel 6, Ser-viceentwicklung, und Kapitel 7, Servicegenerierung, zu vermit-teln. In Kapitel 6 werden Sie die Vorteile des OData-Channel-Pro-grammiermodells nutzen knnen, das wir in diesem Kapitel vorgestellt haben.

7

Inhalt

Vorworte ................................................................................. 17

Einleitung ................................................................................. 23

Teil I Einstieg

1 Einfhrung in SAP Gateway .................................... 31

1.1 Moderne Geschftsanwendungen ........................... 321.1.1 Benutzeroberflchen .................................. 331.1.2 Infrastruktur ............................................... 40

1.2 SAP Gateway fr moderne Geschftsanwendungen .......................................... 44

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

1.4 SAP Gateway im Kontext anderer relevanter SAP-Produkte ......................................... 561.4.1 Duet Enterprise .......................................... 561.4.2 SAP Enterprise Portal ................................. 591.4.3 SAP Mobile Platform ................................. 601.4.4 SAP HANA ................................................. 611.4.5 SAP Process Integration (PI) ....................... 621.4.6 SAP Business Warehouse (BW) .................. 63

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

2 Einfhrung 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

2.3 OData-Operationen ................................................ 842.3.1 Create = Anlegen ....................................... 842.3.2 Read = Lesen ............................................. 852.3.3 Update = ndern ....................................... 87

Inhalt

8

2.3.4 Delete = Lschen ........................................ 882.4 OData-Abfrageoptionen .......................................... 88

2.4.1 Filtern und Projizieren ($filter und $select) ...................................................... 90

2.4.2 Sortieren ($orderby) ................................... 942.4.3 Konsumentenseitiges Blttern ($top,

$skip und $inlinecount) .............................. 952.4.4 Zhlen ($count) .......................................... 1002.4.5 Expansion ($expand) .................................. 1002.4.6 Formatierung ($format) .............................. 104

2.5 OData in SAP-Lsungen .......................................... 1062.5.1 Mobile Productivity-Applikationen ............. 1112.5.2 SAP Fiori .................................................... 1122.5.3 SAP Jam ..................................................... 1122.5.4 SAP Enterprise Portal .................................. 1132.5.5 Duet Enterprise .......................................... 1132.5.6 SAP Solution Manager ................................ 1142.5.7 SAP HANA ................................................. 1142.5.8 SAP-zertifizierte Partnerlsungen ................ 117


3 Architektur und Integration .................................... 119

3.1 Gateway-Prinzipien ................................................. 1193.2 Architektur .............................................................. 121

3.2.1 Konsumentenschicht .................................. 1243.2.2 SAP-Gateway-Schicht ................................. 1253.2.3 SAP-Business-Suite-Schicht ........................ 1273.2.4 Add-on-Struktur ......................................... 129

3.3 Integration mit anderen SAP-Schnittstellen ............. 1313.3.1 Remote Function Call (RFC) ........................ 1313.3.2 Business Object Repository (BOR) .............. 1323.3.3 Service Provider Infrastructure (SPI) ............ 1323.3.4 SAP Business Warehouse (BW) InfoCubes ... 1333.3.5 Easy Query ................................................. 1343.3.6 Generic Interaction Layer (GenIL) ............... 1343.3.7 SAP HANA ................................................. 1343.3.8 SAP Business Process Management (BPM) ... 1353.3.9 SAP Business Workflow .............................. 135


Inhalt

9

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

4.1 Einfhrung in das Deployment von SAP Gateway .... 1374.1.1 Hub-Deployment mit Entwicklung im

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

dem Hub ................................................... 1414.1.3 Embedded Deployment ............................. 1454.1.4 Vergleich der Deployment-Optionen ......... 1464.1.5 Gemischte Deployment-Optionen ............. 148

4.2 Vorbereitung fr Installation und Konfiguration ...... 1504.3 Schnellstartanleitung .............................................. 153

4.3.1 Schritt 1: Deployment der SAP-Gateway-Add-ons .............................. 154

4.3.2 Schritt 2: Aktivierung von SAP Gateway ..... 1554.3.3 Schritt 3: Erstellung eines SAP-Systemalias . 1554.3.4 Schritt 4: Erstellung des

SAP-Gateway-Alias .................................... 1574.3.5 Schritt 5: Aktivierung des OPU-Knotens ..... 1584.3.6 Schritt 6: berprfen der Einstellungen ..... 159

4.4 Installation und Konfiguration im Detail ................. 1614.4.1 Installation der SAP-Gateway-Add-ons ...... 1624.4.2 Grundlegende Konfigurationseinstellungen 1624.4.3 OData-Channel-Konfiguration ................... 1654.4.4 Verbindung von SAP Gateway zur

SAP Business Suite ..................................... 1684.4.5 Business-Enablement-Provisioning-

Konfiguration (BEP) ................................... 1724.4.6 Smoke Tests ............................................... 173


Teil II Serviceerstellung

5 Einfhrung in die Erstellung von OData-Services mit SAP Gateway .................................................... 179

5.1 Serviceerstellung berblick .................................. 1805.2 SAP Gateway Entwicklungswerkzeuge .................. 186

5.2.1 SAP Gateway Service Builder ..................... 187

Inhalt

10

5.2.2 Weitere Werkzeuge neben dem Service Builder: Tools zur Untersttzung beim Serviceerzeugungsprozess ........................... 190

5.3 Serviceerstellung Schritt fr Schritt ........................ 1945.3.1 Datenmodellierung im Service Builder ........ 1945.3.2 Serviceregistrierung im SAP-Business-

Suite-System .............................................. 1985.3.3 Serviceimplementierung ............................. 2015.3.4 Serviceverw

OData und SAP Gateway -...

Documents

Transcript of OData und SAP Gateway -...