Anwendungsentwicklung mit ABAP Objects

LeseprobeLernen Sie die wesentlichen Techniken kennen, die Sie benötigen, um ein Integrationsprojekt mit Webservice-Technologien zu meis-tern!

Thorsten Franz, Tobias Trapp

Anwendungsentwicklung mit ABAP Objects695 Seiten, gebunden, 2. Auflage 2014 69,90 Euro, ISBN 978-3-8362-2635-6

www.sap-press.de/3472

Kapitel 9: »Entwicklung von Webservices«

Inhaltsverzeichnis

Index

Die Autoren

Leseprobe weiterempfehlen

Wissen aus erster Hand.

http://www.sap-press.de/3472?GPP=lpn

mailto:?body=Leseproben-Empfehlung: �Anwendungsentwicklung mit ABAP Objects� von SAP PRESS, http://gxmedia.galileo-press.de/leseproben/3472/leseprobe_sappress_anwendungsentwicklung_abap_objects.pdf&subject=Leseprobe: �Anwendungsentwicklung mit ABAP Objects�

515

9

»Inmitten der Schwierigkeit liegt die Möglichkeit«

(Albert Einstein)

9 Entwicklung von Webservices

Als das Gartner-Unternehmen den Begriff der serviceorientiertenArchitektur (SOA) prägte, dachten viele, dies würde die IT-Architek-turen grundlegend ändern: In Zukunft würden alle Systeme ihreFunktionen als Services exponieren, die sich flexibel wiederverwen-den und orchestrieren lassen und die Entwicklung von IT-Systemenund ganze Architekturen agiler machen. Es gibt Unternehmen, diedies erreicht haben, aber Studien haben ergeben, dass der Grad derWiederverwendung von Services mit einem Faktor von 1.6 sehrgering ist (siehe D. Krafzig et al., 2006). Hierfür gibt es viele Gründe.Zum Beispiel erschweren unterschiedliche Ordnungsbegriffe oderunterschiedliche Datenmodelle von Geschäftsprojekten innerhalbeiner IT-Architektur die Wiederverwendung von Services. Dennochexistieren auch Services mit hohem Wiederverwendungsgrad, diewertvolle Bestandteile in einer IT-Architektur sind.

Obwohl sich die hohen Erwartungen an serviceorientierte Architek-turen nicht immer erfüllt haben, sind Webservices heute wichtigeBestandteile von IT-Systemen. In sogenannten B2B-Szenarien nutzenwir sie zum Datenaustausch mit anderen Geschäftspartnern, undauch im Bereich der Anwendungsintegration spielen sie eine wich-tige Rolle: Externe Systeme können auf Daten und Funktionen desSAP-Backends zugreifen, und umgekehrt können wir von SAP-Syste-men auf Spezialanwendungen (wie z.B. Expertensysteme) zugreifen.

In diesem Kapitel lernen Sie die wesentlichen Techniken kennen, dieSie benötigen, um ein Integrationsprojekt mit Webservice-Technolo-gien zu meistern. Im Vordergrund steht die Entwicklung von soge-nannten Enterprise Services, also SOAP-Webservices, die nach einemModellierungsstandard der SAP erstellt wurden und besondere Qua-litätseigenschaften besitzen.

Entwicklung von Webservices9

516

Die Modellierung und Entwicklung von Enterprise Services wirdsehr gut durch Tools unterstützt. Die Herausforderung in Integrati-onsprojekten besteht unserer Erfahrung nach jedoch nicht in derBenutzung von Tools, sondern im Verstehen der zugrunde liegendenStandards sowie im Verstehen der Infrastruktur des AS ABAP, derAdministration sowie der komplexen Frameworks dieser Infrastruk-tur. Aus diesem Grund legt dieses Kapitel besonderen Wert auf dieZusammenhänge und gibt Tipps für den Praktiker. Dennoch wird dieVerwendung der wichtigsten Tools im Detail erklärt. Weitere The-men dieses Kapitels sind:

� Kriterien für die Auswahl der richtigen Technologie (siehe Ab-schnitt 9.1, »Überblick über die Konnektivitätstechnologien desAS ABAP«)

� Stärken von Webservices sowie die von SAP NetWeaver unterstütz-ten Standards (siehe Abschnitt 9.2, »Grundlagen zu Webservices«)

� Best Practices für Modellierung, Implementierung und Test

� typische Fehler bei SOA-Projekten und wie man sie vermeidet

9.1 Überblick über die Konnektivitäts-technologien des AS ABAP

Stärke von

Webservices

Die Stärke von Webservices liegt in der Verwendung offener Stan-dards, die die Integration von SAP- und Nicht-SAP-Systemen ermög-licht. Zwischen zwei AS-ABAP-Systemen sind RFCs immer noch sehrgebräuchlich. Ebenso lassen sich auch externe Systeme anbinden, fürdie es einen eigenen Connector gibt, wie z.B. den Java-Connector(JCo), den .NET-Connector für .NET sowie das RFC Software Develop-ment Kit (SDK) für C bzw. C++. Somit ist RFC auch im Bereich derAnwendungsintegration über das klassische RFC SDK bzw. das aktu-elle SAP NetWeaver RFC SDK möglich, setzt aber in der Regel einSicherheitskonzept voraus, da sich derzeit im Gegensatz zu Webser-vices die nach außen exponierten Funktionsbausteine nicht ein-schränken lassen, sodass ein Missbrauch möglich ist. Aber auch indiesem Bereich existieren derzeit Verbesserungen in Hinblick auf dieSicherheit, die wir im Folgenden vorstellen.

Überblick über die Konnektivitätstechnologien des AS ABAP 9.1

517

9.1.1 Weiterentwicklung der RFC-Technologie

Neben anderen Anbindungsmöglichkeiten baut SAP auch die RFC-Infrastruktur weiter aus:

� In früheren SAP-Releases war die Übermittlung von tabellenar-tigen Daten nur in TABLES-Parametern möglich. Dies hat sich ge-ändert, sodass es möglich ist, die Schnittstellen einfacher zu ge-stalten.

� Die Performance von RFCs wurde durch binäres XML (sogenann-tes basXML) verbessert. Dieses funktioniert bei tabellenartigenDaten noch nicht so schnell wie das binäre Format der TABLES-Parameter, aber auch hier sind Verbesserungen zu erwarten.

� Auch das klassische RFC-SDK wurde aktualisiert. Sie finden eineListe der Verbesserungen sowie weitere Informationen zum aktu-ellen SAP NetWeaver SDK im Service Market Place unter http://service.sap.com/connectors im Unterpunkt SAP NetWeaver RFC

Library.

� Die Security-Infrastruktur wurde in der Vergangenheit stetig ver-bessert. So wurde z.B. bei RFCs eine automatische Prüfung auf dasBerechtigungsobjekt S_RFC durch den Profilparameter auth/rfc_authority_check ermöglicht. Ebenso gibt es Neuerungen inRelease 7.40 von SAP NetWeaver, auf die wir im Folgenden nocheingehen werden.

Für und Wider

von RFC

Bei der Kommunikation zwischen AS-ABAP-Systemen ist die RFC-Technologie immer noch eine gute Wahl. Im Vergleich zu Webser-vices existieren aber auch einige Nachteile, insbesondere was die fle-xible Erweiterbarkeit angeht: Es ist möglich, einen Webservice kom-patibel durch optionale Felder zu erweitern, ohne dass Clientsangepasst werden müssen. Bei Erweiterungen von RFCs ist dies nichtso einfach möglich: Wird z.B. eine Komponente in einer Struktureines Übergabeparameters eingefügt und in der Länge verändert,dann werden die Daten falsch übertragen, es kommt aber nicht zueinem Laufzeitfehler wie beim Aufruf eines Funktionsbausteins. Dieeinzige Möglichkeit, zu verhindern, dass Clients angepasst werdenmüssen, sobald die Anpassung der Schnittstelle erfolgt und transpor-tiert ist, ist durch einen Mapping-Mechanismus einer Middlewaregegeben, wie z.B. der SAP NetWeaver Process Infrastructure.


518

Neuerung in SAP

NetWeaver 7.40

Ab Release 7.40 gibt es für dieses Problem noch eine andere Mög-lichkeit: Der SAP ABAP Connector ermöglicht es, sogenannte Consu-mer Mappings anzulegen, die es ermöglichen, dass RFCs über dieWebservice-Infrastruktur angesprochen werden, wobei als Providerein RFC aufgerufen wird. Auf diese Weise ist es möglich, RFC-Auf-rufe zwischen SAP-Systemen zu flexibilisieren, wenn sich im Provi-der-System die Schnittstelle ändert. Weitere Informationen findenSie im SAP Help Portal unter Connectivity � SAP ABAP Connector.

Verbesserungen im

Bereich Security

Eine weitere Neuerung in Release 7.40 wird im Bereich Unified

Connectivity beschrieben. Hier gibt es insbesondere ein neues Secu-rity-Verfahren für RFCs. In der Vergangenheit existierte die Schwä-che, dass alle RFCs eines Systems automatisch exponiert werden, waseinen Missbrauch ermöglichen kann. Bei Webservices hingegenkann man ganz gezielt durch die Transaktion bestimmen, welcheServices exponiert werden und welche nicht, was in Abschnitt 9.4.3,»Konfiguration des Webservice mit dem SOAMANAGER«, beschrie-ben wird. In Zukunft können Sie dieses Ein- und Ausschalten ebensobei RFCs durchführen.

9.1.2 OData für moderne Webanwendungen und leichtgewichtige Integrationsszenarien

Für die Entwicklung moderner Webanwendungen sind RFCs nichtgeeignet, da diese in der Regel mittels AJAX-artiger Techniken inJavaScript auf das Backend zugreifen. Hier haben sich leichtgewich-tige REST-basierte Schnittstellen wie OData etabliert. Für die genau-ere Beschreibung dieser Funktionalitäten sei auf SAP Help Portal aufSAP Gateway verwiesen, da diese den Rahmen dieses Buches spren-gen würden.

Derzeit setzen sich OData-basierende Services vor allem für die Ent-wicklung von User Interfaces mit SAP UI5 oder Fiori durch, währendWerbservices sich vor allem in B2B-Szenarien etabliert haben.

9.1.3 Stärken von Webservices

Für die Konnektivität von SAP- und Nicht-SAP-Systemen eignen sichSOAP-Webservices sehr gut, denn sie beruhen auf etablierten Stan-dards wie XML und SOAP, die von allen IT-Systemen verstandenwerden. Die nach außen zu exponierenden Funktionen lassen sichexplizit definieren, sodass die unbenutzten Webservices von der


519

Verwendung ausgeschlossen werden können, um Missbrauch vorzu-beugen. Der AS ABAP besitzt eine Infrastruktur, die diese Standardsunterstützt.

ABAP-ProxysABAP-Anwendungen kommunizieren in der Regel über generierteObjekte, sogenannten Proxys, mit externen Systemen. Für die Erstel-lung dieser Proxys existiert im AS ABAP eine Entwicklungsumge-bung in der ABAP Workbench bzw. der Transaktion SPROXY. DieseProxys kommunizieren mit der Webservice-Runtime des AS ABAP,sodass externe Nachrichten sowohl empfangen als auch gesendetwerden können.

Welche Gründe gibt es, in einem Integrationsprojekt Webservice-Technologien zu verwenden? Ein typisches Szenario ist die Integra-tion einer externen Spezialanwendung, deren Funktionen Sie überSOAP aufrufen. Ebenso müssen externe Systeme auf das SAP-Systemin B2B-oder A2A-Szenarien zugreifen. Hier können Sie die Enter-prise Services der SAP Business Suite verwenden, gegebenenfallserweitern und auch durch eigene Enterprise Services ergänzen, dieFunktionen mit Ihrer Kundenanwendung in einer SOA exponieren.Ebenso kann es sein, dass Sie in einem B2B-Szenario Daten (wie z.B.Rechnungen oder Bestellungen) aus einem externen System an denAS ABAP übermitteln wollen. Hier können Sie gegebenenfalls exis-tierende Enterprise Services nutzen oder in Ihrer Anwendung eigeneServices nach einem B2B-Standard, der auf SOAP aufbaut, modellie-ren und implementieren.

MetadatenEin weiterer Vorteil von Webservices ist die Beschreibung durchMetadaten. Die Modellierung einer Schnittstelle erfolgt durch diesogenannte WSDL, ein Dokument in der sogenannten Web ServicesDescription Language. Sie müssen aber keine solchen Dokumente miteinem externen Tool erstellen, sondern können Modellierungstoolsverwenden: Der AS ABAP besitzt mit dem Metadata Repository(MDR) ein Tool zum Modellieren von Webservices. Ein- und ausge-hende Nachrichten werden von der Webservice-Runtime automa-tisch strukturell validiert, und fehlerhafte Nachrichten werdenzurückgewiesen. Die Metadaten zum Webservice stehen als WSDLzur Verfügung. Durch Metadaten lässt sich z.B. definieren, welcheFelder eines Webservice optional und welche obligatorisch sind, wasbei RFCs nicht möglich ist. Weiterhin bieten Webservices einheit-liche und extern bekannte Datentypen und eine einheitliche Erwei-terungsmöglichkeit.


520

Idempotenz Die Webservice-Infrastruktur des AS ABAP bietet eine Reihe vonVorteilen: Durch das Idempotenz-Framework können Sie z.B. ver-hindern, dass ein zweimaliger Aufruf eines schreibenden EnterpriseService mit denselben Daten zu einer erneuten Verbuchung führt.

Unterstützung von

Single Sign-On

Die Webservice-Infrastruktur unterstützt aber auch Standards wiedie Version 2.0 der Security Assertion Markup Language (SAML), mitder sich Single Sign-On realisieren lässt, wie z.B. in der SAP-Biblio-thek unter Benutzerauthentifizierung und Single Sign-On � Ver-

wendung von SAML 2.0 beschrieben ist.

Lokale Integration

Engine

Ein AS ABAP besitzt neben der Webservice-Infrastruktur noch einelokale Integration Engine, die Sie im Zusammenspiel mit SAP ProcessIntegration (einer Middlewareplattform, die als Enterprise ServiceBus dient) aktivieren können. Weniger bekannt ist, dass Sie dieseFunktionen auch ohne diese Middlewareplattform aktivieren kön-nen, was jedoch Kenntnisse in der SAP Process Integration (kurz PI)voraussetzt und den Rahmen dieses Buches sprengen würde. Durchden Einsatz von PI lassen sich weitere Qualitätsstandards sicherstel-len, die im Folgenden beschrieben werden.

Zustellsicherheit,

Monitoring und

Fehlerhandling

Die Zustellsicherheit lässt sich erhöhen: Werden z.B. in einer LUWasynchrone Webservice-Aufrufe durchgeführt, werden diese beimCOMMIT WORK persistiert und können nicht mehr verloren gehen.Durch die Transaktion SXMB_MONI kann ein besseres Monitoringerreicht werden. Für das Fehlerhandling speziell asynchron schrei-bender Services, die Daten im AS ABAP verändern, existiert mit demFehler- und Konfliktbehandler (Error and Conflict Handler) ein Feh-lerbehebungsframework, das von einem automatischen Retry (z.B.nach Sperrkonflikten) bis hin zu einer komfortablen und revisions-sicheren Korrektur der Payload viele Möglichkeiten bereitstellt.

Zusammengefasst bieten Ihnen die Webservice-Infrastruktur sowiedie lokale Integration Engine einige Vorteile, die andere Konnektivi-tätstechniken nicht besitzen. Aus diesem Grund sind Enterprise Ser-vices nicht obsolet, sondern werden von SAP bei Prozessen empfoh-len, bei denen komplexe Daten mit hoher Zustellsicherheit mit Nicht-SAP-Systemen ausgetauscht werden sollen.

Neuerungen in der

SOAP-Runtime

Nicht nur die RFC-Runtime wurde weiterentwickelt, sondern auchdie SOAP-Runtime. Beispielsweise ist es möglich, auch im AS ABAPIntegrationsszenarien zu definieren, was im SAP Help Portal unterABAP-Web-Services � Mit Consumer-Mappings arbeiten beschrie-


521

ben wird. Auf diese Weise können Sie mit einem Consumer-Proxyeinen Webservice konsumieren, der zu einer neuen Version weiter-entwickelt wurde, ohne dass Sie den Aufruf anpassen müssen. Statt-dessen können Sie durch eine Konfigurationstätigkeit ein Mappingauf die neue Struktur durchführen.

9.1.4 Legacy-Technologien

RFC- und Webservice-Schnittstellen lösen langsam andere Technikenwie Dateischnittstellen ab, die in Zeiten von Anforderungen wieCloud-Fähigkeit obsolet werden. Dateischnittstellen besitzen ebensodas Problem, dass man Versionierungs- und Zeichensatzproblemeoft nur durch Nutzung sehr komplexer Standards wie XML lösenkann. Die Webservice-Infrastruktur verbirgt diese Komplexität weit-gehend vor Ihnen, sodass sich diese Probleme nicht stellen.

Vorteile von

Dateischnittstellen

Der Vollständigkeit halber sollen aber auch die Vorteile vonDateischnittstellen erwähnt werden: In einigen Fällen (wie z.B. ein-maligen Migrationen bei Implementierungen) ist eine Versionier-barkeit nicht gefordert, sondern es gibt stabile Schnittstellen, diein Tests und dann einmalig verwendet werden. Ebenso könnenImporte von Daten durch Dateischnittstellen leicht durchgeführtwerden: Man kopiert die zu verarbeitenden Dateien in die entspre-chenden Dateiverzeichnisse und startet Import- und Verarbeitungs-programme, was die Nachverarbeitung im Fehlerfall vereinfachenkann.

9.1.5 Rolle der SAP Process Integration

SAP Process Integration (PI) ist eine Integrationsplattform, die Sie alsMiddleware für die unternehmensinterne und unternehmensüber-greifende Anwendungsintegration nutzen können. Auf diese Weisekönnen Sie z.B. Integrationsprozesse erstellen oder Legacy-Techno-logien wie Dateischnittstellen auf Webservices oder RFCs mappen.

Weiterentwicklung

der Webservice-

Infrastuktur

In reinen ABAP-Integrationsszenarien wird die Unterstützung vonIntegrationsprozessen auch ohne SAP Process Integration immerbesser:

� Vor dem SAP-NetWeaver-Release 7.02 mussten Enterprise Ser-vices, seien es Service-Provider oder Service-Consumer, mit demEnterprise Service Repository entwickelt werden, das Teil von PI ist


522

bzw. mit SAP NetWeaver Composition Environment erstellt wer-den. Nun stehen auch ABAP-seitige Tools bereit, die Sie inAbschnitt 9.4.1, »Entwicklung von Enterprise Services mit demMetadata Repository«, kennenlernen werden.

� In SAP NetWeaver 7.40 gibt es weitere Verbesserungen: Sie kön-nen ABAP-seitige Integrationsszenarien zwischen ABAP-Systemenund sogenannten Kontrakten definieren, die es ermöglichen, dieseSzenarien besser zu konfigurieren und auch bei Schnittstellenän-derungen anzupassen. Diese Vorgehensweise ist im SAP Help Por-tal unter ABAP-Web-Services � Mit Integrationsszenarios arbei-

ten beschrieben.

Vorteile von PI Was für Vorteile bietet Ihnen die Nutzung von PI? Die bisher be-schriebenen Techniken eignen sich für die Integration von ABAP-Landschaften bzw. Systemen mit sogenannten Punkt-zu-Punkt-Ver-bindungen zwischen Systemen. In unternehmensweiten oder unter-nehmensübergreifenden SOA-Szenarien benötigt man oft eine Infra-struktur, die man auch für Nicht-SAP-Systeme einsetzen kann, sowieAdapter für mannigfaltige B2B-Standards und ALE-Szenarien. Im Ein-zelnen gibt es folgende Vorteile:

� Sie können eine Universal Description, Discovery and Integration(UDDI) verwenden, um Services zu publizieren und auffindbar zumachen – einschließlich der Services Ihrer Nicht-SAP-Systeme.

� Sie besitzen eine bessere Governance und Administration durchIntegrationsszenarien, da Sie nicht mehr Punkt-zu-Punkt-Verbin-dungen konfigurieren müssen. Stattdessen können Sie im Integra-tion Directory Szenarien konfigurieren. Solche Szenarien werdenebenso wie die von Ihnen genutzten Services im Enterprise Ser-vice Repository entwickelt. Sie können dies als zentrales Reposi-tory für Ihre Webservice-Entwicklung, also auch für Nicht-ABAP-Systeme, verwenden.

� Die Konfiguration im Integration Directory umfasst ebenso Map-ping, Routing und verschiedene Adapter. Sie sind in der Lage,Dateischnittstellen auf Webservice-Schnittstellen zu mappen oderIntegrationsprozesse zu bauen, um die Schnittstellenparametervon Services bzw. Serviceversionen anzugleichen.

� Ebenso besitzt diese Infrastruktur verbesserte Monitoring-Mög-lichkeiten.


523

Wenn Sie SAP Process Integration nicht verwenden, können Sie aus-schließlich Point-to-Point-Szenarien (P2P) konfigurieren. Wir wer-den im Folgenden genau auf die Unterschiede eingehen und erklä-ren, in welchen Fällen und wie Sie Teile der SAP-Process-Integration-Infrastruktur verwenden müssen und welche Konsequenzen dies fürdie ABAP-Implementierungen der Integrationsszenarien hat.

9.1.6 Zusammenfassung

Wahl der richtigen

Technologie

Im Rahmen der SAP-NetWeaver-Plattform aber ebenso der SAP Busi-ness Suite existieren eine Reihe von Add-Ons auf der SAP-NetWea-ver-Webservice-Runtime, mit denen sich Funktionen als Webser-vices exponieren lassen. Wenn die SAP-Standardsoftware nicht diebenötigten Webservices bereitstellt bzw. sich diese erweitern kön-nen, sollten Sie zuerst prüfen, ob die SAP-Anwendung, die Sie ver-wenden oder erweitern wollen, nicht bereits eine solche Funktionbereitstellt. An dieser Stelle sollen ein paar Beispiele vorgestelltwerden:

� BRFplus-Funktionen (siehe Abschnitt 5.5, »Geschäftsregeln mitBRFplus«) können als Webservices exponiert werden. Hierfürexistiert ein Werkzeug, mit dem Sie von der Designoberfläche(gegebenenfalls im Expertenmodus) direkt einen RFC-Funktions-baustein und darauf einen Webservice generieren können.

� Ebenso existieren im CRM-Umfeld einige Frameworks, wie dasBOL-Framework für Serviceaufrufe, das in der SAP-Bibliothek fürCRM 7.0 EhP 1 unter Web-Services � Web-Service-Consumption

beschrieben ist.

Wenn Sie ein Add-On zu SAP-Anwendungen schreiben, sollten Sieauch in erster Linie deren Webservice-Frameworks nutzen, um zuihnen kompatibel zu sein. Für Sie lohnt sich dennoch die Lektüredieses Kapitels, denn diese Frameworks setzen immer auf der Web-service-Runtime des AS ABAP auf, die an dieser Stelle beschriebenwird und deren Kenntnis Voraussetzung für jeden Einsatz von Web-services ist.

Performanz von

Webservices

Ein Einwand gegenüber Webservices ist die Befürchtung, dass diesenicht performant seien. Hierzu ist zu sagen, dass es sich hier um eta-blierte Industriestandards handelt, die jedoch sehr komplex sind und


524

durchaus einen Overhead (siehe SAP-Hinweis 1556890 – Compari-son RFC <-> WebService) besitzen. SAP hat die Performance in denletzten EHPs jedoch extrem verbessert, unter anderem durch dieNutzung von Binary XML innerhalb der SAP-NetWeaver-Plattformsowie durch die Nutzung von Simple Transformations zur Serialisie-rung und Deserialisierung der ausgetauschten XML-Nachrichten.

Erfahrungswerte In den meisten Fällen ist der Overhead zu vernachlässigen: Wennz.B. die RFC-Runtime 5 ms benötigt, benötigt die Webservice Run-time ca. 30 ms +/– 15 ms, je nach Typ des Webservice (synchron,asynchron, stateful oder stateless). Diese Laufzeit ist im Vergleich zurLaufzeit der Anwendungslogik, die in der Regel 300 bis 1000 ms inAnspruch nimmt, zu vernachlässigen. Die Größe der Payload-Mes-sage spielt dabei praktisch keine Rolle.

Enterprise SOA Zusammengefasst lässt sich sagen, dass SAP eine Reihe von Modellie-rungs- und Entwicklungsstandards – sogenannte Enterprise SOA-Standards – erstellt, die unter anderem für folgende Zwecke verwen-det werden können:

� standardisierte Kommunikationsmuster (bi- und unidirektional),synchrone und asynchrone Kommunikation

� die Standardisierung von Datentypen, Fehlernachrichten sowieallgemeine Namenskonventionen

� Implementierungsstandards für ändernde Operationen, z.B. Mas-senoperationen, aber auch Qualitätsstandards, wie z.B. Idempo-tenz, aber auch Fehlerbehandlungsstandards

� Erweiterungskonzepte für SAP Enterprise Services, aber auch fürselbst erstellte Enterprise Services

Sie lernen diese Aspekte im Folgenden kennen und ebenso diegrundlegenden Standards, die Sie für den Einsatz der Technologienverstehen sollten.

Unified Connectivity

Interessanterweise nähert SAP in den Releases 7.31 und besonders 7.40von SAP NetWeaver die Eigenschaften der unterschiedlichen Konnektivi-tätstechnologien aneinander an. Darüber hinaus entwickelt SAP einheitli-che Programmiermodelle unter dem Stichwort Unified Connectivity, aufdie wir jedoch nicht näher eingehen können.

Grundlagen zu Webservices 9.2

525

9.2 Grundlagen zu Webservices

Die zugrunde liegenden Standards für Webservices werden durchdas World-Wide-Web-Konsortium (W3C) definiert und erlauben es,Objektzustände bzw. Sichten auf Geschäftsobjekte als XML-Nach-richten auszutauschen. Alle weiteren in diesem Kapitel erwähntenStandards beruhen auf der XML-Syntax, die wir als bekannt voraus-setzen. Das gilt ebenso für das Konzept von XML-Namensräumen,mit denen sich unterschiedliche Vokabulare definieren lassen. Wirbenutzen im Folgenden z.B. das Präfix xsd für XML-Schema-Vokabu-lare und das Präfix wsdl für WSDL-Elemente. Einführungen in dieSyntax finden Sie in jedem Buch zum Thema XML.

In den kommenden Abschnitten werden die weiteren grundlegen-den Standards vorgestellt. Prinzipiell können Sie auch ohne tiefeKenntnis der Standards ein Szenario implementieren, jedoch benöti-gen Sie spätestens im Fehlerfall genauere Kenntnisse, um tiefer inSpezifikationen einsteigen zu können und die Fehlerursache zu ver-stehen und zu beheben.

9.2.1 Einführung in die grundlegenden Standards

Die WSDL spezifiziert einen Webservice in XML-Syntax und auchdie Datentypen der auszutauschenden Nachrichten in einem XML-Element wsdl:types, wofür der Standard XML Schema benutzt wird.Durch ein XML-Schema kann man u. a. den Inhalt und Aufbau voneinfachen oder komplexen Datentypen (denken Sie an geschachtelteStrukturen) definieren. Komplexe Datentypen bestehen aus einerReihe von sogenannten primitiven Datentypen, die wir auch in die-sem Kapitel in einer Beispielanwendung benutzen werden:

� Mit xsd:string können Zeichenketten übermittelt werden.

� Vom Datentyp xsd:string wird der Datentyp xsd:token abgelei-tet, bei dem Tabulatoren, Leerzeichen und Zeilenumbrüche sowiemehrfach hintereinander auftauchende Leerzeichen durch ein ein-zelnes Leerzeichen ersetzt werden.

� Außerdem verwenden wir die Datentypen xsd:unsignedIntegerfür positive ganze Zahlen und xsd:gYear für die Darstellung einesJahres.


526

Serialisierung und

Deserialisierung in

der SOAP-Runtime

Diese Datentypen werden im Austausch in sogenannten SOAP-Mes-sages verwendet. Wenn diese Nachrichten in der Webservice-Run-time des AS ABAP verarbeitet werden, werden sie durch SimpleTransformations, einer speziellen Transformationssprache des ASABAP, serialisiert bzw. deserialisiert, die von der Webservice-Design-time generiert werden. Diese sind wesentlich schneller als XSLT-Pro-gramme, die ebenso durch den AS ABAP unterstützt werden. Zudemwerden bei der Verarbeitung auch der Inhalt und die Reihenfolgeder übermittelten XML-Nachrichten geprüft, was ungefähr einerValidierung durch ein XML-Schema entspricht. Kommt es hier zuunzulässigen Konstellationen (weil man beispielsweise Buchstabenin Zahlenfeldern transportiert), dann kommt es zu einem Fehler inder SOAP-Runtime des AS ABAP, auf die wir in den folgendenAbschnitten eingehen werden.

Kein Ersatz der XML-Schema-Validierung

Die eben erwähnte Validierung ersetzt keine XML-Schema-Validierung,da sie nicht vollständig ist. Wir empfehlen deswegen speziell in B2B-Sze-narien, zumindest vor dem Go-Live oder vor Änderungen eine Validie-rung durch eine Middleware durchzuführen.

Der Austausch der XML-Nachrichten erfolgt durch den SOAP-Stan-dard, der in der aktuellen Version 1.2 vorliegt. Die SOAP-Daten wer-den in der Regel durch HTTP bzw. HTTPS ausgetauscht.

9.2.2 Unterstützte Standards und Interoperabilität

Eine Herausforderung bei SOA-Projekten besteht darin, die komple-xen Standards zu meistern. SOAP ist ein sehr komplexer Standardund litt seit der Entstehung an Interoperabilitätsproblemen, da ver-schiedene Features nicht von allen Implementierungen unterstütztwurden. Schlimmer noch: Teilweise wurden dieselben Konstrukteunterschiedlich interpretiert und implementiert, was für einen Stan-dard, der Interoperabilitätsprobleme löschen soll, nicht akzeptabelist. Aus diesem Grund gründeten große IT-Firmen eine Arbeits-gruppe namens Web Service Interoperability Organization (WS-I), diediese Probleme löst, indem u. a. die Menge der zur nutzenden Featu-res eingeschränkt wird. Als Folge unterstützt der AS ABAP nurWSDLs im document style, die WS-I-konform sind; WSDLs im rpcstyle werden konvertiert. Von den sogenannten encoding styles wirdnur literal akzeptiert.

Grundlagen zu Webservices 9.2

527

Einschränkungen

der SOAP-Runtime

des AS ABAP

Zusätzlich existiert eine Reihe von weiteren Einschränkungen, die inSAP-Hinweis 944029 (Von der ABAP-Proxy-Generierung unter-stützte XML Schema) beschrieben werden.

Wenn es aufgrund der Einschränkungen Probleme gibt, gibt es nurfolgende Lösungen:

� Einsatz eines Integrationsservers (SAP Process Integration), derteilweise mächtiger ist als die SOAP-Runtime des AS ABAP

� Sie können aber ebenso Java-Lösungen (z.B. im SAP CompositionEnvironment) entwickeln. Die Frameworks hierfür sind sehr weitentwickelt und unterstützen weitere Standards der AS ABAP, wiez.B. XML-Encryption.

� Wenn Sie Webservices aus Nicht-SAP-Systemen konsumieren,kann es schon beim Generieren der Client-Proxys (siehe Abschnitt9.5, »Konsumieren von Webservices«) zu Problemen kommen. Somuss die WSDL gegebenenfalls entweder durch denjenigen, derden Service exponiert, oder auch von Ihnen angepasst werden, umeine äquivalente WSDL zu erstellen. Dies wird im SAP-Hinweis856597 (FAQ: XI 3.0 / PI 7.0 / PI 7.1 SOAP Adapter) in einemAnhang wsdl_style_samples.zip mit Beispielen für WSDL-Doku-mente sowie SOAP-Nachrichten beschrieben, die zeigen, wie eineäquivalente WSDL mit einer anderen Formatvorlage geschriebenwerden kann.

� Für den Fall der Übermittlung von im ABAP nicht unterstütztenXML-Schema-Typen aus Nicht-SAP-WSDLs besteht weiterhin dieMöglichkeit, diesen Abschnitt durch xsd:any zu ersetzen. DieserAbschnitt läuft dann in einen String, der von der Providerseite mitSimple Transformations oder XSLT selbst weiter interpretiert wer-den muss. Das ist zwar aufwendig, durch diesen Workaroundkann aber fast jede Nachricht übertragen werden.

Zusammengefasst lässt sich sagen: Innerhalb der SAP-NetWeaver-Plattform sind Integrationsszenarien durch Webservices unproble-matisch. Wenn externe Systeme hinzukommen, sollten Sie im SAPHelp Portal prüfen, welche Standards in welcher Version (z.B. SOAP1.1 und SOAP 1.2, aber nicht SOAP 2.0) in welchem SAP-NetWea-ver-Release unterstützt werden. Ebenso sollten Sie die externen Sys-teme auf Einhaltung der gängigen Interoperabilitätsstandards über-prüfen.


528

9.2.3 SOAP-Runtime der ABAP-Plattform

Innerhalb der ABAP-Plattform gab es verschiedene Ansätze, SOAP-Webservices zu unterstützen. In diesem Buch beziehen wir uns aufdas SAP NetWeaver Release 7.02 SP 8, das in SAP-Hinweis 1575707(ABAP Webservice Connectivity – New Features in Release 7.02)genauer beschrieben wird. Diese Darstellung ist jedoch ebenso abSAP NetWeaver 7.31 gültig.

Releasevoraus-

setzungen

Die letzte große Änderung fand im SAP-NetWeaver-Release 7.0 SP 14statt und wird in SAP-Hinweis 1169688 (Neue Funktionen in Release7.0 Support Package 14) beschrieben. Wir empfehlen, mindestensauf dieses Release zu upgraden, wenn Sie ein Integrationsszenariomit SOAP-Webservices im AS ABAP realisieren wollen. Wenn Sieallerdings eine umfangreichere SOA-Entwicklung durchführen wol-len, empfehlen wir Ihnen, ein SAP-NetWeaver-Release von min-destens 7.02 SP8 zu verwenden, dessen Eigenschaften in http://wiki.sdn.sap.com/wiki/display/ABAPConn/ABAP+Connectivity++-+Web+Services+ABAP genauer beschrieben werden. Im SCN-Wiki findenSie weiterhin eine hervorragende Dokumentation zum Thema.

9.3 Modellierung von Webservices

Sie können Webservices im Bereich der Anwendungsintegration(A2A) und Kommunikation mit Geschäftspartnern (B2B) nutzen, unddie in diesem Kapitel vorgestellten Technologien können Sie in die-sem Zusammenhang verwenden. In beiden Fällen kann der AS ABAPals Service-Provider dienen, der Funktionen exponiert, die vonexternen Systemen aufgerufen werden. Ebenso können ABAP-An-wendungen als Client fungieren und mit externen Systemen kom-munizieren.

A2X-Services Eine andere Anwendung von SOA-Technologien besteht in der Defi-nition von Services – also Funktionen, die Sie im Rahmen IhrerUnternehmensarchitektur verwenden können –, die in maschinellenoder Dialogprozessen verwendet werden. Sie können Operationenauf Anwendungsobjekten als Services bereitstellen oder auch zent-rale Funktionen (denken Sie z.B. an die Geschäftspartneridentifika-tion oder auch an häufig benötigte Berechnungsfunktionen) als Ser-vices anbieten. Solche Services werden A2X-Services genannt – diesekönnen prinzipiell von jedem Consumer aufgerufen werden.

Modellierung von Webservices 9.3

529

SOA-Vorgehens-

modell der SAP

In einem SOA-Projekt empfehlen wir, sich bei der Modellierungeines Service an das Vorgehen von SAP anzulehnen, denn Sie errei-chen auf diese Weise Bezeichnungen und Kommunikationsmuster,die zu den Enterprise Services von SAP konsistent sind. Dies wirddurch eine Reihe von Namenskonventionen sowie Toolunterstüt-zung erreicht. SAP verfolgt einen sehr gründlichen Modellierungsan-satz, der wie folgt aussieht:

� Zuerst wird eine Fachdomäne identifiziert. Diese wird Prozesskom-ponente genannt. Die Prozesskomponente repräsentiert eine Mengevon zusammengehörenden Prozessen.

� Innerhalb einer Prozesskomponente existiert eine Reihe vonAnwendungsobjekten, die Business Objekte genannt werden.

� Für diese Geschäftsobjekte können Sie eine Reihe von ServiceInterfaces definieren, also Operationen für die Anwendungsob-jekte (wie z.B. das Erstellen oder Begleichen einer Rechnung, dieStornierung usw.). Diese Operationen sind standardisiert, waseine Modellierung vereinheitlicht und ebenso die spätere Arbeiterleichtert, da es einheitliche Namen sowie Semantiken gibt, die eserlauben, das Wissen über einen Service auf den anderen zu über-tragen. Es gibt das sogenannten Manage-Pattern, das die CRUD-Operationen realisiert. Mit dem Query-Pattern können Sie nachAnwendungsobjekten suchen und spezielle fachliche Operationenmit dem Action-Pattern durchführen.

SOA by Evolution

Wir empfehlen an dieser Stelle nicht, für ein SOA-Projekt den Ansatz vonSAP zu verfolgen, um die gesamten Prozesse Ihres Unternehmens in Pro-zessdomänen zu gliedern und alle Services zu modellieren. Stattdessensollten Sie die Services erstellen, wenn ein Integrationsszenario vorliegt,in dem sie verwendet werden, und nicht auf Vorrat ohne AnforderungServices entwickeln. Außerdem empfehlen wir Ihnen, aus den Problemender Enterprise Services zu lernen: Diese sind oft viel zu komplex, da SAPden Anspruch hatte, sämtliche Dialoge mit Ihnen abzubilden, was zu brei-ten Schnittstellen führte. Außerdem hatte SAP den Anspruch, sogenannteglobale Datentypen zu verwenden, was einerseits einen erheblichen Vor-teil durch Standardisierung darstellt, andererseits die Arbeit mit ihnensehr schwierig macht, wenn das Typsystem z.B. in Dialoganwendungenbenutzt werden soll, sich aber erheblich von den Datentypen unterschei-det, die der Anwender erwartet. Insofern plädieren wir für einen pragma-tischen Ansatz, der die Stärken der SAP-Methodologie nutzt, aber im


530

Zweifelsfall auch Zugeständnisse macht, wenn dadurch Integrationsszena-rien vereinfacht werden können.

Ein Beispiel für einen pragmatischen Ansatz soll hier gegeben werden: DieEnterprise Services von SAP sind oftmals gewaltig und enthalten bis zu90 % optionale Felder, die je nach Benutzungsvariante nur bedingt opti-onal sind. Unsere Empfehlung lautet deswegen, feingranulare Services fürjede Benutzungsvariante anzulegen, also z.B. Services für verschiedeneGeschäftspartner-Rollen statt eines Service für alle Rollen. Für das Kon-zept des Geschäftspartners und dessen Rollen sei auf Kapitel 7, »SAP-Geschäftspartner«, verwiesen.

9.3.1 Modellierung von Webservice-Signaturen

Die Modellierung von Enterprise Services ist wegen der umfangrei-chen Entwicklungsrichtlinien und Namenskonventionen ein auf-wendiger Prozess. An dieser Stelle wollen wir diese Richtlinien undKonventionen nicht umfassend erklären, sondern genau das Wissenvermitteln, das Sie für die Implementierung benötigen. Zuerst wer-den wir deswegen zeigen, wie die Signatur eines Enterprise Service,also seine Schnittstelle aufgebaut ist, was eine Grundvoraussetzungfür die Implementierung in ABAP ist, die wir mit dem MetadataRepository vornehmen.

Ein Enterprise Service beschreibt eine Operation auf einem Anwen-dungsobjekt. Diese kann fachlich motiviert sein, oder es kann sichum eine Basisoperation wie die CRUD-Operationen handeln: Create,Read, Update, Delete bzw. Cancel. Diese Methoden werden im Fol-genden erklärt.

Namen der Entwicklungsartefakte

SAP ES

Methodology

Wizard

Wir nutzen im Folgenden mit dem SAP ES Methodology Wizard einTool, mit dem sich die Artefakte einer typischen Service-Signatursamt standardisierten Namen generieren lassen (siehe Abbildung9.1). Dieses Tool generiert die Namen, die weitgehend denen desSAP-Dokuments PI Best Practices: Naming Conventions entspricht, dasim SAP Community Network (siehe Abschnitt 11.1.3, »SAP Commu-nity Network«) heruntergeladen werden kann. Der folgende Blog-Eintrag enthält den Download-Link und ebenso die Beschreibung,wie das Tool zu starten ist:


531

http://scn.sap.com/people/mischa.keil/blog/2009/06/18/sap-co-innova-tion-lab-architecture-series-partner-delivered-enterprise-services--levera-ging-a-wizard-to-automate-service-creation-part-5. Sie können diesesTool auch für die Erstellung weiterer Enterprise Services verwenden,und es erleichtert die Modellierung.

Wie Sie in Abbildung 9.1 sehen, müssen Sie zuerst das Anwendungs-objekt nennen, auf das sich die Operation bezieht, und ebenso denNamensraum, der eine URL oder ein URN sein kann.

Abbildung 9.1 Anlegen eines Business-Objekts mit dem SAP ES Methodology Wizard

Wir werden in Abschnitt 9.3.3, »Eigene XML-Namensräume bei derModellierung«, auf die Wahl des Namensraums eingehen. In unse-rem Programmierbeispiel nehmen wir als Namen Vehicle, also dasFahrzeug als Business-Objekt.

Eine Anwendung besitzt in der Regel ein oder mehrere Anwen-dungsobjekte samt zugehörigen Services. Diese werden in einersogenannten Prozesskomponente gebündelt, wie in Abbildung 9.2zu sehen ist. Die Angabe der Prozesskomponente ist hier obligato-risch, aber für die Beispielanwendung überflüssig, da die Anwen-


532

dung in der Regel einer Prozesskomponente entspricht, die denSOA-Layer des Business-Objekts realisiert, das den Service enthält.

Abbildung 9.2 Anlegen der Prozesskomponente

Service-Interface Im Anschluss spezifizieren wir das Service-Interface, das den Servicerepräsentiert, also die Menge der Operationen auf einem einzelnenBusiness-Objekt. Ein Service besitzt als Eigenschaft des Service-Inter-face eine Kategorie, in der festgelegt wird, ob es sich um einenInbound- oder einen Outbound-Service handelt. Wir diskutierenhier Inbound-Services, die im Backend als Service-Provider imple-mentiert und von externen Systemen aufgerufen werden. Die Erstel-lung von Service-Providern wird in Abschnitt 9.5, »Konsumierenvon Webservices«, erklärt.

Art des Interface

festlegen

Ein Service-Interface kann zustandslos (»stateless«), zustandsbehaftet(»stateful«) sein oder dem sogenannten Tentative Update and Compen-sation or Confirm-Muster entsprechen. Wir konzentrieren uns hierauf einen zustandslosen Webservice, der also keine Daten aus demletzten Aufruf (z.B. in Form eines Datenbank-Cursors) speichert. Imnächsten Schritt bestimmen wir die Art des Interfaces, wie in Abbil-dung 9.3 zu sehen ist. Dabei gibt es folgende Muster:

� Mit dem Manage Pattern können wir Serviceoperationen fürCRUD-Operationen anlegen.


533

� Services mit dem Query Pattern werden benötigt, um Such-dienste für Geschäftsobjekte zu realisieren.

� Mit dem Action Pattern können fachliche Operationen wieApprove, Process, Release etc. realisieren.

� Das sogenannte Entries For Pattern können Sie für Wertehilfen-Services verwenden, z.B. für Suchausdrücke der folgenden Art:»Find Sales Order Fulfillment Issue By Fulfillment Issue« oder auch»Find Allowed Cost Centre by Employee«.

Abbildung 9.3 Wahl der Schnittstellenart

Die Einstellung zur XI-3.0-Kompatibilität (XI30-Compatible Imple-

mentation) in Abbildung 9.3 spielt in unserem Programmierbeispielkeine Rolle. Es handelt sich um eine obsolete und nicht mehr rele-vante Einschränkung der Vorgängerversion des aktuellen PI-Release.

CRUD-Operation

auswählen

In unserem Anwendungsbeispiel wählen wir Manage Pattern.Nach der Wahl dieses Interface-Pattern besteht der nächste Schrittdarin, die spezielle Operation auszuwählen (siehe Abbildung 9.4).An dieser Stelle soll noch der Unterschied zwischen den einzelnenOperationen erläutert werden. Create- und Read-Operationen wer-den als bekannt vorausgesetzt, bei den weiteren muss die Bedeutungerklärt werden:


534

� Update-Services besitzen das Verhalten eines BAPIs: Existierenzwei konkurrierende Änderungen, gewinnt das letzte Update. Die-ses Verhalten ist insofern natürlich, als ein zustandsloser Webser-vice keine Sperren setzen kann. In manchen Anwendungsfällen istdieses Verhalten ungewöhnlich, und es wird oft gefordert, dass beieinem parallelen Änderungsversuch (z.B. im Rahmen einer Benut-zerinteraktion) der erste Änderer »gewinnt«, was dann ein Change-Service genannt wird. Diesen realisiert man dadurch, dass beieinem ersten Lesezugriff auf das ändernde Objekt ein sogenannterChange State Identifier (Element ChangeStateID in der Response-Nachricht) zurückgegeben wird, der z.B. aus einem Zeitstempelder letzten Änderung oder einem berechneten Hashwert bestehenkann. Bei einem Change-Service wird dieses Element eingegeben,und hat sich dieses inzwischen geändert, wird die Änderungzurückgewiesen. Weitere Implementierungsdetails bei Ände-rungsstrategien werden sie in Abschnitt 9.4.4, »Weitere Imple-mentierungsdetails von Webservices«, kennenlernen.

Abbildung 9.4 Auswahl der Operation

� Im SAP-Umfeld existieren üblicherweise keine Löschungen. DieCancel-Operation setzt daher lediglich den Status eines Geschäfts-


535

objekts auf »zu löschen«. Es wird dann im Rahmen eines gesonder-ten Lösch- oder Archivierungsprogramms von der Datenbankgelöscht.

� Mit dem Check-Muster können Sie Operationen implementieren,die testen, ob eine Operation (wie das Anlegen, Ändern oderLöschen eines Objekts) zulässig ist.

Namenskonven-

tionen exportieren

Abschließend lassen sich die Namenskonventionen als Excel-Listeexportieren. Wir erhalten folgende Vorschläge für Namenskonven-tionen:

� Das Service-Interface erhält den Namen ManageVehicle_In.

� Die Serviceoperation heißt CreateVehicle_sync. Wir haben andieser Stelle das Postfix _sync angehängt, um zu zeigen, dass essich um ein synchrones Szenario handelt.

� Der Struktur einer Nachricht wird durch den Message Type defi-niert. Dieser ist in unserem Fall VehicleCreateRequest.

� Der dazugehörende Message Data Type heißt VehicleCreate-RequestMessage_sync.

Unsere Empfehlung ist, die Namenskonventionen anhand diesesTools zu wählen. Die Namen unterscheiden sich leicht von dem er-wähnten Dokument PI Best Practices: Naming Conventions, was daranliegt, dass sie auch im SAP-Standard nicht vollständig deckungsgleichsind. Die Abweichungen zwischen beiden Varianten sind minimal,und es ist egal, für welche Variante Sie sich entscheiden. Wichtigerist, dass Sie sich für eine Variante entscheiden und gemäß dieser dieBenennung vornehmen.

9.3.2 Kommunikationsmuster und Standards für Datentypen

Der SOAP-Standard ermöglicht eine Vielzahl von möglichen Kom-munikationsmustern. Enterprise Services reduzieren die Komplexi-tät durch weitere Standardisierung. Wenn wir wie im letztenAbschnitt schreibende Operationen entwickeln, wird die Eingangs-nachricht Request genannt und die Rückgabenachricht Confirmation.Im Falle eines lesenden Service nennt man die Antwort Response.Diese Namenskonventionen der Modellierung sollten Sie auch in derImplementierung verwenden.


536

Unidirektionale

Kommunikations-

muster

Auch wenn wir in diesem Kapitel nur bidirektionale Kommunika-tionsmuster entwickeln werden, soll erwähnt werden, dass es auchunidirektionale Kommunikationsmuster gibt:

� Als Informationen bezeichnen wir Nachrichten, auf die ein Clientnicht reagieren muss.

� Auf Notifikationen hingegen muss reagiert werden. Ein Beispiel füreine solche Notifikation ist z.B. die Stornierung eines Auftrags, diedem Auftragnehmer mitgeteilt werden muss.

Message-Typ Der Aufbau der auszutauschenden Nachrichten wird durch spezielleDatentypen realisiert, die Message-Typ genannt werden. Wir werdendiese bei der Modellierung eines Enterprise Service in Abschnitt9.4.1, »Entwicklung von Enterprise Services mit dem MetadataRepository«, anlegen und auch vom Webservice-Wizard generierenlassen.

Globale Datentypen Bei der Modellierung von Enterprise Services ist es sinnvoll, SAP-Datentypen wiederzuverwenden, die normalerweise kopiert wer-den. Bei der Modellierung von Services werden wir eigene Datenty-pen, sogenannte Free-Style-Datentypen, in Abschnitt 9.4.1, »Entwick-lung von Enterprise Services mit dem Metadata Repository«,anlegen. In der Regel wird man versuchen, Datentypen aus dem SAP-Standard wiederzuverwenden, indem man sie kopiert. Diese Daten-typen können entweder aus globalen Datentypen stammen, die SAPin der Softwarekomponentenversion SAPGLOBAL2.0 im Namens-raum http://sap.com/xi/SAPGlobal/GDT ausliefert. Es werden aberauch weitere fachliche Datentypen in SAP-Anwendungen ausgelie-fert, wie z.B. CreditRiskClassCode im Namensraum http://sap.com/xi/FICA/Global. Diese werden in verschiedenen Message-Typen vonServices im Namensraum http://sap.com/xi/FICA verwendet.

Wiederverwendung

durch Kopie

Wenn Sie ein Add-On zu einer SAP-Anwendung erstellen, sollte IhrZiel sein, diese Elemente in ihren Namensraum zu kopieren, umkompatibel zu bleiben.

9.3.3 Eigene XML-Namensräume bei der Modellierung

In Abbildung 9.1 haben wir einen Namensraum http://tempuri.orgverwendet. Dies ist eine für Beispiele im SOA-Umfeld übliche Abkür-zung für »temporäre URI«. Für ein Beispiel ist dies hinreichend, aber


537

in der Praxis empfiehlt sich eine genauere Konzeption. Bitte beach-ten Sie den fehlenden Slash am Ende der URI, da in manchen SAP-Systemen der Namensraum http://tempuri.org/ benutzt wird.

Anwendungen in

URI aufnehmen

Sie sollten die Services einer Anwendung zuordnen und diese auchin die URL aufnehmen, wie z.B. http://tempuri.org/VehicleManage-ment. Auf diese Weise können Sie die Service-Definitionen verschie-dener Geschäftsanwendungen auseinanderhalten und erreichen eineStrukturierung.

Wenn Sie Ihre ABAP-Anwendung durch Softwarekomponentenstrukturieren und diese ausliefern, sollte sich diese Strukturierungsich auch in den Namensräumen widerspiegeln bzw. in den Soft-warekomponentenversionen des ESR. Der Grund liegt darin, dassdie WSDL-Definition von Service-Providern eine Beschreibung einerWebservice-Schicht einer ABAP-Anwendung ist. Als Webserviceexponierte Schnittstellen einer Anwendung sollten zusammen mitdieser ausgeliefert werden und besitzen auch denselben Releasezyk-lus wie die Anwendung.

Standardisierung

von URLs und URIs

XML-Namensräume werden auf vielfältige Weise genutzt, um Arte-fakte der Softwaretechnik zu strukturieren und zu identifizieren.Wenn Sie in Ihrem Unternehmen viele XML-Namensräume benut-zen, empfiehlt sich eine Standardisierung, um Eindeutigkeit zu errei-chen. Sie können beispielsweise durch ein weiteres Midfix xidiejenigen Namensräume identifizieren, die Sie für Webservices ver-wenden, wie z.B. http://tempuri.org/xi/VHM/VehicleManagement.

Softwarekompo-

nenten und

Namensräume

Wenn Sie z.B. eine Softwarekomponente VHM ausliefern (siehe Ab-schnitt 4.4.3, »Strukturpakete und SAP-Softwarekomponenten«),können diese verschiedene ABAP-Anwendungen enthalten. In die-sem Fall können Sie VHM als Midfix aufnehmen und den Namen derAnwendung anhängen: http://tempuri.org/VHM/VehicleManagementoder http://tempuri.org/VM/ContractManagement. DazugehörendeFree-Style-Datentypen können Sie in http://tempuri.org/VM/Contract-Management/Global ausliefern. Wir empfehlen, dass die ESR-Soft-ware-Komponentenversionen den ABAP-Softwarekomponenten ent-sprechen. Den Grund werden Sie in Abschnitt 9.4.1, »Entwicklungvon Enterprise Services mit dem Metadata Repository«, kennenler-nen. Im Gegensatz zu ESR benötigen Sie keine Softwarekomponen-tenversionen für die Proxy-Entwicklung im MDR.


538

9.4 Entwicklung eines Beispiel-Webservice

Die Grundlagen der Modellierung haben Sie im vorigen Abschnittkennengelernt. Wenn Sie Webservices entwickeln, können Sie dieseim Enterprise Service Repository oder im Metadata Repository entwi-ckeln.

9.4.1 Entwicklung von Enterprise Services mit dem Metadata Repository

Ab SAP NetWeaver 7.02 SP 8 können Sie Enterprise Services mitdem Metadata Repository anlegen. Sie benötigen dafür kein Java-System. Hierfür müssen Sie zuerst einen Namensraum in der Trans-aktion SPXNGENAPPL anlegen, wie in Abbildung 9.5 zu sehen ist.

Abbildung 9.5 Anlegen eines MDR-Namensraums

Anlage eines

Service-Providers

Danach rufen Sie die Transaktion SPROXY auf, und können miteinem Button zwischen ESR-Sicht und lokaler Sicht hin- und herwech-seln. In der lokalen Sicht sehen Sie auf der linken Seite in der Listeder Namensräume den Namensraum http://tempuri.org (MDR). Siekönnen nun mit der rechten Maustaste im Kontextmenü einen MDR-Proxy anlegen. Dann öffnet sich der Wizard aus Abbildung 9.6.

Arbeit mit dem

Webservice-Wizard

Sie können hier verschiedene Proxy-Objekte anlegen. Wir entschei-den uns für einen Service-Provider, da wir einen Service implemen-tieren wollen, der von einem externen Client aufgerufen wird. Imnächsten Bild geben Sie dann den Namen des Service-Interfacegemäß den Konventionen aus Abschnitt 9.3.1, »Modellierung vonWebservice-Signaturen«, an (siehe Abbildung 9.7).

Entwicklung eines Beispiel-Webservice 9.4

539

Abbildung 9.6 Anlegen eines Service-Providers

Abbildung 9.7 Anlegen des Service-Interface


540

Event-Provider

Der AS ABAP unterstützt auch Event-Provider, wie Sie in Abbildung 9.6sehen können. Event-Provider sind technisch Webservice-Consumerohne logischen Port, die sie zum Broadcast von Nachrichten verwendenkönnen. Sie können auf diese Weise ereignisgetriebene Architekturenumsetzen, indem Sie Nachrichten als spezielle Ereignisse über eine SOAexponieren. Dies zu erläutern, würde aber den Rahmen dieses Buchessprengen.

Klicken Sie auf den Button Weiter, und weisen Sie dem Service einEntwicklungspaket zu. Vergeben Sie außerdem einen Transportauf-trag sowie ein Namensraumpräfix für die generierten Objekte (sieheAbbildung 9.8). Bei der Wahl des Namensraumpräfix sollten Sie dar-auf achten, dass das Präfix mit den Namenskonventionen für Paketekorrespondiert. Hierbei gilt, dass ein Unterstrich erst ab der viertenStelle auftauchen darf.

Abbildung 9.8 Angabe des Pakets und des Namensraumpräfix

Diesen Wizard werden Sie in Zukunft immer verwenden, um Proxy-Elemente anzulegen – seien es Artefakte für einund ausgehende


541

Nachrichten oder Datentypen oder die durch diese Artefakte ausge-tauschten Datentypen. Da die Dialogfolge des Wizards immer die-selbe ist, werden wir in Zukunft nicht mehr auf jeden einzelnen derbeschriebenen Schritte eingehen.

Hinweis zur Paket-

strukturierung

Neben dem Objekt für den Service-Provider werden eine Mengeweiterer Objekte generiert, u. a. die Datenelemente und Strukturenfür die Schnittstelle. Hier ist es sinnvoll, diese in einem gemeinsa-men Paket gesteuert mit einem Namensraumpräfix zu generieren.Der Grund besteht darin, dass bei Anpassungen diese Objekte neugeneriert werden, was bei einer Wiederverwendung in anderenPaketen Probleme bereiten kann. Aus diesem Grund empfehlen wir,für Service-Provider eigene Pakete zu verwenden.

In Abbildung 9.9 sehen Sie den erstellten Service-Provider. WennSie in diesem Dialog sind, können Sie den Namen der Webservice-Definition noch ändern und gegebenenfalls an Ihre Namenskonven-tionen anpassen. Ebenso müssen Sie zu diesem Zeitpunkt das Sicher-heitsprofil im Reiter Konfiguration anpassen. Das Sicherheitsprofilkann nachträglich im Reiter externe Sicht geändert werden, indemSie den oberen Knoten im Tree markieren. Dann befindet sich rechtsunten das änderbare Security Level.

Abbildung 9.9 Erzeugung des Service-Providers


542

Wenn Sie diese Einstellungen nachträglich ändern wollen, müssenSie den Service löschen und neu anlegen. Passen Sie auf, dass Sie nurdas Wurzelobjekt und nicht alle abhängigen Objekte löschen.

Operationen zum

Enterprise Service

definieren

Im Anschluss können Sie die Operationen zu dem Enterprise Servicedefinieren. Sie benutzen in der internen Sicht das Kontextmenü mitder rechten Maustaste und legen die Operation CREATE_VEHICLE an,wie in Abbildung 9.10 zu sehen ist. Es erscheint ein Wizard, in demSie einen Namen und einen XML-Namensraum angeben müssenebenso wie ein Paket und ein Namensraumpräfix wie zuvor. Dasgeht auch in der externen Sicht: In diesem Fall kann man den exter-nen Namen der Operation eingeben, und es wird ein ABAP-Metho-den-Name erzeugt, der nachträglich geändert werden kann.

Abbildung 9.10 Anlage einer Service Operation

In Abbildung 9.11 sehen Sie das Resultat des Anlegens der Message-Typen, das ausgehend von der Operation über die Auswahl mit derrechten Maustaste erfolgt. Sie legen sie wie üblich über einen Wizardan, wo Sie einen Namen und einen Namensraum eingeben müssen.In unserem Fall lauten die Namen VehicleCreateRequest bzw.VehicleCreateConfirmation.


543

Abbildung 9.11 Anlegen des Message-Typs

Standardisierung

der ABAP-Objekt-

namen

Sie gehen nun auf das Eingabefeld ABAP-Name im Abschnitt Objekt

und benennen den vorgegebenen Namen in REQUEST um. Es sinn-voll, die ABAP-Namen des Message-Typs im Abschnitt Objektrefe-

renz zu standardisieren – in Abbildung 9.11 wurde er in ZVHM_VHCL_CRT_RQ_MT geändert. Der Grund ist, dass alle generierten Proxyele-mente automatische Namen für die korrespondierenden ABAP-Objekte erhalten. Bei Namenskollisionen werden die letzten Stellendurch Zahlen ersetzt, die hochgezählt werden, was die Objektnamenunleserlich macht und die spätere Implementierung erschwert. Wirempfehlen an dieser Stelle, für die Namen die oben beschriebeneKonvention zu verwenden, weil die Generierung zu einer Vielzahlvon ABAP-Datentypen führt, was die Implementierung und die War-tung erschwert.

Umsetzung der

Namenskonvention

Die Konvention sieht wie folgt aus: Zuerst kontrollieren wir dieNamen durch ein Präfix, das hier ZVHM_ ist. Es folgt der Name desBusiness-Objekts, den wir abkürzen, indem wir die Vokale entfer-


544

nen: VHCL. Dann folgt der Name der Methode, hier CRT für Create,dann der Verweis auf den Message-Typ, also auf das Kommunikati-onsmuster RQ für Request. Schließlich wird mit MT angezeigt, dass essich um einen Message-Typ handelt. Wenn Sie diesen Namen zusam-mensetzen, trennen Sie seine Bestandteile durch Unterstriche: ZVHM_VHCL_CRT_RQ_MT.

Ebenso wurden die ABAP-Namen von INPUT und OUTPUT im Ab-schnitt Objekt in REQUEST und CONFIRMATION umbenannt, was derStandardisierung dient, aber ein rein optionaler Bearbeitungsschrittist.

Anlegen des

Message-

Datentyps

Im Folgenden werden wir für den Message-Typ einen Message-Datentyp anlegen, um dann den Proxy aktivieren zu können. Dafürnavigieren Sie zum Message-Typ. Das kann auf drei verschiedeneArten geschehen. Am einfachsten geht es durch einen Doppelklickauf den Namen VehicleCreateRequest im Abschnitt Objektreferenz

in Abbildung 9.11 oder in der Transaktion SE80, wo Sie den Daten-typ ZVHM_VHCL_CRT_RQ_MT unter dem Paket ZHVMXI unter Enterprise

Services � Datentypen finden. Schließlich können Sie in der Transak-tion SPROXY alle erzeugten Elemente unter dem Namensraum http://tempuri.org finden.

Sie navigieren nun auf den Message-Typ und wechseln auf den Rei-ter Interne Sicht. Dort aktivieren Sie den Änderungsmodus und öff-nen das Kontextmenü des Objekts ZVHM_VHCL_CRT_RQ_MT. Wählen Siehier Datentyp � Neuen globalen Typ anlegen aus, und Sie gelangenwieder in den Wizard zur Erzeugung von Proxy-Elementen. Dortwählen Sie als Namen den Namen des Message-Datentyps (sieheAbschnitt 9.3.3, »Eigene XML-Namensräume bei der Modellierung«)VehicleCreateRequest_sync im Namensraum http://tempuri.org.Dieselben Schritte müssen Sie anschließend für den Rückgabepara-meter (CONFIRMATION) durchführen. Wählen Sie hier lediglich alsMidfix CO für Confirmation statt RQ für Request. Sie sehen das Resul-tat in Abbildung 9.12.

Den generierten Server-Proxy können Sie in der Transaktion SE80oder SPROXY prüfen: Es sind ein Server-Provider-Proxy und Daten-typen entstanden, die wir in Abschnitt 9.3.1 definiert haben und diein Abbildung 9.13 zu sehen sind.


545

Abbildung 9.12 Anlegen des Message-Datentyps

Abbildung 9.13 Generierte Objekte


546

Nachdem wir die Struktur des Webservice bestimmt haben, müssenwir nun die Komponenten der generierten Message-Datentypen imDetail definieren, also die zu übermittelnden fachlichen Daten. DasResultat sehen Sie in Abbildung 9.14. Unser Ziel ist es, die genaueBeschreibung der Eingabeparameter für den Webservice zu definie-ren – also in unserem Beispiel die Daten, die für das Anlegen einesneuen Fahrzeugs notwendig sind.

Abbildung 9.14 Elementdefinition des Message-Datentyps

Sie gehen dafür in den Änderungsmodus, selektieren damit den Mes-sage-Datentyp VehicleCreateMessage_sync mit der rechten Maus-taste und wählen Element hin. Es erscheint ein Eingabefeld, in demSie den Namen in der sogenannten CamelCase-Schreibweise einge-ben, wie sie für WDSL-Dokumente üblich ist, z.B. StandingPlace.

Ein Vorschlag für den ABAP-Namen wird generiert, wobei die inABAP üblichen Unterstriche eingefügt werden. Im Anschluss spezifi-zieren Sie den Typ im Sinne von XML-Schema (wie z.B. xsd:unsi-


547

gnedInt), nehmen gegebenenfalls Werteinschränkungen im Sinnedes XML- Schemas vor und spezifizieren den ABAP-Datentyp.

Genau so gehen wir bei der Konstruktion des Message-DatentypsVehicleCreateConfirmation_sync für den Message-Typ Vehicle-CreateConfirmation vor. Dieser enthält die Rückgabedaten deszu erstellenden Server-Proxys. Sie können den Datentyp in derDetailanzeige in Abbildung 9.15 sehen. Ein Bestandteil dieses Daten-typs ist die ID im Sinne des eindeutigen, technischen Schlüssels fürdas angelegte Objekt. Das Anlegen erfolgt wie üblich durch das Hin-zufügen eines Elements ID vom XML-Schema-Typ xsd:token. DerDatentyp besteht zusätzlich aus einem Element LOG für die Rückmel-dung von Fehlern. Auf dieses Element gehen wir nun im Detail ein.

Nutzung von Log-Elementen für den Fehlerfall

Im Fehlerfall (wenn im Programmierbeispiel z.B. ein Fahrzeug mit den-selben Daten vorliegt) geben wir die Fehlermeldung in einem Log-Ele-ment zurück. Dieses ist standardisiert (z.B. im ESR-Namensraum http://sap.com/xi/BASIS/Global), und Sie können es einfach per Drag & Drop imEnterprise Services Browser bzw. in der Transaktion SPROXY in denMessage-Datentyp aufnehmen, wie Sie in Abbildung 9.15 sehen.

Abbildung 9.15 Log-Element des Message-Datentyps »Confirmation«


548

Die Befüllung des Log-Elements werden Sie im kommenden Ab-schnitt kennenlernen, wenn es wir die Implementierung des Web-service beschreiben.

Drag & Drop Die Arbeit per Drag & Drop kann die Erstellung eines Service undWiederverwendungen vereinfachen und ist ein gutes Hilfsmittel, umFehlersituationen aufzulösen, die von der MDR-Entwicklungsumge-bung geliefert werden.

Die Übernahme des Log-Elements aus dem SAP-Standard ist unüb-lich. Normalerweise modelliert man das Element genauso wieeigene, fachliche Datentypen in einem eigenen Namensraum (z.B.http://tempuri.org/Global) und verwendet ihn dann wieder. Da wirdas Anlegen von MDR-Datentypen mehrfach gezeigt haben, sparenwir uns hier diesen Schritt.

Nutzung von Fault-Messages

Eine weitere Möglichkeit der Kommunikation bei Fehlersituationenist der Gebrauch von sogenannten Fault-Messages. Im Fall von asyn-chronen Services ist dies die einzige Möglichkeit, Daten an Aufruferzurückzugeben. Diese Fault-Messages werden von der Laufzeit desIntegration Servers gespeichert und können durch die TransaktionSXMB_MONI analysiert werden.

Fault-Message in

synchronen Services

Im Fall synchroner Services werden Fault-Messages verwendet, umschwere Anwendungsfehler anzuzeigen, die eigentlich durch einenTest während der Implementierung ausgeschlossen werden können,wie z.B. Programmierfehler oder fehlerhaftes Customizing der An-wendungen. Für unser Programmierbeispiel ziehen wir den Fault-Message-Typ CX_STANDARD_MESSAGE_FAULT1 des XML-Namensraumshttp://sap.com/xi/BASIS/Global in der Transaktion SPROXY auf dieMethode CREATE_VEHICLE unseres Beispiel-Webservice, wie in Abbil-dung 9.16 zu sehen ist.

Diese Vorgehensweise wählen wir hier aus pragmatischen Gründen.Normalerweise würde man diesen Fault-Message-Typ anhand diesesBeispiels nachbilden und gegebenenfalls durch eigene anwendungs-spezifische Informationen ergänzen, die meist parallel zu dem Feldstandard in einer eigenen Struktur addition angehängt werden. Aufdiese Weise erreicht man verständlichere und präzisere Fehlerrück-


549

meldungen. Den so erzeugten Fault-Message-Typ würde man dannin den Services-Operationen einer Anwendung wiederverwenden.

Abbildung 9.16 Anlegen einer Fault-Message

Fehlerbehandlung

Bei der Fehlerbehandlung wird zwischen drei Fällen unterschieden:

� synchron Point-to-Point (P2P)Der Fehler wird an den Aufrufer zurückgegeben, sodass dieser prinzipi-ell darauf reagieren kann.

� asynchron P2P via SAP Process IntegrationDie Meldung wird an SAP Process Integration zurückgegeben undkann dort ausgewertet werden.

� asynchron P2PEs findet keine Rückgabe an den Sender bzw. das Sender-System statt.Stattdessen bleibt die Nachricht in der Transaktion SRT_MONI stehenund kann dort ausgewertet werden.

Aufbau des

Fehlertyps

Zu dem in Abbildung 9.16 dargestellten Aufbau des Fehlertyps istFolgendes zu sagen: Im Element faultText können Sie einen Fehler-text mitgeben und in faultURL einen Link zur weiteren Dokumenta-tion. In der Wiederholstruktur faultDetail können Sie die Fehler-schwere im Element severity angeben, das Sie im mittlerenTreeview unten in der Abbildung sehen. Hierbei gilt wie üblich, dassdie Objekte einen Namen in CamelCase-Notation besitzen und dass


550

ein ABAP-Name in Großschrift vorliegt. Wenn Sie im mittleren Tree-view einen Knoten selektieren, werden beide Varianten in derDetaildarstellung zum Objekt angezeigt.

Fehlerschwere Die Fehlerschwere ist eine Zahl, wobei 1 eine Information zur ord-nungsgemäßen Ausführung bedeutet. Der Wert 2 ist eine Warnung,also ein möglicher Fehler, während der Wert 3 einen echten Fehlerbedeutet, und der Wert 4 steht für einen Abbruch.

Weiterhin stehen die Elemente text für einen Fehlertext, id für dieFehlernummer (z.B. eine Nachrichtennummer im Sinne der ABAP-Nachrichtenklasse) und url zum Verweis auf einen Langtext zur Ver-fügung.

9.4.2 Durchführung der Implementierung

Bisher haben wir nur die Schnittstelle des Webservice definiert, abernoch keine Geschäftslogik implementiert. In Abbildung 9.13 habenSie gesehen, dass neben speziellen Datentypen für die Schnittstellen-strukturen auch eine Klasse ZVHM_CL_MANAGE_VEHICLE_IN generiertwurde, die in Listing 9.1 zu sehen ist. Sie enthält eine Methode CRE-ATE_VEHICLE, die im Interface ZVHM_II_MANAGE_VEHICLE_IN definiertist.

CLASS ZVHM_CL_MANAGE_VEHICLE_IN IMPLEMENTATION.* <SIGNATURE>----------------------------------------+* | Instance Public Method ZVHM_CL_MANAGE_VEHICLE_IN->* | ZVHM_II_MANAGE_VEHICLE_IN~CREATE_VEHICLE* +--------------------------------------------------+* | [--->] REQUEST TYPE ZVHM_VHCL_CRT_RQ_MT* | [<---] CONFIRMATION TYPE ZVHM_VHCL_CRT_CO_MT* | [!CX!] CX_STANDARD_MESSAGE_FAULT1* +---------------------------------------</SIGNATURE>method ZVHM_II_MANAGE_VEHICLE_IN~CREATE_VEHICLE.*** **** INSERT IMPLEMENTATION HERE **** ***endmethod.ENDCLASS.

Listing 9.1 Generierte Proxyklasse

Proxyklasse

schmal halten

Diese generierte Proxyklasse hält man in der Regel sehr schmal undlagert die Logik in eine eigene Klasse aus, die man dann aufruft. Die-ses Vorgehen hat verschiedene Vorteile:

� Man kann die generierte Klasse bei Schnittstellenänderungen pro-blemlos neu generieren.


551

� Der Aufbau der ausgelagerten Klasse kann standardisiert werden.Auf diese Weise lassen sich Vorlagen schaffen, die man schnellkopieren und anpassen kann. Die Implementierungsgeschwindig-keit eines Webservice lässt sich auf diese Weise drastisch erhöhen.

Erstellen der Implementierungsklasse

Für unser Programmierbeispiel legen wir nun die Klasse ZVHM_CL_VHCLCRTRC_IMPL an. Die Namenskonvention setzt sich wie folgtzusammen: Wir besitzen ein Präfix und das Midfix für Klassen, leh-nen uns dann an die Abkürzung für Business-Objekt (Vehicle), dieMethode (Create) und das Pattern (Request/Confirmation) an undhängen schließlich ein Postfix IMPL für Implementierungsklasse an.Die Implementierungsklasse besitzt die folgenden Methoden, derenDefinition inklusive der Schnittstellen der Methoden in Listing 9.2zu sehen ist.

CLASS zvhm_cl_vhclcrtrc_impl DEFINITIONPUBLIC FINAL CREATE PUBLIC .

PUBLIC SECTION.

METHODS executeIMPORTING !i_request TYPE zvhm_vhcl_crt_rq_msgRETURNING value(r_response) TYPE zvhm_vhcl_crt_co_msgRAISING cx_ai_application_fault.

PROTECTED SECTION.

TYPES ty_request TYPE zvhm_vhcl_crt_rq_msg .TYPES:

BEGIN OF ty_bapi_input,license_nr TYPE z_license_nr,seats TYPE z_seats,standing_place TYPE z_standing_place,construction TYPE z_year,

END OF ty_bapi_input .TYPES:

BEGIN OF ty_bapi_output,id TYPE z_vehicle_id,bapiret2t TYPE bapiret2_t,

END OF ty_bapi_output .

METHODS do_validate_requestIMPORTING !i_request TYPE ty_requestRAISING cx_ai_application_fault.

METHODS do_convert_requestIMPORTING !i_request TYPE ty_request


552

RETURNING value(r_bapi_input) TYPE string.

METHODS do_convert_responseIMPORTING !i_bapi_output TYPE ty_bapi_outputRETURNING value(r_response) TYPE zvhm_vhcl_crt_co_msg.

METHODS do_perform_bus_logicIMPORTING !i_bapi_input TYPE ty_bapi_inputRETURNING value(r_bapi_output) TYPE ty_bapi_output .

PRIVATE SECTION.ENDCLASS.

Listing 9.2 Struktur der Implementierungsklasse

Aufbau Der Aufbau der Implementierungsklasse ist sehr einfach:

� Zentraler Zugangspunkt ist die Methode EXECUTE. Diese enthältimmer denselben Code, der in Listing 9.3 zu sehen ist. Zuerst wer-den die Eingabeparameter validiert, dann werden sie in Struktu-ren für einen BAPI-Aufruf konvertiert, danach wird die Geschäfts-logik (im Regelfall ein oder mehrere BAPIs) aufgerufen, undschließlich werden die Ergebnisparameter zurückkonvertiert. ImFehlerfall wird eine Instanz einer Fehlerklasse zurückgegeben – imNormalfall ist dies eine Unterklasse der Klasse CX_AI_APPLICATI-ON_FAULT.

� In der Methode DO_VALIDATE_REQUEST wird der Request-Parame-ter validiert und somit auf zulässige Werte geprüft. Im Falle einesFehlers kann die Nachricht nicht korrekt verarbeitet werden, wes-wegen eine Ausnahme und somit eine Fault-Message zurückgege-ben wird.

� In der Methode DO_CONVERT_REQUEST wird die Request-Nachrichtin ABAP-Datentypen konvertiert, wofür auch die Klasse CL_GDT_CONVERSION verwendet werden kann.

� Der Aufruf der Geschäftslogik (z.B. als BAPI) erfolgt in der KlasseDO_PERFORM_BUS_LOGIC.

� Die vom BAPI zurückgegebenen Werte werden in der Klasse DO_CONVERT_RESPONSE wieder in die Rückgabestruktur des Webservicekonvertiert, wobei Methoden der Klasse CL_GDT_CONVERSION ver-wendet werden können.

METHOD EXECUTE.

DATA: l_bapi_input TYPE ty_bapi_input,l_bapi_output TYPE ty_bapi_output.


553

me->do_validate_request( i_request = i_request ).

l_bapi_input =do_convert_request( i_request = i_request ).

l_bapi_output =do_perform_bus_logic( i_bapi_input = l_bapi_input ).

r_response =do_convert_response( i_bapi_output = l_bapi_output ).

ENDMETHOD.

Listing 9.3 Execute-Methode der Implementierungsklasse

Implementierungs-

klasse aufrufen

Nun sollten Sie in der generierten Proxyklasse die Implementie-rungsklasse aufrufen, wie in Listing 9.4 zu sehen ist:

METHOD zvhm_ii_manage_vehicle_in~create_vehicle.*** **** INSERT IMPLEMENTATION HERE **** ***

DATA lr_implementation TYPE REF TO zvhm_cl_vhclcrtrc_impl.

SET UPDATE TASK LOCAL.

CREATE OBJECT lr_implementation.

lr_implementation->execute(EXPORTING

i_request = request-vehicle_create_requestRECEIVING

r_response = confirmation-vehicle_create_confirmation ).* Nur bei asynchroner Kommunikation

IF confirmation-vehicle_create_confirmation-logbusiness_document_processing_r = 3.

cl_soap_commit_rollback=>commit( ).ELSE.

cl_soap_commit_rollback=>rollback( ).ENDIF.

ENDMETHOD.

Listing 9.4 Aufruf der Implementierungsklasse in der generierten Service-Klasse

Entwicklungsricht-

linien für die Imple-

mentierungsklasse

Für die Implementierungsklasse gelten prinzipiell dieselben Richt-linien wie für BAPIs, und wie erwähnt wird die Implementierungs-klasse ein oder mehrere BAPIs aufrufen. In jedem Fall gelten fol-gende Entwicklungsrichtlinien:

� Es darf keine unkontrollierten Anweisungen COMMIT WORK undROLLBACK WORK geben, ebenso keine Aufrufe von SUBMIT REPORTund CALL TRANSACTION.


554

� Wir empfehlen, die lokale Verbuchung durch SET UPDATE TASKLOCAL zu verwenden.

� Ein Webservice wird vom Internet Connection Framework des ASABAP aufgerufen, weswegen dieselben Restriktionen gelten: EinAufruf von SAP-GUI-Funktionen wie ABAP Dynpro oder Aufrufevon CL_GUI_TIMER führen zu Abbrüchen.

� Wir raten Ihnen ebenso zur Vorsicht bei der Verwendung von sy-batch, da Webservices in Dialogprozessen aufgerufen werden,aber UI-Funktionen aus den oben beschriebenen Gründen nichtaufgerufen werden dürfen.

� Die BAPIRET-Fehlermeldungen des BAPIs werden in ein Log-Ele-ment transformiert. Wenn diese nicht aussagekräftig sind, dannmüssen Sie gegebenenfalls zusätzliche Meldungen erzeugen.

Transaktions-

konzept und

Commit-Handling

Das Commit-Handling hängt davon ab, ob der Webservice synchronoder asynchron, ist sowie von der Seite des Message Calls (Senderoder Empfänger): Das transaktionale Verhalten von synchronen undzustandslosen (stateless) Webservices wurde eben beschrieben. Imsynchronen, zustandsbehafteten (stateful) Fall wird der Zustand imABAP-System gehalten (über globale Variablen), und der Commit/Rollback muss explizit über einen entsprechenden Operationsaufrufgetätigt werden. Speziell bei als Webservices verkleideten, schrei-benden BAPIs ist dieses Verhalten gewünscht und notwendig.

In asynchronen Szenarien wird der Commit ganz am Ende der Lauf-zeit einer Message vom Webservice-Framework durchgeführt. Esmuss und darf kein Commit oder Rollback programmiert werden, dadies zu Problemen mit dem bgRFC führen könnte, der beim asyn-chronen Handling eingesetzt wird. Es muss in jedem Fall bei einemFehler ein CX_AI_APPLICATION_FAULT zurückgegeben werden. Ebensodarf kein Rollback programmiert werden, da auf jeden Fall der Fehlerim Monitor niedergeschrieben werden muss.

9.4.3 Konfiguration des Webservice mit dem SOAMANAGER

Bevor Sie sich an die Konfiguration des Webservice machen, solltenSie ihn lokal testen. Wir werden diese Möglichkeiten in Abschnitt9.6.5, »Test von Webservices«, genau diskutieren.


555

Nachdem Sie die Implementierung angelegt haben, muss sie nochdurch die Transaktion SOAMANAGER exponiert werden. Sie kön-nen diese Transaktion direkt aufrufen oder mit dem Button SOA

Manager aus der Transaktion SPROXY für einen selektierten Web-service aufrufen.

Die notwendigen Berechtigungen sind im SAP-Hinweis 1318883(Einführung neuer Berechtigungen im Web Service Framework)beschrieben. Die erforderlichen Vorarbeiten sind im SAP Help Portalunter Web Services � Mit dem SOA Manager arbeiten � Technische

Konfiguration beschrieben. Nach dem Aufruf aus der TransaktionSPROXY sehen Sie den Dialog aus Abbildung 9.17.

Abbildung 9.17 Transaktion SOAMANAGER


556

Im Reiter Übersicht im unteren Bereich ist der hinterlegte LinkWSDL-Dokument für gewählt. Binding/Service öffnen wichtig.Diesen Link benötigen Sie, wenn Sie den Webservice von einemexternen System aus ansprechen wollen. Wir werden in Abschnitt9.5.1, »Aufruf eines externen Webservice«, näher darauf eingehen.

Service-Endpunkt

anlegen

Im Folgenden müssen wir für den Webservice einen sogenanntenService-Endpunkt anlegen, ihn also konfigurieren und die URL desService bestimmen, unter der der Service erreicht werden kann. Diesgeschieht über den Reiter Konfigurationen aus Abbildung 9.18.

Abbildung 9.18 Konfigurieren des Service-Endpunktes

Es ist möglich, eine Reihe von Service-Endpunkten anzulegen, z.B.mit unterschiedlichen Einstellungen zur Provider-Sicherheit je nachSicherheitszone, aber auch mit unterschiedlichen Transportprotokol-len für unterschiedliche Clients. In unserem Anwendungsbeispielbenötigen wir aber nur einen Endpunkt und klicken auf den ButtonAnlegen. Es erscheint darauf der Pop-up-Dialog aus Abbildung 9.19.


557

Abbildung 9.19 So legen Sie einen Service-Endpunkt an.

BindingBeachten Sie, dass der Service ohne das Anlegen eines sogenanntenBinding nicht aufgerufen werden kann. Hier nehmen wir die inAbbildung 9.19 dargestellten Eingaben vor. Im Folgenden müssenwir die Transportsicherheit und Authentifizierung so einstellen, wiein Abbildung 9.20 dargestellt.

Abbildung 9.20 Konfiguration der Transportsicherheit und Authentifizierung


558

Sicherheitskonzept Die dargestellten Werte sind für unsere Beispielanwendung akzepta-bel, jedoch benötigen Sie noch ein Sicherheitskonzept. Wichtig istdie Festlegung für Transportsicherheit und Authentifizierung:

� Mit den Einstellungen zur Transportsicherheit im Abschnitt Ver-

bindungssicherheit wird bestimmt, ob und wie die ausgetausch-ten Nachrichten signiert oder verschlüsselt werden.

� Die Authentifizierung im Abschnitt Authentifizierungsmethode

bestimmt, wie Service-Consumer und -Provider sich gegenseitigauthentifizieren.

Wenn Sie diese Einstellungen vorgenommen haben, können Sienach dem Sichern den Webservice verwenden. Wenn Sie einen SAP-Java-Applikationsserver wie SAP Process Integration oder CompositionEnvironment besitzen, können Sie den Webservice nun über den WebServices Navigator testen. In Abschnitt 9.5.1, »Aufruf eines externenWebservice«, werden wir den Service testen, indem wir ihn mitABAP-Mitteln aufrufen.

9.4.4 Weitere Implementierungsdetails von Webservices

Die Entwicklung von Webservices ist ein sehr umfangreiches Thema,das wir hier nur in Ansätzen behandeln können. Für größere SOA-Projekte empfehlen wir Ihnen daher die Lektüre des Buches Entwick-lung von Enterprise Services für SAP (2009) von Thomas Pohl undMarkus Peter, das ebenfalls bei SAP PRESS erschienen ist. Wir wol-len Ihnen in Folge dennoch einige zentrale Grundlagen vorstellenund Ihnen zeigen, welche Vorgehensweisen sich in der Praxis be-währt haben und für Integrationsprojekte wichtig sind.

Extended XML-Handling

Der XML-Standard unterscheidet verschiedene Möglichkeiten, umfehlende und initiale Werte zu übermitteln: Ein optionales XML-Ele-ment kann in der SOAP-Nachricht fehlen, es kann initiale Werte ent-halten und oder NULL-Werte, die mit einem Attribut xsi:nilgekennzeichnet werden. Die Semantik ist hier unterschiedlich: Ineiner Suche kann ein fehlendes Feld oder ein Wert mit einem NULL-Wert bedeuten, dass ein Kriterium nicht für die Suche benötigt wird,während bei der Übermittlung eines initialen Werts genau die Sätzegesucht werden sollen, die einen initialen Wert in dem entsprechen-


559

den Feld besitzen. Dieselben Unterschiede gibt es bei ändernden Ser-vices, wodurch das Setzen eines Wertes auf den Initialwert von demBeibehalten des Wertes unterschieden werden kann. Wichtig ist,dass Sie dieses Verhalten einheitlich implementieren.

Mächtiges Such-

und Änderungs-

verhalten

Zusammengefasst können Sie mit dem Extended XML-HandlingWebservices mit sehr mächtigen Such- und Änderungsverhaltenerstellen. Hierfür ist es notwendig, dass die Implementierung einesServer-Proxys feststellen kann, ob in der Payload übermittelte Ele-mente leer (also mit Initialwert), mit dem xsi:nil-Attribut oder garnicht übermittelt wurden. Hierfür muss im Konstruktor des Servicedas sogenannte Extended XML-Handling aktiviert werden, wie inListing 9.5 zu sehen ist:

DATA: lv_protocol_payload TYPE REF TO if_wsprotocol_payload,lv_server_context TYPE REF TO if_ws_server_context.

lv_server_context = cl_proxy_access=>get_server_context( ).lv_protocol_payload ?= l_server_context->get_protocol(

if_wsprotocol=>payload ).

lv_protocol_payload->set_extended_xml_handling(extended_xml_handling = abap_true ).

Listing 9.5 Aktivieren des Extended XML-Handlings

Durch die Aktivierung des Extended XML-Handlings werden zu-sätzliche Felder in den generierten Datenelementen für einen Proxygefüllt, die Sie in der CONTROLLER-Struktur in Abbildung 9.21 sehenkönnen.

Abbildung 9.21 Kontrollstruktur für das Extended XML-Handling

Diese CONTROLLER-Struktur wird nach dem Einschalten des Extended-XML-Handlings mit den folgenden Werten aus der Typgruppe SAIgefüllt, die in Listing 9.6 zu sehen sind:


560

* Control FlagsCONSTANTS:* Send initial value

sai_ctrl_initial TYPE prx_contr VALUE '1',* Send xsi:nil='true'

sai_ctrl_nil TYPE prx_contr VALUE '2',* Suppress Element

sai_ctrl_none TYPE prx_contr VALUE '3'.

Listing 9.6 Konstanten der Typgruppe SAI

Da das Extended XML-Handling in der Regel im Konstruktor dergenerierten Proxy-Klasse aktiviert ist, ist es für alle in der Klasse gene-rierten Methoden aktiv. Sie haben auf diese Weise die Informationenüber den Inhalt der Payload vor der Deserialisierung. Umgekehrtkönnen Sie das Extended XML-Handling bei sogenannten Consumer-Proxys (siehe Abschnitt 9.5, »Konsumieren von Webservices«) auchbenutzen, um den Inhalt der zu erstellenden Payload zu kontrollie-ren, also Elemente auszublenden oder mit dem xsi:nil-Attribut zuversehen. Diese Technik bietet oftmals die einzige Möglichkeit, vonABAP aus Webservices aus Nicht-SAP-Systemen anzusprechen, diedie XML-Payload detailliert auswerten und es deswegen nötigmachen, dass Sie die Generierung steuern.

Idempotenz

In unserem Beispiel haben wir einen synchronen Webservice entwi-ckelt, der es erlaubt, ein Fahrzeug anzulegen. Diesen kann manrobust implementieren und bei jedem Anlegen prüfen, ob bereits einFahrzeug (charakterisiert durch gewisse Werte wie Herstelljahr,Fahrzeugnummer etc.) existiert. Falls in der Vergangenheit bereitsein solches Fahrzeug angelegt wurde, kann man einen Fehler zurück-geben. Generell ist das doppelte Anlegen ein Problem und sollte ins-besondere in asynchronen Szenarien unterbleiben. Es ist in SOA-Projekten eine Best Practice, Webservices so zu gestalten, dass sierobust gegenüber mehrfachen Aufrufen sind.

Idempotenz-

Framework

Es lässt sich durch ein Framework im AS ABAP verhindern, dass einedoppelte Ausführung doppelte Daten angelegt, was die Entwicklungrobuster Integrationsszenarien extrem vereinfacht. Doppelte Aufrufekönnen bei synchronen Services passieren, wenn die Confirmation-Nachricht nicht übermittelt werden kann, die Operation aber den-noch durchgeführt wurde. Webservices, die bei mehrfacher Anwen-


561

dung immer dasselbe Verhalten besitzen und dasselbe Ergebniszurückgeben, werden idempotent genannt. Um idempotente Enter-prise Services zu entwickeln, gehen Sie wie folgt vor:

� In der Service-Signatur wird dem Nachrichtenkopf ein SAP-GDT-Element vom Typ BasicBusinessDocumentMessageHeader hinzu-gefügt, und zwar jeweils für den Input- und den Outputdatentyp.

� Vor der normalen Ausführung der Geschäftslogik wird geprüft, obdie Anfrage schon verarbeitet wurde. Dafür übergibt man denWert des Felds UUID dem Idempotenz-Framework und prüft, obdie Nachricht schon einmal verarbeitet wurde. In dem Fall wirdeine gespeicherte Confirmation-Message zurückgegeben, die manebenso zurücksendet.

� Im anderen Fall wird die Verarbeitung durchgeführt, und nachErfolg wird die Confirmation-Message in der Datenbank unterdem Wert MessageID gespeichert.

Weitere Informationen zum Framework finden Sie im SAP-Hinweis1097348 (Konfiguration von Idempotent Services). Informationenzur Implementierung finden Sie im SAP Help Portal unter dem Stich-wort Implementierung idempotenter Web-Services sowie dann,wenn Sie Verwendungen der Klasse CL_WS_IDP_FACTORY bzw. derMethode CREATE_IDP_HELPER untersuchen.

Änderungsstrategien

Die übliche Strategie, die wir von BAPIs kennen, ist Last One Wins,das heißt, der letzte Änderer gewinnt. Solche Services nennen sichauch Change-Services und werden verwendet, wenn sich die Datenwie in B2B-Prozessen in der Hoheit anderer befinden.

Update-ServicesEine andere Strategie ist First One Wins – was am ehesten dem Dialog-verhalten entspricht. In diesem Ansatz wird oft ein Zeitstempel derletzten schreibenden Änderung auch bei lesenden Zugriffen mitge-liefert. Dieser wird dann bei einem schreibenden Zugriff mitgege-ben, sodass im Service geprüft werden kann, ob zwischendurch eineÄnderung stattgefunden hat. Der erste Änderer gewinnt, und spätereÄnderungen werden abgewiesen, da diese auf einem nicht mehraktuellen Datenabbild beruhen. Diese Services werden auch Update-Services genannt.


562

Generell wird dieses Verhalten in A2X-Services empfohlen. Hier gibtes viele Möglichkeiten zur Implementierung. Man liest und erhälteinen Zeitstempel oder einen Hash des Datensatzes – einen ChangeState Identifier. Der Confirm- oder Cancel-Service erhält dies als Para-meter und entscheidet, ob eine Änderung durchgeführt werden soll.Um einen Change State Identifier zu berechnen, können Zeitstem-pel benutzt werden, zu denen die letzte Änderung des Datensatzesabgespeichert wird. Alternativ können Hashwerte berechnet wer-den. Dafür muss man eine Struktur mit allen Kopf- und änderbarenDaten durch den Befehl CALL TRANSFORMATION ID nach XML umset-zen und dann durch den Funktionsbaustein CALCULATE_HASH_FOR_CHAR erzeugen.

Everyone Wins Die Strategie Everyone Wins ist meist sehr aufwendig, da Delta-Infor-mationen über konkurrierende Änderungen verwaltet werden müs-sen, damit keine Konflikte auftreten.

Bulk- und Bundle-Verarbeitung

Es gibt für Massendaten zwei Modelle: Bundle-Verarbeitung bedeu-tet, dass alle zu ändernden Geschäftsobjekte als eine Einheit betrach-tet werden und in einer LUW geschrieben werden. In der Bulk-Ver-arbeitung werden Objekte in einer Schleife in einzelnen LUWsverarbeitet: Es werden also so viele Daten wie möglich verarbeitet.Das Standardprogrammiermodell in der SAP Business Suite für dieÄnderung einer Menge von Geschäftsobjekten ist die Bulk-Verarbei-tung.

Asynchrone Webservices

Analysiert man die Enterprise Services des SAP-Standards, so sinddie meisten ändernden A2A- und B2B-Services asynchron. Diesüberrascht auch nicht, da asynchrone Systeme oftmals besser skalie-ren. Ein anderer Grund ist, dass für schreibende Änderungen keineSystemverfügbarkeit notwendig ist – im Fall von temporären Proble-men lassen sich Nachrichten puffern und gegebenenfalls späterzustellen.

Asynchrone Webservices unterscheiden sich von synchronen da-durch, dass keine Response oder Confirmation direkt zurückgebenwird, sondern ein Aufruf eines Webservice in derselben LUW er-

Konsumieren von Webservices 9.5

563

folgt. Dies erfolgt analog zum Konsumieren eines Webservice-Pro-viders, das in Abschnitt 9.5, »Konsumieren von Webservices«,beschrieben wird.

Forward Error

Handling

Im Folgenden beschäftigen wir uns mit der Fehlerbehandlung beimServiceaufruf, also möglichen Systemfehlern oder Problemen beiSperren. Bei asynchronen Webservices empfiehlt SAP, ein ForwardError Handling zu implementieren. Dies bezeichnet ein sehr einfa-ches Prinzip: Wenn ein Fehler auftritt, wird die fehlerhafte Eingangs-nachricht zusammen mit den Fehlermeldungen und Zusatzinforma-tionen der betroffenen Geschäftsobjekte gespeichert und kann imaufgerufenen System, das den Webservice exponiert, analysiert undgegebenenfalls manuell oder automatisch nachbearbeitet werden.

Fehler- und

Konfliktbehandler

Das Forward Error Handling im AS ABAP wird durch den Fehler-und Konfliktbehandler unterstützt, eine Softwarekomponente, dienicht Teil des AS ABAP ist, sondern nur auf SAP-Business-Suite-Sys-temen ausgeliefert wird. Sie finden Dokumentation zu diesem Toolim SAP Help Portal unter Fehler- und Konfliktbehandler (CA-FS-

ECH).

Das Tool benutzt das Post Processing Office aus dem SAP-Standard,das in jedem AS ABAP enthalten ist, und die lokale IntegrationEngine des AS ABAP. Es ist eine komplette Infrastruktur, die auch fürdie SAP Enterprise Services der SAP Business Suite verwendet wird.Wenn Sie es einsetzen, besitzen Sie ein extrem leistungsfähiges Feh-lermanagement-Tool, benötigen aber eine Person, die die Fehlermel-dungen auswertet und gegebenenfalls eingreift.

Application Integration Framework (AIF)

Der Vollständigkeit halber soll erwähnt werden, dass es mit dem SAPApplication Interface Framework (AIF) noch ein weiteres Tool gibt, dasSie für die Fehler- und Konfliktbehandlung einsetzen können. Da wir indiesem Buch jedoch Wert darauf legen, dass die Services kompatibel zudenen der SAP Business Suite sind, werden wir das AIF nicht vorstellen.

9.5 Konsumieren von Webservices

Im folgenden Abschnitt werden wir den vorher entwickelten Web-service aus dem AS ABAP heraus aufrufen. Das dient dem folgendenZweck:


564

� Sie können damit die Entwicklung testen und sicherstellen, dassSie den Service tatsächlich ansprechen können und auch Testfälle(z.B. als Unit-Tests) implementieren können.

� Sie können synchrone Webservices aufrufen, um vom AS ABAPexterne Systeme (man denke an Spezialanwendungen oder Exper-tensysteme) aufzurufen.

� Sie benötigen diese Techniken für die Entwicklung asynchronerServices. Diese geben das Resultat der Verarbeitung nicht sofortzurück, sondern rufen selbst einen Webservice auf, wofür die inden kommenden Abschnitten beschriebenen Methoden benötigtwerden.

Sie verwenden Konzepte, die Sie in Abschnitt 9.4, »Entwicklungeines Beispiel-Webservice«, kennengelernt haben: Sie werden einProxy-Element sowie Datenelemente generieren, um die »Brücke« zuder SOAP-Runtime des AS ABAP herzustellen.

9.5.1 Aufruf eines externen Webservice

Der Aufruf eines externen Webservices erfolgt über einen sogenann-ten Client-Proxy. Dieser wird aus der WSDL eines Webservice gene-riert. Als Resultat entstehen eine Reihe von Datenelementen und-strukturen sowie ABAP-Klassen, die wir aufrufen können, nachdemeine Konfiguration durch die Transaktion SOAMANGER erfolgt ist.

Entwicklung von

Client-Proxys

Sie können dies wie üblich über den Webservice-Wizard tun, den Siez.B. über die Transaktion SE80 aufrufen können, indem Sie einfachein ABAP-Entwicklungsobjekt anlegen (hier einen Enterprise Ser-vice). Sie rufen den Webservice-Wizard auf, indem Sie in der ABAP-Workbench ein Paket selektieren und im Kontextmenü Anlegen �

Enterprise Service wählen. Wählen Sie im ersten Schritt desWizards Service-Consumer aus (siehe Abbildung 9.6). Das nächsteEingabefeld im Webservice-Wizard sehen Sie in Abbildung 9.22. Siekönnen hier auswählen, aus welcher Quelle die WSDL generiert wer-den soll. Wir wählen an dieser Stelle Externe WSDL.

Im nächsten Bild des Wizards (siehe Abbildung 9.23) können Sie dieQuelle der WSDL auswählen. Dies kann eine UDDI (wie z.B. die Ser-vice Registry von SAP Process Integration) sein, aber auch eine lokaleDatei. Letztere empfiehlt sich, wenn das Entwicklungssystem desService-Consumers keine Verbindung zum externen System besitzt.


565

Abbildung 9.22 Webservice-Wizard für einen Consumer-Proxy

Abbildung 9.23 Auswahl der Quelle für die WSDL


566

Wir können für unser Programmierbeispiel die URL der WSDL ausder Transaktion SPROXY des Service-Providers wählen. Sie finden sieim Reiter WSDL des Service-Provider-Proxys. Wenn Sie auf den But-ton Weiter klicken, öffnet sich ein Dialog zur Eingabe von Paket-name und Generierungspräfix wie beim Anlegen eines Service-Consumers (siehe Abbildung 9.8). Wir wählen hier als Paket ZVHM_CONSUMER mit dem Präfix ZVHMCO_. Wenn Sie dann auf Fertigstellen

gehen, können Sie Anpassungen vornehmen und die generiertenObjekte aktivieren, wie in Abbildung 9.24 zu sehen ist.

Abbildung 9.24 Nachbearbeitung

Anpassung der

Namens der

generierten Objekte

Die Namen der generierten Objekte können Sie an dieser Stelleanpassen, was den späteren Aufruf des Proxys vereinfacht. Wirfügen an dieser Stelle ein Midfix _CO_ bzw. _RQ_ für Confirmationbzw. Request ein und die Postfixe _MT und _MSG für den Message-Typbzw. den zugehörigen Message-Nachrichtentyp.

Nach der Aktivierung wird eine Klasse ZVHMCO_CO_MANAGE_VEHICLE_IN generiert, die von der Klasse CL_PROXY_CLIENT abgeleitet ist. Eswird weiterhin eine Menge von Datentypen und Exception-Klassengeneriert, die für die Serialisierung und Deserialisierung notwendigsind.

Damit Sie den Consumer-Proxy verwenden können, müssen Sie inder Transaktion SOAMANGER einen logischen Port anlegen undaktivieren. Wie üblich können Sie den Service-Consumer in derTransaktion suchen oder für den Service direkt in der TransaktionSE80 bzw. der Transaktion SPROXY den Button SOAMANAGER

starten aufrufen und anschließend in den Reiter Konfigurationen

wechseln und auf Anlegen klicken. Es erscheint dann der Pop-up-Dialog aus Abbildung 9.25.


567

Abbildung 9.25 Anlegen eines logischen Ports

Konfiguration des

Bindings

Hier empfehlen wir Ihnen, eine WSDL-basierte Konfiguration vor-zunehmen. Wie in Abbildung 9.17 zu sehen ist, können Sie die URLfür die WSDL des angelegten Bindings ermitteln, indem Sie imAbschnitt Details von Service-Defintion ZMANAGEVEHICLE_IN

im Reiter Übersicht unter Allgemeine Attribute auf WSDL-Doku-

ment für gewählt. Binding/Service öffnen klicken. Diese URL tra-gen Sie in das Feld URL für WSDL-Zugriff aus Abbildung 9.25 einund ebenso ihren Benutzer sowie das Passwort, um Zugriff auf dieWSDL zu erhalten. Hier bietet sich in produktiven Szenarien ein spe-zieller Benutzer an, der nur für Konfigurationszwecke der Webser-vice-Runtime verwendet wird. Sie können die Konfiguration auchmanuell vornehmen; nähere Informationen hierzu erhalten Sie inder SAP-Bibliothek.

Fallstrick bei der Konfiguration

Wenn Sie an dieser Stelle die falsche WSDL (z.B. die WSDL aus der Design-time wie der Transaktion SE80 oder SPROXY) verwenden, fehlen die Infor-mationen des Bindings. In einem solchem Fall lässt sich kein logischer Portanlegen und Sie werden auf schwerwiegende Fehler zur Laufzeit stoßen,die zu Konfigurations-Exceptions (siehe Listing 9.7) führen und ebenso inder Transaktion SRT_UTIL analysiert werden können. Die entsprechendenFehlermeldungen sind aber bei Weitem nicht selbsterklärend.


568

Ebenso empfehlen wir, die Checkbox Logischer Port ist Standard

rechts oben in Abbildung 9.25 zu aktivieren, denn auf diese Weisebrauchen Sie den Port beim nachfolgend beschriebenen Aufruf nichthart zu kodieren, sondern können ihn direkt verwenden.

Den logischen Port können Sie wie in Listing 9.7 beschrieben auf-rufen.

DATA lr_client_prxy TYPE REF TO zvhmco_co_manage_vehicle_in.DATA ls_request TYPE zvhmco_vehicle_create_rq_mt.DATA ls_confirm TYPE zvhmco_vehicle_create_co_mt.

TRY.CREATE OBJECT lr_client_prxy.

CATCH cx_ai_system_fault .* Hier liegt ein Konfigurationsfehler vorENDTRY.

ls_request-VEHICLE_CREATE_REQUEST-LICENSE_NUMBER ='FOO-BAR'.

ls_request-VEHICLE_CREATE_REQUEST-SEATS = 80.ls_request-VEHICLE_CREATE_REQUEST-STANDING_PLACE = 20.ls_request-VEHICLE_CREATE_REQUEST-YEAR_OF_CONSTRUCTION =

'20120101'.

TRY.CALL METHOD lr_client_proxy->create_vehicleEXPORTING

input = ls_requestIMPORTING

output = ls_confirm.

CATCH cx_ai_system_fault.* Dies ist ein Fehler bei falscher Konfiguration oder* bei der Serialisierung

CATCH zvhmco_cx_standard_message_ft.* Dies ist die Fault-Nachricht

CATCH cx_ai_application_fault.ENDTRY.

Listing 9.7 Aufruf des Client-Proxys

Dieses Codebeispiel ist prototypisch für den SOAP-Aufruf einesexternen Systems.

Behandlung vonSerialisierungsfehlern

In Listing 9.7 sehen Sie eine Fehlerbehandlung der AusnahmeklasseCX_AI_SYSTEM_FAULT. Eine solche Ausnahme kann auftreten, wennder ABAP-Datentyp nicht zur WSDL passt, also z.B. ein negativerWert in ein Feld geschrieben wird, das als nichtnegativ deklariert


569

wurde. Dies ist ein sehr häufiger Fehlerfall, der dadurch kontrolliertwerden kann, dass die zu sendenden Daten validiert werden.Potenzielle Fehler können Sie gegebenenfalls korrigieren, indemSie auf den Reiter Warnung bei der Anzeige des Service Consumersgehen (siehe Abbildung 9.24). Dort sehen Sie Hinweise auf even-tuelle Konvertierungsprobleme, die auch zu Ausnahmen führenkönnen.

9.5.2 Anmerkungen zum LUW-Konzept beim Aufruf von Consumer-Proxys

In synchronen Szenarien gleicht der Aufruf eines Server-Proxys demAufruf eines RFCs: Sie erhalten Daten oder eine Fehlermeldung undkönnen mit diesen weiterarbeiten. Was passiert aber bei unidirekti-onaler Kommunikation wie Informationen und Notifikationen oderbei Rückmeldungen eines asynchronen Webservice?

In einem solchen Fall werden die Meldungen bei einem COMMIT WORKpersistiert, sobald Sie die lokale Integration Engine von ABAP ver-wenden. Dies ist automatisch der Fall, wenn Sie SAP PI in einemIntegrationsszenario benutzen. Es gehen in diesem Fall aber keineNachrichten verloren.

Mögliche

Fehlerursachen

Kann es dennoch zu Fehlern kommen? Dies sollten sehr selteneEreignisse sein, wenn wir die möglichen Fehlerursachen analysieren:

� Eine temporäre Nichterreichbarkeit eines Systems kann man ggf.mit Methoden der SAP NetWeaver PI abfangen.

� Eine mögliche Ursache ist eine fehlerhafte Konfiguration in derTransaktion SOAMANAGER. Diesen Fall können Sie nur durchsorgfältiges Testen der Konfiguration bei Änderungen der System-konfiguration ausschließen.

� Ein weiterer Fall besteht darin, dass ein Systemfehler oder ein Pro-grammierfehler auftritt. Einen solchen Fall können Sie nur durchTests – insbesondere der Serialisierung der möglichen Eingabepa-rameter – ausschließen.

Zusammengefasst lässt sich also Folgendes sagen: Einen stabilenBetrieb können Sie ausschließlich durch die zentrale Konfigurationund administrative Tätigkeiten nach Änderungen der Systemland-schaft durch Tests sicherstellen. Wenn dennoch Probleme auftauchen,


570

gibt es nur zwei Möglichkeiten: Wenn eine Ausnahme in Listing 9.7aufritt, können Sie den Aufruf durch ein selbst erstelltes Event derWorkflow-Runtime speichern und asynchron erneut ausführen lassen(siehe Abschnitt 4.6.3, »Ereignisbasierte Schnittstellen«), wenn dieFehlerursache behoben ist. Bei asynchronen Webservices könnten Sieauch das sogenannte Forward Error Handling verwenden, um dieRückmeldung zu korrigieren und erneut zuzustellen (siehe Abschnitt9.4.4, »Weitere Implementierungsdetails von Webservices«).

9.5.3 Service-Gruppen

Service-Gruppen lassen sich verwenden, um mehrere Service-Consu-mer gemeinsam zu konfigurieren. Dies ist notwendig, wenn Sie dieKommunikation Ihrer Anwendung mit einer oder mehreren Serviceseiner externen Anwendung gemeinsam konfigurieren wollen. Hier-für können Sie eine Service-Gruppe ZVHMCO_EXTERNAL anlegen, wie inAbbildung 9.26 zu sehen ist.

Abbildung 9.26 Anlegen einer Service-Gruppe


571

Im Anschluss können Sie dann der Service-Gruppe einzelne Service-Consumer zuordnen, wie in Abbildung 9.27 zu sehen ist.

Abbildung 9.27 Zuordnung von Service-Consumern

Im Anschluss wird nach dem Aktivieren automatisch eine KlasseZCL_ZHCMCO_EXTERNAL_GEN generiert. Für die Benutzung dieser Klassesei auf die Programmierbeispiele im SAP Help Portal verwiesen, dieSie unter Mit dem SOAMANAGER arbeiten � Service-Provider und

Service-Consumer konfigurieren � Mit Service-Gruppen arbeiten �

API für technische Empfängerermittlung � API für technische

Empfängerermittlung: Quelltext-Beispiele finden. Die Erzeugungder Service-Gruppe ist nur gewinnbringend, wenn sie auch im sen-derseitigen Coding verwendet wird.

9.5.4 Weitere Funktionen der Transaktion SOAMANAGER

Bisher haben wir die Transaktion SOAMANAGER zur Konfigurationvon einzelnen Services verwendet. Der SOA-Manager hat sich wei-terentwickelt und besitzt zusätzlich einen WSDL-Analyzer zum Prü-fen von WSDL, für die man z.B. einen Proxy-Client generierenmöchte. Er ist ebenso ein Tool für die Massenänderung von Bindingssowie zur Verwaltung von Logs und Traces. Der AS ABAP enthältauch eine Service-Registry, die man über die Transaktion SOAMA-NAGER ansprechen kann. Diese ist allerdings nicht UDDI-konform.Die wichtigsten UDDI-Funktionen sind aber inzwischen ab Release7.02 verfügbar, wie in den SAP-Hinweisen 1911359, 1911360 und1918800 beschrieben ist.

Ab SAP NetWeaver 7.31 kommt der Health-Check-Lauf hinzu, derim SAP Community Network unter der URL http://scn.sap.com/community/abap/connectivity/blog/2013/08/13/are-your-abap-systems-healthy beschrieben wurde. Weitere Verbesserungen werden entwi-ckelt.


572

9.6 Weitere Themen

Sie haben in den vorangegangenen Abschnitten die zugrunde liegen-den Webservice-Standards, Tools und Programmiermodelle kennen-gelernt. Im folgenden Abschnitt sollen noch ergänzende Technikenerklärt werden. Außerdem stellen wir Ihnen einige Best Practiceszum Test von Webservices vor und listen die wichtigsten Transakti-onen für Sie auf.

9.6.1 Nutzung des Enterprise Services Repository

In diesem Kapitel haben wir gesehen, wie Enterprise Services mitdem MDR entwickelt werden können. Welche Gründe kann esgeben, das ESR zu verwenden? Derzeit ist das ESR noch komfortablerals das MDR. Ein weiterer Grund ist, dass sie mit dem ESR auch Ser-vice-Definitionen erstellen können, die in Nicht-AS-ABAP-Systemenetabliert werden. Für die Definition von Services im Rahmen einerunternehmensweiten SOA ist das Tool besonders im Zusammenhangmit SAP Process Integration die bessere Wahl:

SAP versucht, für verschiedene Kundengruppen Lösungen zu bieten.Während große Kunden immer ein Process-Integration-System zurVerfügung haben, haben kleinere SAP-Kunden häufig keinen SAP-Java-Stack im Einsatz, und damit auch kein ESR. Das MDR ist fürdiese Kunden sicher eine gute Wahl, da der Gesamtaufwand durchdie Integration des MDR in der ABAP Workbench für diese Kundenviel geringer wird.

Entwicklung im ESR Wenn Sie Web Services im ESR entwickeln möchten, empfehlen wirIhnen das Buch Entwicklung von Enterprise Services für SAP (2009)von Thomas Pohl und Markus Peter, das ebenfalls bei SAP PRESSerschienen ist. Dort wird auch die Generierung von Proxy-Elemen-ten ebenso wie Namenskonventionen, die sie in Ihrer Entwicklungexplizit verwenden sollten, beschrieben. Die Vorgehensweise ähneltdem der Generierung von Consumer-Proxys, die wie in Abschnitt9.5.1, »Aufruf eines externen Webservice«, beschrieben abläuft: Zueiner externen Definition, die im ESR vorliegt, werden zahlreicheElemente generiert. Am Ende entsteht neben diesen Datentypenauch eine Proxy-Klasse, die wie für die Implementierungsklasse inAbschnitt 9.4.2, »Durchführung der Implementierung«, beschrie-ben, angelegt wird.

Weitere Themen 9.6

573

SWCV-Versionen

und Software-

komponenten

An dieser Stelle möchten wir noch einmal auf den Zusammenhangzwischen den Software-Komponentenversionen (SWCV) des ESRund den Softwarekomponenten des AS ABAP hinweisen. Die Emp-fehlung lautet, dass die SCVWs genau den Softwarekomponentender ABAP-Entwicklung entsprechen sollten, in denen auch die Pro-xys generiert werden. Ebenso sollen ESR-Datentypen gegebenenfallsredundant in jeder SWCV angelegt werden.

Der Grund ist, dass bei der Entwicklung im ESR eine Menge Proxy-Datenelemente generiert werden. Bei der Generierung werden dieProxy-Datenelemente wiederverwendet, wenn sie denselben XML-Namensraum besitzen und im ABAP-Backend derselbe Namensraumbei der Generierung verwendet wird. Das kann dazu führen, dass beider Generierung ein Service-Provider-Proxy Datenelemente verwen-det, die in einer anderen Softwarekomponente liegen, was zu einemInstallationsfehler führt.

9.6.2 Inside-Out-Entwicklung

Die bisher verwendeten Methoden, um Webservice-Provider zuerstellen, setzten immer voraus, dass der Webservice mit einemModellierungstool wie dem ESR oder MDR erstellt wurde. Es gibtaber auch eine weitere Möglichkeit, Webservices aus einzelnenFunktionsbausteinen zu generieren, um ihre Funktionalität auf dieseWeise zu exponieren.

Beispiel für die

Inside-Out-

Entwicklung

Im folgenden Beispiel exponieren wir ein Standard-BAPI BAPI_BUPA_CENTRAL_GETDETAIL als Webservice. Wir öffnen in der TransaktionSE80 die Funktionsgruppe BUBA_3, markieren den Funktionsbausteinund gehen im Kontextmenü auf Anlegen � Enterprise Service. Eserscheint ein Wizard, in dem Sie zuerst den Namen und eineBeschreibung eingeben. Nach einem Klick auf den Button Weiter

können Sie durch das Flag Namen zuordnen die Namen im WSDL-Dokument etwas kanonischer in CamelCase-Notation generieren las-sen. Im nächsten Schritt können Sie das Sicherheitsprofil definierenund dann zur Nachbearbeitung übergehen, die in Abbildung 9.28 zusehen ist.

Die wichtigsten Schritte der Nachbearbeitung sind die Klassifizie-rung (also die Angabe von Name/Wert-Paaren, anhand derer Sie denService finden können, wenn Sie den Service in einer UDDI expo-


574

niert haben) sowie die Anpassung der Parameter, wie in Abbildung9.28 zu sehen ist. Hier können Sie die Namen der Parameter än-dern, Parameter aus der Schnittstelle herausnehmen (also nicht ex-ponieren), als optional kennzeichnen und Standardwerte (Defaults)eintragen.

Abbildung 9.28 Nachbearbeitung eines Inside-Out-Webservice

Diese Vorgehensweise hat bei der Integration externer Systemegegenüber RFCs einige Vorteile – insbesondere wegen der Möglich-keit, Parameter als optional zu kennzeichnen. Zusätzliche Vorteilesind diejenigen, die jeder Webservice besitzt: standardisierte Bereit-stellung der Schnittstelle, die es ermöglicht, mit Nicht-SAP-Systemenzu kommunizieren, sowie die erweiterten Security Features.

9.6.3 Service Implementation Workbench

Der Inside-Out-Ansatz hat den Nachteil, dass wesentliche Qualitäts-kriterien von Enterprises Services aber auch Webservice-Standardsnicht umgesetzt werden können. Ebenso können keine Webservice-Protokolle wie WS-RM instanziiert bzw. abgefragt werden. Somitkann z.B. kein Extended XML-Handling verwendet werden. Wenn

Weitere Themen 9.6

575

Sie Update- oder idempotente Services umsetzen wollen oder ein-heitliche Datentypen benutzen möchten, können Sie die ServiceImplementation Workbench verwenden, die im SAP Help Portal unterService Implementation Workbench (BC-ESI-SIW) beschriebenwird und ab Release 7.31 vorhanden ist. Sie können sie auf zwei ver-schiedene Arten verwenden:

� Sie können aus BAPIs Enterprise Services generieren. Hierbei wirdauch automatisch ESR-Content generiert ebenso wie das Mappingvon ABAP- auf ESR-Datentypen.

� Sie können im ESR oder MDR generierte Proxys schneller imple-mentieren. Dabei wird Code generiert, und es können Templatesgewählt werden, um die Frameworks des SAP-Standards – wie z.B.den Fehler- und Konfliktbehandler oder das Idempotenz-Frame-work – einzubinden (siehe Abschnitt 9.4.4, »Weitere Implemen-tierungsdetails von Webservices«).

Der Einsatz der Service Implementation Workbench lohnt sich,wenn Sie viele Services erstellen und die gleichbleibende Qualitätund Nutzung von Frameworks sicherstellen wollen.

9.6.4 Versionierung von Webservices

Wenn Sie Webservices exponieren, werden diese von einer Reihevon Clients verwendet, die bei einer inkompatiblen Änderung alleangepasst werden müssen. Dies ist schwierig, weswegen Sie Serviceskompatibel weiterentwickeln sollten, sodass Clients nicht angepasstwerden müssen. Diese Kompatibilität wird erreicht, wenn in derWSDL nur optionale Elemente hinzukommen und die übertragenenDaten auch weiterhin gültig sind. Das ist zum Beispiel der Fall, wennsich die Länge von Feldern nur vergrößert, aber nicht verkürzt.

9.6.5 Test von Webservices

Sie können Webservices auf verschiedene Arten testen. Wenn Sieeinen Proxy samt Implementierung angelegt haben, empfiehlt sichein manueller Test über den Button Test ((F8)). Anschließend öffnetsich der Dialog, der in Abbildung 9.29 gezeigt wird, und Sie könnenmit ihm einen lokalen Aufruf durchführen, auch ohne dass der Ser-vice durch die Transaktion SOAMANAGER exponiert wurde.


576

Abbildung 9.29 Test eines Service-Providers

Sie können den Aufruf von Webservices auch über das eCATT-Tooldes AS ABAP testen oder externe Testtools verwenden, die sich z.B.für Regressionstests eignen.

ABAP Unit Test Für den fachlichen Test der Implementierungsklasse bieten sichABAP Unit Tests an. Die Techniken, die für einen Aufruf vonProxys ohne zwingendes Exponieren mit der Transaktion SOA-MANAGER erforderlich sind, werden im SCN-Wiki unter der URLhttp://wiki.sdn.sap.com/wiki/display/ABAPConn/Configuration-less+Shortcut+and+Generic+Consumer+Proxy beschrieben und stehen über eineAPI der Klasse CL_SRT_PUBLIC_FACTORY bzw. der Methode GET_LOCAL_SHORTCUT_HANDLER( ) zur Verfügung.

Generell sind Webservices eine robuste Technologie, und bei derFehleranalyse werden Ihnen folgende SAP-Hinweise weiterhelfen:

� SAP-Hinweis 1292171 (Leitfaden zur Fehlerbehebung: ABAPWebservices Runtime)

� SAP-Hinweis 1319507 (Übersicht: Analyse der ABAP-Web-Ser-vice-Konfiguration)

� SAP-Hinweis 1324884 (Analyse der ABAP-Web-Service-SOA-Kon-figuration)

Weitere Themen 9.6

577

Des Weiteren sind die beiden folgenden Wiki-Einträge sehr hilf-reich:

� http://wiki.scn.sap.com/wiki/display/TechTSG/Web+Services+ABAP

� http://wiki.scn.sap.com/wiki/display/TechTSG/Various+errors+for+WSDL+based+LP+creation

9.6.6 Informationen zu weiteren Themen

Die Webservice-Infrastruktur des AS ABAP ist sehr umfangreich,und es gibt Themen, die wir in diesem Buch nicht ansprechen kön-nen und für die wir auf weitere Quellen, u.a. das SAP Help Portalverweisen:

� Bei der Kommunikation zwischen AS-ABAP-Systemen wird derWS-RM-Standard unterstützt. Sie können auf diese Weise mehrereWebservice-Aufrufe an eine LUW binden und sogar eine auszu-führende Reihenfolge für die Serviceaufrufe festlegen. WeitereInformationen zu diesem Programmiermodell finden Sie im SAPHelp Portal unter Service-Provider und Service-Consumer anle-

gen und konfigurieren � Web-Service konsumieren � Program-

mieren mit Sequenzen.

� Es existiert ein Erweiterungsmodell für Enterprise Services. WennSie eine Anwendung der SAP Business Suite erweitern, ist dieErweiterung der vorhandenden Enterprise Services immer eineOption. Weitere Informationen finden Sie im Enterprise ServiceEnhancement Guide (siehe http://scn.sap.com/docs/DOC-18402).

� Die zulässigen Werte von Datentypen lassen sich oft nicht in einerWSDL definieren, da die zulässigen Werte im Customizing hinter-legt sind. Sie können zulässige Werte für Proxy-Datenelementefestlegen und als sogenannte Codelisten festlegen und durch denEnterprise Service QueryCodeList abfragen. Dies ist in dem BuchEntwicklung von Enterprise Services für SAP (2009) beschrieben, dasebenfalls bei SAP PRESS erschienen ist.

9.6.7 Wichtige Transaktionscodes

In Tabelle 9.1 finden Sie die wichtigsten Transaktionscodes, die indiesem Kapitel verwendet wurden.


578

Transaktionscode Beschreibung

SOAMANAGER SOA Manager

SPROXY Enterprise Services Browser

SPROXY_START Webservice Proxy Editor

SRT_ADMIN Technische Konfiguration der SOAP Runtime

SRT_MONI Hilfsmittel für Webservices: Message Monitor

SRT_MONIS WS-Sequenz Monitor

SRT_UTIL Hilfsmittel für Webservices

SXMB_MONI Integration Engine: Monitoring

Tabelle 9.1 Wichtige Transaktionscodes

7

Inhalt

Geleitwort ................................................................................. 19Vorwort .................................................................................... 21Einleitung .................................................................................. 23

1 Entwurf von Anwendungssystemen ........................ 31

1.1 Anforderungen ....................................................... 321.1.1 Anforderungsanalyse als Prozess ................ 321.1.2 Funktionale Anforderungen ....................... 331.1.3 Nichtfunktionale Anforderungen ............... 341.1.4 Grenzbereich funktionaler und

nichtfunktionaler Anforderungen ............... 431.1.5 Systemspezifikation ................................... 46

1.2 Allgemeine architektonische Überlegungen ............. 491.2.1 Produktfamilien: Trennung von

Rahmen und Inhalt .................................... 491.2.2 Metadaten ................................................ 541.2.3 Generative Programmierung ...................... 561.2.4 Modellgetriebene Architekturen ................ 58

1.3 Verwendung des SAP-Standards ............................. 59

2 Anwendungsobjekt ................................................. 61

2.1 Was ist ein Anwendungsobjekt? ............................. 622.2 Modellierung des Anwendungsobjektes

auf Datenbankebene ............................................... 662.2.1 Strukturiertes Entity-Relationship-

Modell ...................................................... 672.2.2 Datenmodellierung auf

ABAP-Dictionary-Ebene ............................ 712.3 Realisierung der Objektpersistenz ........................... 88

2.3.1 Notwendigkeit von Datenbank-Zugriffsschichten ..................... 88

2.3.2 Object Services .......................................... 932.3.3 Vererbung persistenter Klassen .................. 992.3.4 Zugriff auf abhängige Tabellen ................... 1022.3.5 Query-Dienst ............................................. 105

Inhalt

8

2.3.6 Entwicklung eines eigenen Persistenzdienstes ...................................... 106

2.3.7 Business Object Processing Framework ...... 1072.3.8 BAPI-Zugriffsmethoden .............................. 115

2.4 Transaktionskonzept ................................................ 1162.4.1 Spezielle Techniken des klassischen

Transaktionskonzeptes ............................... 1202.4.2 Objektorientiertes Transaktionskonzept ..... 121

2.5 Best Practices .......................................................... 1232.5.1 Bildung von Primärschlüsseln ..................... 1232.5.2 Modellierung des Anwendungsobjektes

im ABAP Dictionary ................................... 1252.5.3 Service-Funktionen für persistente Objekte 1252.5.4 Speicherung un- und

semistrukturierter Daten ............................ 1292.5.5 Performante Datenbankzugriffe .................. 1322.5.6 Weiterführende Überlegungen ................... 1332.5.7 Wichtige Transaktionen .............................. 134

3 Klassen, Interfaces und Ausnahmen ....................... 135

3.1 Vorteile von ABAP Objects ...................................... 1373.1.1 Definition von Konstanten in Klassen

und Interfaces ............................................ 1373.1.2 Funktionsgruppen versus Objekte .............. 1383.1.3 Events ........................................................ 138

3.2 Ausnahmen ............................................................. 1393.2.1 Klassische und objektorientierte

Ausnahmen ................................................ 1403.2.2 Assertions .................................................. 1423.2.3 Ausnahmebehandlung ................................ 144

3.3 Grundprinzipien des objektorientierten Entwurfs ..... 1453.3.1 Umkehrungen von Abhängigkeiten ............ 1463.3.2 Open-Closed-Prinzip .................................. 1473.3.3 Vererbung und das Substitutionsprinzip ..... 1493.3.4 Testbarkeit durch Unit-Tests ...................... 151

3.4 Klassische Modularisierungseinheiten ...................... 1533.4.1 Funktionsbausteine .................................... 1543.4.2 Reports ...................................................... 154

3.5 Best Practices .......................................................... 156

Inhalt

9

3.5.1 Allgemeine Überlegungen zum objektorientierten Entwurf ........................ 156

3.5.2 Wichtige Transaktionen ............................. 158

4 Anwendungsarchitektur .......................................... 159

4.1 Anforderungen an die Anwendungsarchitektur ....... 1594.2 Softwarestrukturierung aus Sicht der

Softwaretechnik ...................................................... 1614.3 Wie strukturiert man ein Softwaresystem? .............. 165

4.3.1 Strukturierung nach fachlichen und technischen Kriterien .......................... 165

4.3.2 Identifizierung von Schichten .................... 1694.3.3 Zerlegung in Teilanwendungen .................. 1704.3.4 Schaffung von Basiskomponenten .............. 1714.3.5 Abhängigkeit vom SAP-Standard ............... 1724.3.6 Strukturierung der Beispielanwendung ...... 172

4.4 Paketkonzept .......................................................... 1744.4.1 Paketschnittstellen und Prüfungen ............. 1764.4.2 Sichtbarkeit von Paketschnittstellen ........... 1794.4.3 Strukturpakete und

SAP-Softwarekomponenten ....................... 1794.4.4 Durchführung von Paketprüfungen ............ 1834.4.5 Exkurs: Kompatibilitätsprobleme ............... 1844.4.6 Exkurs: Namenskonventionen und

Namensräume ........................................... 1864.5 Komposition von Paketen ....................................... 1894.6 Laufzeitkonfiguration von Softwarekomponenten ... 190

4.6.1 Realisierung von Schnittstellen durch Erweiterungen ........................................... 195

4.6.2 Schaltbare Erweiterungen – das Switch Framework ................................................ 199

4.6.3 Ereignisbasierte Schnittstellen ................... 2044.7 Best Practices .......................................................... 212

4.7.1 Architekturdokumentation ........................ 2134.7.2 Eigenschaften der Paketzerlegung .............. 2144.7.3 Schnittstellenkonzeption ........................... 2164.7.4 Paketprüfungsmodus ................................. 2184.7.5 Auslieferung von Softwarekomponenten ... 2204.7.6 Einführung des Paketkonzepts ................... 220

Inhalt

10

4.7.7 Operationales Paketkonzept ....................... 2214.7.8 Wichtige Transaktionen .............................. 222

5 Anwendungsschicht ................................................ 223

5.1 Anwendungslogik .................................................... 2245.1.1 Realisierung des Anwendungsobjektes ....... 2265.1.2 Trennung von Objekt und Prozess .............. 229

5.2 Customizing ............................................................ 2325.2.1 Grundlagen ................................................ 2335.2.2 Technisches Customizing ............................ 235

5.3 Suchdienste ............................................................. 2405.4 Workflows ............................................................... 245

5.4.1 Beispielszenario: Wiedervorlage zu einem bestimmten Termin .................................... 247

5.4.2 Wichtige Transaktionen .............................. 2635.5 Geschäftsregeln mit BRFplus .................................... 263

5.5.1 Implementierung von Geschäftsregeln ........ 2655.5.2 Entwicklung von Geschäftsregeln

mit BRFplus ............................................... 2665.5.3 Aufruf einer BRFplus-Funktion in ABAP ...... 2815.5.4 Architektur von regelbasierten

Anwendungen ............................................ 2845.5.5 Best Practices ............................................. 2865.5.6 Zusammenfassung ...................................... 2885.5.7 Wichtige Transaktionen .............................. 289

6 GUI-Programmierung .............................................. 291

6.1 Überblick über die UI-Technologien von SAP .......... 2926.2 Ergonomiebeispiele und Dialogstandards ................ 294

6.2.1 SAP R/3 Style Guide ................................... 2946.2.2 Ergonomiebeispiele .................................... 2956.2.3 Menüstandards .......................................... 2966.2.4 Bildaufbau und Benutzerführung ................ 296

6.3 Tabellenpflegedialoge .............................................. 3026.3.1 Generierung und Erweiterung von

Tabellenpflegedialogen .............................. 3036.3.2 Tipps zum Umgang mit Pflege-Views ......... 312

6.4 Bereichsmenüs ........................................................ 3146.5 Objektorientierte Dynpro-Programmierung ............. 316

Inhalt

11

6.5.1 Pro und contra Subscreens ........................ 3166.5.2 Subscreens als Modularisierungseinheit ..... 3176.5.3 Kapselung mit Dynpros ............................. 3186.5.4 Message Handling mit Dynpros ................. 3186.5.5 Das BUS-Screen-Framework ...................... 3196.5.6 Vorzüge objektorientierter Dynpros ........... 3216.5.7 Verwendungen des

BUS-Screen-Frameworks ........................... 3226.5.8 Normale Dynpros und modale

Dialogfenster ............................................. 3226.5.9 Ablauflogik definieren ............................... 3246.5.10 Instanzen erzeugen .................................... 3256.5.11 Dynpro aufrufen ........................................ 3266.5.12 Reihenfolge der

Verarbeitungszeitpunkte ............................ 3266.5.13 Eigene Dynpro-Logik definieren ................ 3286.5.14 Titel und GUI-Status setzen ....................... 3286.5.15 Benutzereingaben behandeln .................... 3286.5.16 Fehlermeldungen sammeln

und ausgeben ............................................ 3326.5.17 Anbindung des Business

Application Logs ........................................ 3356.5.18 Table Controls und ALV-Grids ................... 3376.5.19 Dynpros mit Subscreen-Areas .................... 3386.5.20 Subscreens definieren ................................ 3406.5.21 Datentransport zwischen Dynpro-Feldern

und Dynpro-Klasse .................................... 3416.5.22 Tabstrips ................................................... 3426.5.23 Für Fortgeschrittene: Selektionsbilder

und Dynpro Painter ................................... 3486.5.24 Selektionsbilder in Verbindung mit dem

BUS-Screen-Framework ............................. 3546.5.25 Ausblick .................................................... 359

6.6 Web Dynpro ABAP ................................................. 3596.6.1 Grundlagen ............................................... 3606.6.2 Erstellung einer Beispielanwendung ........... 3636.6.3 Web-Dynpro-ABAP-Konfigurations-

Framework ................................................ 3706.6.4 Beispiel für eine modifikationsfreie

Erweiterung durch Konfiguration ............... 374

Inhalt

12

6.7 Floorplan Manager .................................................. 3806.7.1 Grundrisse .................................................. 3816.7.2 Generische und andere UIBBs .................... 3826.7.3 Feeder-Klassen ........................................... 3856.7.4 Floorplan Manager und Konfigurations-

Framework ................................................. 3876.8 Herausforderung der Dialogintegration .................... 3886.9 SAP NetWeaver Business Client ............................... 391

6.9.1 Desktop- und HTML-Client ........................ 3916.9.2 Index-Seite ................................................. 3926.9.3 Side Panel .................................................. 393

6.10 Best Practices .......................................................... 3986.10.1 Wahl der richtigen GUI-Technologie .......... 3986.10.2 Softwaretechnische Aspekte ....................... 3986.10.3 Wichtige Transaktionen .............................. 3996.10.4 Wichtige Web-Dynpro-Anwendungen ....... 400

7 SAP-Geschäftspartner ............................................. 401

7.1 Hintergrundinformationen ....................................... 4017.1.1 Entstehung des SAP-Geschäftspartners ....... 4027.1.2 Konzeptueller Überblick ............................. 4037.1.3 Erster Eindruck ........................................... 404

7.2 Erweiterung des SAP-Geschäftspartners ................... 4067.2.1 Beispiel für eine Erweiterung ...................... 4067.2.2 Anwendung pflegen ................................... 4087.2.3 Datenset pflegen ........................................ 4097.2.4 Tabellen pflegen ......................................... 4097.2.5 Feldgruppen pflegen .................................. 4107.2.6 Sichten (Transaktion BUS3) ........................ 4107.2.7 Abschnitt (Transaktion BUS4) ..................... 4127.2.8 Bilder (Transaktion BUS5) ........................... 4127.2.9 Bildfolgen (Transaktion BUS6) .................... 4147.2.10 GP-Sichten (Transaktion BUSD) .................. 4147.2.11 Rollentyp und Rolle anlegen ...................... 4147.2.12 Funktionsgruppe »ZVHM_BUPA« ............... 4167.2.13 Aufbau des Dynpros 0100 .......................... 4187.2.14 Zeitpunkte ................................................. 4187.2.15 BDT-Namenskonventionen ........................ 4317.2.16 Test der Erweiterung .................................. 432

Inhalt

13

7.2.17 Fehlersuche ............................................... 4337.2.18 Zusammenfassung ..................................... 436

7.3 Erweiterung des SAP Locators ................................. 4377.3.1 Einführung in den SAP Locator .................. 4377.3.2 Ziel der Erweiterung .................................. 4387.3.3 Transaktion LOCA_CUST ........................... 4397.3.4 Definition der Hierarchie ........................... 4407.3.5 Append-Suchhilfe anlegen ......................... 4427.3.6 Elementare Suchhilfe anlegen .................... 4427.3.7 Suchhilfe zur Append-Suchhilfe

zuordnen ................................................... 4437.3.8 Funktionsgruppe anlegen .......................... 4447.3.9 Such-Dynpro anlegen ................................ 4447.3.10 Formroutine zum Initialisieren

der Suche .................................................. 4467.3.11 Formroutine zum Holen der Suchfelder ..... 4477.3.12 Formroutine zum Setzen der Suchfelder .... 4477.3.13 Formroutine zum Erzeugen des

Dynpro-Objektes ....................................... 4487.3.14 Funktionsbaustein anlegen ........................ 4497.3.15 Lokale Suchklasse anlegen ......................... 4507.3.16 Suche-ID im Locator-Customizing

bekannt machen ........................................ 4527.3.17 Suche testen .............................................. 4537.3.18 Zusammenfassung ..................................... 453

7.4 Geschäftspartner in SAP Master Data Governance .................................................... 454

7.5 Wichtige Transaktionen .......................................... 458

8 Techniken der Anwendungsprogrammierung ......... 459

8.1 Realisierung des Anwendungsprotokolls ................. 4608.1.1 Adressat der Protokolle ............................. 4618.1.2 Protokollrecherche als Geschäftsprozess .... 4618.1.3 Business Application Log (BAL) .................. 4648.1.4 Datenmodell des BAL ................................ 4648.1.5 Entwicklerschnittstelle ............................... 4658.1.6 Beispiel: Protokoll erzeugen

und anzeigen ............................................. 4668.1.7 Beispiel: Protokoll speichern ...................... 468

Inhalt

14

8.1.8 Transaktionskonzept .................................. 4698.1.9 Protokolle anreichern ................................. 4728.1.10 Komplexe Zusatzdaten speichern ............... 4808.1.11 Weitere Callbacks in der Anzeige nutzen .... 4828.1.12 Benutzerdefinierte Buttons ......................... 4838.1.13 Protokolle löschen und archivieren ............. 4848.1.14 Zusammenfassung und weiterführende

Informationen ............................................ 4848.2 Anwendungen parallelisieren ................................... 485

8.2.1 Anwendungsfall ......................................... 4858.2.2 Voraussetzungen ........................................ 4888.2.3 Asynchroner Remote Function

Call (aRFC) ................................................. 4928.2.4 Parallelisierung mit Hintergrundjobs ........... 5048.2.5 Parallelisierung mit dem PV-Tool

BANK_PP_JOBCTRL ................................... 5068.2.6 Zusammenfassung ...................................... 5128.2.7 Weiterführende Informationen ................... 513

8.3 Wichtige Transaktionen ........................................... 514

9 Entwicklung von Webservices ................................ 515

9.1 Überblick über die Konnektivitätstechnologien des AS ABAP ........................................................... 5169.1.1 Weiterentwicklung der RFC-Technologie .... 5179.1.2 OData für moderne Webanwendungen und

leichtgewichtige Integrationsszenarien ....... 5189.1.3 Stärken von Webservices ............................ 5189.1.4 Legacy-Technologien .................................. 5219.1.5 Rolle der SAP Process Integration ............... 5219.1.6 Zusammenfassung ...................................... 523

9.2 Grundlagen zu Webservices ..................................... 5259.2.1 Einführung in die grundlegenden

Standards ................................................... 5259.2.2 Unterstützte Standards und

Interoperabilität ......................................... 5269.2.3 SOAP-Runtime der ABAP-Plattform ........... 528

9.3 Modellierung von Webservices ................................ 5289.3.1 Modellierung von

Webservice-Signaturen .............................. 530

Inhalt

15

9.3.2 Kommunikationsmuster und Standards für Datentypen .......................................... 535

9.3.3 Eigene XML-Namensräume bei der Modellierung ....................................... 536

9.4 Entwicklung eines Beispiel-Webservice ................... 5389.4.1 Entwicklung von Enterprise Services mit

dem Metadata Repository ......................... 5389.4.2 Durchführung der Implementierung .......... 5509.4.3 Konfiguration des Webservice mit dem

SOAMANAGER ......................................... 5549.4.4 Weitere Implementierungsdetails von

Webservices .............................................. 5589.5 Konsumieren von Webservices ............................... 563

9.5.1 Aufruf eines externen Webservice .............. 5649.5.2 Anmerkungen zum LUW-Konzept

beim Aufruf von Consumer-Proxys ............. 5699.5.3 Service-Gruppen ........................................ 5709.5.4 Weitere Funktionen der Transaktion

SOAMANAGER ......................................... 5719.6 Weitere Themen ..................................................... 572

9.6.1 Nutzung des Enterprise Services Repository ................................................. 572

9.6.2 Inside-Out-Entwicklung ............................. 5739.6.3 Service Implementation Workbench .......... 5749.6.4 Versionierung von Webservices ................. 5759.6.5 Test von Webservices ................................ 5759.6.6 Informationen zu weiteren Themen ........... 5779.6.7 Wichtige Transaktionscodes ...................... 577

10 Anwendungsentwicklung mit SAP HANA ............... 579

10.1 Einsatzszenarien für SAP HANA .............................. 58010.1.1 Anpassung bestehender Anwendungen

an SAP HANA ............................................ 58010.1.2 Neue Anwendungen für SAP HANA

entwickeln ................................................. 58110.1.3 Abwärtskompatible SAP-HANA-

Anwendungen entwickeln ......................... 58110.1.4 Side-by-Side-Anwendungen entwickeln .... 582

10.2 Besonderheiten von SAP HANA .............................. 58310.2.1 Spaltenorientierung ................................... 583

Inhalt

16

10.2.2 Schnelle Rechen-Engine ............................. 58310.2.3 Besondere Funktionen ............................... 585

10.3 Analysewerkzeuge für die Codeoptimierung ............ 58810.3.1 Abgleich nach einem Release-Upgrade ....... 58910.3.2 Unicode-Prüfungen .................................... 59010.3.3 Code Inspector ........................................... 59110.3.4 Systemlastanalyse ....................................... 59210.3.5 SQL-Monitor .............................................. 59310.3.6 Arbeitsvorrat für SQL-Optimierung ............ 59510.3.7 Weitere Analysewerkzeuge ........................ 596

10.4 Architekturempfehlungen für den Entwurf neuer Anwendungen ......................................................... 59710.4.1 Hybrider Charakter der Anwendung ........... 59710.4.2 Datenbanknahes Programmiermodell ......... 60010.4.3 Kapselung .................................................. 60110.4.4 Erweiterbarkeit beachten ........................... 602

10.5 Architekturempfehlungen für abwärtskompatible Anwendungen ......................................................... 60310.5.1 Nichtfunktionale Anforderungen

priorisieren ................................................. 60410.5.2 Funktionsliste mit und ohne

SAP HANA aufstellen ................................. 60510.5.3 Fallunterscheidung realisieren .................... 606

10.6 Architektur von Side-by-Side-Anwendungen ........... 60710.6.1 Einsatzfelder von Side-by-Side-

Szenarien ................................................... 60810.6.2 Datenreplikation ........................................ 60810.6.3 Technik für den Zugriff ............................... 61110.6.4 Optionales Sidecar ..................................... 612

10.7 Transaktionale Anwendungen und Analytik ............. 61310.8 Praxisbeispiel ........................................................... 617

10.8.1 Voraussetzungen ........................................ 61710.8.2 InfoSet anlegen .......................................... 61810.8.3 InfoSet verwenden ..................................... 62010.8.4 Fazit des Anwendungsbeispiels .................. 625

10.9 Zusammenfassung ................................................... 62510.10 Wichtige Transaktionen ........................................... 626

Inhalt

17

11 Informationsquellen in der Projektplanungs- und Realisierungsphase .................................................. 629

11.1 SAP Service Marketplace ........................................ 62911.1.1 SAP Help Portal ......................................... 62911.1.2 SAP Support Portal .................................... 63211.1.3 SAP Community Network .......................... 63311.1.4 SAP Learning Hub und weitere

Trainingsplattformen ................................. 63411.2 ABAP-Schlüsselwortdokumentation ........................ 63411.3 SAP Design Guild .................................................... 63511.4 Innenleben des AS ABAP ........................................ 636

11.4.1 Debuggen ................................................. 63611.4.2 Informationsquellen im SAP-System .......... 63711.4.3 Laufzeitanalyse .......................................... 63911.4.4 Datenbank-Trace ....................................... 64211.4.5 Umfeldermittlung ...................................... 643

11.5 Wissensmanagement .............................................. 64411.6 Wichtige Transaktionen .......................................... 647

12 Management von Entwicklungsprojekten .............. 649

12.1 Rollen in Entwicklungsprojekten ............................. 64912.1.1 Rolle des Chefdesigners ............................. 65012.1.2 Frameworks und Tools .............................. 650

12.2 Qualitätsmanagement ............................................. 65112.2.1 Risikomanagement .................................... 65212.2.2 Entwicklungsrichtlinien .............................. 65312.2.3 Code Inspections und Erweiterung des

Code Inspectors ......................................... 65512.2.4 Dokumentation anlegen ............................ 66512.2.5 Prüfung freischalten ................................... 66612.2.6 Softwaretest .............................................. 66612.2.7 Dokumentation ......................................... 66812.2.8 Wartung von Anwendungen ...................... 67112.2.9 Wichtige Transaktionen ............................. 672

Inhalt

18

Anhang ............................................................................ 673

A Literaturverzeichnis ............................................................ 675

B Zitatverzeichnis .................................................................. 679

C Die Autoren ....................................................................... 681

Index ......................................................................................... 683

683

Index

A

A2X-Service 528ABAP

Dictionary 71, 91, 125, 167, 176, 218, 223, 598, 606

Klasse 249Schlüsselwortdokumentation 634Sperrkonzept 78Workbench 249

ABAP in Eclipse 598ABAP Managed Database

Procedures 598ABAP Objects 137, 138ABAP Test Cockpit 183, 596ABAP Unit 151ABAP-Proxy 519Abgrenzung, dynamische 240Abhängigkeit, zyklische 168Ablauflogik 324Ableitung 61Abmisch-Tool 41Abwärtskompatible Anwendung 603

Fallunterscheidung 606Funktionsliste 605Motivation 604nichtfunktionale Anforderungen 604

ACID-Eigenschaften 118Add-On Assembly Kit 220ADK 85, 195, 484Administrationsumgebung 37Administrationswerkzeug 209Administrator, fachlicher 37Administrator-Cockpit 38Administrierbarkeit

Customizing-Inhalte 38laufender Betrieb 37

Aggregatfunktion 86Agile Methode 34, 64Aktivierungsfehler 177ALE 89, 225ALV-Grid 292, 331, 337Analyse, objektorientierte 62Änderungsbeleg 127Anforderung 33

Anforderungsanalyse 32Anforderungsmanagement 51

funktionale 33nichtfunktionale 34

Anwendungsadministrator 462Anwendungsarchitektur 159Anwendungsdaten

Fusion 41Prüfung 54

Anwendungslogik 224Anwendungsobjekt 61, 62, 66,

125, 226Beispiel 63

Anwendungsprogrammierung 459Anwendungsschicht 223, 579Anwendungssystem 31Append-Suchhilfe 442Application Help 631Application Link Enabling 89, 225Arbeitsvorrat für SQL-Optimierung

592, 595Architektur 212

modellgetriebene (MDA) 58Architekturdokumentation 213Archive Development Kit 85,

195, 484ArchiveLink 228, 229Archivierung 84, 482Archivierungskriterium 85Archivindex 85Archivinformationssystem 86Archivmigration 230Archivrecherche 65, 86AS ABAP 636ASSERT 143Assertion 142, 143Assoziation 65Ästhetik 159Attribut 61

öffentliches 106transientes 97virtuelles 66

Auslieferbarkeit 39Ausnahme 135, 139, 144, 210

dynamisch geprüfte 141geprüfte 141klassische 140objektorientierte 140

684

Index

ungeprüfte 142verkettete 145

Ausnahmebehandlung 207Ausnahmehierarchie 145Ausnahmeklasse 140

CX_BO_ERROR 209CX_BO_TEMPORARY 209CX_DYNAMIC_CHECK 141CX_NO_CHECK 142CX_STATIC_CHECK 141CX_SWF_EVT_INVALID_EVENT

207CX_SWF_EVT_INVALID_OBJTYPE

207CX_SY_NO_HANDLER 141PREVIOUS-Parameter 145

Ausnahmekonzeption 144Ausnahmeschnittstelle 139Auswertungs-Report 314

B

B2B 515Background Remote Function

Call 554BAdI 150, 195, 196, 199, 214, 218BAL 42, 140, 154, 460, 464, 465

BAL_DB_DELETE 482BAL_DB_LOAD 465BAL_DB_SAVE 465BAL_DSP_LOG_DISPLAY 465,

466, 480BAL_DSP_PROFILE_SINGLE_LOG_

GET 474BAL_LOG_CREATE 480Detailinformation 475interaktive Funktionen 463Protokollanzeige 463Protokollobjekt 464Protokollrecherche 462Protokollsubobjekt 464

BANK_PP_JOBCTRL 506BAPI 55, 115, 166, 225, 457,

552, 639Basisfunktion 171Basisklasse 193Basiskomponente 171, 234BC-Set 216

BDT 55, 106, 316, 403Abschnitt 412Aktualgedächtnis 417Anwendungen 408Anwendungsobjekt 403Anwendungsobjekt BUPA 407Bilder 412Bildfolge 414Datensets 409Direct Input 56, 419, 457Feldgruppe 410Feldmodifikation 55Funktionsgruppe 408Gesamtgedächtnis 417Namenskonventionen 431partizipierende Anwendung 404Sicht 410Tabellen 409tabellenbesitzende Anwendung 404Träger-Dynpros neu generieren 433Zeitpunkt 419, 420, 421

Benutzerführung 296Benutzeroberfläche, grafische 292Benutzerschnittstelle 294Berechtigung 90Berechtigungskonzept 226Berechtigungsobjekt 225Berechtigungsprüfung 90, 225Bereichsmenü 37, 204, 314BEx Query Designer 621Bezeichner 333bgRFC 554Bildaufbau 296Binary XML 524Binding 567Blog 633, 646BOPF 107BOR-Objekt � Business-ObjektBreakpoint 143BRFplus 523BSP (Business Server Pages) 292Bündelungstechnik 83, 91Business Add-in � BAdIBusiness Application Log � BALBusiness Application Programming

Interface � BAPIBusiness Data Toolset � BDTBusiness Function 201, 607Business Functions Sets 204

685

Index

Business Object Builder 149, 227Business Object Processing

Framework 107Business Workplace 294Business-Objekt 65, 70, 227, 228, 249

Delegation 149BUS-Screen-Framework 316, 319,

322, 354, 454Button, benutzerdefiniert 483BW-Query 616, 617

Praxisbeispiel 617

C

CALL DIALOG 495CALL SCREEN 323, 495CALL SUBSCREEN 340CALL TRANSACTION 495CALL TRANSFORMATION 58, 130Callback 464, 482, 483

Methode 496Schnittstelle 196

Callback-Routine 478, 479, 495Cancel-Operation 534Canvas 393Change State Identifier 534, 562Change-Service 534Check Agent 96Checkpoint-Gruppe 143, 144Chefdesigner 650CHIPs 394Cloud-Fähigkeit 42Coaching 645, 650Code Inspection 655

automatisierte 656Code Inspector 151, 181, 183, 592,

655, 656, 665Erweiterung 657Kategorie 658Meldungsunterdrückung 665SAP HANA 591

Codelinie 605Codelisten 577COMMIT WORK 77, 94, 95, 98, 115,

119, 122, 129, 155, 469, 470, 495COMMUNICATION RECEIVE 496Component 361Configuration Guide 631Consumer-Mappings 520

Container-Operation 254Conversion Workbench 87Coverage Analyzer 596CRUD-Operationen 529, 530CRUD-Schnittstelle 227Customer Engagement Initiative

(CEI) 646Customizing 34, 38, 153, 191, 194,

232, 233, 314Prüffunktionen 35Tabelle 193technisches 235Zugriffsschichten 234

D

Data Modeler 67, 68, 228, 638, 669Daten

komplexe 480unstrukturierte 129

Datenarchivierung 85Datenaustauschverfahren 47Datenbank

Ebene 66Index 82Persistenz 64Pufferung 82Sperre 77Trace 642

Datenbank-Trace 642Datenbank-Zugriffsschicht 88Datenbereich, einklappbarer 301Daten-Cluster 129, 480, 481Datenherkunft 56Datenisolation 35Datenmodell 64, 67

Änderungen 86Datenmodellierung 71Datenqualität 133, 134Datentyp

abstrakt 136komplexer 525primitiver 525

Deadlock 78Debugger 636

Layer Debugging 637Verbuchungsdebugging 435

Default-Schnittstelle 182Denormalisierung 71, 106

686

Index

Deserialisierung 148Design, objektorientiertes 63Dialogfenster, modales 322Dialogstandard 293, 294Dialog-Workprozess 504Direct Extractor Connection 610Dirty Read 77Dokumentation 162, 163, 665,

668, 669obligatorische Bestandteile 669

Druckliste 154Druckprozess 229DTD-Validierung 130DXC 610Dynpro 318

Aufruf 326Logik 328

Dynpro Painter 319, 348Dynpro-Feld 341Dynpro-Klasse 341, 356Dynpro-Programmierung 293

klassische 293objektorientierte 316

E

eCATT (extended Computer Aided Testtool) 667

Eclipse 152EDI-Verfahren 50Einzelbelegzugriff 85Einzelschrittaufgabe 226, 256Embedded BW 615

aktivieren 616Enqueue-Baustein 79Enqueue-Server 78Enterprise Service 515Enterprise Service Marketplace 639Enterprise Service Repository

537, 572Enterprise SOA 524Entitätstyp 68Entity-Relationship-Diagramm 68Entity-Relationship-Modell, struktu-

riertes 67Entwickler, Anforderungen 53Entwickler-Customizing 233, 234Entwicklerschnittstelle 465Entwicklung, testgetriebene 152Entwicklungsklasse 162

Entwicklungskoordination 53Entwicklungsobjekt umbenennen

163Entwicklungsrichtlinie 653, 654Entwicklungsumgebung 161Ereignis 262Ereignis-Behandler 331, 332Ereignisblock 358Ereigniskopplung 206, 208, 263

asynchrone 248Ereignis-Queue 263Ereignis-Queue-Browser 210Ereignis-Trace 210Ergonomie 294, 295Error and Conflict Handler

� Fehler- und KonfliktbehandlerErweiterbarkeit 34Erweiterung 195

modifikationsfreie 106Erweiterungsimplementierung 202ESR 537, 572ETL (Extract Transform Load) 42Event 138, 205Exception 494Existenzabhängigkeit 68EXIT FROM STEP-LOOP 496EXPORT 481EXPORT TO DATA BUFFER 130Extended XML-Handling 559Extraktor 621

F

Fault-Message 548, 552Feeder-Klasse 385Fehler

Meldung sammeln und ausgeben 332potenzieller 212Prozess 230Situation 139Systemfehler 139temporärer 139, 208, 212Typ 212unerwarteter 212

Fehler- und Konfliktbehandler 520, 563

Feldmodifikation 55, 410Fixture-Methode 151Flexibilität 34Floorplan Manager 108, 360, 361

687

Index

Folgeprozess 89Forum 633Forward Error Handling 563, 570Framework 50, 53, 157, 650Freestyle UIBB 385Freigabe, externe 60Fremdschlüssel 76Funktionsbaustein 154, 195, 242

Aufruf 493BAL_DB_SAVE 470BAL_DSP_LOG_DISPLAY 483BAL_DSP_PROFILE_DETLEVEL_

GET 474BAL_DSP_PROFILE_NO_TREE_

GET 474BAL_DSP_PROFILE_POPUP_

GET 474BAL_DSP_PROFILE_STANDARD_

GET 474BAL_LOG_CREATE 465BAL_LOG_MSG_ADD 465BAPI_TRANSACTION_COMMIT 121BAPI_TRANSACTION_ROLLBACK

115, 121BP_CALCULATE_NEXT_JOB_

STARTS 506BP_JOBVARIANT_OVERVIEW

155, 505BP_JOBVARIANT_SCHEDULE

155, 505BP_START_DATE_EDITOR 506BUP_BUPA_BUT000_GET 422BUPA_DIALOG_SEARCH 449BUS_MESSAGE_STORE 422BUS_PARAMETERS_ISSTA_GET 422BUS_SEARCH_GENERATOR_

MAIN 57DB_COMMIT 117DISPLAY_XML_STRING 130FIMA_DECIMAL_MONTHS_

AND_YEARS 183FLUSH_ENQUEUE 80FREE_SELECTIONS_DIALOG 242FREE_SELECTIONS_INIT 242GET_PRINT_PARAMETERS 505GUID_CREATE 75JOB_OPEN 505JOB_SUBMIT 505NUMBER_CHECK 74NUMBER_GET_NEXT 73

OWN_LOGICAL_SYSTEM_GET 42SAP_WAPI_START_

WORKFLOW 262SPBT_DO_NOT_USE_SERVER 494SPBT_GET_PP_DESTINATION 494SPBT_INITIALIZE 493TR_OBJECTS_CHECK 312TR_OBJECTS_INSERT 123, 312TR_SYS_PARAMS 46VIEW_MAINTENANCE_SINGLE_

ENTRY 311Funktionscode 329, 330Funktionsgruppe 138Fuzzy Search 585

G

GAF 381Geheimnisprinzip 136, 142, 162,

163, 173, 174, 176, 210GENERATE REPORT 57Geospatiale Funktionen 586Geschäftspartner 401

Rolle 402Geschäftspartnerbeziehung 403Geschäftspartner-Rollen 530Geschäftsprozess 61GET BADI 197GUI (Graphical User Interface)

Programmierung 240, 291Schnittstelle 47Status 321Technologie 398, 399

GUIBB 382GUID (Global Unique Identifier) 75,

76, 124, 489Guided Activity 381Guided Activity Floorplan 381

H

Haupt-Dynpro 322Hauptpaket 166, 172, 174Hilfsklasse, globale 126Hintergrundjob 504, 513Hintergrundprogramm 154Hintergrundverarbeitung 156Hintergrund-Workprozess 503, 504

688

Index

I

Icon 300, 477Idempotenz 520Idempotenz-Framework 560Identität 61Identity Management 43IMG-Knoten 204Implementation Guide (IMG) 38IMPORT 481Include 137

Mehrfachverwendung 307Programm 307

Index 83InfoProvider, transienter 621Informationen 536InfoSet

anlegen 618Tabelle auswählen 619verwenden 620

Initial-Customizing 233INSERT FOR UPDATE 78INSERT REPORT 57Inside-Out 573Installation Guide 630Instanz 61Integrationstest 666Integrität, referenzielle 76Interface 135, 137, 146, 198

/BOBF/IF_TRA_SERVICE_MANAGER 113

/BOBF/IF_TRA_TRANSACTION_MGR 113

BI_EVENT_HANDLER_STATIC 205, 207, 208, 227

BI_OBJECT 249, 251BI_PERSISTENT 249, 251IF_BADI_INTERFACE 198IF_OF_CHECK 96IF_OS_CA_INSTANCE 96IF_OS_CA_PERSISTENCY 94, 96,

101, 105IF_OS_CHECK 103, 104, 128IF_OS_FACTORY 96IF_OS_STATE 97, 103IF_OS_TRANSACTION 98, 121IF_SERIALIZABLE_OBJECT 239IF_WORKFLOW 207, 227, 249IFARCH21 228, 229

Isolationsstufe 78

J

Jobeinplanung 504

K

Kapselung 196, 318Klärungsfall 50Klasse 61, 135, 161

abstrakte 137CL_ABAP_EXPIMP_DB 481CL_ABAP_OBJECTDESCR 239CL_ABAP_ZIP 130CL_AUNIT_ASSERT 151CL_BATCH_EVENT 155CL_BUS_ABSTRACT_MAIN_

SCREEN 322CL_BUS_ABSTRACT_SCREEN

325, 354CL_BUS_ABSTRACT_SUB_SCREEN

340, 356CL_BUS_LOCATOR_SEARCH 449CL_BUS_LOCATOR_SEARCH_

SCREEN 448CL_BUS_MESSAGE 332, 334CL_BUS_TAB 342CL_BUS_TABSTRIP 342, 347CL_BUS_TABSTRIP_TAB 347CL_GDT_CONVERSION 552CL_OS_CA_COMMON 96CL_OS_SYSTEM 122CL_PROXY_CLIENT 566CL_SFW_EVT_EVENT 208CL_SRT_PUBLIC_FACTORY 576CL_SYSTEM_TRANSACTION_

STATE 92cl_system_uuid 75CL_WS_IDP_FACTORY 561CX_AI_APPLICATION_FAULT 552CX_AI_SYSTEM_FAULT 568DO_PERFORM_BUS_LOGIC 552finale 137persistente 95, 99, 101

Klassenakteur 126Klassendiagramm 190Klassenmodell 64Kohäsion 136, 230Kompatibilitätsproblem 184, 185Komponentisierung 171

689

Index

Konnektivitätsstandard 43Konstante 137, 236Konstruktor, abstrakter 150Kontrollfluss 142Kontrollschleife 495Kunden-Customizing 233, 234Kundenerweiterung 196

L

Lastverteilung 506Laufzeitanalyse 639Laufzeitfehler 495Laufzeitkonfiguration 190Layer Debugging 637Lifecycle Management 43Linguistische Suche 585Liste, interaktive 154Locator 297Locator-Framework 322Loghandle 464Logical Unit of Work � LUWLOGPOINT 251Lokale Integration Engine 520, 569LUW 73, 95, 116, 155

Ablauf 117

M

Mandantenfähigkeit 35, 234Mapping 94Massendatenfähigkeit 36, 106Master Data Governance � MDGMaster Guide 630MDG 455

Erweiterung 456Voraussetzung 455Vorteile 456

MDR 519, 538Memory Inspector 249, 667Menu Painter 296Menüstandard 296Merger-Readiness 86MESSAGE 495Message Handling 318Message-Datentyp 544, 546Message-Typ 536, 542Metadata Repository 519, 538Metadaten 54

Methode 61asynchrone 257CREATE_IDP_HELPER 561

Migration 84, 91, 124, 166, 168Migration Workbench 87Mini-SAP-System 512Mobile Anwendung 108Mock-Objekt 153MODIFY FOR UPDATE 78Modularisierung 35, 90, 136Modularisierungseinheit 153Modulgedächtnis 138Modultest 151, 152Monitoring 491Monitoring-Werkzeug 209MVC (Model View Controller) 361

N

Nachrichtenklasse 116Namenskollision 186Namenskonvention 186, 187, 654Namensraum 175, 186, 188Near-Realtime-Replikation 610Normalisierung 70Notifikationen 536NULL-Wert 83

Nutzen 84Semantik 84

Nummernkreis 54, 72externes Intervall 74Geschäftsjahr 74Intervall 74, 406Intervallstände 73Nummernkreisgruppen 74Pufferung 72

Nummernkreisintervall, disjunktes 124

Nummernkreisobjekt 72, 74Nummernkreisverwaltung 54Nummernvergabe, externe 72

O

Oberflächenstatus 296Object Services 93, 122

Check Agent 96Klassenakteur 96, 101, 104,

105, 106

690

Index

Mapping 94, 126Objekt-Initialisierung 102Query-Dienst 101, 106Transaktionsdienst 121Transaktionskonzept 122transiente Attribute 97Typidentifikator 99Vererbungstypen 99

ObjektAbleitung 61Attribut 61Auswahl 297Dienst 228Identität 61Instanz 61Klasse 61Lebenszyklus 229Methode 61Modell 64persistentes 98, 125, 226Persistenz 88, 166Verwaltung 166

Objektbasierte Navigation (OBN) 390Objektorientierung 61, 145, 194OData 108, 518, 600OData-Services 599OO-Ereignis 330Open-Closed-Prinzip 147, 150Open-Source-Projekt 645OpenSQL 611Operational Analytics 615Operatives Reporting 86Organisationsmanagement 246Overview Page Floorplan (OVP) 381

P

P2P-Kommunikation 523, 549Package Builder 176Paket 168, 173, 174, 189, 215, 217

deklaratives 172Hauptpaket 174Hierarchie 176Konzept 159, 162, 174, 670Name 175Struktur 162, 167Strukturpaket 174Zerlegung 214zyklische Verwendung 168, 215

Paketierung 489Kriterien 491

Paketprüfung 218Client 178Prüfungsmodus R3ENTERPRISE 182Prüfungsmodus RESTRICTED 178,

183, 219Server 177, 219

Paketschnittstelle 174, 176, 638Sichtbarkeit 179Verlängerung der Sichtbarkeit 179

Paketstrukturierung 541Parallelisierbarkeit 487, 488Parallelisierung 156, 459, 485, 506

Hintergrundjobs 504Parallelverarbeitung 513Parallelverarbeitungs-Framework 513PERFORM ON COMMIT 92, 120, 128Performanceoptimierung 36, 487Persistenzdienst 106Persistenzmechanismus 93, 102Persistenzschicht 106Personas 292Pflegedialog 304Pflege-View 204, 303, 304, 312Plug-in 148Polymorphie 99, 101, 125, 136, 190Power User 631Prädiktive Analytik 586Pragma 665Predictive Analysis Library 587Primärschlüssel 72, 79, 123, 125Produktfamilie 49, 50Produktidee 31, 160Produktkonzeption 170Programmierung

generative 56, 57objektorientierte 135Prinzipien 136

Protokoll 459, 462Adressat 461anreichern 472archivieren 484auf Datenbank speichern 468erzeugen und anzeigen 466Kopf 480löschen 484Objekt 464persistentes 459Recherche 461

691

Index

speichern 468Standard-Profilvorlagen 474Subobjekt 464

Protokollanzeige 474Protokollierung 471Prototyping 653Prozesskomponente 529Prüffunktion 35Prüf-Report 314Prüfungsklasse 659Prüfungsmodus 178Publish-&-Subscribe-Schnittstelle 45,

190, 204, 217, 227, 248, 257

Q

Qualitätsmanagement 651Querschnittsfunktion 196Query

anlegen 622, 624testen 624

Query-Dienst 94, 105

R

R 586Reference Information 631REJECT 496Release-Planung 163Release-Upgrade 589Release-Wechsel 652Remote Function Call � RFCReport 154

ABAP_SLIN_PRAGMAS 665BDT_ANALYZER 433RS_PACKAGE_TREE 179, 181SBAL_ARCHIVE 484SBAL_ARCHIVE_DELETE 484

Report-Variante 155Repository-Infosystem 643Returncode 494Reuse Library 635Reuse-Option 457RFC 89, 116

asynchroner 485, 492, 513RFC-Servergruppe 493, 506Risikomanagement 651, 652Robustheit 90

ROLLBACK WORK 95, 107, 470, 471, 496

Run Time Type Information (RTTI) 237, 239

S

SAML 520Sammelsuchhilfe 441SAP Business Workflow 316SAP Business Workplace 245SAP BW 51, 616SAP Community Network 633SAP Design Guild 635SAP ES Methodology Wizard 530SAP Fiori 518SAP Folders Management 129SAP GUI für HTML 245SAP HANA 86, 132

abwärtskompatible Anwendung 581, 603

Analysewerkzeuge 588Anwendungsentwicklung 579Besonderheiten 583bestehende Anwendung 580Codeoptimierung 588Datenreplikation 608Einsatzszenarien 580Erweiterbarkeit von

Anwendungen 602Funktionen schalten 606Kapselung 601, 607mengenorientierte Zugriffe 601neue Anwendung 581, 597Optimierter Code 580Optimierungsbedarf 588Parallelisierung 584Rechen-Engine 583Replikationsrichtung 609Schaltbarkeit 606Side-by-Side-Anwendung 582, 607Spaltenorientierung 583Statistikfunktion 585Suche 585Transportcontainer 599Transportwesen 598

SAP HANA Studio 598SAP Help Portal 629SAP InnoJam 633SAP Inside Track 633

692

Index

SAP Landscape Transformation 610SAP Locator 437

Such-Dynpro 444Suche-Anwendungen 439Suche-ID 439, 452Suche-Typ 439Suchhilfe-Hierarchien 441

SAP LUW 469, 471SAP NetWeaver Business Client

391, 625SAP Process Integration 520, 522SAP Query 618SAP R/3 Icons 301SAP R/3 Style Guide 294SAP Releasenote 60SAP Screen Personas 292SAP Service Marketplace 629SAP SLT 610SAP Support Portal 632SAP Web Flow Engine 245SAP_ABA 59, 172, 179SAP_BASIS 59, 172, 179SAP-Bibliothek 629, 631SAP-Geschäftspartner 65, 67, 296,

401, 402, 403Geschäftspartnerbeziehungen 403Geschäftspartnerrolle 402GP-Rollen definieren 414GP-Sichten 414Grund-Customizing 404Rolle 416Rollentyp 415

SAP-Hinweis 60, 632SAPlink 58, 148SAP-Query 315SAP-Releasenote 632SAPscript 475SAP-Softwarekomponente 179SAP-Standard 59, 161, 172, 186SAPUI5 600Schaltbarkeit 200Schicht 169Schichtenmodell 49, 169, 214Schnittstelle 47, 161, 195

ereignisbasierte 204, 228externe 166Konzeption 216öffentliche 162Typ 182Verletzung 177

SCI-Meldung 665SCN 633Screen BAdI 317Screen Scraping 394Script Engine 637Scrum 650Security Assertion Markup

Language 520Security Guide 630SELECT FOR UPDATE 78SELECT-OPTIONS 348Selektionsbild 348, 349, 350,

352, 354Selektionskriterium 348Serialisierung 148SERM 68Service 196Service Implementation

Workbench 575Service Registry 564Service-Dienst 305Service-Gruppen 571Service-Klasse 230, 231Service-Provider 538SET HANDLER 332SET PF-STATUS 354SET UPDATE TASK LOCAL 107, 120Shared Buffer 481Shared Memory 481Shared Object 93Sicherheitsfassade 139Side Panel 393, 394Side-by-Side-Anwendung 607

Datenreplikation 608Einsatzfelder 608optionales Sidecar 612Richtlinie 612sekundäre Datenbank-

verbindung 611Switch und Enhancement

Framework 613Transaktionszuschnitt 609

Sidecar-Szenarien 582Simple Transformations 130, 131,

524, 526Skalierbarkeit 36, 486Skalierung, lineare 486SLT 87SOA by Evolution 529Softwarearchitektur 214

693

Index

Software-as-a-Service 42Softwarekomponente 179, 180, 190,

220, 537, 573BBPCRM 172, 184SAP_HR 172

Softwarepyramide 40Softwarequalität 651Softwarestrukturierung 159, 161, 170Softwaretechnik 160, 161Softwaretest 666Solution Manager 615Sortierung 474Speicher 667Speichermangel 667Speicherung 129Sperre 78

aufheben 81Sperrkonzept 80Sperrobjekt 79, 212Sperrverwaltung 126Spezifikation 33, 46, 48Sprache, domänenspezifische

(DSL) 57SQL-Monitor 83, 593

Verfügbarkeit 595SQLscript 586Stammdaten-CHIPs 395Stammdatentabelle 233Steuerparameter 233Steuerungsprogramm 147STOP 496Strukturiertes Entity-Relationship-

Diagramm 68Strukturpaket 174, 179, 180Strukturpaketprüfung 182Styleguide 635SUBMIT 495Subscreen 316, 317, 319, 322, 340,

343, 350, 352Subscreen-Area 338Subscreen-Klasse 341Substitutionsprinzip 149, 150Suchdienst 44, 45, 88, 92, 93, 105,

106, 189, 190, 191, 192, 227, 240Suchhilfe, elementare 235, 441Suchkriterium

komplexes 92Rückgabe 244

Switch Framework 199, 200, 606Switch und Enhancement

Framework 613

Sybase IQ 583Systemanalyse

SAP HANA 593Systemfehler 139, 208, 211

Neutralisierung 211Systemlastanalyse 592Systemspezifikation 46Systemtest, automatischer 44

T

T100-Nachricht 116Tabelle, abhängige 102Tabellenpflege 304, 311Tabellenpflegedialog 302, 303, 311Table Control 337, 437Tabstrip 299, 342, 343Tag-Interface 198, 239Technical Operations Manual 631Teilanwendung 170Test-Customizing 153Testmethode 151»TODO«-Kommentar 657Tool 650Top-Include 138Transaktion

BOBT 113BOBX 115SOAMANAGER 555, 564SRT_MONI 549SXMB_MONI 520

Transaktionskonzept 116, 469klassisches 120objektorientiertes 121

Transaktionsmechanismus 89Transaktionssicherheit 118Transaktionssteuerung 119, 123Transportsystem 304, 312Trigger-based Replication 610

U

UDDI 522, 564, 571UIBBs, wiederverwendete 385Umfeldermittlung 643Umfeldinformation 472UML-Diagramm 167Unicode-Prüfung 590Unicode-Umstellung 590

694

Index

Unidirektionale Kommunikations-muster 536

Unique Constraint 72Unit-Test 151Universal Description, Discovery and

Integration � UDDIUniversal Worklist 245Unscharfe Suche 585UPDATE FOR UPDATE 78Update-Service 534, 561

V

Vendor Lock-in 582Verbuchung 120Verbuchungs-Task 470Vererbung 76, 99, 136, 149Vererbungshierarchie 101Verifikation 45Verwaltungsdienst 88Verwendung, zyklische 168, 215Verwendungserklärung 174, 180Verwendungsnachweis 208, 636Viewcluster 313Volltext-Suche 585

W

WAIT UNTIL 495WAIT UP TO 495Wartbarkeit 163Web Dynpro 292, 359

Anwendung 363Code Wizard 368Component Controller 365Component-Interface 365Interface-View 365Namenskonventionen 655Programmiermodell 362Window 365

Web Dynpro ABAP 58Web Dynpro ABAP Page Builder 394Web Dynpro ABAP-Konfigurations-

Framework 370Web Dynpro Code Wizard 360Web Service Description Language

� WSDL

Web Service Interoperability Organization 526

Webservice 55, 165, 225Authentifizierung 558Bulk-Verarbeitung 562Metadaten 519Performance 523Transportsicherheit 558Vorteil 519zustandsloser 532

Webservice-Implementierungs-klasse 551

Webservice-Signatur 530Webservice-Wizard 538Wf-XML 245WHERE-Bedingung 244Wiki 646Workflow 42, 47, 101, 125, 149, 166,

225, 229, 245, 249asynchrone Methoden 257beendende Ereignisse 257Container-Operation 254Customizing 44Einzelschrittaufgabe 226, 246, 256Ereignis 208Ereigniskopplung 209Event 205generelle Aufgabe 252Mehrschrittaufgabe 258Protokoll 246, 261, 262Stellvertreterregelung 246Test 258Verbrauchertyp 206Vorlagetermin 255Wiedervorlage 247Workitem-Vorschau 246

Workflow Builder 258Workflow-Container 252, 254Workflow-Muster 252Workflow-Technik,

objektorientierte 249Working Area 127Write-Back-Szenario 609WS_I 526WSDL 525

Document Style 526WS-RM-Standard 574, 577

695

Index

X

XML 129, 148Archivierung 85Clobbing 130Shredding 131

XML Library 130XML Schema 525XML-Schema-Validierung 526XPRA-Programm 91XS Engine 599XSL-Transformation 58

Z

Zentraler Geschäftspartner (ZGP) � SAP-Geschäftspartner

ZIP-Komprimierung 130Zusatzfeld 474Zuständigkeit 168, 230

Trennung 51

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Gerne dürfen Sie diese Leseprobe empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Die vorliegende Leseprobe ist in all ihren Teilen urheberrecht- lich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Thorsten Franz ist Gründer des SAP-Beratungsunterneh-mens operatics und seit mehr als 15 Jahren als Architekt, Berater, Entwickler, Projektleiter und Coach im SAP-Ent-wicklungsumfeld tätig.

Tobias Trapp ist Software-Architekt bei der AOK Systems GmbH. Er besitzt mehr als 15 Jahre Erfahrung in der Soft-wareentwicklung auf verschiedenen Plattformen und mit verschiedenen Programmiersprachen, sowohl im Bereich der Individual- wie auch der Standardsoftware.

Thorsten Franz, Tobias Trapp

Anwendungsentwicklung mit ABAP Objects695 Seiten, gebunden, 2. Auflage 2014 69,90 Euro, ISBN 978-3-8362-2635-6

www.sap-press.de/3472

Wissen aus erster Hand.

http://www.sap-press.de/3472?GPP=lpn

https://www.facebook.com/GalileoPressVerlag

https://plus.google.com/118435207805510651040

http://twitter.com/Galileo_Press

Anwendungsentwicklung mit ABAP Objects

Documents

Transcript of Anwendungsentwicklung mit ABAP Objects