Entwicklung von Enterprise Services für SAP - Amazon S3 · 2018. 3. 26. · Die modell- und...

Bonn � Boston

Thomas Pohl, Markus Peter

Entwicklung von Enterprise Services für SAP®

1200.book Seite 3 Dienstag, 3. Februar 2009 11:08 11

Auf einen Blick

Teil I Modellierung von Enterprise Services

1 Grundlagen der Modellierung von

Enterprise Services ................................................... 23

2 Modellierung von A2X-Services ................................ 81

3 Prozessintegration und Integrationsszenarien ........... 127

Teil II Entwicklung von Enterprise Services

4 Enterprise Services Repository .................................. 141

5 Technische Grundlagen und Standards für

Services .................................................................... 157

6 Entwicklung von Enterprise Services in ABAP ........... 179

7 Entwicklung von Enterprise Services in Java .............. 249

Teil III Implementierungsbeispiele für Enterprise Services

8 Beispielimplementierung von

Enterprise Services in ABAP ...................................... 267

9 Implementierungsbeispiele für

Service Consumer ..................................................... 331

A Literaturverzeichnis .................................................. 409

B Die Autoren ............................................................. 411


7

Inhalt

Einleitung ................................................................................... 15

TEIL I Modellierung von Enterprise Services

1 Grundlagen der Modellierung von Enterprise Services ................................................... 23

1.1 Serviceorientierte Architekturen ................................. 261.1.1 Merkmale serviceorientierter Architekturen ... 271.1.2 SOA für Unternehmenssoftware –

offene Fragen ................................................. 301.1.3 SOA für Unternehmssoftware –

der SAP-Weg ................................................. 321.2 Enterprise Services ...................................................... 34

1.2.1 Ableitung aus dem Unternehmensmodell ....... 351.2.2 Rolle der globalen Datentypen ....................... 381.2.3 Von BAPIs über Webservices zu Enterprise

Services .......................................................... 401.3 A2X-, A2A- und B2B-Services ..................................... 44

1.3.1 A2X-Services .................................................. 451.3.2 A2A-Services .................................................. 461.3.3 B2B-Services .................................................. 48

1.4 Enterprise-Services-Metamodell ................................. 491.4.1 Prozesskomponenten ..................................... 501.4.2 Business-Objekte ........................................... 521.4.3 Service-Operationen ...................................... 551.4.4 Service-Schnittstellen ..................................... 571.4.5 Deployment Units .......................................... 581.4.6 Kommunikationsmuster und

Nachrichtenkategorien ................................... 591.4.7 Interface-Muster – Muster zusammen-

gehörender Schnittstellen .............................. 641.4.8 Zusammenfassung .......................................... 69

1.5 Enterprise Services Repository & Registry .................... 691.5.1 Wege zu einem eigenen SAP Enterprise

Services Repository ........................................ 701.5.2 Enterprise Services Builder – ein kurzer

Überblick ....................................................... 72


Inhalt

8

1.5.3 Modelle der SAP-Anwendungen und Enterprise Services ........................................ 75

1.6 Zusammenfassung ...................................................... 79

2 Modellierung von A2X-Services ............................... 81

2.1 Modellierung der Metamodell-Entitäten .................... 822.1.1 Anwendungsfall zur Analyse .......................... 822.1.2 Vorbereitungen im Enterprise Services

Repository ..................................................... 832.1.3 Identifizierung der Business-Objekte ............. 852.1.4 Schnitt der Prozesskomponenten und

Deployment Units ......................................... 882.1.5 Erstellung des Architekturmodells ................. 902.1.6 Zusammenfassung ......................................... 101

2.2 Konsistente Signaturen und ihre Wichtigkeit .............. 1012.3 Modellierung von Business-Objekten ......................... 103

2.3.1 Struktur des integrierten Business-Objekt-Modells ......................................................... 104

2.3.2 Business-Objekt-Eigenschaften ...................... 1092.3.3 SAP Global Data Types und

Core Data Types ............................................ 1152.3.4 Abschluss der Business-Objekt-

Modellierung ................................................ 1182.4 Ableitung der Enterprise-Services-Signaturen ............. 119

2.4.1 Business Document und Business Document Object .......................................... 119

2.4.2 Ableitung der Business-Document-Object-Struktur ......................................................... 121

2.4.3 Aufbau der Business-Document-Struktur ....... 1232.5 Zusammenfassung ...................................................... 126

3 Prozessintegration und Integrationsszenarien ........ 127

3.1 Integrationsszenariomodelle ...................................... 1283.1.1 Darstellung von Integrationsszenario-

modellen ....................................................... 1293.1.2 Integrationsszenariomodelle erstellen ............ 131

3.2 Prozesskomponenten-Interaktionsmodelle ................. 1343.2.1 A2A- und B2B-Services im Unterschied zu

A2X-Services ................................................. 135


Inhalt

9

3.2.2 Prozesskomponenten-Interaktionsmodelle erstellen ......................................................... 136

3.3 Integrationsszenariokatalog ........................................ 1373.4 Zusammenfassung ...................................................... 138

TEIL II Entwicklung von Enterprise Services

4 Enterprise Services Repository ................................. 141

4.1 Organisation des Enterprise Services Repository Contents ..................................................................... 142

4.2 Übersicht der benötigten Designobjekte ..................... 1434.2.1 Service-Interfaces ........................................... 1444.2.2 Message-Typen .............................................. 1464.2.3 Datentypen .................................................... 1464.2.4 Fault-Message-Typen ..................................... 1524.2.5 Zusammenfassung .......................................... 152

4.3 Industriespezifische Felder kennzeichnen .................... 1534.4 Namensräume im Enterprise Services Repository ........ 1544.5 Namenskonventionen für Designobjekte im

Enterprise Services Repository .................................... 1554.6 Zusammenfassung ...................................................... 156

5 Technische Grundlagen und Standards für Services 157

5.1 Webservices ............................................................... 1585.2 Extensible Markup Language ...................................... 159

5.2.1 Aufbau eines XML-Dokumentes ..................... 1595.2.2 Beispiel eines XML-Dokumentes .................... 1605.2.3 Namensräume ................................................ 1615.2.4 Verarbeitungsanweisung ................................ 1625.2.5 Syntaktische und semantische Korrektheit ...... 162

5.3 XML-Schema-Definition ............................................. 1625.3.1 Primitive Datentypen ..................................... 1625.3.2 Wertebereich, lexikalischer Bereich, Facette ... 1635.3.3 Abgeleiteter Datentyp .................................... 1635.3.4 Einfache Datentypen ...................................... 1645.3.5 Komplexe Datentypen ................................... 166

5.4 Web Services Description Language ............................ 1675.4.1 Aufbau eines WSDL-Dokumentes .................. 1685.4.2 Definitionen ................................................... 170


Inhalt

10

5.4.3 Datentypen ................................................... 1705.4.4 Nachricht ...................................................... 1705.4.5 Port-Typ ........................................................ 1715.4.6 Binding ......................................................... 1715.4.7 Service .......................................................... 172

5.5 SOAP ......................................................................... 1735.6 Weitere W3C-Standards ............................................ 174

5.6.1 XML-Parser ................................................... 1745.6.2 Extensible Stylesheet Language for

Transformation .............................................. 1755.6.3 XML Path Language ...................................... 177


6 Entwicklung von Enterprise Services in ABAP ......... 179

6.1 Motivation und grundlegende Eigenschaften ............. 1806.1.1 Entkopplung .................................................. 1806.1.2 Modellbasierte Entwicklung .......................... 1806.1.3 Transaktionales Verhalten .............................. 1806.1.4 Zustandslose und zustandsbehaftete

Kommunikation ............................................ 1816.1.5 Unidirektionale und bidirektionale

Kommunikation ............................................ 1816.1.6 Synchrone und asynchrone Kommunikation ... 1816.1.7 Eingehende und ausgehende Operationen

und Service-Interfaces ................................... 1836.1.8 Kommunikationsmuster ................................ 1846.1.9 Quality of Service .......................................... 1926.1.10 Verlässliche Nachrichtenzustellung ................ 193

6.2 Generierung von Proxys im Backend-System .............. 1956.2.1 ABAP-Provider-Proxy .................................... 1966.2.2 ABAP-Consumer-Proxy .................................. 197

6.3 ABAP-Proxy-Laufzeit und Konfiguration ..................... 1996.3.1 Übersicht über die Nachrichtenverarbeitung

zur Laufzeit ................................................... 2006.3.2 Konfiguration von Provider-Proxys ................ 2036.3.3 Konfiguration von Consumer-Proxys .............. 2066.3.4 Konfiguration der Nachrichtenverarbeitung

über den Integration Server ........................... 2086.3.5 Serialisierung und Deserialisierung ................ 209


Inhalt

11

6.4 Implementierung von Inbound-Service-Interfaces ....... 2126.4.1 Allgemeine Überlegungen zur

Implementierung ........................................... 2126.4.2 Grundlegendes Programmiermodell von

Enterprise Services ......................................... 2126.4.3 Implementierung von ändernden Services ...... 2166.4.4 Codelisten ...................................................... 2256.4.5 Verlässlicher Nachrichtenaustausch ................ 2306.4.6 Erweiterungskonzept ..................................... 2326.4.7 Fehlerbehandlung .......................................... 2336.4.8 Branchenspezifische Erweiterungen ................ 2376.4.9 Massendaten-Services .................................... 240

6.5 Testen von Services im Web Services Navigator .......... 2416.6 Evaluieren von Services im Enterprise Services

Workplace .................................................................. 2426.7 Publizieren von Services in die Services Registry ......... 243

6.7.1 Strukturierung von Services in der Services Registry .......................................................... 245

6.7.2 Konsumierung von Webservices aus der Services Registry ............................................ 247

6.7.3 Publikation von Services in die Services Registry .......................................................... 247


7 Entwicklung von Enterprise Services in Java ........... 249

7.1 Inside-Out-Implementierung ...................................... 2507.2 Outside-In-Implementierung ...................................... 250

7.2.1 Voraussetzungen ............................................ 2517.2.2 Import eines WSDL-Dokumentes ................... 2517.2.3 Proxy-Generierung ......................................... 2557.2.4 Anzeigen der generierten Webservice-

Artefakte ........................................................ 2577.3 Konfiguration von Webservices zur Designzeit ............ 258

7.3.1 Konfiguration der Authentifizierungsstufe ...... 2587.3.2 Konfiguration der Transportgarantie ............... 2597.3.3 Konfiguration von Web Services Reliable

Messaging (WS-RM) ...................................... 2607.3.4 Konfiguration von zustandsbehafteter

Kommunikation ............................................. 2607.3.5 Implementierung des JavaBean-Skeletons ...... 260


Inhalt

12

7.4 Konfiguration von Java-Webservices mit dem SAP NetWeaver Administrator ................................... 261

7.5 Publikation von Services aus dem SAP NetWeaver Administrator ............................................................. 262

7.6 Testen von Services mit dem Web Services Navigator 2647.7 Zusammenfassung ...................................................... 264

TEIL III Implementierungsbeispiele für Enterprise Services

8 Beispielimplementierung von Enterprise Services in ABAP ..................................... 267

8.1 Überblick über das Implementierungsprojekt ............. 2678.2 Vorbereitungen im Enterprise Services Repository ...... 2698.3 Vorbereitungen im ABAP-System ............................... 2738.4 Muster für den Entwurf der Service-

Implementierungen ................................................... 2758.5 Reservierung, Buchung und Stornierung eines

Fluges ........................................................................ 2798.5.1 Spezifikationen der Services ........................... 2798.5.2 Implementieren der Service-Interface-

Proxy-Klassen ................................................ 2828.5.3 Vorlage für Service-Implementierungs-

klassen .......................................................... 2848.5.4 Vervollständigung der Service-Implemen-

tierungsklasse Create Flight Sales Order ......... 2868.5.5 Hilfsklassen ................................................... 2908.5.6 Vervollständigung der Confirm- und Cancel-

Services ......................................................... 2928.6 Service zum Lesen einer Flugbuchung ........................ 296

8.6.1 Spezifikation des Service Read Flight Sales Order ............................................................ 296

8.6.2 Service-Implementierungsklasse Read Flight Sales Order .................................................... 297

8.7 Wertehilfe-Services .................................................... 3028.7.1 Implementieren des Service Find Flight

Customer ...................................................... 3048.7.2 Implementieren des Service Find Flight ......... 3118.7.3 Wertehilfen für Core-Datentypen vom Typ

Code ............................................................. 315


Inhalt

13

8.8 Service zur Überprüfung der Verfügbarkeit eines Fluges ......................................................................... 318

8.9 Änderungen von Flugbuchungen ................................ 3198.10 Testen der Service-Implementierungen ....................... 3278.11 Zusammenfassung ...................................................... 329

9 Implementierungsbeispiele für Service Consumer ... 331

9.1 Entwicklung einer Consumer-Anwendung in ABAP ..... 3329.1.1 Beispielanwendung ........................................ 3329.1.2 Rahmen des Reservierungs-Reports ................ 3349.1.3 Füllen der Listboxen für Flughafen und

Buchungsklasse .............................................. 3379.1.4 Ermittlung der Flüge ...................................... 3419.1.5 Interaktive Anzeige der Flüge mit einem

ABAP List Viewer ........................................... 3449.1.6 Aufruf der Verfügbarkeitsprüfung ................... 3489.1.7 Service-Aufruf zur Reservierung eines Fluges ... 3509.1.8 Zusammenfassung .......................................... 353

9.2 Anwendungsentwicklung mit dem SAP NetWeaver Composition Environment .......................................... 3549.2.1 SAP NetWeaver Visual Composer .................. 3559.2.2 Web Dynpro Java ........................................... 365

9.3 Anwendungsentwicklung mit Eclipse .......................... 3789.3.1 Eclipse ........................................................... 3799.3.2 JSP-Beispielapplikation .................................. 3819.3.3 Erzeugen eines dynamischen Webprojektes

in der Eclipse IDE ........................................... 3829.3.4 Import des WSDL-Dokumentes ...................... 3839.3.5 Erstellen der JavaServer Page ......................... 3849.3.6 Editieren des Deployment Descriptors ........... 3859.3.7 FlightDemoServlet-Servlet .............................. 3869.3.8 Implementieren der JavaBean

FlightDemoBean ............................................ 3909.3.9 Resultat ......................................................... 393

9.4 Anwendungsentwicklung mit Microsoft .NET ............. 3949.4.1 Generieren des Consumer-Proxys ................... 3959.4.2 Erstellen der Consumer-Anwendung .............. 3979.4.3 Resultat ......................................................... 405



Inhalt

14

Anhang ........................................................................... 407

A Literaturverzeichnis .............................................................. 409B Die Autoren ......................................................................... 411

Index .......................................................................................... 413


179

Enterprise Services sind in mehrfacher Hinsicht standardisiert. Die modell- und designspezifischen Grundlagen für die einheitli-che Definition der Services wurden bereits besprochen und die technischen Standards für die Nachrichtenübertragung erläu-tert. Services besitzen darüber hinaus ein gemeinsames Program-miermodell, um ein einheitliches Verhalten zur Laufzeit zu garantieren. Dies soll in diesem Kapitel dargestellt werden.

6 Entwicklung von Enterprise Services in ABAP

In den vorangegangenen Kapiteln haben Sie erfahren, wie EnterpriseServices modelliert und im Enterprise Services Repository in einem stan-dardisierten Format spezifiziert werden. Wir wollen nun in diesem Kapi-tel beschreiben, nach welchen Richtlinien die Services in ABAP entwi-ckelt werden.

Die Implementierung erfolgt in Proxys, die aus den Metadaten der Ser-vices generiert werden. Eine gemeinsame Architektur sorgt dafür, dasssich die Services zur Laufzeit in einer einheitlichen und konsistentenWeise verhalten. Wir werden in diesem Kapitel ausführlich auf diese Ar-chitektur eingehen. Zuvor wollen wir noch einige grundlegende Eigen-schaften von Enterprise Services beschreiben, die für das Verständnis derfolgenden Ausführungen wichtig sind. Statt des Begriffs »Enterprise Ser-vices« werden dabei auch die Bezeichnungen »Webservices« oder aucheinfach »Services« benutzt, je nachdem, ob eher das Gesamtkonzept, dietechnische Implementierung oder die Funktionalität an sich gemeint ist.

Um die Darstellung des Inhalts einfacher und übersichtlicher zu gestal-ten, beziehen wir uns auf die aktuellen Releases der SAP Business Suitebzw. SAP NetWeaver Process Integration 7.1 EhP1, auch wenn viele derin diesem Kapitel dargestellten Funktionalitäten bereits in früheren Re-leases verfügbar sind.


180

Entwicklung von Enterprise Services in ABAP6

6.1 Motivation und grundlegende Eigenschaften

Eine servicebasierte Architektur unterscheidet sich in vielerlei Hinsicht vondem herkömmlichen Programmiermodell für Geschäftsanwendungen. DieUnterschiede manifestieren sich nicht nur im Entwicklungsprozess von Ge-schäftsanwendungen, sondern auch in der Art und Weise, wie Applikati-onen zur Laufzeit miteinander kommunizieren und wie sie miteinander in-tegriert sind. In diesem Kapitel wollen wir auf die Besonderheiten einerservicebasierten Architektur und ihre Vorzüge näher eingehen.

6.1.1 Entkopplung

SOAP Eine Motivation zum Einsatz von Enterprise Services ist die Entkopplungder Anwendungen durch zwischengeschaltete Dienste. Consumer undProvider können ohne Einschränkungen hinsichtlich der Plattform mit-einander kommunizieren, auf der sie implementiert sind. So kann zumBeispiel eine Java EE-basierte Geschäftsanwendung auf Services zugrei-fen, die in ABAP implementiert sind. Dies wird durch die Standardisie-rung der verwendeten Technologie ermöglicht, die mittlerweile weitfortgeschritten ist. Consumer und Provider kommunizieren über ein of-fenes Protokoll (SOAP) und verwenden nur standardisierte Schnittstellen-informationen, die in einer Services Registry publiziert werden können.Dadurch erlaubt die technische Entkopplung die Wiederverwendbarkeitvon Services auf unterschiedlichen Plattformen.

6.1.2 Modellbasierte Entwicklung

Metadaten Bei der Entwicklung von Enterprise Services spielen die Metadaten einewichtige Rolle. Sie definieren auf technischer Ebene den Vertrag zwi-schen Consumer und Provider. Anhand der Metadaten kann der Consu-mer das Format der Nachrichten sowie weitere Informationen ermitteln,die er für den Aufruf des Service aus seiner Anwendung benötigt. Fürden Provider stellen die Metadaten die Vorgaben dar, die es zu imple-mentieren gilt. Consumer und Provider können aus ihnen die Rahmenbzw. Skeletons der benötigten Entwicklungsobjekte generieren.

6.1.3 Transaktionales Verhalten

Datenkonsistenz Es ist eine grundlegende Anforderung an das Verhalten von EnterpriseServices, dass ihre Ausführung die Datenbank immer in einem konsisten-ten Zustand hinterlässt. Insbesondere soll es nicht erforderlich sein, zu-sätzliche Services aufzurufen, um die Datenkonsistenz sicherzustellen.


181

Motivation und grundlegende Eigenschaften 6.1

Stattdessen transformiert jeder Service-Aufruf die Datenbank von einemkonsistenten Zustand in einen anderen konsistenten Zustand.

6.1.4 Zustandslose und zustandsbehaftete Kommunikation

Prinzipiell können Enterprise Services zustandslos oder zustandsbehaftetsein. Dabei bedeutet zustandsbehaftet, dass für eine laufende Interaktionmit einem Consumer eine spezifische Kontextinformation beim Providerüber mehrere aufeinanderfolgende Aufrufe hinweg gespeichert wird.

Der Kontext kann auf mehreren Ebenen bereitgestellt werden:

� auf der Ebene der technischen Kommunikation mittels eines zustands-behafteten Protokolls

� auf der Service-Ebene, indem aufeinanderfolgende Aufrufe von dem-selben Verwender zu einer Session zusammengefasst werden (etwaindem eine Session-ID ausgetauscht wird)

� auf der Ebene der Applikation, die dann ihrerseits entsprechendeMechanismen bereitstellen muss

Die von SAP in der Business Suite ausgelieferten Enterprise Services sindalle zustandslos. Auch im Folgenden werden ausschließlich zustandsloseEnterprise Services betrachtet, ohne dies jedes Mal explizit zu erwähnen.

6.1.5 Unidirektionale und bidirektionale Kommunikation

Benachrich-tigungen

Services können unidirektional und auch bidirektional kommunizieren.Dabei bedeutet unidirektional, dass der Initiator der Kommunikationeine Nachricht an einen Empfänger sendet. Bei der bidirektionalen Kom-munikation wird zusätzlich vorausgesetzt, dass der Empfänger der Nach-richt wieder eine Antwortnachricht an den Sender schickt.

Typische Szenarien für unidirektionale Kommunikation sind Benachrich-tigungen einer anderen Applikation über den Ausgang einer Verarbei-tung. In den meisten Fällen wird jedoch eine bidirektionale Kommunika-tion benötigt, da der Initiator am Ergebnis seiner Nachricht interessiert ist.

6.1.6 Synchrone und asynchrone Kommunikation

Synchrone und asynchrone Kommunikation sind zwei grundsätzlich ver-schiedene Modi, um Informationen auszutauschen:


182


Kommunikations-kanal

� Synchrone KommunikationSynchrone Kommunikation ist im Allgemeinen bidirektional, denn sieerfordert einen Kommunikationskanal zwischen dem Initiator derNachricht und dem Empfänger, über den dann auch die Antwortnach-richt direkt an den Initiator zugestellt werden kann. Die synchrone Kom-munikation kann mit einem Telefongespräch verglichen werden, beidem der Anrufer eine Request-Nachricht an den Empfänger übermittelt(zum Beispiel »Buche den Flug mit der Nummer LH454 von Frankfurtnach San Francisco am 1. Mai 2009«) und der Empfänger diesen Requestdirekt bestätigt oder ablehnt. Der Initiator setzt die Verarbeitung erstdann fort, wenn er die Antwort vom Empfänger erhalten hat.

Blockierend Dieses Verhalten, das kennzeichnend für die synchrone Kommunika-tion ist, wird auch als blockierend bezeichnet, da in dieser Zeitspannewichtige Systemressourcen, wie zum Beispiel Datenbanksperren oderder Kommunikationskanal, exklusiv genutzt werden.

Nicht blockierend � Asynchrone KommunikationDie asynchrone Kommunikation ist auf den ersten Blick unidirektio-nal, was nicht zwangsläufig bedeutet, dass keine Antwort gesendetwerden kann. Sie kann verglichen werden mit der Kommunikationüber E-Mail. Der Initiator würde in diesem Fall eine elektronischeNachricht an den Empfänger senden, der zeitversetzt antworten kannoder auch nicht. Der große Vorteil der asynchronen Kommunikationliegt darin, dass der Initiator seine Verarbeitung fortsetzen kann, ohneSystemressourcen zu blockieren, bis die Antwort eingetroffen ist.

Verfügbarkeit desEmpfängers

Aus diesem Grund skalieren Anwendungen, die auf asynchronerKommunikation basieren, deutlich besser als solche, die eine syn-chrone Kommunikation verwenden. Der Ressourcenbedarf einerasynchronen Anwendung wächst bei steigenden Eingabemengen imAllgemeinen deutlich geringer als bei einer synchronen Anwendung.Dies setzt natürlich voraus, dass die Antwortnachricht nicht unmittel-bar benötigt wird. Ein weiterer Vorteil gegenüber der synchronenKommunikation ist, dass der Empfänger nicht zu dem Zeitpunkt ver-fügbar sein muss, zu dem der Initiator seine Nachricht sendet.

Fehlerbehandlung Jeder hat schon oft erlebt, dass bei einem Telefonanruf der Empfängernicht abhebt oder der Anschluss besetzt ist. Auf der anderen Seitestellt die asynchrone Kommunikation deutlich höhere Anforderungenan die technische Infrastruktur, die die Antwortnachricht mit der Ein-gangsnachricht korrelieren und sie an den entsprechenden Empfängersenden muss. Außerdem sind spezielle Mechanismen erforderlich,um aufgetretene Fehler zu behandeln.


183


6.1.7 Eingehende und ausgehende Operationen und Service-Interfaces

Eine eingehende Operation ist eine Operation eines eingehenden Ser-vice-Interface, und analog ist eine ausgehende Operation eine Operationeines ausgehenden Service-Interface. Statt der Kennzeichnung eingehendund ausgehend werden synonym auch die geläufigen Bezeichnungen in-bound bzw. outbound verwendet. Das aus einem Inbound-(Outbound-)Service-Interface generierte Proxy-Objekt wird auch als Inbound-(Out-bound-)Proxy bezeichnet. Eine eingehende Operation empfängt Nach-richten von einem Sender, und eine ausgehende Operation sendet Nach-richten an einen Empfänger.

� Eine Outbound-Operation wird von einer rufenden Anwendung ausfolgenden Gründen verwendet:

� Es soll eine Request-Nachricht an einen Provider versendet wer-den. In diesem Fall soll ein Service des Providers aufgerufen wer-den. Der Aufruf erfolgt aus einer Consumer-Applikation in einemConsumer-Proxy. Im Allgemeinen wird eine Antwort (Confirma-tion) erwartet.

� Es soll eine andere Applikation über einen Vorgang benachrich-tigt werden. In diesem Fall soll lediglich eine Nachricht an dieandere Applikation übertragen werden. Eine Antwort wird nichterwartet.

Service Provider� Eine Inbound-Operation wird vom Service Provider implementiert.Sie enthält die Funktionalität, die den Consumern als Service (imSinne einer technischen Dienstleistung) zur Verfügung gestellt wer-den soll. Die Implementierung der Funktionalität erfolgt in einemProvider-Proxy.

In Abbildung 6.1 ist der Zusammenhang von Consumer-Applikation undProvider-Applikation sowie Consumer-Proxy und Provider-Proxy darge-stellt.

Abbildung 6.1 Zusammenhang zwischen Consumer- und Provider-Proxy

Consumer-ApplikationConsumer-Proxy

(Outbound)

Provider-ApplikationProvider-Proxy

(Inbound)

ruft auf


184


6.1.8 Kommunikationsmuster

Analog zur interpersonellen Kommunikation, bei der zwischen verschie-denen Formen der Kommunikation unterschieden wird (zum BeispielMonolog, Dialog, Diskussion), können die Kommunikationen zwischenAnwendungen nach verschiedenen Kriterien klassifiziert werden. Bei derservicebasierten Kommunikation wird zwischen den folgenden Kommu-nikationsmustern (Communication Patterns) unterschieden, die in diesemKapitel aus Sicht der Implementierung charakterisiert werden:

Bidirektional � Request/Confirmation-MusterDieses Muster ist dadurch charakterisiert, dass der Aufrufer beim Pro-vider eine Aktivität anfordert (zum Beispiel ein Geschäftsobjekt anle-gen oder ändern) und der Provider die Aktivität nach der Ausführungbestätigt.

� Query/Response-MusterBei diesem Muster wird eine Anfrage an den Provider gesendet (zumBeispiel welche Geschäftsobjekte gehören zu meiner Organisations-einheit), die der Provider in seiner Response-Nachricht beantwortet.

Unidirektional � Notification-MusterHier wird eine Nachricht an einen Empfänger versendet. Es wird je-doch keine Antwort erwartet, sondern der Aufrufer geht davon aus,dass der Empfänger die Nachricht erwartungsgemäß verarbeitet, umden Geschäftsprozess konsistent abzuschließen.

� Information-MusterIn diesem Pattern wird wie beim Notification-Muster eine Nachrichtan einen Empfänger versendet, allerdings sind an die Verarbeitungder Nachricht keine Erwartungen geknüpft. Der Empfänger kann dieNachricht zur Kenntnis nehmen, und die weitere Verarbeitung istallein ihm überlassen.

Im Unterschied zu den beiden ersten Mustern handelt es sich bei der No-tification und der Information um eine unidirektionale Kommunikation,die über asynchrone Outbound-Service-Interfaces modelliert werdenkann. Das Request/Confirmation- und das Query/Response-Muster sindbidirektional und können sowohl in synchroner als auch in asynchronerAusprägung vorkommen.

Im Folgenden werden diese Muster aus Sicht der Entwicklung näher be-schrieben und dabei auch die Unterschiede zwischen synchroner undasynchroner Kommunikation erläutert.


185


Synchrones Request/Confirmation-Muster

Der Ablauf des synchronen Request/Confirmation-Musters ist wie folgtdefiniert (siehe Abbildung 6.2):

� Die Consumer-Applikation sendet eine Request-Nachricht an die Pro-vider-Applikation, indem sie die entsprechende Methode des Out-bound-Proxys aufruft.

� Dies führt dazu, dass auf der Seite des Providers die zugehörige Me-thode des Inbound-Proxys aufgerufen wird, die die gewünschte Ge-schäftslogik implementiert.

� Das Ergebnis des Aufrufs (die Return-Parameter) wird unmittelbar deraufrufenden Applikation übergeben.

� Nach Ausführung des Aufrufs kann die Applikation mit der Verarbei-tung fortfahren.

Abbildung 6.2 Sequenzdiagramm für das synchrone Request/Confirmation-Muster

Ein synchrones Request/Confirmation-Muster wird im Enterprise Ser-vices Repository durch ein eingehendes Service-Interface abgebildet, daseine synchrone Operation mit folgenden Messages enthält:

� Request

� Response

� Fault

Abbildung 6.3 zeigt ein Beispiel eines solchen Service-Interface.

ProviderInbound-Proxy

ConsumerOutbound-Proxy

Sende Confirmation

Sende Request

Geschäftslogik

�

�

�

�


186


Abbildung 6.3 Beispiel für ein synchrones Service-Interface im Enterprise Services Repository

Asynchrones Request/Confirmation-Muster

Höhere Durchsätze Das asynchrone Request/Confirmation-Muster unterscheidet sich vomsynchronen Muster dadurch, dass Consumer und Provider asynchronkommunizieren. Der Vorteil einer asynchronen Kommunikation liegt da-rin, dass die Verarbeitung der Messages entkoppelt erfolgen kann undsich dadurch höhere Durchsätze ergeben.

Point-to-Point-Kommunikation

Für die Laufzeit ergibt sich dadurch aber das Problem, die Antwortnach-richt wieder dem ursprünglichen Aufrufer zuzustellen. Prinzipiell erge-ben sich zwei Möglichkeiten, die Nachrichten zuzustellen. Zunächst wirddie direkte Kommunikation zwischen Consumer und Provider beschrie-ben, die auch als Point-to-Point-Kommunikation (P2P) bezeichnet wird,und danach die Kommunikation über einen Broker.

Direkte (P2P-)KommunikationDer Ablauf des asynchronen Request/Confirmation-Musters bei einer di-rekten Kommunikation zwischen Consumer und Provider ist wie folgt:

� Der Consumer sendet eine Request-Nachricht an den Provider. Hierzuruft er in seiner Applikation die entsprechende Methode des Out-bound-Proxys auf.

� Dies führt dazu, dass auf der Seite des Providers die zugehörige Me-thode des Inbound-Proxys aufgerufen wird.

� In der Implementierung des Inbound-Proxys wird die gewünschte Ge-schäftslogik ausgeführt.


187


� Nachdem die Geschäftslogik ausgeführt wurde, wird ein Outbound-Proxy der Provider-Anwendung aufgerufen.

� Der Outbound-Proxy sendet die Bestätigungsnachricht (Confirmation)an die aufrufende Applikation.

� Der Consumer empfängt die Nachricht in dem dafür vorgesehenenInbound-Proxy.

Der Ablauf ist in dem Sequenzdiagramm in Abbildung 6.4 dargestellt.Diese Kommunikation setzt voraus, dass der Provider sich die Adressin-formation des Consumers so lange merkt, bis er die Antwortnachricht anihn zugestellt hat. Zudem sehen Sie an diesem Beispiel, dass sowohl aufConsumer- als auch auf Provider-Seite ein Inbound- und ein Outbound-Proxy aufgerufen werden.

Abbildung 6.4 Sequenzdiagramm für das asynchrone Request/Confirmation-Muster (P2P)

Kommunikation über einen Integration BrokerEine andere Möglichkeit ist es, dass die Consumer- und die Provider-Ap-plikation indirekt über einen Integration Broker kommunizieren. DerAblauf ist dabei wie folgt:



ConsumerInbound-Proxy

ProviderOutbound-Proxy

Sende Request-Nachricht

Geschäftslogik

Erzeuge Outbound-Proxy

Sende Confirmation

� �

�

�

��


188


� Der Consumer sendet einen Request an den Broker. Hierzu ruft er inseiner Applikation die entsprechende Methode des Outbound-Proxysauf.

� Der Broker ermittelt den gewünschten Provider und leitet den Re-quest an diesen weiter.

� Der Provider ruft die gewünschte Geschäftslogik auf.

� Der Provider instanziert seinen Outbound-Proxy für die Antwort.

� Der Outbound-Proxy sendet die Bestätigungsnachricht (Confirmation)an den Broker.

� Der Broker empfängt die Bestätigungsnachricht, ermittelt den Emp-fänger und leitet sie an ihn weiter.

� Der Consumer empfängt die Bestätigungsnachricht in dem dafür vor-gesehenen Inbound-Proxy.

Dieser Ablauf ist im Sequenzdiagramm in Abbildung 6.5 dargestellt.

Abbildung 6.5 Sequenzdiagramm für das asynchrone Request/Confirmation-Muster mit einem Integration Broker

Integration Broker

ProviderOutbound-Proxy

ConsumerInbound-Proxy



Geschäftslogik

Erzeuge Outbound-Proxy

Sende Request-Nachricht

Leite Request-Nachricht weiter

Sende Bestätigungsnachricht

Leite Bestätigungsnachricht weiter

�

�

�

�

�

�

�


189


Service-Interface im Enterprise Services RepositoryDas asynchrone Request/Confirmation-Muster wird im Enterprise ServicesRepository über zwei Service-Interfaces abgebildet. Das eingehende Ser-vice-Interface enthält eine asynchrone Operation für den Request, und daskorrespondierende ausgehende Service-Interface enthält eine asynchroneOperation für die Bestätigungsnachricht (Confirmation). Die Operation fürdas eingehende Service-Interface enthält zudem eine Fault Message.

Abbildung 6.6 zeigt ein Beispiel für ein eingehendes Service-Interface undAbbildung 6.7 ein Beispiel für ein ausgehendes Service-Interface. Beidezusammen bilden ein asynchrones Request/Confirmation-Muster ab.

Abbildung 6.6 Beispiel für ein asynchrones ausgehendes Service-Interface im Enterprise Services Repository

Abbildung 6.7 Beispiel für ein asynchrones eingehendes Service-Interface im Enterprise Services Repository


190


Notification-Muster

Der Ablauf des Notification-Musters ist wie folgt definiert:

1. Die Applikation löst das Versenden der Nachricht an einen Empfängeraus.

2. Der Empfänger erhält und verarbeitet die Nachricht.

3. Der Empfang und die Verarbeitung der Nachricht sind erforderlich,um den Geschäftsprozess konsistent abzuschließen.

Das Notification-Muster wird im Enterprise Services Repository über einausgehendes zustandsloses Service-Interface abgebildet. Es enthält eineasynchrone Operation in der Rolle Request. Ein Beispiel ist in Abbildung6.8 gezeigt.

Abbildung 6.8 Beispiel eines Notification-Musters

Information-Muster

Das Information-Muster läuft wie folgt ab:

1. Die Applikation löst das Versenden der Nachricht an einen Empfängeraus.

2. Der Empfänger erhält die Nachricht und kann sie verarbeiten.

3. Im Unterschied zur Notification ist die Verarbeitung der Nachrichtauf Empfängerseite nicht unbedingt erforderlich, um den Geschäfts-prozess konsistent abzuschließen. Dem optionalen Empfänger ist esfreigestellt, Folgeaktionen anzustoßen.

Das Information-Muster wird analog zum Notification-Muster über einausgehendes zustandsloses Service-Interface abgebildet. Es enthält eine


191


asynchrone Operation in der Rolle Request. Ein Beispiel ist in Abbildung6.9 aufgeführt.

Abbildung 6.9 Beispiel eines Information Patterns

TU&C/C-Muster (Tentative Update & Confirm/Compensation)

Bei betriebswirtschaftlichen Anwendungen kommt es häufig vor, dassein Vorgang erst vorläufig ausgeführt wird, bevor er endgültig verarbei-tet wird. Ein Beispiel hierfür ist eine Reservierung, die gewisse Ressour-cen für eine gewisse Zeit vor weiterem Zugriff sperrt (zum Beispiel Arti-kel aus einem Lager), bevor die eigentliche Buchung erfolgt. Zwischender Reservierung und der Buchung kann die Reservierung noch mehr-mals geändert werden.

Im Beispiel der Flugbuchung würde die Fluggesellschaft sich bei der Re-servierung verpflichten, den Sitz (für eine gewisse Zeit) nicht weiter zuvergeben. Innerhalb dieser Zeit ist es möglich, die Reservierung nochmehrmals zu ändern. Erst wenn die Fluggesellschaft eine Bestätigung vomAuftraggeber erhält, erfolgt eine verbindliche Buchung durch den Anbie-ter, das heißt die Fluggesellschaft. Der Auftraggeber kann aber auch dieReservierung stornieren. In diesem Fall würde die Fluggesellschaft denSitz wieder für andere Auftraggeber bereitstellen.

Technisch handelt es sich hier um ein Protokoll, das durch das TU&C/C-Muster abgebildet werden kann. Es werden die folgenden Schrittedurchlaufen:


192


SQL-Transaktions-isolation

1. Der Consumer ruft über eine synchrone Tentative-Update-Operationeinen Service beim Provider auf. Dieser Service führt den Vorgangaber noch nicht endgültig aus, sondern kennzeichnet die Änderungenals vorläufig. Die Änderung ist für andere Consumer sichtbar, dasheißt es liegt keine Isolation im Sinne einer SQL-Transaktionsisolationvor.

Transaktions-ID 2. Im weiteren Verlauf kann diese Anforderung noch mehrfach geändertwerden. Mit einer Transaktions-ID stellt der Aufrufer den Bezug zudem Vorgang her.

3. Abschließend teilt der Aufrufer dem Service Provider mit, ob derVorgang nun endgültig ausgeführt oder storniert werden soll. Diesgeschieht über den Aufruf einer asynchronen Confirm- bzw. einerasynchronen Compensation-Operation.

Voraussetzung für dieses Protokoll ist auf technischer Ebene die garan-tierte Verarbeitung von Messages und auf semantischer Ebene die Ein-haltung eines bestimmten Vertrages zwischen Consumer und Provider.Dieser Vertrag schreibt vor, dass der Consumer immer am Ende der Ver-arbeitung eine Confirm Message oder eine Compensation Message ver-schickt und der Provider diese Nachrichten korrekt verarbeitet. Die Ein-haltung des Vertrages muss auch bei technischen Problemen (zum BeispielAusfall des Provider-Systems) gewährleistet sein.

Im Enterprise Services Repository wird ein TU&C/C-Muster durch einspezielles Service-Interface abgebildet, das mindestens eine synchroneOperation und zwei asynchrone Operationen enthält. Da Service-Inter-faces dieser Art nicht XI 3.0-kompatibel sind, wird dieses Muster in derSAP Business Suite noch nicht verwendet.

6.1.9 Quality of Service

VerlässlicheNachrichten-

zustellung

Der Quality of Service bzw. die Dienstgüte ist ein wichtiges Attributeines Kommunikationsdienstes, das die Verlässlichkeit der Nachrichten-zustellung beschreibt. Im Zusammenhang mit Webservices wird zwi-schen verschiedenen Qualitätsanforderungen, die im Folgenden be-schrieben werden, unterschieden.

� Best EffortBest Effort bezeichnet eine Dienstgüte, bei der die anfallenden Nach-richten so gut und schnell wie möglich übertragen werden. Allerdingswird aus Sicht des Netzwerkes keine Garantie dafür übernommen,dass die Nachrichten zugestellt werden.


193


Beispielsweise wird gewöhnliche Briefpost nach diesem Prinzip ver-sendet: Der Briefträger tut sein Bestes, den Brief zuzustellen. Trotz-dem kann es vorkommen, dass Briefe verzögert zugestellt werdenoder auf dem Postweg verloren gehen.

Auch Standard-SOAP übernimmt keine Garantie für eine verlässlicheNachrichtenzustellung und enthält keine Mechanismen, um die Kom-munikation gegen Nachrichtenverlust oder mehrfache Nachrichtenzu-stellung abzusichern.

� At Most OnceAt Most Once garantiert, dass dieselbe Nachricht höchstens einmaldem Empfänger zugestellt wird. Mehrfachzustellungen derselbenNachricht sind nicht erlaubt. Möglicherweise werden nicht alle Nach-richten zugestellt.

� At Least OnceAt Least Once garantiert, dass jede Nachricht mindestens einmal zuge-stellt oder eine Fehlermeldung erzeugt wird. Möglicherweise wirdeine Nachricht mehrfach zugestellt.

� Exactly OnceExactly Once garantiert, dass jede Message genau einmal zugestelltbzw. eine Fehlermeldung erzeugt wird, falls dies nicht möglich ist.

� In OrderIn Order garantiert, dass die Nachrichten in der Reihenfolge (Se-quence) zugestellt werden, in der sie versendet wurden.

� Exactly Once In OrderExactly Once In Order ist eine Kombination aus Exactly Once und InOrder und bezeichnet eine Dienstgüte, die sicherstellt, dass Nachrich-ten genau einmal und in der Reihenfolge beim Empfänger ankom-men, in der sie abgeschickt wurden.

6.1.10 Verlässliche Nachrichtenzustellung

SAP Idempotency Framework

Bei geschäftskritischen Anwendungen ist es von großer Bedeutung, dassNachrichten zuverlässig (reliable) zugestellt werden. Eine Grundanforde-rung ist dabei die Zustellung von Nachrichten mit dem Quality of ServiceExactly Once (QoS EO). Da SOAP keine Aussage über die Zustellgarantiemacht, sind zusätzliche Hilfsmittel bzw. Standards erforderlich, um die-ses Ziel zu erreichen.

Bei synchronen Services kann die Applikation Exactly Once dadurch er-zielen, dass sie das Idempotency Framework (IDP) verwendet, das Bestand-teil von SAP NetWeaver ist. In Abschnitt 6.4.5, »Verlässlicher Nachrich-


194


tenaustausch«, wird das zugrunde liegende Programmiermodell genauerbesprochen. Im Fall von asynchronen Services hängt die Vorgehensweisedavon ab, ob die Zustellung über einen Broker (PI Integration Server)oder über P2P erfolgt. Diese Fälle werden im Folgenden näher beschrie-ben.

Reliable Messaging bei Einsatz des PI Integration Servers

Das SAP-eigene XI 3.0-Nachrichtenaustauschprotokoll, das beim Einsatzdes PI Integration Servers verwendet wird, enthält bereits die notwendi-gen Mechanismen, um Nachrichten auf der Qualitätsstufe EO zuzustel-len.

Reliable Messaging bei P2P-Kommunikation

WS-RM Um auch den zuverlässigen Nachrichtenaustausch ohne Verwendung derInfrastruktur von SAP NetWeaver PI zu ermöglichen, unterstützt SAP Net-Weaver den offenen Standard Web Services Reliable Messaging (WS-RM).WS-RM ist ein Protokoll, das dazu verwendet werden kann, die Quali-tätsstufe EO oder sogar EOIO zur Verfügung zu stellen.

Sequenzen Das WS-RM-Protokoll bedient sich dabei sogenannter Sequenzen. Inner-halb einer Sequenz werden die Nachrichten aufsteigend mit 1 beginnendnummeriert, sodass der Empfänger feststellen kann, ob eine Messagenicht zugestellt wurde und in welcher Reihenfolge die Nachrichten ver-schickt wurden.

Abbildung 6.10 zeigt ein typisches WS-RM-Szenario. Der Consumer(Endpoint A) sendet zunächst einen Request zur Erstellung einer Se-quenz an den Provider (Endpoint B), den dieser mit der Rückgabe einerIdentifikation für die Sequenz quittiert. Unter Bezugnahme auf diese Se-quenz sendet der Consumer nun drei Nachrichten, die er mit 1 begin-nend durchnummeriert (MessageNumber). Die letzte Nachricht ist mitdem Attribut LastMessage gekennzeichnet. Nach Erhalt dieser Nach-richt bestätigt der Provider den Erhalt der Nachrichten mit den Sequenz-nummern 1 und 3. Da die Nachricht mit der Sequenznummer 2 verlorengegangen ist, wird sie vom Consumer erneut verschickt. Danach wird dieSequenz beendet.

WS-RM wird auf Protokollebene bereits von SAP NetWeaver unterstützt.Zur Unterstützung von P2P-Interaktion ohne Einsatz eines IntegrationServers plant SAP, asynchrone Services sukzessive in der SAP BusinessSuite dieses Protokoll unterstützen zu lassen.


195

Generierung von Proxys im Backend-System 6.2

Abbildung 6.10 Nachrichtenaustausch bei WS-RM (Quelle: http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf)

Im folgenden Abschnitt wird nun beschrieben, wie die Services im Back-end-System implementiert werden.

6.2 Generierung von Proxys im Backend-System

Plattformspe-zifische Laufzeit-objekte

Während die Designobjekte im Enterprise Services Repository plattform-unabhängig definiert sind, handelt es sich bei Proxy-Objekten um platt-formspezifische Laufzeitobjekte, die angepasst für die jeweilige Laufzeitum-gebung (zum Beispiel ABAP oder Java) generiert werden. Voraussetzung fürdie Generierung der Proxy-Objekte ist, dass die zugehörigen Designobjekteim Enterprise Services Repository modelliert oder zumindest als eine ex-terne WSDL-Beschreibung verfügbar sind. Im ABAP-Backend-System musseine Paketstruktur angelegt sein, die definiert, in welchem Paket die Proxysangelegt werden.

Enterprise Services Browser

Abbildung 6.11 zeigt einen Ausschnitt des Navigationsbaums im Enter-prise Services Browser in der ABAP-Entwicklungsumgebung. Im Detail-bild sehen Sie für das Service-Interface CostCentreLineItemBudget-MonitoringRuleByIDQueryResponse_In den Namen des erzeugten Proxy-Interfaces sowie der implementierenden Provider-Proxyklasse.

EndpointA

EndpointBReliable Messaging Protocol

Establish Protocol Preconditions

CreateSequence()

CreateSequenceResponse( Identifier = http://fabrikam123.com/abc )

Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 1 )

Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 2 )

Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 3, LastMessage )

SequenceAcknowledgement( Identifier = http://fabrikam123.com/abc, AcknowledgementRange = 1,3 )

Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 2, AckRequested )

SequenceAcknowledgement( Identifier = http://fabrikam123.com/abc, AcknowledgementRange = 1 ... 3 )

TerminateSequence( Identifier = http://fabrikam123.com/abc )


196


Abbildung 6.11 Enterprise Services Browser

Für die folgende Diskussion soll ein Szenario, bestehend aus einem Pro-vider- und einem Consumer-Proxy, zugrunde gelegt werden. Der Provi-der-Proxy wird generiert aus einem eingehenden Service-Interface. Zudem eingehenden Service-Interface kann ein korrespondierendes ausge-hendes Interface angelegt werden, aus dem der Consumer-Proxy gene-riert wird.

6.2.1 ABAP-Provider-Proxy

TransaktionSPROXY

Für die Generierung der Proxys wird mit der Transaktion SPROXY derEnterprise Services Browser gestartet.

1. Expandieren Sie die Knoten der zugehörigen Softwarekomponenten-version (SWCV) und des Namensraums, und wählen Sie dann das rele-vante Service-Interface aus.

2. Per Doppelklick oder über das Kontextmenü können Sie nun die be-nötigten Proxy-Objekte erzeugen, das System erfragt zusätzlich not-wendige Daten wie ABAP-Paket und Transportauftrag, denen dieProxy-Objekte hinzugefügt werden sollen.

3. Als Resultat erhalten Sie ein ABAP-Interface und eine ABAP-Klasse,die auch Proxy-Klasse oder implementierende Klasse genannt wird und


197

Generierung von Proxys im Backend-System 6.2

das ABAP-Interface verwendet. Außerdem werden ABAP Data Dic-tionary-Objekte als Proxys für die vom Service-Interface verwende-ten Daten- und Message-Typ-Definitionen erzeugt (sofern nichtbereits vorhanden).

ABAP-InterfaceDie ABAP-Klasse eines Service-Providers enthält die Implementierungder Service-Operationen. Sie verwendet dazu ein ABAP-Interface, das fürjede im Enterprise Services Repository modellierte Operation eine Me-thode enthält. Aus Kompatibilitätsgründen mit dem XI 3.0-Protokoll be-stehen derzeit die Service-Interfaces der SAP Business Suite aus nur je-weils einer Operation. Diese Methoden werden anschließend vonAnwendungsentwicklern implementiert.

Ein Provider-Proxy basiert auf einem eingehenden Service-Interface undmuss in der ABAP-Backend-Komponente generiert werden, von der derService bereitgestellt wird. Es kann dabei ein Präfix angegeben werden,das bei den Vorschlägen für die Benennung der ABAP-Objekte berück-sichtigt wird.

BeispielFür das synchrone eingehende Service-Interface PurchaseOrderCreate-RequestConfirmation_In aus dem zur SWCV ESA-ECC-SE 604 gehören-den Namensraum http://sap.com/xi/APPL/SE/Global wurden die fol-genden Objekte generiert. Als Präfix wurde PUR eingetragen, und dieNamen wurden abgekürzt:

� das Interface II_PUR_PURCHASEORDERCRTRC mit der zu implementieren-den Methode EXECUTE_SYNCHRONOUS

� die implementierende Provider-Klasse CL_PUR_PURCHASEORDERCRTRC

� die Service-Definition ECC_PURCHASEORDERCRTRC

Generieren Sie selbst Proxys, können Sie deren Default-Namen über-schreiben. Falls das Service-Interface aus mehreren Operationen besteht,enthält das generierte ABAP-Interface natürlich für jede Operation eineentsprechende Methode, deren Name mit dem Namen der Operationübereinstimmt.

Die Service-Definition kann dazu verwendet werden, eine Laufzeitkonfi-guration anzulegen. Auf das Thema Laufzeit und Konfiguration werdenwir näher in Abschnitt 6.3, »ABAP-Proxy-Laufzeit und Konfiguration«,eingehen.

6.2.2 ABAP-Consumer-Proxy

Ein ABAP-Consumer-Proxy wird in einer Anwendung benutzt, um einenWebservice aufzurufen, das heißt zu konsumieren. Er enthält ABAP-Ob-


198


jektklassen und basiert im Allgemeinen auf einem ausgehenden Service-Interface. Um einen Service, der durch ein eingehendes Service-Interfacebeschrieben ist, zu konsumieren, legen Sie zunächst – sofern nicht be-reits vorhanden – ein passendes ausgehendes Interface im Enterprise Ser-vices Repository an. Alternativ besteht die Möglichkeit, das ausgehendeService-Interface aus einem WSDL-Dokument des eingehenden Servicezu erzeugen.

Im Unterschied zu Provider-Proxys, für die im ABAP-Backend-System je-weils eine Klasse implementiert werden muss, können Consumer-Proxysdirekt von einer Anwendung benutzt werden. ABAP-Consumer-Proxyskönnen in jedem ABAP-System erzeugt werden, da nur die WSDL-Be-schreibung erforderlich ist.

Abbildung 6.12 ABAP-Proxy-Generierung

Falls im Enterprise Services Repository ein entsprechendes ausgehendesService-Interface verfügbar ist, erfolgt die Generierung des Consumer-Pro-xys analog zur Generierung des Provider-Proxys über den Enterprise Ser-vices Browser, der über die Transaktion SPROXY aufgerufen werden kann.Falls nur ein (externes) WSDL-Dokument verfügbar ist, erfolgt die Gene-rierung des Consumer-Proxys über den Repository Browser, der überTransaktion SE80 ausgewählt werden kann.

Enterprise Services Repository

Outbound-Service-Interface

Inbound-Service-Interface

ABAP-Anwendung

Consumer-Proxy

SAP NetWeaver Application Server ABAP

ABAP-Anwendung

Provider-Proxy

SAP NetWeaver Application Server ABAP

ABAP-Proxy-Generierung

ABAP-Proxy-Generierung

Web

serv

ice

Lauf

zeit

Web

serv

ice-

Lauf

zeit

Web

serv

ice-

Lauf

zeit


199

ABAP-Proxy-Laufzeit und Konfiguration 6.3

Logischer PortZur Konfiguration des (ausgehenden) Consumer-Proxys wird auch ein lo-gischer Port benötigt. Dabei handelt es sich um ein SAP-spezifisches Kon-zept zur Konfiguration der Laufzeiteigenschaften eines Consumer-Pro-xys. Zum Beispiel enthält der logische Port die URL-Adresse, unter derder Service aufgerufen werden soll. Darauf wird im folgenden Abschnitt6.3 näher eingegangen.

In Abbildung 6.12 ist der Zusammenhang von Consumer-Proxy, Provi-der-Proxy und den zugehörigen Service-Interfaces dargestellt.

6.3 ABAP-Proxy-Laufzeit und Konfiguration

Process IntegrationDieser Abschnitt beschäftigt sich mit der ABAP-Proxy-Laufzeit und derenKonfiguration. Diese Konzepte beschreiben, wie Webservices zur Lauf-zeit verarbeitet werden.

Der Einfachheit halber bleibt die Darstellung hier auf synchrone Webser-vices beschränkt; der SAP NetWeaver Application Server ABAP (ASABAP) unterstützt auch asynchrone Services. Hier ist allerdings eine In-frastruktur erforderlich, die es ermöglicht, die Nachrichten verlässlichzuzustellen, was derzeit hauptsächlich über die Infrastruktur von SAPNetWeaver Process Integration (PI) erfolgt.

Internet Communication Framework

Die Kommunikation mittels Webservices basiert auf SOAP. Derzeit wirdSOAP nur über HTTP(S) unterstützt. Die Verarbeitung von SOAP-Re-quests erfolgt über das Internet Communication Framework (ICF). DerAS ABAP verwendet dazu HTTP im Internet Communication Frameworkfür die Kommunikation zwischen Consumer und Provider.

Der SAP NetWeaver Application Server ABAP kann sowohl als Providerfür Webservices als auch als Consumer von Webservices verwendet wer-den. Die ABAP-Proxy-Laufzeit unterstützt Webservices sowohl mit Betei-ligung eines Integration Servers als auch Punkt-zu-Punkt-Verbindungenmittels SOAP. In beiden Fällen wird ein Consumer-Proxy benötigt, um dieNachricht an den Empfänger zu senden bzw. ein Provider-Proxy, der diegewünschte Funktionalität implementiert.

Per Konfiguration eines ABAP-Consumers können Sie entscheiden, ob essich um eine SOAP-basierte Punkt-zu-Punkt-Verbindung handeln soll,oder ob die Nachricht über das XI-Protokoll versendet werden soll. Diesebeiden Möglichkeiten sind in Abbildung 6.13 dargestellt.


200


Abbildung 6.13 Kommunikation über den Integration Server mit XI-Protokoll bzw. Punkt-zu-Punkt-Kommunikation über SOAP

Dabei gelten die folgenden Regeln:

Quality of Service � Bei der Kommunikation über einen Integration Server kann die Kom-munikation synchron oder asynchron erfolgen. Der Quality of Service(QoS) ist im synchronen Fall Best Effort, im asynchronen Fall ExactlyOnce bzw. Exactly Once In Order.

� Bei der Punkt-zu-Punkt-Kommunikation über SOAP erfolgt die Kom-munikation derzeit synchron, in Zukunft soll auch eine asynchroneKommunikation über WS-RM möglich sein, die als Quality of ServiceExactly Once In Order unterstützt.

6.3.1 Übersicht über die Nachrichtenverarbeitung zur Laufzeit

Am Beispiel eines synchronen Webservice werden wir im Folgenden er-läutern, was während des Aufrufs eines Webservice geschieht. Es wirddavon ausgegangen, dass der Service über HTTP aufgerufen wird.

Integration Server

Integration Engine

Proxy

Proxy Runtime

LocalIntegration Engine

Web Services Framework

SAP Web/NetWeaver AS >= 6.40

Proxy

Proxy Runtime

LocalIntegration Engine

Web Services Framework

SAP Web/NetWeaver AS >= 6.40

XI-Protokoll

XI-Protokoll

SOAP


201


Internet Communication Manager

HTTP, HTTPS und SMTP

Der Internet Communication Manager ermöglicht die Kommunikationzwischen dem SAP NetWeaver Application Server und der Außenweltüber die Protokolle HTTP, HTTPS und SMTP. Der ICM behandelt HTTP-Requests und -Responses und stellt Dienste für die weitere Verarbeitungbereit, die im Folgenden ausschnittweise vorgestellt werden:

� Um einen Überblick über die Auslastung des ICM zu erhalten, könnenZugriffe aus dem bzw. in das Internet oder Intranet protokolliert wer-den. Die Log-Datei kann in eine Datei exportiert und mit externenAuswertungsprogrammen analysiert werden.

� Eingehende HTTP-Requests können abgeändert werden, bevor sie denApplikationsserver erreichen. Dazu gehören die folgenden Operatio-nen:

� Hinzufügen, Entfernen und Ändern von HTTP-Header-Feldern

� Filtern von Requests

� Umleitung von Requests auf eine andere Seite (Redirect)

� Umschreiben von URLs (Rewriting)

� Der ICM-Server-Cache speichert Objekte, bevor sie zum Client ge-schickt werden. Wird das Objekt später wieder durch einen Requestangefordert, kann der Inhalt direkt aus dem Server-Cache gelesen wer-den, falls die Verfallszeit noch nicht abgelaufen ist. Dies führt zu einererheblichen Performancesteigerung bei der Verarbeitung von HTTP-Requests.

� Die Administration des Internet Communication Managers erfolgtüber Profilparameter, den ICM Monitor (Transaktion SMICM) oderdie Webadministrationsoberfläche.

Für die weitere Verarbeitung wird der HTTP-Request an das InternetCommunication Framework (ICF) weitergeleitet.


IF_HTTP_EXTENSION

Das Internet Communication Framework (ICF) bildet die Schicht zwi-schen dem Internet Communication Manager, der die HTTP-Requestsversendet oder entgegennimmt, und der Verarbeitung im Workprozessdes SAP NetWeaver Application Servers. Der ICF besitzt Server- und Cli-ent-Funktionalität. Eingehende Aufrufe im SAP-System werden an HTTP-Request-Handler weitergeleitet. Ein HTTP-Request-Handler ist eineABAP Objects-Klasse, die das Interface IF_HTTP_EXTENSION implemen-


202


tiert. Zur Laufzeit wird der HTTP-Request-Handler anhand der Request-URL ermittelt.

Transaktion SICF Damit der HTTP-Request-Handler bei der Eingabe einer bestimmten URLim Browser aufgerufen wird, muss der Handler in einen ICF-Service ein-gebunden sein. Zum Anlegen und Konfigurieren der ICF-Services dientdie Transaktion SICF. Die ICF-Services sind hierarchisch angeordnet, ausdem Pfad zu einem ICF-Service in dieser Hierarchie ergibt sich der URL-Pfad für seinen Aufruf.

Für Webservices liefert SAP den ICF-Service sap/bc/srt/xip/sap aus, diein einem ABAP-System verfügbaren Webservices sind unter diesem Kno-ten zu finden und erben auch den zugehörigen Request-Handler.

Verarbeitung im Web Service Enabling Layer

Im Web Service Enabling Layer wird überprüft, ob die Nachricht das XI-Protokoll oder SOAP verwendet. Dementsprechend wird die Nachrichtan die Webservice-Laufzeit oder die lokale XI-Laufzeit übergeben. Dieweitere Verarbeitung erfolgt im ABAP-Proxy-Framework.

Verarbeitung im Application Service Enabling Layer

Im weiteren Verlauf der Nachrichtenverarbeitung wird die Proxy-Imple-mentierung aufgerufen. In Abschnitt 6.4, »Implementierung von In-bound-Service-Interfaces«, wird besprochen, welche Schritte hier aufge-rufen werden.

Die Service-Implementierung ruft dann die Geschäftslogik auf. DieserAufruf kann über eine Methode einer ABAP Objects-Klasse, eines BAPIoder einer API erfolgen, die die Applikation für diesen Zweck zur Verfü-gung gestellt hat. Abbildung 6.14 zeigt ein Übersichtsbild, in dem dieVerarbeitung der Nachrichten zur Laufzeit dargestellt ist.

Beispiel

Der AS ABAP läuft auf dem Rechner saphost auf Port 8080. Der ICF-Ser-vice ping wurde im Knoten sap/bc angelegt, und dem ICF-Service wurdeder Handler CL_HTTP_MYPING zugeordnet. Bei Eingabe der URL http://saphost:8080/sap/bc/ping wird dann die Methode handle_request() auf-gerufen, die im Handler implementiert wurde.


203


Abbildung 6.14 Verarbeitung der Nachrichten zur Laufzeit

6.3.2 Konfiguration von Provider-Proxys

Service-EndpunktEine Service-Definition allein ist noch keine aufrufbare Einheit. Umeinen Webservice konsumieren zu können, muss zunächst eine Laufzeit-repräsentierung der Service-Definition angelegt werden, die Service-

Webservice Runtime

Lokale XI- Runtime

ABAP-Proxy-Framework

Proxy-Implementierung

Methode API BAPI

Service-Implementierung


Internet Communication Manager

Consumer-Applikation

Application Service Enabling Layer

Application Layer

Webservice Enabling Layer

HTTP Communication Layer

RSOAP(über HTTP)


204


Endpunkt genannt wird. Der Service-Endpunkt enthält die Konfigurati-onseinstellungen zur Webservice-Definition und befindet sich auf demProvider-System an einer bestimmten Stelle, der sogenannten Service-Endpunkt-URL. Diese URL wird von der konsumierenden Anwendungbenutzt, um den konfigurierten Webservice aufzurufen.

SOAMANAGER Zum Anlegen von Service-Endpunkten wird das SOA-Management-Toolverwendet, das über Transaktion SOAMANAGER aufgerufen werdenkann. Die Service-Endpunkte erlauben folgende Konfigurationseinstel-lungen:

� Provider-SicherheitEs können Einstellungen zur Transportgarantie (zum Beispiel ohneTransportgarantie, HTTPS, Signatur und Verschlüsselung etc.) und zurAuthentifizierungsmethode (zum Beispiel keine Authentifizierung,HTTP-Authentifizierung über Benutzer-ID/Kennwort, X.509-SSL-Client-Zertifikat, Anmeldeticket oder Message-Authentifizierung über SAML1.1) vorgenommen werden.

� Webservice-AdressierungDas Protokoll für die Webservice-Adressierung kann ausgewählt wer-den.

� NachrichtenaustauschDas Protokoll für zuverlässigen Nachrichtenaustausch sowie die Dauerdes Bestätigungsintervalls (in Sekunden) können hinterlegt werden. DasBestätigungsintervall ist die Zeit, innerhalb der der Provider dem Con-sumer den Empfang einer Nachricht quittieren muss.

� TransporteinstellungenZusätzlich kann zur berechneten Zugriffs-URL eine alternative Zu-griffs-URL angegeben werden. Falls der Service nicht lokal verfügbarist (zum Beispiel hinter einer Firewall), muss der alternative Pfad an-gegeben werden.

� NachrichtenanhängeEs kann angegeben werden, ob Nachrichtenanhänge verarbeitet wer-den sollen. In diesem Fall können mehrere Dateien mit einer Nach-richt versendet werden.

� OperationsspezifischEs kann eine SOAP Action für eine Operation spezifiziert werden. DieSOAP Action wird als URI hinterlegt und als HTTP-Header übertragen,wenn der Webservice-Aufruf via HTTP erfolgt.

Abbildung 6.15 zeigt den Screen für die Eingabe der Konfigurationsein-stellungen.


205


Abbildung 6.15 Screen für die Eingabe der Konfigurationseinstellungen eines Service-Endpunktes

Sie können einer Webservice-Definition mehrere Service-Endpunkte zu-ordnen, die sich in ihren Konfigurationseinstellungen unterscheiden.Damit ist es möglich, dieselbe Webservice-Definition mit verschiedenenKonfigurationseinstellungen zu exponieren und Consumern zur Verfü-gung zu stellen.

Gruppen von Service-Endpunkten

Sogenannte Services definieren Gruppen von Service-Endpunkten. EineService-Definition kann mehrere Services haben, die ihrerseits aus ver-schiedenen Service-Endpunkten bestehen können. Dieser Zusammen-hang ist in Abbildung 6.16 dargestellt.

WSDL-DokumentFür jeden Service-Endpunkt ist es möglich, ein WSDL-Dokument zu ge-nerieren. Dieses WSDL-Dokument enthält bereits die Binding-Informa-tion, im Unterschied zur sogenannten Port-Type-WSDL, die noch keineKonfigurationsinformation enthält.


206


Abbildung 6.16 Services und zugehörige Service-Endpunkte

6.3.3 Konfiguration von Consumer-Proxys

Logische Ports Die Konfiguration von Consumer-Proxys erfolgt mittels sogenannter lo-gischer Ports. Daher wird ein logischer Port auf Grundlage der Anforde-rungen des Providers angelegt. Ein logischer Port verweist auf einen Ser-vice-Endpunkt, der unter einer eindeutigen Lokation im Provider-Systemverfügbar ist. Ein logischer Port enthält zusätzlich für den Zugriff auf denService-Endpunkt eine Laufzeitkonfiguration. Darüber hinaus enthältder Port die Anmeldedaten, die für den Aufruf der Service-Methoden be-nötigt werden.

Pro Consumer-Proxy können mehrere logische Ports angelegt werden.Jeder logische Port kann jedoch nur auf einen Endpunkt zeigen. Die Ad-ministration und Konfiguration von Consumer-Proxys erfolgen über dasSOA Management (Transaktion SOAMANAGER).

Der Zusammenhang zwischen logischen Ports und Service-Endpunktenist in Abbildung 6.17 dargestellt. Die Verbindung wird hergestellt,indem ein Service Consumer einen Aufruf über einen logischen Port sen-det. Ein logischer Port kann einen Aufruf nur an einen Service-Endpunktsenden. Ein Service-Endpunkt kann jedoch über mehrere logische Portsaufgerufen werden.

Folgende Optionen sind bei der Pflege der logischen Ports verfügbar:

� Consumer-SicherheitEinstellungen zur Transportsicherheit und Authentisierung könnenvorgenommen werden.

� Webservice-AdressierungDas Protokoll für die Webservice-Adressierung kann spezifiziert werden.

� NachrichtenaustauschDas Protokoll für den sicheren Datenaustausch sowie das Zeitintervallfür die Rückmeldung können angegeben werden. Die Lebenszeit einer

Service-

Definition

Service 1

Service-Endpunkt 1

Service-Endpunkt 2

Service 2 Service-

Endpunkt 3


207


Sequenz ist die Zeitspanne in Sekunden, für die die Sequenz aktivbleibt. 0 bedeutet unendlich. Der Inaktivitäts-Timeout ist die maxi-male Zeitspanne, für die die Sequenz offen gehalten wird, ohne dasseine Rückmeldung erfolgt.

Abbildung 6.17 Zusammenhang zwischen logischem Port und Service-Endpunkten

� TransporteinstellungenEinstellungen für den Nachrichtenaustausch können vorgenommenwerden. Lokalen Aufruf durchführen sollte markiert werden, fallssich Consumer und Provider auf demselben ABAP-System befinden.Dies führt beim Service-Aufruf dazu, dass keine erneute Anmeldungerforderlich ist. Maximale Wartezeit WS Consumer definiert denHTTP-Timeout, das heißt wie lange der Consumer auf die Antwort-nachricht wartet.

� NachrichtenanhängeEs kann spezifiziert werden, ob Nachrichtenanhänge erlaubt sind odernicht.

� OperationsspezifischEine SOAP Action kann für eine Operation spezifiziert werden. DieSOAP Action wird als URI hinterlegt und als HTTP-Header erzeugt,wenn der Webservice-Aufruf via HTTP erfolgt.

Konfigurationsszenarien

Massen-konfiguration

Konfigurationsszenarien können im SOA Management unter Business-

Administration durch Auswahl des Eintrags Massenkonfiguration

Logischer Port LP_123Logischer Port

LP_123Logischer Port LP_123

Consumer-Proxy

Webservice-Client

Consumer-System

Provider-Proxy

Webservice

Provider-System

Logischer Port LP_123Logischer Port

LP_123Service-Endpunkt SE_ABC


208


ausgesucht werden. In einem Konfigurationsszenario können mehrereWebservice-Definitionen gruppiert und Profilen zugeordnet werden.Abbildung 6.18 zeigt den Einstieg in die Pflege einer Massenkonfigura-tion im SOA-Management.

Abbildung 6.18 Massenkonfiguration von Services im SOA Management

6.3.4 Konfiguration der Nachrichtenverarbeitung über den Integration Server

Soll die Nachrichtenverarbeitung nicht von Punkt zu Punkt, sondernüber einen Integration Broker erfolgen, sind noch Einstellungen im Inte-gration Directory vorzunehmen. Hier soll nur ein Überblick gegebenwerden, für weitere Informationen verweisen wir auf die entsprechendeSAP-Dokumentation des Integration Directory.

Im Integration Directory können die folgenden Einstellungen vorgenom-men werden:

� Sender-VereinbarungWelcher Adapter wird für die Eingangsverarbeitung verwendet?

� EmpfängerermittlungWer ist Empfänger der Nachricht?

� SchnittstellenermittlungWelche Schnittstelle wird beim Empfänger verwendet?

Abbildung 6.19 gibt einen Überblick über den Ablauf der Nachrichten-verarbeitung auf dem Integration Server, die im Integration Directorykonfiguriert wird.


209


Abbildung 6.19 Konfiguration im Integration Directory

6.3.5 Serialisierung und Deserialisierung

Simple Transformations

Die Daten, die ein Eingangs-Proxy erhält bzw. ein Ausgangs-Proxy sendet,werden in zwei Schritten konvertiert. Im ersten Schritt erfolgt bei einge-henden Nachrichten eine technische Konvertierung der Daten der Nach-richt, deren Typbeschreibung in einer XML-Schema-Definition (XSD) vor-liegt, in die Datenstrukturen der ABAP-Laufzeitumgebung. Dies wirdauch Deserialisierung genannt. Dies geschieht automatisch über die vomABAP-Proxy-Framework erzeugten Simple Transformations (ST).

Eine Simple Transformation beschreibt dabei Transformationen vonABAP-Daten in XML (Serialisierung) und von XML in ABAP-Daten (Dese-rialisierung). Für den Aufruf einer Simple Transformation in einem ABAP-Programm steht der Sprachbefehl CALL TRANSFORMATION zur Verfügung, derneben Simple Transformations auch XSL-Transformationen unterstützt.

Kanonische Serialisierung

Bei einer Simple Transformation erfolgt implizit eine kanonische Serialisie-rung von ABAP-Daten bzw. eine kanonische Deserialisierung in ABAP-Da-ten, bevor die Transformation ausgeführt wird. Der SAP-XSLT-Prozessor istweitgehend konform mit der Spezifikation für die Version XSLT 1.0. DieseKonvertierungen sind in Abbildung 6.20 dargestellt.

Integration Server

Consumer-System

Provider-System

Outbound-Interface-Sender-Adapter

Inbound-Interface-Receiver-Adapter

Eingangs-verarbeitung Routing

Ausgangs-verarbeitung

Sender-vereinbarung

Empfänger-ermittlung

Schnittstellen-ermittlung

Empfänger-vereinbarung

Sender Empfänger

Integration Directory


210


Abbildung 6.20 Serialisierung und Deserialisierung

In vielen Fällen ist eine technische Konvertierung jedoch nicht ausrei-chend, um etwa eingehende Nachrichten so aufzubereiten, dass sie derApplikation, das heißt den intern vorhandenen Programmierschnittstel-len, übergeben werden können. Beispielsweise kann der Fall auftreten,dass externe ISO-Codes oder Maßeinheiten in das SAP-spezifische For-mat übertragen werden müssen.

Daher besteht die Möglichkeit, auch auf Ebene der Applikation eine Kon-vertierung auszuführen. Neben der Standardkonvertierung der Applika-tion werden in der Implementierung des Webservice auch sogenannteBusiness Add-ins (BAdIs) bereitgestellt, die eine weitergehende kunden-individuelle Konvertierung ermöglichen. Abbildung 6.21 veranschau-licht den zweistufigen Konvertierungsprozess.

Abbildung 6.21 Zweistufige Konvertierung

Typsysteme Allerdings sind die Typsysteme XSD und ABAP nicht vollständig kompa-tibel, sodass beim Mapping eines XSD-Datentyps auf den zugehörigenABAP-Datentyp (und umgekehrt) Verluste auftreten können. Daher ist eswichtig, diese Fälle zu dokumentieren und Regeln anzugeben, wie mitunterschiedlichen Wertebereichen verfahren werden soll. Eine geeigneteAusgangsbasis bilden die Core-Datentypen, da sie eine überschaubareMenge bilden und alle anderen Datentypen auf diesen basieren. Die Vor-gehensweise soll an einem Beispiel verdeutlicht werden.

Beispiel Der Core-Datentyp Amount ist im Enterprise Services Repository wie inTabelle 6.1 definiert.

ABAP XML

Serialisierung

Deserialisierung

GDTXSD-Datentyp

Proxy-DatentypABAP-Datentyp

BAPI-/API-DatentypABAP-DatentypProxy-Framework Proxy-Implementierung

Konvertierung Konvertierung

Element Attribut XSD

Amount xsd:decimal totalDigits="28"; fractionDigits="6"

currencyCode xsd:token minLength="3";maxLength="3" use="required"

Tabelle 6.1 Definition des Datentyps Amount im Enterprise Services Repository


211


Der zugehörige Proxy-Datentyp SAPPLSEF_AMOUNT im ABAP Dictionary istwie in Tabelle 6.2 definiert.

Für ein konsistentes Mapping zwischen dem XSD- und ABAP-Datentypstehen die statischen Methoden AMOUNT_INBOUND und AMOUNT_OUTBOUNDder Klasse CL_GDT_CONVERSION zur Verfügung. Neben einer typgemäßenPrüfung und Aufbereitung werden die Daten auch mit den Customizing-Einstellungen im SAP-Backend-System verprobt.

Die Klasse CL_GDT_CONVERSION enthält weitere Methoden, die für dieKonvertierung von anderen Core-Datentypen zur Verfügung stehen. DerGesamtablauf der Konvertierung ist in Abbildung 6.22 skizziert.

Abbildung 6.22 Gesamtablauf der Konvertierung

Nachdem Sie nun die technischen Grundlagen für Webservices kennen-gelernt haben, werden wir nun auf die Implementierung von Service-Providern eingehen.

Strukur Komponenten Komponententyp Datentyp

SAPPLSEF_AMOUNT CONTROLLER PRXCTRLTAB

CURRENCY_CODE SAPPLSEF_CURRENCY_CODE CHAR(3)

VALUE SAPPLSEF_AMOUNT_CONTENT1 DEC(28,6)

Tabelle 6.2 Definition des zugehörigen Proxy-Datentyps im ABAP Dictionary

AB

AP-

Prox

y-

Fram

ewor

kPr

oxy-

Impl

emen

tier

ung

Konvertiere XML nach ABAP

Ausführung der Default-Import- Konvertierung

Aufruf BAdI für Eingangs-

verarbeitung

Ausführung Geschäftslogik

Aufruf BAdI für Ausgangs-

verarbeitung

Konvertiere ABAP nach XML


413

Index

.NET-Framework 394

A

A2A 44Kommunikation 135PCIM 135Service 46, 127, 135

A2X 44Service 45, 135Serviceentwurf 81

ABAPConsumer-Proxy 197Paket 273Präfix 334Proxy-Laufzeit und Konfiguration 199UI-Feld 336Unit-Test 276Web Dynpro 333

ABAP List Viewer � ALVABAP-Proxy-Objekt

Generierung 274Namenskonvention 274Präfix 274

Abstraktion 87ActionCode 271, 320Adaptive RFC 2 Model 368Adaptive Web Service Model 368Aggregation 105

Beziehung rückwärts verfolgen 121aggregierter Datentyp 148Agilität 23AirlineCode 272AirportCode 272ALE 89ALV 332

objektorientierter 344Table Control 332

Amount 270Analyse

objektorientierte 33, 85Änderungsliste 133Anmeldedaten 404Annotation 257, 258

AnwendungFehlermeldung 342

Anwendungsintegration 24, 128Anwendungsprofil 74Apache Tomcat 379Application Link Enabling � ALEApplication Service Enabling Layer 202Application-to-Application � A2AApplication-to-Unknown � A2XArchitektur

serviceorientierte � SOAArchitekturmodell 129Assoziation 54, 105asynchrone Kommunikation 48Asynchrones Request/Confirmation-

Muster 186At Least Once 193At Most Once 193Atomizitätsforderung 282Attribut 159Auslieferungseinheit 142Ausnahme 233

technische 344Authentifizierungsstufe 258Authentisierungsmethode 340Automatisierung

von Standardprozessen 44

B

B2B 44Kommunikation 135PCIM 136Service 48, 127, 135

BAdIfür die Ausgangsverarbeitung 215für Eingangsverarbeitung 214

BAPI 40BasicBusinessDocumentMessageHeader

232, 271Basiert-auf-Beziehung 132Beispiel-Anwendungsfall 82Best Effort 192Beziehung 104

contains 93, 107


414

Index

Beziehung (Forts.)Typ 105

bidirektional 181blockierend 182Broker 186Bulk-Verarbeitung 241Bundle-Verarbeitung 241Business Application Programming Inter-

face � BAPIBusiness Document 119, 135

Aufbau 123Message Header 120, 123

Business Document Object 119, 135Ableitung 121

Business Function 238Business Function Set 238Business Network Transformation 24Business Object Map 88

Erstellen 91Business Object Map � SAP Entity MapBusiness Object Node 107Business Object Type 95Business Process Modeling Notation 129Business Process Object 66, 95Business Server Pages 333Business-Objekt 52, 82, 127, 155, 245,

253Anlegen 93Attribut pflegen 94Business Partner 87Eigenständigkeit 53Flight 85, 107, 111Flight Connection 107, 109Flight Customer 86, 107Flight Sales Order 86, 108, 112führendes 119Identifizierung 85integriertes Modell 102, 104integriertes Objektmodell 52Knoten 53, 104Knotenmodell 114Modell 127Modellierung 103

Business-to-Business � B2B

C

CALL TRANSFORMATION 209Cancel 66CCTS 39, 109, 149, 157CDATA 160CDT � Core-DatentypChange State Identifier � CSIChange-Operation 66Change-Service 218ChangeStateID 271Check Flight Availability 318CL_CENG_GEN_CODE_LIST_PROVIDER

316CL_FEH_REGISTRATION 237CL_GDT_CONVERSION 211, 214CL_PROXY_FAULT 235CL_SALV_TABLE 344CL_SOAP_COMMIT_ROLLBACK 216Client-Proxy

Generierung 333Code 147Codeliste 225Compensation-Operation 192Complete Transmission Indicator 320Component Controller 365, 367, 373Composite Application 23, 82, 244Composite Application Framework 354Connector 133Consumer

Sicherheit 206Consumer-Proxy

externer Name 339Generierung 333

contains 93, 107Context-Kategorie 239Context-Mapping 371CONTROLLER 224, 278, 324, 325Controller 367Coordinated Universal Time � UTCCore Component Technical Specification

� CCTSCore-Datentyp 39, 147, 150CRUD-Operation 64CSI 220

Berechnung 295Prüfung 293

Custom Controller 367CustomerID 270


415

Index

D

Data Link 371Data Modeler 371Date 270Datenbank

Cursor 307, 309Modellierung 105

Datenbanksperre 182Datenintegrität 31Datenkonsistenz 180Datentyp 144, 146

abgeleiteter 163Ableitungsregel 164aggregierter 148Amount Core 116Code 117Core 39, 115, 147, 150einfacher 164Facette 163frei modellierter 148globaler 38, 39, 150, 249, 269Identifier 117Indicator 117komplexer 166Kopie 271lexikalischer 163Maximallänge 273Measure 117Mindestlänge 273primitiver 162Quantity 117Spezifizierung 272Text 117Wertebereich 163

DateTimeWertedarstellung 300

DeklarationCreate Flight Sales Order 285

Deployment Descriptor 383Deployment Unit 58, 127, 129, 245, 253

Anlegen 92Flight Sales Order Processing 90Foundation Layer 90

Design by Contract 28Designobjekt 141, 195

Interface-Objekt 72Modellierung 72Prozessintegration 72

Designobjekt (Forts.)Prozesskomponente 73Spezifikation 72

Destination 377Destination Template 358

Management 358Dienst 26Dienstgüte 192Dienstleistungsverzeichnis 28Document Object Model � DOMDocument Style 171Document Type Definition � DTDdoGet 387DOM 174

Objekt 174Domänenfestwert 228doPost 387DTD 162Duration 270

E

Eclipse 379Einsetzbarkeit

Interface-Objekt 84EJB 250

Model 368Projekt 250, 251Session Bean 250zustandsbehaftete 257zustandslose 257

Element 159Empfänger 47, 135Empfängerermittlung 208Endpunkt 327, 328End-to-End-Geschäftsprozess 134Enhancement Package 243Enhancement Spot 232Enterprise JavaBean � EJBEnterprise Service 31, 34

ABAP 179Kategorie 127Metamodell 49Programmiermodell 212Schnitt 30, 35Signatur 36zustandsbehafteter 181zustandsloser 181

Enterprise Services Browser 195, 196


416

Index

Enterprise Services Builder 70, 72, 84, 141Starten 91

Enterprise Services Bundle 243Enterprise Services Registry 252Enterprise Services Repository 35, 69,

83, 90, 141, 189, 195, 252Content 141, 142Implementierung 267Installationsoption 71Namensraum 269, 270Ordner 84, 269

Enterprise Services Workplace 242Enterprise SOA 30Enterprise-Application-Projekt 250, 251Entity Relationship Modeling 105Entkopplung 180Enumeration 226Erweiterung 214

branchenspezifische 237Konzept 232

ESM ERP 76ESM INTEGRATION 76, 132ESR-Content 75EverybodyWins 218Exactly Once 193, 230Exactly Once In Order 193Executable GUI Language � XGLExport-Konvertierung 214Extensible Application Markup Language

� XAMLExtensible Markup Language � XMLExtensible Stylesheet Language for Trans-

formation � XSLT

F

Facette 148Fachkonzeptklasse 33, 53Fault-Message-Typ 56, 144, 152, 234FEH 214, 236Fehlerbehandlung 214, 233Fehlernachricht 235Finalize-Methode 216FirstOneWins 218FlightConnectionID 272FlightID 272FlightSalesCounterID 272FlightSeatClassCode 272

Formatierungvon Werten 40

Forward Error Handling � FEHfrei modellierter Datentyp 148

G

GDT � globaler DatentypGeneric Modeling Language � GMLGeschäftsanwendung 180Geschäftslogik 214Geschäftsobjekt 32Geschäftspartneranwendung 136Geschäftsprozess 82Geschäftsprozessplattform 23, 138Geschäftssprache 31globaler Datentyp 39, 150, 249, 269GML 363Governance Process 141

H

harmonisiertes Unternehmensmodell 32Hash-Algorithmus 295Hash-Wert 295Hilfsklasse

ZMPTP_CL_PROXY_IMPL_HELPER 287, 290

Hinterlegung 95, 136Homonym

Vermeidung 55HTTP 199

Request-Handler 201

I

ICF 199, 201ICM 201Idempotency Framework � IDPIdempotenz 231

Forderung 282Framework 277

Identifizierungänderungsrelevantes Feld 324

IDP 193, 277Implementierung

ABAP-System 267Cancel Flight Sales Order 292Check-Service 276


417

Index

Implementierung (Forts.)Confirm Flight Sales Order 292Create Flight Sales Order 282, 286Enterprise Services Repository 267Find Flight 311Find Flight Customer 304Read Flight Sales Order 297Update Flight Sales Order 323

implizite KanteErzeugen 93

Import-Konvertierung 214In Order 193Indikator 270Industrieklassifikation 153

Industry Classification Context 240Information-Muster 190Inside-Out 249Integration

Geschäftspartnersystem 24SAP- und Nicht-SAP-Anwendung 25

Integration Broker 187Integration Builder 70Integration Repository 57Integrationsobjekt 142Integrationsszenario 127, 129

Katalog 137Modell 128, 129Modell erstellen 131

integriertes Business-Objekt-Modell 103Integritätsbedingung

Prüfung 286Interaktionstyp 130Interface-Muster 64, 144

Action 64Manage 64, 66Notification 68Request/Confirmation 67

Interface-ObjektEinsetzbarkeit 84

Internet Communication Framework � ICF

Internet Communication Manager � ICM

Interoperabilität 157, 379semantische 29syntaktische 28technische 28

is placeholder for 134

J

Java 249Artefakt 255

Java Connector 40JavaBean 381

Model 368JavaServer Pages � JSPJAX-RPC 380JAX-WS 257, 380JSP 379

K

Kardinalität 105, 106Kategorie 144Klassifikation 253, 262

System 245, 253, 262Kohärenz 37Kommentar 160Kommunikation 130

asynchrone 48, 181bidirektionale 181mittels Enterprise Service 130Muster 184synchrone 48, 181unidirektionale 181zustandsbehaftete 260

Kommunikationskanalvorlage 72Kommunikationsmuster 59, 155

Information 62Notification 61Query/Response 61Request/Confirmation 60Request/Response 62

Komponente 26Zerlegung 27

Komposition 54, 105Konfiguration 199, 203

Szenario 207Konsistenz

Laufzeitverhalten 102von Service-Signaturen 102

KonvertierungFlightConnectionID 288

koordinierte Weltzeit 301Kopplung

lose 27


418

Index

korrektsemantisch korrekt 162

L

Label 373LastOneWins 218Laufzeit-Governance 32Lebenszyklusstatus 246, 253Listbox 337Liste

Behandlung 320Literal 163Log 123, 271

Element 289logisches Löschen 321Loose coupling � lose KopplungLöschen

logisches 321lose Kopplung 27LPCONFIG 339

M

Mapping 136Mapping-Programm 72Massendaten-Service 240Massenkonfiguration 207Master Data Object 66, 95maxOccurs 166Message Header 119, 123Message-Interface 58Message-Typ 56, 97, 143, 146

Definition 269Metadaten 180Methode

DO_CONVERT_REQUEST 287DO_CONVERT_RESPONSE 289DO_PERFORM_BUS_LOGIC 288DO_VALIDATE 286EXECUTE 282, 283

Metro 381minOccurs 166Model 367Model Binding 371Modell

Integrationsszenario 128modellbasierte Entwicklung 180

ModellierungEnterprise Service 23objektorientierte 105

Modellierungsname 63Modelltyp 73Model-View-Controller 381Muster 184

Information 184Notification 184Query/Response 184Request/Confirmation 184Tentative Update & Confirm/Compensa-

tion (TU&C/C) 191

N

Nachrichtenanhang 204Nachrichtenkategorie 59

Confirmation 61Information 62Notification 61Query 61Request 60Response 61

Nachrichtentransformation 136Nachrichtenzustellung

verlässliche 193Namenskonvention

Message-Typ 63Namensraum 144Namespace

Package Mapping 255Navigationsikone 77, 134, 138Navigationslink 366Nettodaten-Regel 320Next-Practice-Geschäftsprozess 127Node Data Type 114Notification

Interface-Muster 67Kommunikationsmuster 61

Notification-Muster 190NumberValue 270NWDI 365

O

Objektklasse 110objektorientierte Analyse 33, 85objektorientierte Modellierung 105


419

Index

Open Source 379Operation 145

ausgehende 183Change versus Update 66eingehende 183

operationsspezifisch 204Optimistic Locking 218Ordner

im Enterprise Services Repository 84Outside-In 249

P

P2PKommunikation 186

Paket 386Pattern � MusterPayload-Protokoll 223PCIM 129, 134Pflege-View

V_SCODE_REGISTRY 316PI � SAP NetWeaver Process IntegrationPIC 157Plattformunabhängigkeit 28Platzhalter 131, 133Plug 366Plug-in 379Point-to-Point � P2PPort

logischer 199, 206, 339Prepare-Methode 216Process Composer 355Process Integration Content Council

� PICProcessing Condition 124Property 110Proxy

Inbound 183Outbound 183

Prozessintegration 127Szenario 72, 129

Prozessintegrität 31Prozesskomponente 32, 50, 82, 127,

243, 245, 253Anlegen 93Architekturmodell 73Business Partner Data Processing 88,

100Drittanbieter 131

Prozesskomponente (Forts.)Flight Data Processing 88, 100Flight Sales Order Processing 89, 98Identifizierung 33Modell 95Modell erstellen 95Partner 130Schnitt 51Typ 130

Prozesskomponenten-Interaktionsmodel-len � PCIM

Prozesskomponentenmodell � SAP ProComp Model

Prozessorientierung 128PRXCTRL 224Publikation 247Publizierungsregel 262PurchaseOrderCreateRequest-

Confirmation_In 168

Q

Qualität 35Quality of Service 192, 200Quelle

Code 317Domänenfestwert 317IMG-Tabelle 318

QueryCodeList 226, 316Metadaten 316Provider-Klasse 316

QueryHitsMaximumNumberValue 303

R

Reliable Messaging 194Remote Function Call � RFCRepository-Namensraum 154Representation 110Representation Term 147, 225Request/Confirmation

Kommunikationsmuster 60Request/Confirmation-Muster

asynchrones 186synchrones 185, 215

RequestDispatcher 381RFC 40

Library 40rpc style 171


420

Index

S

SAML 1.1 204SAP Business Object Model 107SAP Business Object Node 114SAP Business Suite 23SAP Data Type Model 114SAP Entity Map 74, 92SAP ERP

Foundation 58Modul 34without HCM 58

SAP ERP HCM 58SAP Exchange Infrastructure � SAP Net-

Weaver Process IntegrationSAP Global Data Type 115

Aggregated 116Basic 116Modell 117

SAP GLOBAL MODEL 117SAP Integration Scenario Model 133SAP Integration Server 129SAP List Viewer � ALVSAP NetWeaver Administrator 261SAP NetWeaver Application Server

Java 249SAP NetWeaver Composition Environ-

ment 70, 354Developer Edition 355

SAP NetWeaver Developer Studio 249SAP NetWeaver Development Infrastruc-

ture � NWDISAP NetWeaver Portal 365SAP NetWeaver Process Integration 26,

57, 70, 129, 199Metamodell 57PI Integration Server 194SAP Exchange Infrastructure 129XI-Content 75

SAP NetWeaver Visual Composer 45, 354

SAP ProComp 96Interaction Model 136Model 74

SAP Scenario Catalog 137SAP SERM 105SAP Solution Map 243SAP-Anmeldeticket 340SAPGLOBAL 76, 79

SAPGLOBAL 2.0 143, 240, 270SAPGLOBAL MODEL 76SAPlink 268SAX 175Schachtelung

Proxy-Feld 324Schalter 238Schlüssel

zusammengesetzter 112Schnittstellenermittlung 208SEI 255semantisch korrekt 162semantische Interoperabilität 29Sender 47, 135Sender-Vereinbarung 208Sequenz 194Serialisierung

Deserialisierung 209Service

auf Einstiegsstufe 38auf Fortgeschrittenenstufe 37Cancel Flight Sales Order 96Check Flight Availability 100Confirm Flight Sales Order 97Create Flight Sales Order 96Endpunkt 204Find Flight 99Find Flight Customer 99idempotenter 231, 277, 283, 284, 350Implementierungsklasse 276Kategorie 44Kontrakt 35Lebenszyklus 32Massendaten-Service 240Operation 55QueryCodeList 337Read Flight Sales Order 96Schnittmuster 59Signatur 127synchroner 327Update Flight Sales Order 96

Service Consumer 27, 135Service Endpoint Interface � SEIService Provider 27, 135Service-Aufruf

Check Flight Availability 348Create Flight Sales Order 350Ergebnis 342Find Flight 341


421

Index

Service-Endpunkt-URL 204Service-Interface 57, 143, 144, 246

abstraktes 144Attribut pflegen 97ausgehendes 183Definition 269eingehendes 183Inbound 47, 144Modell 96Outbound 47, 144TU&C/C 145Unterschied 57zustandsbehaftetes 145zustandsloses 145zustandsloses (XI 3.0-kompatibel) 144

Service-Operation 82, 246Attribut 98Modell 96

serviceorientierte Architektur � SOAServices Registry 28, 70, 243Service-Schnittstelle � Service-InterfaceService-Signatur 101

Ableitung 119Servlet 379, 381SICF 202Simple API for XML � SAXSimple Transformations 209Sitzungsbehaftung 42Skalierung 182Skeleton 180, 387SLD 83, 132, 142SOA 26, 180

Architekturmuster 29by Design 33, 89by Evolution 33, 52, 58, 81, 89Enterprise SOA 30Governance 32Ziel 23

SOAMANAGER 204, 327, 396logischer Port 339

SOAP 158, 159, 173, 180, 199soap:body 172Softwarekatalog

Eintrag 132Softwarekomponente

SAP GLOBAL MODEL 117Softwarekomponentenversion 75, 142,

246, 253Eigenschaft 84

Softwarekomponentenversion (Forts.)Import 83

Spezialisierung 87Spezifikation

Create Flight Sales Order 279Find Flight 311Find Flight Customer 303Read Flight Sales Order 296Update Flight Sales Order 319

SPROXY 196, 274Service-Test 328

Stabilität 35Stammdaten 89

Verteilung 89Standardelement

ProcessingCondition 303StandardMessageFault 234Stornierung

Löschung 66Strategie

First one wins 281, 320Supplementary Component 116

Entfernung 273Switch Framework 237synchrone Kommunikation 48synchroner Service 327Synchrones Request/Confirmation-Mus-

ter 185Synonym

Vermeidung 55syntaktische Interoperabilität 28System Landscape Directory � SLD

T

targetNamespace 170technische Interoperabilität 28Template 175Test

synchroner Service 327Time 270transaktionales Verhalten 180Transporteinstellung 204, 207Transportgarantie 259Treffermenge

Begrenzung 303, 304, 307Blättern 303, 304, 307, 312


422

Index

TrennungSchnittstelle und Implementierung 28

Typsystem 210

U

UDDI 28, 158, 244UML

Aktivitätsdiagramm 137Klassendiagramm 105Sequenzdiagramm 137

UN/CEFACT 39Unicode 169unidirektional 181United Nations Center for Trade Facilita-

tion and Electronic Business � UN/CEFACT

Universal Description, Discovery and Integration � UDDI

UnlimitedQueryHitsIndicator 303Unternehmensmodell

harmonisiertes 32Update-Operation 67Update-Service 218UTC 301UTF-8 160, 169

V

Verallgemeinerung 87Verarbeitungsanweisung 160Verbuchung

lokale 213Verzeichnisdienst 159View 366Visual Studio 394

W

W3C 157Web Dynpro 45, 354, 365

Explorer 369Web-Dynpro-Component 365, 370Web-Dynpro-Development-Component

369Web-Dynpro-Flex 363Web-Dynpro-HTML 363

Web Service Creation Wizard 255Web Service Enabling Layer 202

Web Services Description Language � WSDL

Web Services Navigator 264, 327Web Services Reliable Messaging

� WS-RMweb.xml 385Webapplikation 383Webprojekt

dynamisches 382Webservice 27, 158

Adressierung 206Weltzeit

koordinierte 301Wertetabelle 228Wiederaufsetzungspunkt 307Wiederverwendbarkeit 180Wiederverwendung 24Window 365, 367Windows Presentation Foundation 394World Wide Web Consortium � W3CWS Navigator 230, 241WSADMIN 327WSCONFIG 327WSDL 28, 49, 158, 167

Dokument 205Import-Wizard 251

wsdl:binding 168wsdl:definitions 168wsdl:message 168wsdl:port 168wsdl:portType 168wsdl:service 168wsdl:types 168WS-RM 194, 260Wurzelelement 160Wurzelknoten 106

X

X.509SSL-Client-Zertifikat 204

XAML 395XGL 363XI � SAP NetWeaver Process IntegrationXI-Content 75XI-Protokoll 199, 231XML 158, 159

Nachricht 56Namensraum 142, 154


423

Index

XML Path Language � XPathXML-Dokument

gültiges 162wohlgeformtes 161

XML-Handlingerweitertes 223, 323, 324

xmlns 161XML-Parser 174XML-Schema-Definition � XSDXPath 177XSD 162, 209

Editor 146xsd:all 167xsd:choice 166xsd:extension 167xsd:list 165xsd:normalizedString 163

xsd:restriction 164xsd:sequence 166xsd:string 163xsd:token 164xsd:union 166xsl:stylesheet 175xsl:template 175xsl:transform 175XSLT 175

Prozessor 177

Z

Zertifikat 259zusammengesetzter Schlüssel 112Zustandslosigkeit 309


Date post:	30-Jul-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Entwicklung von Enterprise Services für SAP - Amazon S3 · 2018. 3. 26. · Die modell- und...

Documents