Generische Anbindung von Datenhaltungssystemen

mit Web Services

am Beispiel von SAP R/3

Diplomarbeit

Jorg Diesinger

Naturwissenschaftlich-Technische Fakultat I

der Universitat des Saarlandes

November 2004

Hiermit erklare ich an Eides statt, dass ich die vorliegende Arbeit

selbststandig verfasst und keine anderen als die im Literaturverzeichnis an-

gegebenen Quellen verwendet habe.

Saarbrucken, 30. November 2004

(Jorg Diesinger)

Inhaltsverzeichnis

Vorwort 1

1 Einleitung 3

1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 8

2 Konzepte verteilter Ausfuhrungsplattformen 9

2.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Verteiltes System . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Middleware-Technologien . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Remote Procedure Call (RPC) . . . . . . . . . . . . . . 10

2.3 Service-oriented architecture (SOA) . . . . . . . . . . . . . . . 11

2.3.1 Anforderungen und Modell . . . . . . . . . . . . . . . . 12

2.3.2 Service Provider . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3 Service Broker . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.4 Service Consumer . . . . . . . . . . . . . . . . . . . . . 13

3 Web Services 15

3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Web Services architecture (WSA) . . . . . . . . . . . . . . . . . 16

3.3 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . 16

3.3.1 SOAP Nachricht . . . . . . . . . . . . . . . . . . . . . . 17

3.3.2 Kodierung und Datentypen . . . . . . . . . . . . . . . . 18

3.3.3 SOAP fur RPC . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Web Services Description Language (WSDL) . . . . . . . . . . 21

3.5 Universal Description, Discovery and Integration (UDDI) . . . 24

4 SAP R/3 25

4.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Business Framework . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Business-Komponenten . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Business-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . 28

i

Inhaltsverzeichnis

4.5 Business Application Programming Interfaces (BAPIs) . . . . . 31

4.5.1 Merkmale von BAPIs . . . . . . . . . . . . . . . . . . . 32

4.5.2 Vorteile von BAPIs . . . . . . . . . . . . . . . . . . . . . 33

4.5.3 Voraussetzungen fur den Zugriff auf BAPIs . . . . . . . 34

4.5.4 Zugriffsmoglichkeiten . . . . . . . . . . . . . . . . . . . . 36

4.5.5 Beispiel: Company.GetList() . . . . . . . . . . . . . 37

4.6 Integrationsdienst ALE (Application Link Enabling) . . . . . . 40

4.7 Remote Function Call (RFC) . . . . . . . . . . . . . . . . . . . 41

5 Zugriff auf SAP R/3 mit SAP Java Connector (JCo) 42

5.1 Technologie des JCo . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Metadaten von RFMs . . . . . . . . . . . . . . . . . . . . . . . 46

5.3.1 JCO.Repository und JCO.Function . . . . . . . . 46

5.3.2 JCO.ParameterList . . . . . . . . . . . . . . . . . . 47

5.4 Aufruf von RFMs . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.5 Beispiel: BAPI COMPANY GETLIST . . . . . . . . . . . . . . . . 49

6 Zugriff auf relationale Datenbanken mit JDBC 51

6.1 Technologie der JDBC . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3 Metadaten von Relationen . . . . . . . . . . . . . . . . . . . . . 54

6.4 Ausfuhren von SQL-Anweisungen . . . . . . . . . . . . . . . . . 55

7 Anforderungen 57

7.1 Anforderungen an Web Services . . . . . . . . . . . . . . . . . . 57

7.2 Anforderungen an Generic Web Services . . . . . . . . . . . . . 59

8 Entwurf von Generic Web Services 62

8.1 Vorbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.2 Servlet-basierter Aufbau . . . . . . . . . . . . . . . . . . . . . . 63

9 Implementierung 64

9.1 Datenbank-Adapter . . . . . . . . . . . . . . . . . . . . . . . . 64

9.2 Generierungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 65

9.3 Web Service Invocation Framework (WSIF) . . . . . . . . . . . 66

10 Einsatzbeispiel 67

10.1 Generierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

10.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

10.3 Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

10.3.1 WSIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

10.3.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . 77

A ABAP Dictionary Datentypen 78

ii

Inhaltsverzeichnis

B CD-ROM 80

C Installationsanleitung 82

C.1 Installation der Komponenten . . . . . . . . . . . . . . . . . . . 82

C.2 Installation von Generic Web Services . . . . . . . . . . . . . . 84

C.3 Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

C.4 Installation von Datenquellen-Middleware . . . . . . . . . . . . 86

C.5 Integration von Datenquellen-Adaptern . . . . . . . . . . . . . 86

Abbildungsverzeichnis 87

Tabellenverzeichnis 88

Literaturverzeichnis 90

iii

Vorwort

Die Grundidee zur vorliegenden Arbeit entstand bei der T-Systems Nova

GmbH, Entwicklungszentrum Sud-West in Saarbrucken. Der Einsatz von SAP

R/3 sowohl innerbetrieblich als auch bei Kundenunternehmen zur Abwick-

lung relevanter Geschaftsprozesse verlangte nach einer Technologie, die ande-

ren, typischerweise in der Praxis SAP-fremden Systemwelten Zugriff auf die

R/3-intern gehaltenen Daten gewahrt. Vor dem Hintergrund, daß die Ver-

waltung dieser Rohdaten vorgegebenen und innerhalb der Applikationslogi-

kebene des Systems spezifizierten betriebswirtschaftlichen Geschaftsregeln und

-operationen unterliegt, bietet R/3 zur Wahrung der Datenintegritat keine sy-

stemubergreifende direkte Schnittstelle zum Datenbanksystem.

Die besondere Anforderung lag dabei vor allem bei der einfachen Anwend-

barkeit der Technologie in der Praxis, der Plattform- und Programmierspra-

chenunabhangigkeit sowie einer großtmoglichen Wiederverwendbarkeit. Zwar

konnte auf Grund der von R/3 unterstutzten Kommunikationsschnittstellen

auch bisher mit dem System interoperiert werden, allerdings mit hohem Auf-

wand: In Abhangigkeit von der integrierenden Anwendung mussten”ad-hoc“-

Implementierungen die Anbindung uber die jeweils kompatible Schnittstelle zu

R/3 realisieren, um Daten integrieren zu konnen.

Mit Beginn der Betreuungsphase durch den Lehrstuhl von Prof. Dr.-Ing.

Weikum am Max-Planck-Institut fur Informatik in Saarbrucken wurde eine

darauf aufbauende, verallgemeinernde Aufgabenstellung konkretisiert: Die Er-

zeugung von Web Services in einem automatisierten generischen Prozess sollte

es ermoglichen, individuell definierte Dienste bereitzustellen, die die Daten be-

liebiger aber jeweils fix spezifizierter Datenhaltungssysteme extrahierbar und

modifizierbar und damit flexibel integrierbar machen.

Die Ausarbeitung prasentiert gleichermaßen die notwendigen theoretischen

Grundlagen zur Softwarearchitektur von Web Services, deren konkrete Umset-

zung in der Praxis wie auch den Entwurf und die Realisierung einer Anwendung

zur automatisierten Generierung und Bereitstellung dieser Softwaredienste.

Die Implementierung der Prototyp-Applikation Generic Web Services

in der Programmiersprache Java liegt dieser Arbeit zusammen mit allen

zur Ausfuhrung der vorliegenden Version notigen Softwarekomponenten auf

CD-ROM bei.

1

Die Realisierung dieser Diplomarbeit erfolgte in den Raumen der T-

Systems Nova GmbH, die unter anderem einen Zugang zu SAP R/3, erfor-

derliche Softwarekomponenten sowie Know-how im Umgang mit dieser Syste-

mumgebung zur Verfugung stellten.

2

Kapitel 1

Einleitung

Der Entwurf von System- und Anwendungsarchitekturen basiert auf grundle-

genden Konzepten. Anwendungen lassen sich prinzipiell drei funktionalen Ebe-

nen zuteilen, die logisch betrachtet ubereinander anzuordnen sind wie Abbil-

dung 1.1 zeigt.

Abbildung 1.1: Die drei Ebenen einer Anwendung

Innerhalb der Datenebene befinden sich die Rohdaten, mit denen die Anwen-

dung arbeitet. Sie werden entweder im Dateisystem gehalten (die Anwendung

speichert die Datenebene selbst) oder sie sind, wie in den meisten Fallen, in

angeschlossenen Datenbanksystemen organisiert, die damit die Datenebene re-

prasentieren. Diese auch als Enterprise Information Layer bezeichnete Ebene

kann auch Legacy-Systeme oder ERP-Systeme (Enterprise Resource Planning)

beinhalten (z.B. SAP R/3).

Die Applikationslogikebene enthalt die implementierten Anwendungsope-

rationen auf den Daten der Datenebene.

Die Prasentationsebene stellt das Bindeglied zwischen der Anwendung und

dem Benutzer dar. Sie prasentiert die Anwendung bzw. deren Ausfuhrungsre-

sulte auf irgendeine benutzerverstandliche Art. Typische Beispiele sind Web-

seiten oder anwendungsspezifische graphische Oberflachen (z.B. SAP GUI).

In immer starkerem Maße spielt in der heutigen Zeit die Vernetzung von

Rechnern und damit das verteilte Computing eine wichtige Rolle. Das Inter-

net als globales Netzwerk ubernimmt dabei langst nicht mehr nur die Aufgabe

der reinen Prasentation von Informationen und Wissen. Vielmehr ruckt immer

3

haufiger beispielsweise unter dem Begriff des E-Business die Abwicklung von

Geschafts- und Handelsbeziehungen in den Vordergrund. Unternehmen nut-

zen das Internet sowie das innerbetriebliche Intranet als Kommunikationsnetz-

werk, um die taglich anfallenden Geschaftsprozesse dezentral, automatisiert

und somit zeit- und kostensparend in allen Funktionsbereichen wie Marketing,

Vertrieb, Produktion, Logistik etc. durchzufuhren.

Mit dem Internet ist die Basis fur ein einheitliches Kommunikationsmedi-

um geschaffen, das als Standard gesetzt und anerkannt ist. Die auf den Schnitt-

stellen aufgesetzten Anwendungsplattformen mussen dabei allerdings moglichst

flexibel sein, was die Integration verschiedener externer Informationssysteme

oder Geschaftsablaufe und -einheiten in die bestehende IT-Landschaft betrifft.

Von dieser Anforderung hangen letztlich die Effizienz und die Akzeptanz des

gesamten Systems ab. Nur wenn einzelne Applikationen Daten austauschen

konnen, konnen Erweiterungen und Optimierungen in der Geschaftsprozes-

skette realisiert werden. Ein Vorteil der Integration von Unternehmens- oder

E-Business-Anwendungskomponenten in vorhandene IT-Infrastrukturen ist so-

mit aus betriebswirtschaftlicher Sicht offensichtlich: Prozessoptimierung, Ko-

stensenkung und das Ziel, daraus einen gemeinsamen Mehrwert mit dem ver-

netzten Partner zu erlangen, sichern die Wettbewerbsfahigkeit. Aus technischer

Sicht stoßt die Kopplung auch wenig komplexer Softwarekomponenten auf

Grund unvereinbarer Technologien oder fehlender Schnittstellen immer wie-

der an Grenzen. Der Einsatz von webbasierten, d. h. uber das Internet bzw.

Intranet kommunizierenden Systemarchitekturen ist noch keine hinreichende

Voraussetzung fur die Realisierung von unternehmensubergreifenden, verteil-

ten Prozessen in einem Rechnerverbund. Existiert hier keine einheitliche oder

zumindest klar definierte Struktur bei der Darstellung von Informationen und

sind diese nur uber system- und anbieterspezifische Technologien austauschbar,

ist eine Anbindung von Fremdsystemen meist unmoglich oder unrentabel.

Als Ausgangssituation fur dieses Szenario betrachte man zunachst die ty-

pische Architektur eines webbasierten Systems. Die drei Ebenen einer Anwen-

dung konnen verschiedenen Komponentenschichten (tiers) zugeteilt werden wie

Abbildung 1.2 darstellt.

Die drei Anwendungsebenen lassen sich dabei wie folgt auf die Komponen-

tenschichten verteilen: Die Datenebene wird durch den Datenserver (tier 4) re-

prasentiert, wahrend der Applikationsserver (tier 3) die Applikationslogikebene

abdeckt. Tier 1 und tier 2 bilden schließlich zusammen die Prasentationsebene.

Informationsanfragen, die der Benutzer von einem Client aus in der Regel

uber einen Browser formuliert, nimmt der Webserver entgegen. Die Ausfuhrung

der entsprechenden Anwendungslogik ubernehmen innerhalb des Applikations-

server laufende Programme. Dabei stehen notwendige Daten in separat gehal-

tenen Datenhaltungssystemen zur Verfugung.

Was nun im beispielhaft angefuhrten E-Business-Szenario von Interesse

ist, ist die Realisierung der Verteilung der Applikationslogik auf mehrere am

4

1.1. Problemstellung

Abbildung 1.2: 4-Tier-Architektur1 eines webbasierten Systems

Netzwerk beteiligte Rechnersysteme. Ermoglicht man die Kommunikation ein-

zelner Anwendungskomponenten untereinander, konnen Geschaftsprozesse hier

die Unternehmensgrenzen uberschreiten. Bestehende Business-Losungen oder

Informationssysteme unterschiedlicher Anbieter konnen integriert werden, und

so kann das Unternehmen auf zunehmende Anforderungen flexibel reagieren.

Die Motivation fur den Einsatz verteilter Anwendungsarchitekturen liegt

nicht ausschließlich in der Integrierbarkeit existierender (Fremd-)Losungen und

steht unter dem erwahnten wirtschaftlichen Gesichtspunkt. Skalierbarkeit und

Lastenverteilung sind nur zwei Schlagworter bei der Betrachtung der techni-

schen Aspekte. Abbildung 1.3 zeigt die veranderte Situation in der Anwen-

dungsschicht eines verteilten Systemkonzepts.

Abbildung 1.3: Webbasiertes System mit verteilter Applikationslogik

1.1 Problemstellung

Die Fragestellung und damit die Problematik, die sich im technischen Kontext

ergibt, ist, wie die Bereitstellung und Nutzung, d. h. die Kommunikation mit

5

1.1. Problemstellung

den Anwendungen erfolgen kann, die auf Systemen implementiert sind, die sich

in der Praxis haufig durch eine heterogene Hard- und Softwareumgebung aus-

zeichnen. Es mussen Schnittstellen gegeben sein, die Dienste zum Austausch

verteilter Anwendungsobjekte anbieten. Diesbezuglich verfugbare Middleware-

Technologien mussen in der Lage sein, von gegebenen Hard- und Softwarear-

chitekturen zu abstrahieren, um so plattform- und programmiersprachenun-

abhangig die Kommunikation mit komponentenorientierten Applikationen zu

ermoglichen.

Hier prasentieren verschiedene Technologiehersteller Losungen. Zum Bei-

spiel stellt Microsoft fur Windows-Plattformen den DCOM-Standard (Distri-

buted Component Object Model) [5] zur Verfugung, somit allerdings eine Ein-

schrankung auf Windows-Systeme. Mit CORBA (Common Object Request

Broker Architecture) [6] existiert ein weit verbreiteter Ansatz fur E-Business-

Losungen der Object Management Group (OMG). Dieser wurde von Unter-

nehmen wie IBM und der Sun Microsystems, Inc. weiterentwickelt und stan-

dardisiert. Der Einsatz von CORBA ermoglicht zwar eine Uberschreitung von

Betriebssystem- und Programmiersprachengrenzen, Applikationen, die auf die-

sem Konzept basieren, sind aber dennoch abhangig von anbieterspezifischen

Implementierungen: Die Schnittstelle zum verteilten Objekt und deren Be-

schreibung mussen in den Sprachen spezifiziert und angeboten werden, von

denen aus ein Zugriff erwunscht ist2.

An dieser Stelle treten Web Services als Middleware-Konzept in den Vor-

dergrund. Bei der Realisierung von verteilter Anwendungsfunktionalitat setzen

Web Services auf bereits etablierte plattform- und sprachenunabhangige Tech-

nologien. Die beispielhaft erlauterten Einschrankungen im Umgang mit vor-

herrschenden Losungen zur Realisierung verteilter Anwendungsfunktionalitat

werden von Web Services durch Standardisierungen umgangen. Die Festlegung

auf das Kommunikationsprotokoll SOAP, welches Vorschriften fur die Forma-

tierung auszutauschender Daten zwischen verteilten Anwendungen definiert,

stellt dabei die eigentliche Neuerung dar.

Ebenso wie SOAP basiert auch die Schnittstellenbeschreibungssprache

WSDL fur Web Services auf XML (eXtensible Markup Language) [17]. Auch

bei der Verwendung des Tragerprotokolls zur Ubermittlung der Daten wird

die Zielsetzung von Web Services deutlich: Offene Internet-Standards wie das

uberwiegend eingesetzte HTTP (HyperText Transfer Protocol) [15] sichern ei-

ne plattformubergreifende Kommunikation und eine standardisierte Verfugbar-

keit. Andererseits sind Konzepte wie die der entfernten Methodenaufrufe (Re-

mote Procedure Call) oder der serviceorientierten Architektur von Web Ser-

vices keine neue Erfindung. Auf Grund ihres zusatzlichen Grades an Plattform-

und Programmiersprachenunabhangigkeit und der breiten Verfugbarkeit von

Webserver-Architekturen scheint mit Web Services allerdings eine verteilte

2CORBA verwendet hier die sogenannte Interface Definition Language (CORBA IDL),

vgl. [23, 6]. Sie ist an die Programmiersprache C++ angelehnt.

6

1.2. Zielsetzung

Ausfuhrungstechnologie gefunden, die eine Losung der Problematik verspricht.

1.2 Zielsetzung

Ziel dieser Arbeit ist es, Web Services einzusetzen, um die Anbindung von

Datenhaltungssystemen zu implementieren und damit im verteilten System

transparent anzubieten. Die Kommunikation mit Datenservern uber spezifi-

sche proprietare Middleware wird im Web Service gekapselt. Uber definierte

Schnittstellen werden die Daten innerhalb der Applikationsschicht zugreifbar

und integrierbar gemacht. Die Architektur in Abbildung 1.4 veranschaulicht

das Konzept.

Abbildung 1.4: Webbasiertes System mit Web Services zur verteilten

Datenserveranbindung

Unter Ausnutzung der gegebenen Standardisierung der Komponenten soll ei-

ne generische Erzeugung der Web Services realisiert werden: Die Spezifizierung

von Schnittstelle und Schnittstellenbeschreibung (WSDL), die den Web Service

identifizieren, mussen ebenso generisch realisiert werden wie dessen Implemen-

tierung, die schließlich im Applikationsserver zugreifbar wird. Die Aufgabe der

Web Service Implementierungen soll es sein, Methoden im verteilten System

zur Verfugung zu stellen, die – je nach erfolgtem Generierungsprozess – eine

Selektion oder Manipulation auf Daten eines Datenhaltungssystems ausfuhren

und somit diese Funktionalitat im”Ready-to-use“-Format anbieten und ver-

breiten konnen.

In der Realisierung werden in Abhangigkeit des Anbieters eines Datenhal-

tungssystems (ORACLE, MySQL, Microsoft SQL Server, SAP R/3, etc.) spe-

zifische Middleware-Implementierungen den Zugriff innerhalb des Web Service

ubernehmen. Generische Datenstrukturen mussen dann dafur sorgen, die Da-

ten systemkonform zu halten, d. h. vorgegebene Datenschemata und -relationen

mussen vom Web Service gewahrt werden, um die Datenintegritat im System zu

erhalten. Gleichzeitig konnen uber diese Datenstrukturen Methodenparamter

definiert werden, um eine Spezifizierung der zu selektierenden oder manipulie-

renden Daten im Datenhaltungssystem zu ermoglichen. Wie noch zu erlautern

7

1.3. Gliederung der Arbeit

sein wird, dienen die Metadaten der jeweiligen Datenquelle dazu, diese Struk-

turen zu erzeugen.

Es sei an dieser Stelle explizit darauf hingewiesen, dass die im Rahmen die-

ser Arbeit betrachteten Datenhaltungssysteme auf dem relationalen Datenmo-

dell beruhen. Auch die 3-Tier-Architektur des SAP R/3 nutzt auf Datenebene

relationale Datenbanksysteme (vgl. 4.1).

Zusatzlich zur Generierung der eigentlichen Web Service Komponenten

muss die Moglichkeit zur Erzeugung einer passenden Client-Anwendung gege-

ben sein. Ziel ist es, nicht nur einen Client auf Programmierebene, sondern

auch im Sinne einer graphischen Benutzeroberflache umzusetzen.

Die Realisierung des Generierungsprozesses erfolgt innerhalb der Imple-

mentierung des Projektes Generic Web Services.

1.3 Gliederung der Arbeit

Die Kapitel 2 und 3 der vorliegenden Arbeit dienen der Einfuhrung in die The-

matik der Web Services: Kapitel 2 gibt eine Definition fur verteilte Systeme

und stellt das allgemeine Konzept des Remote Procedure Call zum Zugriff auf

Anwendungen sowie die grundlegende Architektur von Middleware-Losungen

im verteilten System vor. In Kapitel 3 werden diese Aspekte aufgegriffen und

in ihrer speziellen Auspragung im Kontext der Web Services als Middleware

dargestellt. Dabei wird insbesondere auf die Spezifikation des Ubertragungspro-

tokolles SOAP sowie der Schnittstellenbeschreibungssprache WSDL von Web

Services eingegangen.

Kapitel 4 fuhrt grundlegend in das SAP R/3-System ein. Angefangen bei

der Systemarchitekur werden die bedeutenden Softwarekonzepte unter Be-

trachtung des sogenannten Business Framework erlautert. Von besonderem

Interesse sind hier spezielle Schnittstellen, die R/3 bietet und letztlich diese

Arbeit motiviert haben.

Kapitel 5 und 6 befassen sich mit speziellen Middleware-Technologien, ei-

nerseits fur die Anbindung an ein SAP R/3-System, andererseits fur die An-

bindung von relationalen Datenbanksystemen. Beide Ansatze basieren auf Java

und werden in der Verwendung ihrer wichtigsten Funktionalitaten beschrieben.

Mit Kapitel 7 beginnt der Einstieg in die Webapplikation Generic Web Ser-

vices. Hier werden zunachst die grundlegenden Anforderungen beschrieben, die

an Web Services bezuglich ihrer Architektur zu stellen sind. Weiterhin werden

Forderungen an Generic Web Services gestellt, was die konkrete Auspragung

bzw. Implementierung der zu generierenden Web Services angeht.

Der allgemeine Entwurf der Applikation

8

Kapitel 2

Konzepte verteilter

Ausfuhrungsplattformen

Die in diesem Kapitel betrachteten Konzepte sollen keineswegs eine vollstandi-

ge Bearbeitung des Themenkomplexes”Verteilte Systeme“ darstellen, sondern

lediglich in die im Hinblick auf eine Einordnung der Technologie Web Services

notwendigen Zusammenhange einfuhren.

2.1 Definitionen

2.1.1 Verteiltes System

Bis in die 80iger Jahre liefen Computeranwendungen zentralisiert auf einem

System. Mit der Entwicklung und zunehmenden Popularitat von Datenban-

ken und Netzwerken entstanden die mit heutiger Terminologie bezeichneten

2-Tier- bzw. Zwei-Schicht-Anwendungen. Zu der Zeit etablierte sich der Be-

griff der”Client/Server-Systeme“. Anwendungen wurden zerlegt in einen Ap-

plikationsclient und einen Datenbankserver [23]. Die fortschreitende technische

Entwicklung erlaubte unter anderem eine mehr und mehr zunehmende Ver-

netzung und somit immer großere Rechnerverbundsysteme, so dass schließlich

dazu ubergegangen wurde, einzelne am Verbund beteiligte Systeme mit ihren

Anwendungen nach außen transparent zu halten, d. h. bei Ausfuhrung eines

Programmes war fur den Benutzer nicht mehr nachvollziehbar, wo Systemres-

sourcen und wie viele davon in Anspruch genommen wurden. Der Begriff der

”verteilten Systeme“ kam auf.

In der einschlagigen Literatur findet sich diesbezuglich beispielsweise die Defi-

nition von Tanenbaum [13]:

”A distributed system is a collection of independent computers that

appear to the users of the system as a single computer.“

Im Bereich der Softwareumgebung mußten offene Standards geschaffen

werden, um es zu ermoglichen, Anwendungen auf entfernten autonomen Sy-

9

2.2. Middleware-Technologien

stemen dynamisch zu integrieren. Mit der damaligen Version des Distribu-

ted Computing Environment-Standards (DCE) der Open Software Foundation

(OSF)1, einem low-level Request/Response-Modell, wurden von der Sun Mi-

crosystems, Inc. und Microsoft entfernte Prozeduraufrufe (Remote Procedure

Call, RPC) realisiert [2].

Das Prinzip von RPC bildet auch aus heutiger objektorientierter Sicht

die Grundlage fur Middleware-Technologien. RPC wird in diesem Kontext in

Abschnitt 2.2.1 untersucht.

2.1.2 Middleware

Als Middleware bezeichnet man Dienste, die verteilte Anwendungen integrie-

ren, die Systemplattform mit einzelnen Applikationen verbinden oder die In-

tegration von Softwareanwendungen untereinander herstellen.

Die Middleware-Ebene ist eine Sammlung verschiedener Technologien und

Plattformen zum objektorientierten, direkten Datenaustausch zwischen ver-

schiedenen Applikationen.

Middleware konvertiert die Informationen mehrerer Softwaretypen und be-

findet sich in der Regel zwischen einer Anwendung und

• einem Betriebssystem,

• einem Netzwerkbetriebssystem oder

• einem Datenbankmanagementsystem.

2.2 Middleware-Technologien

In [13] wird zwischen vier verschiedenen Middleware-Auspragungen unterschie-

den. Dies sind insbesondere RPC, welches im Folgenden genauer zu beschrei-

ben sein wird, sowie datenzugriffsorientierte Middleware, nachrichtenorientierte

Middleware und objektorientierte Middleware. Da die letzten drei genannten

Typen fur diese Ausarbeitung keine wesentliche Rolle spielen, werden sie nicht

weiter betrachtet2.

2.2.1 Remote Procedure Call (RPC)

Der Mechanismus des Remote Procedure Call macht es innerhalb verteil-

ter Architekturen moglich, Anwendungen auf entfernten Rechnern uber ein

Netzwerk-Protokoll aufzurufen, wobei mit der Entwicklung der objektorientier-

ten Programmiersprachen in den 90er Jahren das Konzept modifiziert werden

1heute als Open Group bekannt2Datenzugriffsorientierte Middleware ist nach Kategorisierung in [13] im Kontext von fode-

rierten Datenbanken zu sehen. Insofern fallt der in dieser Arbeit implementierte Datenbank-

Adapter zur Anbindung relationaler Datenbanksysteme nicht in diese Kategorie.

10

2.3. Service-oriented architecture (SOA)

mußte. Es gilt nunmehr die Anforderung, Objekte client- und serverseitig uber

Protokolle zu referenzieren (ORPC) und deren Methoden aufzurufen. Aufrufen-

de Objekte mussen vom Client fur den Transport protokollkonform serialisiert

und vom Server zu einem programmiersprachenkonformen Objekt deserialisiert

werden, so daß ein aufgerufenes Objekt (Endpoint) initiiert werden kann.

Entfernte und lokale Methodenaufrufe unterscheiden sich dabei prinzipiell

nicht. Das grundlegende Prinzip von RPC-implementierenden Architekturen

besteht darin, die Verteilung durch”Stellvertreterobjekte“ (Stubs und Skele-

tons) zu abstrahieren und so vor den Kommunikationspartnern zu verbergen.

Das verteilte Serverobjekt wird von seinem Skeleton durch eine Schnittstelle

beschrieben, die das Stub-Objekt clientseitig implementiert und somit das

Serverobjekt lokal reprasentiert.

Abbildung 2.1: RPC mit Stub und Skeleton

Das Client-Objekt ruft die Methode lokal in seinem Stub auf. Gemaß der ver-

wendeten RPC-basierten Middleware erfolgt zunachst das als Marshalling be-

zeichnete”Verpacken“ der Anfrage zum Methodenaufruf zusammen mit der

Serialisierung des Stub-Objektes sowie zu ubergebender Parameter. Das server-

seitige Skeleton-Objekt fuhrt ein Unmarshalling und Deserialisieren aus und

ruft die Methode auf dem vom Stub referenzierten Server-Objekt auf. Der

Ruckgabenwert der Methode wird schließlich an den Client zuuckgesendet.

Um Verwirrungen zu vermeiden sei noch erwahnt, daß die CORBA- und

DCOM-Architekturen, die dieses Prinzip implementieren, an dieser Stelle un-

terschiedliche Bezeichnungen verwenden: Die hier verwendeten Namen”Stub“

und”Skeleton“ entsprechen der CORBA-Terminologie. Unter DCOM werden

sie als”Proxy“ und

”Stub“ bezeichnet.

2.3 Service-oriented architecture (SOA)

Die Moglichkeit, Softwarekomponenten in einem verteilten System als Dienste

anzubieten, die uber das Netzwerk abgerufen werden konnen, zum Beispiel

durch RPC-Mechanismen, stellt zusatzliche Anforderungen an die Architektur

der zugrunde liegenden Middleware-Technologien.

11

2.3. Service-oriented architecture (SOA)

2.3.1 Anforderungen und Modell

Serviceorientierte Architekturen (SOA) zeichnen sich dadurch aus, daß sie auf

Basis einer Menge von moglichst unabhangigen Formaten und Protokollen

Dienste gemaß folgenden Anforderungen anbieten konnen:

• Es erfolgt eine strikte Trennung der Schnittstellenmodellierung und der

Implementierung der Applikationslogik. Durch diese lose Kopplung kann

einerseits die Komplexitat der Logik dadurch verborgen bleiben, dass le-

diglich eine sehr kleine Anzahl an Zugriffsmethoden fur bestimmte Funk-

tionalitaten bereitgestellt werden, andererseits beeinflussen interne Mo-

difikationen nicht zwangslaufig den verteilten Zugriff.

• Das dynamische Auffinden von Diensten bzw. Schnittstellen bereitgestell-

ter Applikationslogik kann auf Grund von spezifischen Beschreibungen

ermoglicht werden.

• Eine einfache Integration und ein Austausch der Dienste in bestehenden

Umgebungen resultiert aus einer losen Kopplung sowie der Verwendung

von plattform- und programmiersprachenunabhngigen Protokollen (Wie-

derverwendbarkeit).

Auf dieser Grundlage kann eine Definition einer serviceorientierten Architektur

wie der in [1] gegeben werden:

”An architecture that uses a distributed, discovery-based execution

environment to expose and manage a collection of service-oriented

software assets.“

Abbildung 2.2 [12] visualisiert das Anforderungskonzept, das entsprechend

uber drei Rollen und zugehorigen Operationen spezifiziert werden kann.

2.3.2 Service Provider

Der Service Provider tragt die Implementierung des Dienstes und legt die Funk-

tionalitat fest, die innerhalb der Architektur offentlich gemacht wird. Die ent-

sprechenden Schnittstellen werden uber IDL (Interface Definition Language),

einer architektureigenen Beschreibungssprache, abgebildet, dem Service Broker

zur Verfugung gestellt und registriert.

2.3.3 Service Broker

Der Service Broker verwaltet als zentral zugreifbare Einheit die Informatio-

nen der veroffentlichten Dienste. Dazu gehoren gleichermaßen semantische Be-

schreibungen, Informationen uber die Erreichbarkeit des Service Provider sowie

12

2.3. Service-oriented architecture (SOA)

Abbildung 2.2: Service-oriented architecture (SOA)

die Spezifizierung des Zugriffsmechanismus (zum Beispiel RPC). Als Reposi-

tory dient der Broker gleichzeitig dem Service Consumer, indem er registrierte

Dienste klassifizieren und so auf Suchanfragen der Consumer reagieren und

entsprechende Informationen liefern kann.

2.3.4 Service Consumer

Der Service Consumer ist der Nutzer der Dienste. Er erhalt vom Service

Broker uber die Interaktion suchen alle notwendigen Informationen, um

einen Dienst zu lokalisieren und zu binden: Die detaillierte Auskunft, die die

Schnittstellenbeschreibung uber den Dienst gibt, wird vom Consumer genutzt,

um eine Ausfuhrungsanfrage einschließlich der erforderlichen Parameter zu

erzeugen und an den Provider zu senden.

Das vorgestellte Modell stellt eine Standard-Architektur fur verteilte Sy-

steme dar. Die herstellerspezifischen Protokolle, Schnittstellenbeschreibungs-

sprachen, RPC-Implementierungen, etc. sind jedoch vielfaltig. Um einen Ein-

blick zu erlangen, wird in Tabelle 2.1 eine Ubersicht uber bekannte SOA-

Implementierungen und deren Formate gegeben3. Von Standardisierung und

Plattformunabhangigkeit kann demnach nicht die Rede sein.

3Es werden lediglich die Abkurzungen der genannten Technologien erlautert. Auf eine

detaillierte Beschreibung kann verzichtet werden.

13

2.3. Service-oriented architecture (SOA)

Java RMI1 CORBA DCE Web Services

Aufruf-

MechanismusJava RMI CORBA RMI RPC JAX-RPC, .NET, . . .

Daten-

FormatSerialized Java CDR2 NDR3 XML

Ubertragungs-

FormatStream GIOP4 PDU5 SOAP

Ubertragungs-

ProtokollJRMP6 IIOP7 RPC CO8 HTTP, SMTP, . . .

Interface-

BeschreibungJava Interface CORBA IDL DCE IDL WSDL

Auffind-

MechanismusJava Registry COS naming9 CDS10 UDDI

Tabelle 2.1: Beispiele fur SOA Formate und Protokolle

An dieser Stelle treten Web Services in den Vordergrund: Die Realisie-

rung dieser”Internet-Middleware“ mit ihren XML-basierter Komponenten

ermoglicht nicht zuletzt eine herstellerunabhangige serviceorientierte Architek-

tur. Applikationen konnen flexibel und nach offenen Standards komponenten-

weise von Grund auf (bottom-up) entwickelt und integriert werden. Speziell im

B2B-Umfeld ist es von Interesse, zeit- und kostenkritische Entwicklungen und

Modifikationen auf die Wiederverwendung verfugbarer Dienste mit existieren-

den Basistechnologien zu reduzieren. Das Konzept der SOA aus der Sicht von

Web Services bildet daher die Grundlage fur die Umsetzung der Aufgabenstel-

lung dieser Arbeit. Das folgende Kapitel behandelt ausfuhrlich die charakteri-

stischen Technologiespezifikationen.

1Java Remote Method Invocation2Common Data Representation3Network Data Representation4General Inter-ORB Protocol5Protocol Data Units6Java Remote Method Protocol7Internet Inter-ORB Protocol8Remote Procedure Call Connect-Oriented protocol9CORBA Object Services naming

10Cell Directory Service

14

Kapitel 3

Web Services

3.1 Definition

Der Begriff”Web Service“ umschreibt eine Technologie, die die Interaktion

zweier Systeme uber ein Netzwerk ermoglicht. Dabei bedient sie sich typischer-

weise des Internet-Protokolls HTTP bei der Datenubertragung und stutzt ihre

Kommunikationssprache und offentlichen Schnittstellendefinitionen auf die Be-

schreibungssprache XML. Das World Wide Web Consortium (W3C) gibt mit

Beginn der Entwicklung einer Referenz-Architektur die folgende Definition ei-

nes Web Service[19]:

”A Web Service is a software application identified by a URI, whose

interfaces and binding are capable of being defined, described and

discovered by XML artifacts and supports direct interactions with

other software applications using XML based messages via Internet-

based protocols.“

Web Services implementieren jedoch keine Client/Server-Architektur im Sinne

einer direkten Interaktion mit einem Benutzer wie zum Beispiel das Zusam-

menspiel von Webserver und Webseite verstanden werden kann. Web Services

bieten keine graphische Benutzeroberflache. Die Kommunikation umfasst den

Austausch von Applikationslogik, Daten und Prozessen mit anderen Anwen-

dungen uber eine Programmschnittstelle. Programme stellen somit die Kom-

munikationspartner auf beiden Seiten dar. Stattdessen konnen Web Service

Clients uber ein GUI initiiert und vom Web Service Provider zur Verfugung

gestellte Funktionalitat integriert und dem Benutzer visuell dargeboten werden.

Praktisch umgesetzt wird dieser Ansatz im Kontext der vorliegenden Aufga-

benstellung: Der Prozess der Generierung der Web Services beinhaltet gleicher-

maßen ein webbasiertes Frontend, Web Service Invocation Framework (WSIF)

genannt (siehe Kapitel 9.3).

15

3.2. Web Services architecture (WSA)

3.2 Web Services architecture (WSA)

Das Grundkonzept der serviceorientierten Architektur wurde bereits in 2.3 vor-

gestellt. Web Sevices implementieren diese Architektur mit Hilfe dreier XML-

basierter Formate:

• Simple Object Access Protocol (SOAP)

• Web Services Description Language (WSDL)

• Universal Description, Discovery and Integration (UDDI)

Betrachtet man diese im Kontext von Web Services eingesetzten Tech-

nologien kann die Abbildung 2.2 zu einer Web Services Architektur (WSA)

konkretisiert werden [12]:

Abbildung 3.1: Web Services architecture (WSA)

3.3 Simple Object Access Protocol (SOAP)

Das Simple Object Access Protocol (SOAP) wird in der Spezifikation 1.1 als

ein”einfacher Mechanismus fur den Austausch strukturierter und typisierter

Informationen zwischen Rechnern in einer dezentralen verteilten Umgebung

auf Basis von XML“ beschrieben [16]. Eine andere Definition nennt SOAP

”ein XML-/HTTP-basiertes Protokoll fur den plattformunabhangigen Zugriff

auf Dienste, Objekte und Server“.

Die Entwicklung von SOAP wurde 1998 von Microsoft und anderen Firmen

begonnen. Im gleichen Jahr hat sich aus einer fruhen Version der Spezifikation

das Protokoll XML-RPC [21] abgespalten. Eine erste Version von SOAP hat

Microsoft dann im November 1999 uber die Internet Engineering Task Force

(IETF) veroffentlicht, woraufhin sich Firmen wie IBM, SAP AG und andere der

16

3.3. Simple Object Access Protocol (SOAP)

Entwicklungsgruppe um Microsoft anschlossen. Im Mai 2000 wurde die SOAP

Spezifikation in der Version 1.1 beim World Wide Web Consortium (W3C)

eingereicht. Aufgrund seiner breiten Unterstutzung in der Softwareindustrie

ist SOAP 1.1 aber als De-facto-Standard zu bezeichnen.

In diesem Abschnitt werden zunachst die bedeutendsten Aspekte der

SOAP Spezifikation herausgearbeitet. Der Begriff”Web Services“ und dazu-

gehorige Technologien, vor allem die fur SOAP oft verwendete Schnittstellen-

beschreibungssprache WSDL, werden im Anschluss daran kurz vorgestellt.

Aus Komplexitatsgrunden mussen viele Details der Spezifikationen vorent-

halten bleiben.

3.3.1 SOAP Nachricht

Die SOAP Spezifikation definiert eine XML Grammatik, mit der strukturier-

te und typisierte Informationen zu einer Nachricht zusammengefasst werden

konnen. Eine SOAP Nachricht ist ein XML-Dokument, auch Umschlag (Enve-

lope) genannt, das einen optionalen Kopfinformations-Teil (Header) und den

eigentlichen Inhaltsteil (Body) enthalt. Listing 3.1 zeigt den grundsatzlichen

Aufbau einer SOAP-Nachricht.

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP:Header>

</SOAP:Header>

<SOAP:Body>

</SOAP:Body>

</SOAP:Envelope>

Listing 3.1: Aufbau einer SOAP Nachricht

Der SOAP Envelope gehort zum XML Namespace1

"http://schemas.xmlsoap.org/ soap/envelope/". Der Body

als eigentlicher Nutzdaten-Teil einer SOAP Nachricht muss genau einmal

im SOAP Envelope vorkommen und zwar als direktes Kind-Element des

Envelope. Der Body wiederum kann beliebig viele direkte Kind-Elemente

enthalten, die sogenannten Body-Elemente.

1XML Namespace ist ein W3C-Standard fur Namensraume in XML Dokumen-

ten zur Vermeidung von Namenskollisionen. Namensraume werden durch einen Uni-

form Resource Identifier (URI) gekennzeichnet, konnen in XML-Dokumenten uber

das Attribut xmlns eingefuhrt werden und erhalten dabei einen Kurznamen (z. B.

xmlns:meinns="http://meine.firma.org/meinns"). Namen konnen qualifiziert ver-

wendet werden, indem der lokale Teil – durch einen Doppelpunkt abgetrennt – von ei-

nem Namensraum-Prafix erganzt wird (z. B. meinns:einname). Ein solcher namensraum-

qualifizierter Name wird auch als QName bezeichnet.

17

3.3. Simple Object Access Protocol (SOAP)

3.3.2 Kodierung und Datentypen

Die Kodierung der in den Body-Elementen ubertragenen Daten kann mit

dem Attribut encodingStyle fur jedes Body-Element einzeln festge-

legt werden. Die Angabe des encodingStyle-Attributes im Envelope-

Element legt eine Standard-Kodierung fest, die verwendet wird, falls in

den Kind-Elementen keine eigene Kodierung festgelegt wurde. Die SOAP

Spezifikation schlagt eine Kodierung vor, die uber den Namensraum

"http://schemas.xmlsoap.org/soap/encoding/" verwendet werden

kann. Sie basiert auf einem einfachen Typsystem, das die wichtigsten Typen

gangiger Programmiersprachen abdeckt.

Das Typsystem unterscheidet einfache und zusammengesetzte Datentypen.

Die SOAP Spezifikation ubernimmt als einfache Datentypen die Datentypen

von XML Schema [18]. Das sind unter anderem:

• int : Integer-Wert

• float : Fließkommawert

• string : Zeichenkette

• enumerations Mengen zulassiger Werte

• array of bytes Binardaten

Da in XML die Daten vollstandig im Klartext erscheinen, wird ein XML-

Dokument unnotig aufgeblaht, wenn derselbe Wert mehrfach vorkommt. Des-

halb kann Elementen uber das optionale Attribut id ein Identifikator zugewie-

sen werden. Geschieht dies wie im folgenden Beispiel bei einem String-Element,

konnen andere String-Elemente uber das Attribut href auf den String des ersten

Elements verweisen:

<name id="String-0">Mustermann</name><suchname href="#String-0"/>

Die Elemente name bzw. suchname in diesem Beispiel werden auch als

Zugriffselemente (accessor) fur den String Mustermann bezeichnet.

Zu Datenelementen in einer SOAP Nachricht kann der Typ explizit

angegeben werden. Dies geschieht uber das Attribut xsi:type aus dem

Namensraum "http://www.w3.org/2001/XMLSchema-instance", der

ublicherweise mit xsi bezeichnet wird. Der Datentyp selbst kann di-

rekt aus XML Schema [18] entnommen werden, der Namensraum lau-

tet dann "http://www.w3.org/2001/XMLSchema" (die ubliche Kurz-

bezeichnung lautet xsd). Die SOAP Datentypen sehen aber einige Be-

sonderheiten vor. So sind z. B. die oben beschriebenen String-Referenzen

mit den Attributen id und href nicht in der XML Schema Definition

enthalten. Sollen die Besonderheiten genutzt werden, ist der Namensraum

18

3.3. Simple Object Access Protocol (SOAP)

"http://schemas.xmlsoap.org/soap/encoding/" zu verwenden (die

ubliche Kurzbezeichnung lautet SOAP-ENC). Das folgende Beispiel zeigt die

explizite Angabe des Elementtyps unter der Annahme, dass die Namensraume

xsd, xsi und SOAP-ENC an fruherer Stelle in der SOAP Nachricht eingefuhrt

wurden. Diese Annahme gelte in allen folgenden Beispielen dieses Abschnitts.

<name id="String-0" xsi:type="SOAP-ENC:string">Mustermann</name>

Auf die explizite Angabe des Datentyps kann verzichtet werden, wenn sich

der Typ aus einer Schema-Beschreibung (z. B. einem WSDL-Dokument, siehe

Abschnitt 3.4) ergibt.

Viele Programmiersprachen sehen universelle Datentypen vor, deren In-

stanzen die Werte von verschiedenen Typen annehmen konnen (in CORBA

z.B. der Typ any). SOAP unterstutzt solche universellen Datentypen mit den

sogenannten polymorphen Zugriffselementen (polymorphic accessors). Instan-

zen dieses universellen Datentyps mussen ihren Typ immer explizit angeben.

Neben den einfachen Datentypen unterstutzt SOAP auch die folgenden

zusammengesetzten Datentypen:

• struct : entspricht den aus Programmiersprachen bekannten Struktu-

ren bzw. Records. Die Namen der Zugriffselemente dienen als einzige

Unterscheidung zwischen den Attributen. Die Reihenfolge ist also nicht

relevant. struct-Typen sind durch ein eigenes Schema in einem eigenen

Namensraum zu definieren. Ein Beispiel fur eine Instanz des struct-

Typs ist Adresse:

<beispiel:musteradresse xsi:type="beispiel:Addresse"xmlns:beispiel="http://schema.adresse.de/adresseschema>

<strasse xsi:type="xsd:string">Talweg</strasse><hausnr xsi:type="xsd:string">12</hausnr><ort xsi:type="xsd:string">Saarbrcken</ort>

</beispiel:musteradresse>

• array : entspricht den aus Programmiersprachen bekannten Feldern

bzw. Arrays. Hier haben alle Zugriffselemente den gleichen Namen; die

Unterscheidung der einzelnen Elemente erfolgt ausschließlich uber die

Position, an der sie genannt werden. Der Typ fur SOAP Felder lau-

tet SOAP-ENC:array. Der Typ der Feld-Elemente ist in der Variable

SOAP-ENC:arrayType anzugeben und kann z. B. xsd:int[2] lau-

ten fur ein zweielementiges Feld des Grundtyps xsd:int. SOAP bietet

auch eine Unterstutzung fur nur teilweise ubermittelte oder nur teilweise

belegte Felder.

• Mischformen : SOAP unterstutzt auch Mischformen, in denen die Ele-

mente zwar uber ihren Namen referenziert werden wie in einer Struktur,

aber einzelne Elemente mehrfach auftauchen konnen wie in einem Feld.

19

3.3. Simple Object Access Protocol (SOAP)

Die verschiedenen zusammengesetzten Datentypen konnen ineinander ver-

schachtelt werden, beispielsweise in einem Feld uber einem struct-Typ oder

in mehrdimensionalen Feldern. Auch bei zusammengesetzten Datentypen sind

Referenzen mit den Attributen id und href zulassig.

Werden in SOAP Nachrichten einzelne Elemente weggelassen, kann dies

entweder einen Standard-Wert implizieren oder, dass der Wert unbekannt ist

(null-Wert). Die SOAP Spezifikation uberlasst dies dem einzelnen Anwen-

dungskontext.

3.3.3 SOAP fur RPC

Eine der erklartermaßen wichtigsten Anwendungen von SOAP ist die Verwen-

dung fur den entfernten Prozedur- bzw. Methodenaufruf RPC. Das Verfahren

basiert auf dem Anfrage-Antwort-Mechanismus. Der Unterschied liegt in erster

Linie in veranderten Nutzdaten: Statt dem Austausch von allgemeinen Doku-

menten werden in der Anfrage serialisierte Parameter ubermittelt, um damit

eine entfernte Methode aufzurufen. Als Antwort wird das serialisierte Ergebnis

zuruckgesendet (Abschnitt 2.2.1).

Der Methodenaufruf wird wie folgt mit einer SOAP Nachricht ubertragen:

• Der Aufruf wird als Struktur im SOAP Body modelliert. Die Struktur

tragt den Namen der Methode. Jeder in- und in/out-Parameter wird

Element dieser Struktur. Name und Typ des Elementes mussen mit dem

Namen und dem Typ des Methodenparameters ubereinstimmen. Die Pa-

rameter sind in der gleichen Reihenfolge aufzufuhren wie in der Metho-

densignatur vorgesehen.

• Zusatzinformationen, die zur Verarbeitung notig sind, die aber nicht zu

den Methodenparametern gehoren, konnen als SOAP Header Elemente

aufgefuhrt werden. Ein Beispiel hierfur waren etwa Transaktionsnum-

mern, die typischerweise nicht zu einer Methodensignatur gehoren und

von einer Infrastrukturkomponente (dem Transaktionsmanager) verar-

beitet werden statt von der Anwendung selbst.

Das Methodenergebnis wird ebenfalls mittels einer SOAP Nachricht unter

Berucksichtigung der folgenden Festlegungen ubertragen:

• Auch das Ergebnis wird als Struktur im SOAP Body modelliert. Jeder

out- und in/out-Parameter wird Element dieser Struktur. Wieder mussen

Name und Typ ubereinstimmen. Als erstes Element ist das Methodener-

gebnis beliebig benannt aufzufuhren, es folgen die Parameter in derselben

Reihenfolge wie in der Methodensignatur.

• Tritt bei der Bearbeitung der Methode ein Fehler auf, ist statt der Er-

gebnisstruktur das SOAP Fault Element zu verwenden. Außerdem ist die

20

3.4. Web Services Description Language (WSDL)

Fehlerbehandlung des Transportprotokolls zusatzlich zu verwenden (z. B.

Verwendung eines HTTP Fehlercodes in der HTTP Response).

3.4 Web Services Description Language (WSDL)

Damit der effektive Zugriff auf Web Services moglich ist, benotigt ein Client

eine moglichst exakte Beschreibung, welche Informationen ein SOAP Request

enthalten muss und wie die SOAP Nachrichten aussehen, die er vom Web Ser-

vice zuruckerhalten wird. Eine Sprache fur solche Beschreibungen ist die Web

Services Description Language (WSDL) [20]. WSDL wurde von den Firmen

Microsoft und IBM gemeinsam entwickelt und als Version 1.1 im Marz 2001

an das W3C ubermittelt.

Die Spezifikation klassifiziert WSDL als eine XML Grammatik zur Be-

schreibung von Netzwerkdiensten. Dabei werden die Dienste als Netzwerkkno-

ten betrachtet, die Nachrichten mit anderen Knoten austauschen konnen. Das

Hauptaugenmerk liegt auf SOAP Diensten. WSDL schließt aber auch andere

Protokolle nicht aus.

WSDL Dokumente konnen als Vertrag zwischen Client und Server uber die

Details der gemeinsamen Kommunikation aufgefasst werden. Es handelt sich

also um eine Schnittstellenbeschreibungssprache (Interface Definition Langua-

ge, IDL).

WSDL sieht folgende abstrakte Definitionen vor:

• Types : Definition eigener Datentypen, z. B. Strukturen.

• Messages : Definition von Nachrichtentypen, also Klassen von Nachrich-

ten.

• Port Types : Ein Port Type ist eine Menge abstrakter Operationen. Je

Operation werden mehrere Messages zu Eingabe-, Ausgabe- und Fehler-

nachrichten zusammengesetzt und so Operationssignaturen beschrieben.

Ein Port Type ist eine abstrakte Definition, die noch nicht festlegt, mit wel-

chem Protokoll (z. B. SOAP) die Ubertragung der Nachrichten erfolgt und wie

einzelne Parameter dieses Protokolls zu wahlen sind (z. B. das Transportproto-

koll HTTP). Diese Festlegung kann fur jeden Port Type mit einem sogenannten

Binding geschehen. Je Port Types sind auch mehrere unterschiedliche Bindings

zulassig.

Ein Binding wird in WSDL durch das Element binding be-

schrieben, mit den Attributen name, das den Namen festlegt, sowie

type, das auf den Port Type verweist. Ein Binding muss genau ein

Nachrichtenaustausch-Protokoll festlegen. Im Falle von SOAP geschieht

dies mit dem leeren Kindelement soap:binding aus dem Namensraum

21

3.4. Web Services Description Language (WSDL)

soap="http://schemas.xmlsoap.org/wsdl/soap/". Mit dem Attri-

but transport von soap:binding kann das Transportprotokoll festgelegt

werden (z. B. "http://schemas.xmlsoap.org/soap/http").

<binding ... >

<soap:binding>

<operation ... >

<soap:operation .../>

<input><soap:body .../>

<soap:header ...> ... </soap:header></input>

<output><soap:body .../>

<soap:header ...> ... </soap:header></output>

</operation>

</binding>

Listing 3.2: Struktur des WSDL Elementes binding

Abbildung 3.2 zeigt die Struktur des WSDL Elements binding und sei-

ner Kindelemente. Jede Operation wird durch ein Kindelement operation

beschrieben, dessen Attribut name mit dem Namen der entsprechenden Ope-

ration des Port Type ubereinstimmen muss. Ein operation Element besteht

wiederum aus folgenden Kindelementen:

• soap:operation Ein leeres Element zur Festlegung weiterer SOAP-

spezifischer Attribute, z. B. des HTTP-Headers SOAPAction.

• input Innerhalb dieses Elementes wird festgelegt, wie zu dem im Port

Type festgelegten Eingangsnachrichtentyp eine konkrete SOAP Nachricht

gewonnen werden kann. Diese SOAP-spezifische Festlegungen werden mit

Hilfe der Kindelemente soap:body und soap:header getroffen.

• output Analog zu input, nur auf die Ausgangsnachricht bezogen.

Das Binding konkretisiert also den abstrakten Port Type im Hinblick auf

die Details der Datenubermittlung. Damit diese Informationen nicht nur fur

einen einzigen konkreten Server verwendet werden konnen, darf das Binding

noch keine Adressinformationen enthalten. Dies ist dem sogenannten Port vor-

behalten, der ein Binding mit einer konkreten Adresse verknupft. Mehrere

Ports konnen dann zu einem Service gruppiert werden.

22

3.4. Web Services Description Language (WSDL)

Das konkrete Beispiel einer WSDL Datei in Listing 3.3 ist fur das Verstand-

nis hilfreich. Die Nachrichtentypen getPreisRequest als Eingabenachrich-

tentyp und getPreisResponse als Ausgabenachrichtentyp ergeben zusam-

men die Operation getPreis. Diese Operation ist die einzige Operation des

KatalogPortType. Mit dem KatalogBinding wird der Port Type kon-

kretisiert. Der KatalogPort beinhaltet schließlich auch Adressinformationen

und ist der einzige Port im KatalogService. Damit ist ein konkreter Dienst

vollstandig beschrieben.

In dem Listing sind die Querverweise innerhalb der WSDL Definition farbig

markiert.

<?xml version="1.0" encoding="UTF-8"?><definitions name="Katalog"

targetNamespace="http://beispiel.org/Katalog"xmlns:myns="http://beispiel.org/Katalog"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns="http://schemas.xmlsoap.org/wsdl/">

<types></types>

<message name="getPreisRequest"><part name="artikelnummer" type="xsd:int"/><part name="waehrung" type="xsd:string"/>

</message>

<message name="getPreisResponse"><part name="result" type="xsd:int"/>

</message>

<portType name="KatalogPortType"><operation name="getPreis">

<input message="myns:getPreisRequest"/><output message="myns:getPreisResponse"/>

</operation></portType>

<binding name="KatalogBinding" type="myns:KatalogPortType"><soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="getPreis">

<soap:operation soapAction="http://beispiel.org/Katalog" style="rpc"/><input>

<soap:body use="encoded" namespace="http://beispiel.org/Katalog"encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<input><output>

<soap:body use="encoded" namespace="http://beispiel.org/Katalog"encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<output><operation>

<binding>

<service name="KatalogService"><documentation>Ein Beispiel-Service</documentation><port name="KatalogPort" binding="myns:KatalogBinding">

<soap:address location="http://ein.host.beispiel.org/soapservlet/Katalog"/></port>

</service></definitions>

Listing 3.3: Beispiel einer WSDL Definitionsdatei

23

3.5. Universal Description, Discovery and Integration (UDDI)

3.5 Universal Description, Discovery and Integrati-

on (UDDI)

Einen Verzeichnisdienst fur Web Services hat ein Industriekonsortium unter

Fuhrung der Firmen IBM, Microsoft und Ariba mit der Universal Description,

Discovery and Integration Spezifikation (UDDI, dt.: Universelle Beschreibung,

Auffindung und Integration) vorgelegt.

UDDI spezifiziert ein Datenmodell zur Beschreibung von Anbietern und

Web Services sowie eine auf SOAP aufbauende Programmierschnittstelle zur

Abfrage und Veroffentlichung solcher Daten. Das Verzeichnis wird dezentral

von mehreren Anbietern gepflegt, mit einer automatischen Replikation der ein-

zelnen Datenbanken. Dies ist vergleichbar mit dem Verfahren beim DNS (Do-

main Name Service), einem im Internet eingesetzten Dienst zur Auflosung von

Hostnamen in IP-Adressen.

UDDI unterstutzt drei wichtige Nutzungsarten:

•”White Pages“ : Sie enthalten Informationen uber Firmen inkl. Na-

men, Kontaktinformationen und einer Klartextbeschreibung und sind

vergleichbar mit einem Telefonbuch)

•”Yellow Pages“ : Sie tragen Informationen uber Tatigkeitsfelder, d. h.

Branchen, Produkte und regionale Tatigkeitsfelder und sind vergleichbar

mit den gelben Seiten eines Telefonbuches.

•”Green Pages“ : Sie liefern Informationen uber E-Business Dienste,

insbesondere Web Services. Es werden dabei verschiedene Abstraktions-

grade unterschieden, die funktionelle Ebene, die technische Ebene und

die Implementierungsebene.

Der UDDI fallt im Rahmen der Diplomarbeit keine wesentliche Bedeutung

zu, so dass keine detailliertere Betrachtung vorgenommen wird. Stattdessen

wird auf [14] verwiesen.

24

Kapitel 4

SAP R/3

Die SAP AG stellt mit SAP R/3 den wohl wichtigsten Vertreter betriebswirt-

schaftlicher Standard-Software. SAP R/3 bietet branchenneutrale Losungen

fur Bereiche wie Logistik und Personalwirtschaft, die individuellen Kundenan-

forderungen angepasst werden kann1.

Auf Grund der daraus resultierenden enormen Komplexitat und Vielfalt

an unterstutzten Technologien kann im Rahmen dieses Kapitels lediglich ein

Einblick in das System gegeben werden. Es werden grundlegende Kenntnisse

uber die Architektur des Basis-Systems sowie das R/3-Business Framework

vermittelt, die fur Thematik der Arbeit von Bedeutung sind.

Die Ausfuhrungen stutzen sich auf Informationen der SAP Bibliothek, die

als Online-Dokumentation [8] umfangreiche Erlauterungen zu allen SAP R/3-

Komponenten bietet.

4.1 Systemarchitektur

Das SAP R/3-System ist ein mehrstufiges Client/Server-System. Es basiert

auf einer dreigeteilten Softwarearchitektur, wobei jeder Anwendungsebene ei-

ne eigene Komponentenschicht zugeteilt ist, so dass eine Trennung in Prasen-

tationsschicht (Frontend-Client), Applikationsschicht (Applikationsserver) und

Datenbankserver (Backend) erfolgt. Die einzelnen Softwarekomponenten fun-

gieren je nach Schicht als Client oder Server fur die Komponenten der anderen

Schichten.

Ein zentrales Datenbanksystem, das alle Daten des R/3-Systems verwal-

tet, bildet die Datenbankschicht. SAP stellt kein eigenes Datenbanksystem fur

R/3 zur Verfugung und unterstutzt infolgedessen Fremdsysteme verschiedener

Hersteller, z. B. ORACLE, Microsoft SQL Server oder DB2.

Die Datenbank enthalt nicht nur die betriebswirtschaftlichen Daten der

Anwendungsprogramme, sondern ist die zentrale Datenablage fur das gesamte

1Nachdem das R/3-System um internetbasierte Funktionalitaten und Technologien erwei-

tert wurde, wird es unter dem Namen”mySAP“ vermarktet.

25

4.2. Business Framework

R/3-System. Insbesondere enthalt die Datenbank auch Steuerungsdaten, die

das Verhalten des R/3-Systems festlegen. Diese in einem speziellen Teil der

Datenbank gehaltenen Komponenten werden als R/3-Repository bezeichnet.

Die Softwarekomponenten des R/3-Systems auf Applikationsebene be-

stehen aus einem oder mehreren Applikationsservern, die eine Anzahl von

Diensten fur den Betrieb zur Verfugung stellen. Die sich durch den Einsatz

von verteilten Ausfuhrungsplattformen ergebenden Vorteile sind auch fur R/3

relevant. Die Moglichkeit der Verteilung der Dienste gewahrt eine anforde-

rungsgemaße Konfiguration der Einzelsysteme. Eine hohe Skalierbarkeit der

Applikationsserver sorgt fur eine flexible Organisation des Systemkomplexes.

In der Praxis werden daher mehrere Applikationsserver auf jeweils separaten

Rechnern aufgesetzt, um zudem die lokal auftretende Systemlast zu reduzieren

und kurze Antwortzeiten zu ermoglichen. Alle Applikationsserver eines R/3-

Systems bilden zusammen die Applikationsschicht der Architektur.

Die Prasentationsschicht bilden in R/3 die Komponenten der SAP-eigenen

graphischen Oberflache SAP GUI (Graphical User Interface). Sie stellen die

Schnittstelle zu den Benutzern dar.

Die komponentenorientierte Entwicklung von Anwendungen ist eine der Grund-

voraussetzungen dafur, mit SAP R/3 ein offenes System zu realisieren. Zusam-

men mit Standards fur Kommunikationsschnittstellen wird das Zusammenspiel

und die Portierbarkeit von Funktionalitaten und Daten auch auf Fremdsysteme

ermoglicht. Diese Umsetzung fuhrt zur Architektur des Business Framework.

4.2 Business Framework

Das SAP R/3-Business Framework setzt eine Strukturierung der R/3-

Anwendungsfunktionalitaten in einzelne Softwarekomponenten (Business-

Komponenten) und Objektmodelle um. Diese Einfuhrung von”Black-

Box-Ansatzen“, d. h. die Modularisierung und Schnittstellenbildung tragt

wesentlich zur Komplexitatsreduzierung des Gesamtsystems bei und ermoglicht

es, Komponenten beliebig untereinander sowie mit kompatiblen Modellen

von Kunden und Partnern zu koppeln, so dass eine Interaktion mit externen

Anwendungen stattfinden kann.

Die wichtigen Bestandteile der Business Framework Architektur sind:

• Business-Komponenten

Die Business-Komponenten sind eigenstandige funktionelle Einheiten,

die sich aus Business-Objekten zusammensetzen. Geschaftsprozesse wer-

den entweder innerhalb einer Business-Komponente implementiert oder

erstrecken sich uber mehrere Komponenten (verteilte Geschaftsprozes-

se). Beispielsweise sind der Business-Komponente Human Resources

26

4.2. Business Framework

unter anderem die Business-Objekte Employee (Mitarbeiter) und

Applicant (Bewerber) untergeordnet (Tabelle 4.1).

• Business-Objekte

Business-Objekte sind die Grundlage der objektorientierten Struk-

turierung des R/3-Systems. Sie kapseln die betriebswirtschaftlichen

Daten und Funktionalitaten und helfen, Geschaftsobjekte in SAP R/3

programmtechnisch abzubilden. Sie sind mit Klassen einer objektorien-

tierten Programmiersprache zu vergleichen.

SAP Business-Komponente SAP Business-Objekt

SAP HR Employee (Mitarbeiter)

(Human Resources) Applicant (Bewerber)

SAP FI Company (Unternehmen)

(Financials) Debtor (Debitor)

Vendor (Lieferant)

SAP LO Material (Material)

(Logistics) MaterialBOM (Materialstuckliste)

MaterialGroup (Warengruppe)

ProductCatalog (Produktkatalog)

SalesOrder (Kundenauftrag)

PurchaseOrder (Bestellung)

PurchaseRequisition (Bestellanforderung)

Tabelle 4.1: Beispiele fur SAP Business-Komponenten und ihre Objekte

• Business Application Programming Interfaces (BAPIs)

BAPI s ermoglichen als Programmierschnittstelle an den Business-

Objekten den objektorientierten Zugriff auf das R/3-System. Zusammen

mit den Business-Objekten definieren und dokumentieren die BAPIs den

Schnittstellenstandard auf betriebswirtschaftlicher Ebene.

• Integrationsdienst ALE (Application Link Enabling)

Voraussetzung fur die technische Integration verteilter Geschaftsprozesse

ist, die Daten kontrolliert austauschen und konsistent halten zu konnen.

Diese Aufgabe ubernimmt das Verteilungsmodell des Application Link

Enabling, das fur eine systemubergreifende Verteilung von Business-

Objekten zwischen SAP Systemen einerseits und zwischen SAP Systemen

und Fremdsystemen andererseits sorgt.

27

4.3. Business-Komponenten

• Kommunikationsdienste

Kommunikationsdienste sind Kommunikationstechnologien wie beispiels-

weise der Remote Function Call (RFC), einer SAP-eigenen Implementie-

rung des RPC-Protokolls, der DCOM-Standard von Microsoft oder COR-

BA, die das Business Framework verwendet, um auf BAPIs zuzugreifen.

Die nachfolgenden Abschnitte behandeln die Architekturkomponenten im Ein-

zelnen.

4.3 Business-Komponenten

Die SAP Business-Komponenten implementieren spezifische Funktionen auf

betriebswirtschaftlichen Daten. Dabei reprasentieren sie diese Funktionalitaten

uber die zugehorigen Business-Objekte und fassen sie als logische Gruppe zu-

sammen. Das Modell der Business-Komponenten und -Objekte erlaubt die

Entkopplung der technischen Realisierung und der betriebswirtschaftlichen

Geschaftslogik, was bedeutet, dass eine komponenteninterne Anderung der Im-

plementierung von Geschaftsregeln und -prozessen oder die Einfuhrung neuer

Technologien innerhalb von R/3 keinen Einfluß auf die Ausfuhrbarkeit der An-

wendungen hat, die diese Business-Komponente nutzen.

4.4 Business-Objekte

Die SAP Business-Objekte werden dazu verwendet, betriebswirtschaftliche

Sachverhalte der realen Welt im SAP R/3-System abzubilden und vor allem

zu handhaben. Business-Objekte reprasentieren sowohl konkrete oder abstrak-

te Gegenstande als auch Tatigkeiten oder Ablaufe. Beispiele sind Bestellungen,

Vertrage, Kunden oder Telefonanrufe.

Die Business-Objekte beinhalten sowohl die Funktionalitaten (Objektme-

thoden) als auch die Daten (Objektattribute) dieser Sachverhalte, kapseln je-

doch die Datenstrukturen und Funktionsimplementierungen und verbergen auf

diese Weise ihre Komplexitat. Dies entspricht dem Grundgedanken der Objek-

torientierung.

Um diese Kapselung zu erreichen, bestehen die SAP Business-Objekte aus

mehreren Schichten, wie in der Abbildung 4.1 dargestellt ist.

• Kern

Der Kern ist die innerste Schicht des SAP Business-Objektes und stellt

die eigentlichen Daten.

• Integritatsschicht

28

4.4. Business-Objekte

Abbildung 4.1: Schichten eines SAP Business-Objektes

Die zweite Schicht, die Integritatsschicht, beinhaltet die betriebswirt-

schaftliche Logik des Objektes. Sie umfasst Geschaftsregeln zur konsisten-

ten Integrierung der Objektdaten sowie Einschrankungen (Constraints)

auf Werten, die fur die Business-Objektattribute moglicherweise gelten.

• Schnittstellenschicht

Die dritte Schicht beschreibt die erlaubten Zugriffsmoglichkeiten auf das

Business-Objekt. Sie definiert somit die Schnittstelle des Objektes nach

außen und wird daher als Schnittstellenschicht bezeichnet. Hier sind die

Zugriffsmethoden (BAPIs) anzusiedeln.

• Zugriffsschicht

Die vierte und außerste Schicht eines Business-Objektes ist die Zugriffs-

schicht. Sie definiert die Middlewaretechnologien, mit denen ein externer

Zugriff auf die Objektdaten moglich ist.

Wie die Abbildung zeigt, trennt die Schnittstellenschicht die Daten eines

Business-Objektes von den Anwendungen und Technologien, mit denen auf

diese Daten zugegriffen wird. Nach außen ist dadurch nur eine Schnittstelle

von klar definierten Methoden sichtbar, uber die Anwendungen auf die Daten

des Business-Objektes zugreifen konnen. Daher genugen dem Anwendungspro-

grammierer Informationen uber diese Methoden, um das Business-Objekt nut-

zen zu konnen. Kenntnisse uber die SAP-spezifischen Implementierungsdetails

sind nicht erforderlich.

An dieser Stelle soll bei Business-Objekten nun unterschieden werden zwi-

schen den Business-Objekttypen oder -Objektklassen und der Instanz eines

Business-Objektes. Wahrend Objekttypen Beschreibungen eines Objektes sind

und diese definieren, bezeichnen Objektinstanzen eine spezifische zur Laufzeit

erzeugte und mit konkreten Daten versehene Instanz seines Objekttyps. So

29

4.4. Business-Objekte

gehoren beispielsweise die Mitarbeiter in einem Unternehmen alle zum Ob-

jekttyp Employee. Der Mitarbeiter mit dem Namen Meier und der Mitarbei-

ternummer 0815 stellt eine Instanz dieses Objekttyps dar.

Anwendungsentwickler definieren bei der objektorientierten Programmie-

rung die Objekttypen, die von ihren Programmen verwendet werden sollen. Zur

Laufzeit greift das Anwendungsprogramm dann auf die spezifischen Instanzen

der definierten Objekttypen zu. Die Instanz eines Business-Objektes stellt nur

die Merkmale und Methoden zur Verfugung, die fur ihren Objekttyp definiert

wurden. Die Business-Objekte definieren sich anhand folgender Eigenschaften:

• Objekttyp

Der Objekttyp beschreibt die allgemeinen Beschaffenheiten, Eigenschaf-

ten und Gemeinsamkeiten jeder einzelnen Objektinstanz.

• Schlusselfelder

Die Schlusselfelder eines Objekttyps bestimmen die Struktur eines Kenn-

zeichnungsschlussels, der einer Anwendung einen eindeutigen Zugriff

auf eine spezifische Instanz des Objekttyps gewahrt. Ein Beispiel stellt

das Schlusselfeld Employee.Number des Objekttyps Employee dar.

Schlusselfelder sind mit Primarschlusseln relationaler Datenbanktabellen

vergleichbar.

• Methoden

Eine Methode ist eine Operation, die auf einem Business-Objekt aus-

gefuhrt werden kann und den Zugriff auf Objektdaten ermoglicht. Eine

Methode ist durch einen Namen und eine Reihe von Parametern und

Ausnahmen definiert, die zur Nutzung der Methode vom aufrufenden

Programm geliefert werden. BAPIs sind Beispiele fur derartige Metho-

den.

• Attribute

Ein Attribut enthalt Daten eines Business-Objektes und beschreibt ein

bestimmtes Objektmerkmal. Employee.Name ist beispielsweise ein At-

tribut des Objekttyps Employee.

Der allgemein geltende Hauptvorteil dieser objektorientierten Technologie ist

die Wiederverwendbarkeit von Softwarekomponenten, die in diesem Fall durch

die Ableitung neuer Objekttypen von vorhandenen Objekttypen erzielt wird.

Wenn ein Objekttyp aus einem vorhandenen generiert wird, wird der neue Ob-

jekttyp als Subtyp (oder Subklasse) und der vorhandene Objekttyp als uber-

geordneter Typ (oder Supertyp oder Superklasse) bezeichnet. Der Objekttyp

Employee ist beispielsweise ein Subtyp, der vom ubergeordneten Typ Person

abgeleitet wurde.

30

4.5. Business Application Programming Interfaces (BAPIs)

Ein Subtyp erbt alle Eigenschaften und Methoden, die fur den uberge-

ordneten Typ gultig sind, von dem der Subtyp abgeleitet wurde. Der Subtyp

kann jedoch auch uber zusatzliche Eigenschaften und Methoden verfugen oder

die Methoden, die er vom ubergeordneten Typ geerbt hat, mit einem ande-

ren Verhalten implementieren. Diese Gegebenheit ist unter dem Begriff des

Polymorphismus bekannt.

4.5 Business Application Programming Interfaces

(BAPIs)

In den vorangehenden Abschnitten dieses Kapitels wurde beschrieben, wie

innerhalb des SAP Business Framework die betriebswirtschaftlichen Daten

und Prozesse des R/3-Systems objektorientiert reprasentiert werden konnen.

Den zielsetzenden Bestandteil dieses Konzeptes stellen die BAPIs (Business

Application Programming Interfaces) dar, die es letztlich ermoglichen, diese

Business-Objekte im verteilten System zuganglich zu machen (Abbildung 4.1

zeigte bereits diesen Sachverhalt). Sie werden nun genauer spezifiziert und cha-

rakterisiert.

Zweck der BAPIs ist es, den Zugriff auf SAP Funktionalitat uber offizielle,

stabile und dialogfreie Schnittstellen zu ermoglichen. Diese Schnittstellen sollen

sowohl von anderen SAP Komponenten als auch von externen Anwendungen,

die von Kunden oder Partnerunternehmen entwickelt werden, benutzt werden

konnen.

BAPIs werden als API-Methoden von SAP Business-Objekttypen defi-

niert. Diese Objekttypen werden dazu verwendet, eine objektbasierte Kom-

munikation zwischen Komponenten zu realisieren. Durch die Business-Objekte

und ihre BAPIs wird es somit moglich, die Vorteile der Objektorientierung in

der zentralen Informationsverarbeitung von Unternehmen zu nutzen. So wird

beispielsweise die Wiederverwendung bestehender Funktionen und Daten, eine

reibungslose technische Interoperabilitat und ein flexibler Einsatz von Fremd-

komponenten moglich.

Implementiert sind BAPIs in R/3 als Funktionsbausteine, d. h. als Pro-

zeduren in der SAP-eigenen Programmiersprache ABAP (Advanced Business

Application Programming). Jeder Funktionsbaustein, der einem BAPI zugrun-

de liegt, wird als Methode den Business-Objekttypen eindeutig zugeordnet. Als

zentrale Einheit sorgt das Business Object Repository (BOR) fur die Verwal-

tung und die Verfugbarkeit dieser Informationen. Mit Hilfe dieser objektorien-

tierten Schnittstellen konnen andere Komponenten somit direkt auf die Anwen-

dungsschicht eines SAP R/3-Systems zugreifen, ohne Implementierungsdetails

kennen zu mussen.

Vervollstandigt wird dieses Integrationsszenrio mittels des Integrations-

dienstes ALE in Abschnitt 4.6.

31

4.5. Business Application Programming Interfaces (BAPIs)

4.5.1 Merkmale von BAPIs

Bei der Betrachtung der BAPIs und der Realisierung der Implementierungen

lassen sich einige charakteristische Merkmale erkennen:

• Namenskonvention

Ein BAPI wird durch den Namen des betreffenden Business-Objekttyps

gefolgt von dem Namen des BAPI selbst vollstandig identifiziert.

Der Name eines BAPI beschreibt die Funktion, die es am Business-

Objekt ausfuhrt. Beispielsweise lautet die vollstandige Indentifizie-

rung des BAPI ExistenceCheck() am Business-Objekt Company

Company.ExistenceCheck().

• Standardisierte BAPIs

Es existieren standardisierte BAPIs, die fur einen Großteil der Business-

Objekttypen implementiert werden konnen. Diese BAPIs stellen gewis-

se Grundfunktionen bereit. Sie erhalten an allen Business-Objekten den

gleichen Namen und werden nach bestimmten Designvorgaben imple-

mentiert. So erlaubt z. B. das BAPI GetList() das Auflisten aller

existierender Instanzen eines Business-Objekttyps und findet etwa in

Company.GetList() und Material.GetList() Anwendung.

• Instanzabhangige und -unabhangige BAPIs

BAPIs konnen nach ihrer Abhangigkeit von Instanzen eines Objekt-

typs unterschieden werden. Instanzabhangige BAPIs (Instanzmetho-

den) beziehen sich auf eine konkrete Instanz eines Business-Objekttyps

(z. B. Company.GetDetail()), wahrend Klassenmethoden instanzu-

nabhangig sind (z. B. Company.GetList()).

• Datenbankkonsistenz

Ein BAPI kann eine Instanz eines Objektes erstellen oder die Daten ei-

nes Objektes verandern. Derartige Anderungen hinterlassen immer einen

konsistenten Datenbankzustand. Alle Datenbankanderungen werden ent-

weder vollstandig oder uberhaupt nicht ausgefuhrt.

• Keine Dialogorientierung

BAPIs liefern keine Bildschirmdialoge vom R/3-System an die aufru-

fende Anwendung zuruck. SAP R/3 bietet allerdings der Moglichkeit,

den systeminternen Aufruf von Funktionsbausteinen uber eine SAP GUI-

Komponente zu visualisieren. Basierend auf dem Function Builder, der

in R/3 die Verwaltung der Funktionsbausteine ubernimmt, steht eine in-

tegrierte Test- und Entwicklungsumgebung mit Benutzeroberflache zur

Verfugung. Funktionsbausteine, die BAPIs zugrunde liegen, konnen hier

auf konkreten Parametern ausgefuhrt und Ruckgabewerte eingesehen

32

4.5. Business Application Programming Interfaces (BAPIs)

werden. Abschnitt 4.5.5 zeigt entsprechende GUI-Dialoge an einem Bei-

spiel eines Funktionsbausteins.

• Berechtigungen

Jede Benutzerinteraktion mit einem R/3-System setzt entsprechende Be-

rechtigungen voraus. Die Benutzer der Anwendung, die BAPIs ausfuhrt,

mussen uber die notwendigen Berechtigungen in den R/3-Stammdaten

verfugen, um den BAPI Aufruf zu ermoglichen. Jeder auf Grund un-

zureichender Berechtigungen fehlgeschlagene Ausfuhrungsversuch eines

BAPI wird der aufrufenden Anwendung gemeldet.

• Attribute von Business-Objekten

Der Zugriff auf die Attribute (Daten) eines Business-Objektes erfolgt

uber die BAPI Schnittstelle selbst. Ein Beispiel hierfur ist die Zugriffs-

methode GetDetail().

4.5.2 Vorteile von BAPIs

Die folgenden Punkte fassen die Vorteile zusammen, die sich aus der Einfuhrung

und Nutzung der BAPIs als Zugriffsmethoden auf die SAP Business-Objekte

ergeben.

• Betriebswirtschaftlicher Standard

Die Business-Objekttypen und ihre BAPIs bilden den Standard fur die

betriebswirtschaftlichen Inhalte des R/3-Systems und ermoglichen die In-

tegration von R/3 und anderer Softwarekomponenten auf betriebswirt-

schaftlicher Ebene.

• Konformitat mit Standards

Eine Initiative der SAP AG mit Kunden, Partnern und fuhrenden Nor-

menorganisationen ist verantwortlich fur die Entwicklung der BAPIs.

Als Zielsetzung bildete sich die Entwicklung eines Kommunikationsstan-

dards zwischen betriebswirtschaftlichen Systemen heraus. Die Business-

Objekte von SAP sind konform mit den Spezifikationen und Richtlinien

der Open Applications Group (OAG) [7].

• Stabilitat und Abwartskompatibilitat

Die Schnittstellen eines BAPI bleiben nach der Einfuhrung und Freigabe

durch SAP langfristig stabil. Anwendungen werden somit von Anderun-

gen der zugrunde liegenden R/3-Software und -Daten nicht beeinflusst.

Erweiterungen von BAPIs konnen durch Hinzufugen weiterer Parameter

realisiert werden, ohne die Stabilitat vorhandener Anwendungen zu be-

eintrachtigen. Neue Anwendungen konnen dagegen von der neuen Funk-

tionalitat profitieren.

33

4.5. Business Application Programming Interfaces (BAPIs)

• Objektorientierung

Die Architektur der SAP Business-Objekte und BAPIs als Schnittstellen-

methoden folgen den Prinzipien der Objektorientierung. BAPIs konnen

mit Hilfe objektorientierter Schnittstellentechnologien aufgerufen werden

und ermoglichen auf diese Weise die freie Interaktion der Softwarekom-

ponenten von SAP und anderen Anbietern.

• Offenheit

Der Zugriff auf BAPIs kann von allen Plattformen erfolgen, die das SAP

Protokoll RFC unterstutzen.

4.5.3 Voraussetzungen fur den Zugriff auf BAPIs

Um die BAPI Schnittstellen fur den Zugriff auf SAP Business-Objekte zu nut-

zen, mussen neben dem Namen des BAPI Informationen uber die Methodenpa-

rameter vorliegen, um einen Aufruf aus einem Anwendungsprogramm realisie-

ren und Ruckgabewerte verarbeiten zu konnen. Dabei muss einerseits zwischen

verschiedenen Parametertypen differenziert und andererseits eine Betrachtung

der zugrunde liegenden Datentypen erfolgen.

ABAP Datentypen

Datentypen in ABAP unterteilen sich in elementare und komplexe Typen.

Komplexe Datentypen werden nach Strukturen und Tabellen differenziert.

• Elementare Datentypen

Elementare Typen (auch Felder genannt) sind sogenannte in R/3”einge-

baute“ Datentypen und atomar in dem Sinn, dass sie nicht aus anderen

Typen zusammengesetzt sind (Abbildung 4.2 (a)).

• Strukturen

Strukturen (oder Feldleisten) sind eine Folge beliebiger elementarer oder

auch komplexer Datentypen. Strukturen konnen somit beliebige Kom-

ponenten enthalten, weshalb sie zusatzlich in geschachtelte und nicht-

geschachtelte sowie flache und tiefe Strukturen (Abbildung 4.2 (b) und

(e)) unterteilt werden.

• Tabellen

Tabellen bestehen aus einer Folge von Zeilen gleichen Datentyps. Ihr Zei-

lentyp kann ein beliebiger elementarer (Abbildung 4.2 (c)) oder wiederum

komplexer Datentyp sein (Abbildung 4.2 (d)). Tabellen werden immer

dann eingesetzt, wenn mehrfache Daten einer festen Struktur program-

mintern verwendet werden.

34

4.5. Business Application Programming Interfaces (BAPIs)

Abbildung 4.2: (a) elementarer ABAP Datentyp (b) nicht-geschachtelte,

flache Struktur (c) Tabelle mit elementarem Datentyp (d) Tabelle mit

nicht-geschachtelter Struktur (”echte“ Tabelle) (e) tiefe Struktur

ABAP Datentypen werden im sogenannten ABAP Dictionary als benutzerdefi-

nierte ABAP Dictionary Datentypen (auch Datenobjekte genannt) verwaltet.

Sie liefern die Sicht des Benutzers auf die Daten, d. h. das Datenformat an

der Benutzeroberflache, wahrend der ABAP Datentyp die Datenobjekte be-

schreibt. Beispielsweise wird der ABAP Dictionary Datentyp CHAR n auf den

elementaren ABAP Datentyp C der Lange n abgebildet.

BAPI Parameter

BAPIs verwenden in der Regel bis zu drei der Parametertypen:

• Importparameter

Die Parameter, die der Methode beim Aufruf ubergeben werden, werden

als Importparameter bezeichnet. Sie sind entweder elementaren Daten-

typs oder in Auspragung als Struktur. Ein BAPI kann auch ohne Im-

portparameter sein.

• Exportparameter

Exportparameter definieren die an die aufrufende Anwendung zuuckge-

lieferten Parameter und konnen ebenfalls von elementarem oder Struk-

turtyp sein. Ein BAPI muss mindestens den standardisierten Exportpa-

rameter RETURN besitzen, der Statusmeldungen oder aufgetretene Fehler

dokumentiert. Dieser kann allerdings als Tabellenparameter ausgepragt

sein.

• Tabellenparameter

Tabellenparameter sind optional einsetzbar. Sie konnen dazu verwen-

det werden, eine beliebige Anzahl von Parametern derselben Struktur

in Form einer Tabelle zu ubergeben oder zuruckzuliefern. Tabellenpara-

35

4.5. Business Application Programming Interfaces (BAPIs)

meter sind somit als Import- und Exportparameter nutzbar. Ein Tabel-

lenparameter kann nicht aus elementaren Datentypen bestehen.

Diese prinzipiellen Kenntnisse uber die BAPI Parameter und deren Datentypen

sind fur die Programmierung der Methodenaufrufe notwendig. Als Metadaten

von Funktionsbausteinen werden sie in Kapitel 5 verfugbar gemacht.

4.5.4 Zugriffsmoglichkeiten

Basierend auf der Trennung der Definition eines BAPI als Methode auf einem

Business-Objekt von seiner tatsachlichen Implementierung als Funktionsbau-

stein ergeben sich zwei unterschiedliche technologische Ansatze, um auf BAPIs

zuzugreifen.

Abbildung 4.3: Zugriff auf BAPIs

• Objektorientierter Zugriff

Wie Abbildung 4.3 darstellt, erfolgt der objektorientierte Aufruf des BA-

PI uber das Business Object Repository. Das BOR stellt die entspre-

chenden Metadaten der Methode zur Verfugung und liefert Instanzen

der zugehorigen Objekttypen auf denen das BAPI schließlich ausgefuhrt

wird.

Der objektorientierte Zugriff ist uber zahlreiche Programmierplatt-

formen moglich. Beispielsweise wird eine BAPI C++- und Java-

Klassenbibliothek angeboten ebenso wie ein SAP DCOM Component

Connector2 und mit ObjectBridge eine CORBAR-basierte Middleware.

• Funktionsorientierter Zugriff

2Der SAP DCOM Component Connector ist ein von Microsoft und der SAP AG ge-

meinsam entwickelter Adapter zur Integration von SAP Business-Objekten und Microsoft

COM-Objekten. Weitere Informationen finden sich in der SAP Bibliothek [8] zur DCOM

Connector Architektur und unter [5].

36

4.5. Business Application Programming Interfaces (BAPIs)

Ahnlich zum objektorientierten Ansatz erfolgt der funktionsorientierte

Zugriff auf ein BAPI. Die Aufgabe des BOR ubernimmt bezuglich der

Funktionsbausteine der Function Builder, und die Client-Aufrufe werden

gemaß dem RFC-Protokoll an den gewunschten Funktionsbaustein im

R/3-System weitergeleitet.

Grundvoraussetzung fur das Gelingen eines RFC-Zugriffs auf einen Funk-

tionsbaustein ist, dass dieser in R/3 explizit als”remotefahig“ gekenn-

zeichnet ist.

Im Rahmen dieser Arbeit wird ausschließlich das Modell des funktionsorientier-

ten, also RFC-basierten Zugriffs auf die BAPIs angewendet. Es soll sowohl eine

moglichst plattform- und betriebssystemunabhangige Middleware verwendet

werden als auch eine weitestgehend einfach zu nutzende und dennoch perfor-

mante Technologie zum Einsatz kommen, so dass letztlich mit dem SAP Java

Connector (JCo) gearbeitet wird, der in Kapitel 5 mit seinen Moglichkeiten

vorgestellt wird.

4.5.5 Beispiel: Company.GetList()

Zur Veranschaulichung einer BAPI Schnittstellenmethode und deren Parame-

ter gewahrt dieser Abschnitt basierend auf dem entsprechenden BAPI Funkti-

onsbaustein anhand von Screenshots des SAP GUI einen Einblick in die Bild-

schirmdialoge des Function Builder.

Als Beispiel dient das standardisierte und instanzunabhangige BAPI

GetList() auf dem Business Objekt Company. Der zugehorige Funktions-

baustein BAPI COMPANY GETLIST ist uber den Function Builder auszuwahlen

und anzuzeigen.

37

4.5. Business Application Programming Interfaces (BAPIs)

Abbildung 4.4: SAP Function Builder

In nachfolgenden Abbildungen zeigt die GUI des Function Builder die Import-,

Export- und Tabellenparameter des Funktionsbausteins.

Abbildung 4.5: Importparameter BAPI COMPANY GETLIST

38

4.5. Business Application Programming Interfaces (BAPIs)

Abbildung 4.6: Exportparameter BAPI COMPANY GETLIST

Abbildung 4.7: Tabellenparameter BAPI COMPANY GETLIST

BAPI COMPANY GETLIST besitzt keine Importparameter. Der standardisierte

Parameter mit Namen RETURN ist der einzige Exportparameter. Der Tabel-

lenparameter COMPANY LIST wird schließlich als Exportparameter dienen und

die Liste aller Unternehmen, d. h. aller im R/3-System verfugbaren Instanzen

des Objekttyps Company zuruckliefern. Die Attribute der Objektinstanzen, die

exportiert werden, definieren sich auf Grund der Struktur, die dem Tabellentyp

BAPI0014 1 von COMPANY LIST zugrunde liegt (Abbildung 4.7, blaue Mar-

kierung). Abbildung 4.8 zeigt deren beiden Attribute COMPANY und NAME1

dar.

Abbildung 4.8: Struktur des Tabellenparameter BAPI COMPANY GETLIST

Da keine Importparameter zu fullen sind, kann der Funktionsbaustein ohne

Benutzereingabe ausgefuhrt werden und folgende Ruckgabewerte liefern:

39

4.6. Integrationsdienst ALE (Application Link Enabling)

Abbildung 4.9: Ausgabe BAPI COMPANY GETLIST

4.6 Integrationsdienst ALE (Application Link

Enabling)

Das Konzept des Application Link Enabling (ALE) bildet die Grundlage fur

die Interaktion im objektorientierten Ansatz des SAP Business Framework.

ALE bezeichnet eine nachrichtenorientierte Middlewarearchitektur, welche die

Verteilung der betriebswirtschaftlichen Prozesse und Funktionen in einer SAP

Umgebung ubernimmt.

Hierbei beschreibt das logische ALE-Verteilungsmodell innerhalb seiner

Konfiguration, welche Anwendungen auf welchen Systemen laufen und wel-

che Business-Objekttypen die Anwendungen untereinander austauschen bzw.

welche BAPIs aufgerufen werden konnen.

Das Design samtlicher, im Rahmen des Business Framework relevanter

Sachverhalte, erfolgt szenariengetrieben, d. h. Integrationsszenarien beschrei-

ben, wie und welche Komponenten, Business-Objekttypen und BAPIs zusam-

menspielen (Abbildung 4.10). Das Verteilungsmodell des ALE sorgt fur die

Integration, indem es die Szenarien definiert und damit auf semantischer Ebe-

ne die Synchronisation von Geschaftsprozessen sicherstellt.

40

4.7. Remote Function Call (RFC)

Abbildung 4.10: ALE Integrationsszenario

4.7 Remote Function Call (RFC)

Unter einem Remote Function Call (RFC) wird ein”entfernter Funktionsauf-

ruf“ verstanden. RFC kann als eine SAP-Variante des Remote Procedure Call

(RPC) angesehen werden. Bei RFC handelt sich dabei um den Aufruf eines als

remotefahig gekennzeichneten Funktionsbausteins, der sich auf demselben oder

einem entfernten System befinden kann. Obwohl die Moglichkeit besteht, einen

Funktionsbaustein auch lokal uber RFC aufzurufen, verfolgt der Grundgedan-

ke des RFC vor allem Aufrufe aus verschiedenen (externen), typischerweise

heterogenen Systemen. Das RFC-Schnittstellenprotokoll erlaubt also Funkti-

onsaufrufe zwischen zwei SAP Systemen (auch R/2 und R/3) oder zwischen

einem SAP System und einem nicht-SAP System. Es ubernimmt dabei die

Kommunikationssteuerung, die Parameterubergabe und die Fehlerbehandlung.

Echtzeit-Kommunikation mit sRFC (synchronous RFC)

Die in diesem Kapitel beschriebenen Kommunikationsszenarien des ent-

fernten Aufrufs eines BAPIs uber dessen remotefahigen Funktionsbaustein,

folgen der synchronen Ubertragungsform der Daten und werden als sRFC

(synchronous RFC ) bezeichnet. Dies setzt voraus, dass das gerufene Sy-

stem, der RFC-Server, erreichbar ist. Der aufrufende Client ist in seinem

Programmablauf blockiert, solange die Server-Antwort aussteht.

41

Kapitel 5

Zugriff auf SAP R/3 mit SAP

Java Connector (JCo)

In Kapitel 4 wurde das SAP R/3-System mit seinem Business Framework vor-

gestellt. Wahrend dort mit RFC eine grundlegende Technologie beschrieben

wurde, um auf R/3-Anwendungsfunktionalitaten und somit schließlich auf die

betriebswirtschaftlichen Objektdaten zuzugreifen, behandelt dieses Kapitel die

praktische Anwendung dieser Technologie mit Hilfe der SAP Java Middleware

JCo.

Der JCo bietet grundsatzlich die Moglichkeit, sowohl von Java-

Programmen auf R/3-interne ABAP-Komponenten und -Programme zuzugrei-

fen (inbound call) als auch den Aufruf von Java-Applikationen mit ABAP

(outbound call) zu realisieren. Auf Grund der Zielsetzung dieser Arbeit ist hier

lediglich das Szenario des inbound call von Interesse.

Als Informationsquellen dienten das JCo-Tutorial [9] sowie die API-

Dokumentation der eingesetzten Version 1.1.03, die dem von SAP zur

Verfugung gestellten JCo-Paket beiliegen.

Anstelle der Terminologie BAPI wird von nun an aus bereits dargelegten

Grunden der Begriff des Funktionsbausteins verwendet.

5.1 Technologie des JCo

Der SAP Java Connector (JCo) ermoglicht dem Programmierer, remotefahige

SAP Funktionsbausteine (Remote Function Modules, RFMs) von einem exter-

nen SAP-fremden System aus uber die Programmiersprache Java aufzurufen

(Client-Programmierung), ohne direkt auf die API des RFC-Protokolls zugrei-

fen zu mussen. Die RFC API beinhaltet eine Reihe von Funktionen in der

Programmiersprache C, die mit der Entwicklung der RFC-Klassenbibliothek in

C++-Klassen gekapselt wurden. Der JCo setzt auf dieser Bibliothek auf und

kann somit als objektorientierte Schicht uber der RFC API gesehen werden.

Abbildung 5.1 schematisiert die Technologiearchitektur.

42

5.2. Verbindungsaufbau

Gemaß [9] ist der JCo die beste Wahl fur die Entwicklung von Java-

Applikationen mit R/3-Funktionalitat. Basierend auf dem Java Native Inter-

face (JNI) realisiert JCo eine einfach zu nutzende und performante Middleware

fur das RFC-Protokoll. Er ist fur viele gangige Betriebssystemplattformen wie

Windows, Linux, Solaris, IBM-AIX, HP-UX etc. verfugbar.

Abbildung 5.1: SAP Java Connector Architektur

Ebenso wie in [9] kann auch im Rahmen der Aufgabenstellung dieser Arbeit

die Behandlung der SAP-Client-Programmierung auf die synchrone Kommu-

nikation (sRFC) beschrankt werden.

Aus programmiertechnischer Sicht bereitet die import-Anweisung

import com.sap.mw.jco.*;

auf die Verwendung aller JCo-Klassen vor.

5.2 Verbindungsaufbau

Der JCo unterstutzt zwei Programmiermodelle fur den Verbindungsaufbau zu

SAP R/3-Systemen:

• Direkte Verbindungen (direct connections)

Direkte Verbindungen konnen beliebig viele hergestellt werden. Sie blei-

ben solange geoffnet bis sie explizit vom Anwendungsprogrammierer ge-

schlossen werden.

• Verbindungspools (connection pools)

Ein Verbindungspool definiert eine spezifizierte Menge von verfugbaren

Verbindungen, die dem Pool entnommen und genutzt werden konnen. Die

43

5.2. Verbindungsaufbau

Anzahl der gleichzeitig zu verwendeten Verbindungen ist somit durch den

Pool beschrankt. Das Offnen und Schließen der jeweiligen Verbindungen

wird von einem Pool-Manager gesteuert.

Um ubermaßigen Overhead auf Seiten des R/3 zu vermeiden, der durch

das Einloggen auf dem System entsteht, sollten insbesondere Webapplika-

tionen Verbindungspools einsetzen. Die Anzahl der parallel bestehenden

Verbindungen wird auf einem fixen Maß gehalten. Zusatzlich wird haufigem

Neuaufbau von Verbindungen dadurch entgegengewirkt, dass diese uber die

Ausfuhrungszeit einer Applikation hinaus offen gehalten werden und bei

Bedarf ohne Neuanmeldung am System zur Verfugung stehen.

Eine Verbindung zu einem SAP R/3-System wird vom SAP Java Connector

uber eine Objektinstanz der Klasse JCO.Client reprasentiert.

JCO.Client client;

Je nach gewahlter Verbindungsart gemaß obiger Modelle werden diese unter-

schiedlich erzeugt.

Direkte Verbindungen

Fur eine direkte Verbindung mit einem R/3-System liefert die statische

Methode createClient der Klasse JCO in Abhangigkeit verschiedener

Verbindungsparameter ein JCO.Client-Objekt.

client = JCO.createClient("001", // SAP Client Nummer"<user>", // Benutzername"<password>", // Kennwort"DE", // Sprache"<host>", // Name des Applikationsservers/IP-Adresse"00"); // Systemnummer

Der JCo bietet mehrere uberladene Versionen dieser Methode an. Diese konnen

der JCo API-Dokumentation entnommen werden. An dieser Stelle soll noch die

Moglichkeit aufgezeigt werden, die Verbindungsparameter als Objekt der Java

Standard-Klasse java.utils.Properties zu ubergeben. Listing 5.1 zeigt

den zughorigen Programmcode.

Properties props = new Properties();

props.setProperty("jco.client.client", "001");props.setProperty("jco.client.user", "<user>");props.setProperty("jco.client.passwd", "<password>");props.setProperty("jco.client.lang", "DE");props.setProperty("jco.client.host", "<host>");props.setProperty("jco.client.sysnr", "00");

44

5.2. Verbindungsaufbau

client = JCO.createClient(props);

Listing 5.1: JCO.Client-Objekt zur direkten Verbindung mit R/3

Die Erzeugung des JCO.Client-Objekts offnet allerdings noch keine Ver-

bindung zum SAP R/3-System. Dies ubernimmt dessen connect-Methode.

Das Schließen der Verbindung veranlasst letztlich ein Aufruf der Methode

disconnect.

try {client.connect();

/* Aufrufen von SAP Funktionen (RFMs) */}catch (Exception ex) {

System.out.println("Verbindung kann nicht hergestellt werden.");}finally {

client.disconnect();}

Verbindungspools

Ein Verbindungspool des JCo wird durch seinen Namen identifiziert

und ist innerhalb der Java Virtual Machine (JVM) fur Anwendungen global

zuganglich. Alle Verbindungen in einem Pool basieren auf denselben Werten

der Verbindungsparameter, verwenden also die gleichen System-, Benutzer-

und Client-Informationen. Es konnen beliebig viele Pools angelegt werden.

JCO.addClientPool("BeispielPool",10,"001","<user>","<passwort>","DE","<host>","00");

Analog zur direkten Verbindungsart liefert auch bei Verwendung von Verbin-

dungspools die Klasse JCO uber eine statische Methode das JCO.Client-

Objekt in Abhangigkeit des eindeutigen Namen des Pools.

try {client = JCO.getClient("BeispielPool");

/* Aufrufen von SAP Funktionen (RFMs) */}catch (Exception ex) {

System.out.println("Verbindungspool existiert nicht oder maximaleAnzahl offener Verbindungen ist erreicht.");

}

45

5.3. Metadaten von RFMs

finally {JCO.releaseClient(client);

}

Listing 5.2: JCO.Client-Objekt aus R/3-Verbindungspool

Die getClient-Methode liefert entweder eine bestehende offene Verbindung

zuruck oder offnet eine neue, falls deren maximale Anzahl noch nicht erreicht

ist (der”BeispielPool“ erlaubt 10 offene Verbindungen).

Im Unterschied zu direkten Verbindungen werden die Verbindungen aus

Verbindungspools nicht explizit geschlossen, sondern uber die statische JCO-

Methode releaseClient in den Pool”zuruckgelegt“ und damit zur er-

neuten Verwendung freigegeben. Der Pool-Manager ubernimmt implizit die

Aufgabe der Verwaltung der angelegten Pools sowie die Kontrolle uber den

Verbindungsauf- und abbau auf JCO.Client-Objekten. Nachfolgendes Li-

sting 5.3 zeigt Beispiele, den Pool-Manager zu nutzen und zu konfigurieren.

// JCo Pool-Manager ObjektJCO.PoolManager manager = JCO.getClientPoolManager();

// "Uberpr"ufung auf existierenden VerbindungspoolJCO.Pool pool = manager.getPool("BeispielPool");if (pool == null) {

// ...}

// Zeitspanne bis zum Schlieen einer ungenutzten offenen Verbindung// default-Wert: 600000 ms = 10 minmanager.setConnectionTimeout(600000);

Listing 5.3: JCO.PoolManager

5.3 Metadaten von RFMs

5.3.1 JCO.Repository und JCO.Function

Das SAP Repository enthalt als zentrale Verwaltungseinheit aller R/3-

Systemdaten unter anderem die Metainformationen zu den systemweit

verfugbaren RFMs. Die Klasse JCO.Repository implementiert dieses Re-

pository und macht auf Basis einer konkreten R/3-Verbindung JCO.Client

client die Metadaten eines bestimmten RFM dynamisch aus dem R/3-

Repository zur Laufzeit abrufbar:

JCO.Repository repository =new JCO.Repository("BeispielRepository", client);

try {IFunctionTemplate ft =

repository.getFunctionTemplate("BeispielRFM");

46

5.3. Metadaten von RFMs

JCO.Function function = ft.getFunction();}catch (Exception ex) {

System.out.println("Der Funktionsbaustein ist nicht vorhanden.");}

Listing 5.4: RFM als JCO.Function-Objekt

RFMs werden von dem JCo als Objekte der Klasse JCO.Function reprasen-

tiert. Das JCo Repository liefert uber die Methode getFunctionTemplate

eine”Funktionsvorlage“, die alle Metadaten und Parameter des RFM kapselt.

Der JCo ruft diese Informationen lediglich einmal ab und cached sie dann aus

Performancegrunden. Das JCO.Function-Objekt wird aus der Funktionsvor-

lage erzeugt und tragt die aktuellen Parameter, die fur die Ausfuhrung des

RFM erforderlich sind. Die Beziehung zwischen einer Funktionsvorlage und ei-

ner Funktion innerhalb des JCo ist vergleichbar mit der einer Klasse und eines

Objektes in Java.

5.3.2 JCO.ParameterList

Die Klasse JCO.Function stellt die drei Methoden

• getImportParameterList(),

• getExportParameterList() und

• getTableParameterList()

zum Zugriff auf eine Liste der jeweiligen Parametertypen eines RFM zur

Verfugung. Die einzelnen Parameterobjekte dieser JCO.ParameterList-

Instanzen sind gemaß ihrem Datentyp und Namen zuganglich: Erinnert man

sich an die moglichen ABAP Datentypen aus Kapitel 4, Abschnitt 4.5.3, kom-

men fur Import- und Exportparameter Felder und Strukturen in Betracht,

wahrend Tabellenparameter den Tabellentyp auspragen1. Der JCo bildet diese

Datentypen uber entsprechende Klassenobjekte ab:

• getField(String name) bzw. getField(int i) liefert ein Ob-

jekt vom Typ JCO.Field,

• getStructure(String name) bzw. getStructure(int i) ein

Objekt vom Typ JCO.Structure und

• getTable(String name) bzw. getTable(int i) ein Objekt der

Klasse JCO.Table,

1Obwohl SAP R/3 ab Release Version 4.6C die beliebige Schachtelung komplexer Da-

tentypen unterstutzt, nutzen BAPIs diese Moglichkeit nicht [9]. Stattdessen werden lediglich

nicht-geschachtelte, flache Strukturen sowie”echte“ Tabellen verwendet (vgl. Abbildung 4.2).

47

5.3. Metadaten von RFMs

wobei name den Namen des Parameter bzw. i den Positionsindex des Para-

meter innerhalb der Parameterliste bezeichnet.

Strukturen und Tabellen sind aus Feldern zusammengesetzte ABAP Dic-

tionary Datentypen und lassen sich damit letztlich, wie der Feldtyp selbst,

auf einen elementaren ABAP Datentyp zuruckfuhren2. Daher bietet der JCo

Getter- und Setter-Methoden auf den JCO.Field-Objekten an, die die Feld-

inhalte gemaß einer Konvertierungstabelle fur elementare ABAP Datentypen

und Java Datentypen liefern und setzen. Das Type-Mapping (Tabelle 5.1) wird

in Tabelle 5.2 den JCo Zugriffsmethoden gegenubergestellt.

Elementarer Beschreibung Java Datentyp JCo Typ-Konstante

ABAP Typ

b 1-Byte Integer int JCO.TYPE INT1

s 2-Byte Integer int JCO.TYPE INT2

l 4-Byte Integer int JCO.TYPE INT

C Zeichen String JCO.TYPE CHAR

N Numerisches Zeichen String JCO.TYPE NUM

P BCD (Binary Coded Decimal) BigDecimal JCO.TYPE BCD

D Datum Date JCO.TYPE DATE

T Zeit Date JCO.TYPE TIME

F Fließkommazahl double JCO.TYPE FLOAT

X Raw Data byte[ ] JCO.TYPE BYTE

g Zeichenkette (variable Lange) String JCO.TYPE STRING

y Raw Data (variable Lange) byte[ ] JCO.TYPE XSTRING

Tabelle 5.1: Mapping von ABAP Datentypen und Java Datentypen

JCo Typ-Konstante JCo Zugriffsmethoden

Getter-Methoden Setter-Methoden

JCO.TYPE INT1 int getInt() void setValue(int i)

JCO.TYPE INT2 int getInt() void setValue(int i)

JCO.TYPE INT int getInt() void setValue(int i)

JCO.TYPE CHAR String getString() void setValue(String s)

JCO.TYPE NUM String getString() void setValue(String s)

JCO.TYPE BCD BigDecimal getBigDecimal() void setValue(Object o)

JCO.TYPE DATE Date getDate() void setValue(Object o)

JCO.TYPE TIME Date getTime() void setValue(Object o)

JCO.TYPE FLOAT double getDouble() void setValue(double d)

JCO.TYPE BYTE byte[ ] getByteArray() void setValue(byte[ ] b)

JCO.TYPE STRING String getString() void setValue(String s)

JCO.TYPE XSTRING byte[ ] getByteArray() void setValue(byte[ ] b)

Tabelle 5.2: Java Datentypen und JCo Zugriffsmethoden

2Es wird daran erinnert, dass ein Unterschied besteht zwischen ABAP Dictionary Daten-

typen oder Datenobjekten und ABAP Datentypen (vgl. Abschnitt 4.5.3).

48

5.4. Aufruf von RFMs

5.4 Aufruf von RFMs

Der Aufruf der Remote-Funktionsbausteine erfolgt, nachdem alle erforderlichen

Importparameter uber die JCo Setter-Methoden derer Felder gefullt wurden.

Es ist dabei nicht zwingend notwendig, alle Felder mit Werten zu belegen.

Die Implementierung des BAPI im Funktionsbaustein in R/3 ubernimmt zur

Laufzeit die Uberprufung der Importdaten und liefert gegebenenfalls Status-

meldungen uber den RETURN-Parameter an den Client zuruck.

Die Problematik ist hierbei allerdings, dass die JCo API die Funktionalitat zur

Abfrage der Mussfelder von Importparametern nicht unterstutzt. Dies wird

bei der spateren benutzergesteuerten Definition der Web Service Methoden

von Bedeutung sein.

Prinzipiell geschieht der Aufruf des RFM uber das R/3-Verbindungsobjekt

JCO.Client und der JCo RFM Instanz wie folgt:

try {client.execute(function);

}catch {

System.out.println("Fehler beim Aufruf des RFM.");}

Listing 5.5: RFM Aufruf

5.5 Beispiel: BAPI COMPANY GETLIST

Der Funktionsbaustein aus Abschnitt 4.5.5 wird auch in diesem Kapitel als

Grundlage dienen, die hier behandelte Thematik an einem konkreten RFM

zusammenzufassen. Die Paramter konnen anhand der Abbildungen in Kapitel

4 nachvollzogen werden.

BAPI COMPANY GETLIST als RFM besitzt keine Importparameter. Der

Tabellenparameter COMPANY LIST referenziert als”echte“ Tabelle die Felder

COMPANY und NAME1 in seinen Zeilen. Die Felder sind vom ABAP Dictionary

Datentyp CHAR und werden somit nach Tabelle A in den elementaren ABAP

Typ C konvertiert und von JCo in Java als String behandelt (siehe Tabelle

5.1).

Der Aufruf des RFM und das Auslesen der Felder des Tabellenparameter er-

geben sich mit JCo nach folgendem Listing 5.6:

import com.sap.mw.jco.*;

try {// Verbindung erstellenJCO.Client client =

JCO.createClient("020","TNO100124","******",

49

5.5. Beispiel: BAPI COMPANY GETLIST

"DE","164.23.5.154","20");

// Verbindung ffnenclient.connect();

// Repository erzeugenJCO.Repository repository =

new JCO.Repository("de.tsystems.ws.sap.repository", client);

// Funktionsbaustein einlesenJCO.Function function =

repository.getFunctionTemplate("BAPI_COMPANY_GETLIST").getFunction();

// Funktionsbaustein aufrufenconn.execute(function);

// Tabelle einlesenJCO.Table table = function.getTableParameterList().getTable("

COMPANY_LIST");

// Tabellenzeilen durchlaufenfor (int i = 0; i < table.getNumRows(); i++) {

table.setRow(i); // Cursor auf Zeile setzenSystem.out.println(table.getString("NAME1") + ’\t’ +

table.getString("COMPANY"));}

client.disconnect(); // Verbindung trennen}catch (Exception ex) {

ex.printStackTrace();}

Listing 5.6: JCo und BAPI COMPANY GETLIST

Die Ausgabe des Programms beinhaltet schließlich die zur Abbildung 4.9

identische Datenliste des SAP Function Builder.

50

Kapitel 6

Zugriff auf relationale

Datenbanken mit JDBC

Dieses Kapitel behandelt in Analogie zum SAP Java Connector fur den Zugriff

auf R/3-Systeme die JDBC-Schnittstelle als Moglichkeit fur den Zugriff auf

relationale Datenbanksysteme.

JDBC ist eine Datenbankschnittstelle der Sun Microsystems, Inc., die un-

abhangig von einem konkreten Datenbanksystem wie beispielsweise ORACLE

ist. Die damit einhergehende Moglichkeit zur Portierung auf andere Daten-

banksysteme stellt zusammen mit der Tatsache, als Java-basierte Technologie

plattformunabhangig zu arbeiten, ein wesentlicher Vorteil dar. Zudem rechtfer-

tig die aufwandsarme und einfache Programmierung mit JDBC deren Einsatz,

nicht zuletzt im Rahmen der vorliegenden Aufgabenstellung dieser Arbeit.

Die API-Spezifikation fur JDBC [11] wurde von JavaSoft im Marz 1996

als vorlaufige Version 0.50 vorgestellt. Sie liegt nunmehr in der Version 3.0 vor

und wird mit Sun’s Java Development Kit (JDK) Version 1.4 ausgeliefert.

Die Moglichkeiten der JDBC werden nachfolgend nur insoweit angefuhrt,

wie sie in der Implementierung der erzeugten Web Services dieser Arbeit ge-

nutzt werden. Grundkenntnisse zum Modell und zur Anfragesprache Structured

Query Language (SQL) von relationalen Datenbanksystemen werden voraus-

gesetzt, da eine Einfuhrung den Rahmen dieser Arbeit sprengen wurde. Als

Literaturhinweise sind beispielsweise [4] oder [22] zu nennnen.

6.1 Technologie der JDBC

Die Java Database Connectivity ist in den Standardklassen des JDK seit Ver-

sion 1.1 enthalten. Die Klassen und Interfaces der JDBC API befinden sich

in den Paketen java.sql und javax.sql. Sie definieren lediglich den Zu-

griffsmechanismus, die Methoden, durch welche man aus Java auf relationale

Datenbanken zugreifen kann.

Die Arbeit wird beim Datenbankzugriff vom sogenannten JDBC-Treiber

51

6.1. Technologie der JDBC

durchgefuhrt, der die JDBC-Schnittstellenmethoden datenbankspezifisch im-

plementiert.

Die Verwaltung der Treiber in der Java Laufzeitumgebung wird vom

JDBC-Treibermanager ubernommen. Wenn man eine Verbindung zu einem

konkreten Datenbanksystem aufbauen will, muss man den zugehorigen Trei-

ber zunachst beim Treibermanager registrieren. In einer Anwendung kann man

prinzipiell beliebig viele Treiber beim Treibermanager anmelden. Beim Verbin-

dungsaufbau zu einer Datenbank wird anschließend vom Treibermanager der

benotigte Treiber angefordert. Wenn der Treiber dem Treibermanager bekannt

ist, wird er initialisiert und fur die Durchfuhrung der Datenbankzugriffe ver-

wendet.

Die Gesamtarchitektur von JDBC zeigt nachfolgende Abbildung 6.1.

Abbildung 6.1: JDBC Architektur

Als die wichtigsten Klassen und Interfaces bei der Programmierung mit JDBC

sind zu nennen:

• DriverManager

Die Klasse ist – wie bereits beschrieben – fur die Verwaltung der daten-

bankspezifischen JDBC-Treiber zustandig und ist im java.sql-Paket

direkt implementiert.

Stattdessen sind die Implementierungen der folgenden Interfaces der

JDBC API abhangig vom Datenbanksystem und somit Teil der JDBC-

Treiber:

• Connection

Eine Verbindung zu einer Datenbank wird durch die Implementierungs-

klasse Connection reprasentiert. Sie wird fur die Ausfuhrung von

52

6.2. Verbindungsaufbau

SQL-Anweisungen und den Zugriff auf die Metadaten in der Datenbank

benotigt.

• DatabaseMetaData

Der Zugriff auf das Data Dictionary1 erfolgt uber die vom JDBC-Treiber

implementierte Klasse DatabaseMetaData.

• Statement

Statement stellt die Basisklasse fur die Ausfuhrung von SQL-

Anweisungen dar. Mit ihr konnen beliebige, als String vorliegende SQL-

Anweisungen an das Datenbanksystem geschickt werden.

• PreparedStatement

Ein prepared statement definiert eine SQL-Anweisung, in denen Platz-

halter (≫?≪) fur Parameter gesetzt werden. Um dieselbe Anweisung

mehrmals mit wechselnden Parametern auszufuhren, konnen diese Platz-

halter mit Werten belegt werden. In JDBC steht dazu das Interface

PreparedStatement zur Verfugung.

• ResultSet

ResultSet stellt eine Ergebnismenge einer SQL-Abfrage (Query) dar.

6.2 Verbindungsaufbau

Bevor eine Verbindung zu einer Datenbank uber den JDBC-Treiber erfolgen

kann, muss dieser innerhalb des Treibermanagers registriert sein. Um dies zu

erreichen, wird die JDBC-Treiberklasse uber den ClassLoader der Java Lauf-

zeitumgebung geladen. Die JDBC-Spezifikation verlangt, dass der Treiber sich

daraufhin selbst durch einen statischen Initialisierungsteil beim Treibermana-

ger registriert.

String driverName = "oracle.jdbc.OracleDriver"; // vollqualifizierterKlassenname

Class.forName(driverName); // Klasse laden und Registrierung initiieren

Schließlich kann basierend auf gultigen Verbindungsdaten eine Verbindung zum

Datenbanksystem uber den Treibermanager erfolgen, der bei Erfolg das Ver-

bindungsobjekt Connection zuruckliefert:

String host = "<host>"; // Name des Datenbankservers/IP-AdresseString port = "<port>"; // PortnummerString sid = "<sid>"; // Systemnummer

1Das Data Dictionary beschreibt den Zustand einer Datenbank, enthalt also die Metada-

ten.

53

6.3. Metadaten von Relationen

String url = "jdbc:oracle:thin:@" + host + ":" + port + ":" + sid

Connection conn = DriverManager.getConnection(url, "<user>", "<passwort>");

Listing 6.1: Connection-Objekt der JDBC-Verbindung

Eine weitere Moglichkeit, eine Datenbankverbindung aufzubauen bzw. ein

gultiges Connection-Objekt zu erhalten, besteht auch bei JDBC durch

Connection Pooling. Diese Technik der Wiederverwendung physischer Daten-

bankverbindungen wird auch von der JCo Middleware angeboten und wurde

dort bereits beschrieben (siehe Kapitel 5, Abschnitt 5.2).

6.3 Metadaten von Relationen

Basierend auf dem Connection-Verbindungsobjekt konnen Metainformatio-

nen uber die angeschlossene Datenbank abgefragt werden.

DatabaseMetaData dbmeta = conn.getMetaData();

Listing 6.2: DatabaseMetaData-Objekt der JDBC-Verbindung

Auf Grund der Vielzahl der zur Verfugung gestellten Metadaten wird an dieser

Stelle wiederum eine Auswahl derjenigen getroffen, die fur die Web Service

Generierung relevant sind:

• getTables(...)

Die Methode liefert eine Auflistung der in der Datenbank enthaltenen

Relationen (Tabellen) in Form eines ResultSet.

• getColumns(...)

Die Methode liefert eine Auflistung der in einer Tabelle enthaltenen At-

tribute (Tabellenspalten) in Form eines ResultSet. Von Interesse sind

hier insbesondere die Datentypen der Attribute. Analog zur JCo Middle-

ware existiert auch in der JDBC Spezifikation [11] ein Mapping auf Java

Datentypen wie in Tabelle 6.1.

• getPrimaryKeys(...)

Die Methode liefert eine Auflistung der Attribute einer Tabelle, die als

Primarschlussel dienen, in Form eines ResultSet.

• getExportedKeys(...)

Die Methode liefert eine Auflistung der Fremdschlussel-Attribute, die die

Primarschlussel-Attribute der gegebenen Tabelle referenzieren.

54

6.4. Ausfuhren von SQL-Anweisungen

JDBC Typ Java Typ

CHAR String

VARCHAR String

LONGVARCHAR String

NUMERIC java.math.BigDecimal

DECIMAL java.math.BigDecimal

BIT boolean

BOOLEAN boolean

TINYINT byte

SMALLINT short

INTEGER int

BIGINT long

REAL float

FLOAT double

DOUBLE double

BINARY byte[ ]

VARBINARY byte[ ]

LONGVARBINARY byte[ ]

DATE java.sql.Date

TIME java.sql.Time

TIMESTAMP java.sql.Timestamp

CLOB Clob

BLOB Blob

ARRAY Array

STRUCT Struct

REF Ref

Tabelle 6.1: Mapping von JDBC Datentypen und Java Datentypen

• getImportedKeys(...)

Die Methode liefert eine Auflistung der Primarschlussel-Attribute, auf

die sich die Fremdschlussel-Attribute der gegebenen Tabelle beziehen.

6.4 Ausfuhren von SQL-Anweisungen

Wenn eine Verbindung zur Datenbank hergestellt ist, konnen uber das

Connection-Objekt dieser Verbindung SQL-Anweisungen ausgefuhrt werden.

In diesem Zusammenhang muss zwischen der Ausfuhrung von”dynamischem

SQL“, basierend auf der Implementierung des Interface Statement, und”vor-

bereitetem SQL“ auf PreparedStatement-Objekten unterschieden werden.

Im Kontext dieser Arbeit werden SQL-Anweisungen uber prepared state-

ments generiert, so dass die Klasse Statement hier keine weitere Beachtung

findet. Die Methoden verhalten sich ahnlich, variieren lediglich leicht in ihrer

Signatur und konnen gegebenenfalls der API [11] entnommen werden.

55

6.4. Ausfuhren von SQL-Anweisungen

Anweisungen auf PreparedStatement-Objekten

Zunachst wird eine Instanz der Klasse PreparedStatement benotigt.

Connection conn;String sql;

PreparedStatement stmt = conn.prepareStatement(sql);stmt.setObject(i, o);

stmt.execute();

Listing 6.3: PreparedStatement Ausf”uhrung

Die Methode setObject(int i, Object o) setzt den Wert i-ten Para-

meter des prepared statement vor der Anweisungsausfuhrung. Dabei wird das

Objekt o implizit auf den nach Tabelle 6.1 entsprechenden JDBC Datentyp

gemappt.

Die Methode execute() auf dem PreparedStatement-Objekt fuhrt

die Anweisung aus.

Eine analoge Vorgehensweise ergibt sich fur die Ausfuhrung einer SQL-Abfrage

SELECT.

56

Kapitel 7

Anforderungen

Gemaß der Zielsetzung aus Einleitung 1.2 soll Generic Web Services dazu

dienen, Web Services in einem automatischen Generierungsprozess zu erstellen,

die auf den zuvor spezifizierten Daten eines beliebigen Datenhaltungssystems

operieren.

Generic Web Services hat nun die Aufgabe, diesen Generierungsprozess zu

implementieren. Dabei werden verschiedene Anforderungen gestellt. Einerseits

gelten diese Anforderungen bezuglich der Komponenten, die ein Web Service

grundsatzlich bieten muss. Ebenso wie die WSA (Web Service Architecture,

siehe Abschnitt 3.2) gibt auch das RPC-Protokoll Vorgaben was die Notwen-

digkeit von Softwarekomponenten betrifft (vgl. Abschnitt 2.2.1). Beispielsweise

ist hier an Schnittstellenbeschreibung oder Client/Server-Stub zu denken. So-

mit sind also die Typen der Komponenten der Web Services eindeutig definiert.

Andererseits beziehen sich die Anforderungen auf den Generierungspro-

zess, d. h. auf die spezifischen Auspragungen der jeweiligen Web Service Kom-

ponenten. Methodensignaturen als Schnittstelle mussen z. B. festgelegt werden

und letztlich naturlich auch die eigentliche Implementierung der Funktionalitat

dieser Methoden.

Die Tatsache, dass die Auspragung der Daten in dem Datenhaltungssystem

nicht vordefiniert ist und die Art der Operation auf den Daten unspezifisch

ist, muss Generic Web Services diese Informationen dynamisch sammeln und

darauf basierend den an den Web Service gestellten Anforderungen gerecht

werden.

Es gilt nun hauptsachlich, diese Anforderungen im Detail zu definieren,

um sie im Generierungsprozess umsetzen zu konnen.

7.1 Anforderungen an Web Services

Die Anforderungen an die Implementierung der Web Services kann unterteilt

werden bezuglich der serverseitigen und der clientseitigen Softwarekomponen-

ten.

57

7.1. Anforderungen an Web Services

Serverseitige Komponenten

Auf Serverseite erfolgt die eigentliche Ausfuhrung des Softwaredienstes,

der als Web Service im verteilten System angeboten wird. Hierzu sind die

folgenden Komponenten bereitzustellen:

• Web Service Implementierung

Die eigentliche Implementierung des Web Service muss eine eigenstandig

lauffahige Softwarekomponente sein, die eine spezifische Funktionalitat

bietet. Im Rahmen der Aufgabenstellung dieser Arbeit lasst sich diese

Funktionalitat generell beschreiben als

– Zugriff auf SAP R/3-Systeme

Die Softwarekomponente greift auf ein SAP R/3-System zu, um

R/3-Anwendungen auf konkreten Daten auszufuhren.

– Zugriff auf relationale Datenbanksysteme

Die Softwarekomponente greift auf eine Datenbank zu, um eine Da-

tenselektion konkreter Datenbankinhalte zu realisieren oder die Da-

tenmanipulation in definierter Form durchzufuhren.

• Web Service Schnittstelle (Interface)

Damit die Softwarekomponente als Web Service zugreifbar ist, muss eine

Schnittstelle nach außen gegeben sein.

• Web Service Beschreibung (WSDL)

Um im Sinne der Web Service Architektur den Aufruf des implementier-

ten Dienstes zu ermoglichen, muss eine Beschreibung seiner Schnittstel-

le in Form der WSDL verfugbar sein. Die WSDL-Beschreibung sichert

damit das Lokalisieren des Web Service im verteilten System einerseits

und die vollstandige Spezifizierung seiner Schnittstelle bezuglich Ein- und

Ausgabeparametern, Datentypen der Ubergabe- und Ruckgabewerte und

Signatur der Schnittstellenmethode andererseits.

• RPC-Skeleton

Zur Realisierung einer RPC-basierten Kommunikation mit dem Web Ser-

vice muss auf Serverseite ein RPC-Skeleton-Objekt zur Verfugung stehen,

das den Web Service lokal anspricht.

Clientseitige Komponenten

Der Web Service Client ist lediglich fur den Aufruf von Interesse. Zu-

sammen mit der Vorderung nach einer RPC-Kommunikation ergeben sich im

Einzelnen:

58

7.2. Anforderungen an Generic Web Services

• Web Service Client

Um den Web Service aufrufen zu konnen, muss eine Clientkomponente

implementiert sein.

• Web Service Invocation Framework (WSIF)

Der Web Service Client bietet in der Regel keine graphische Oberflache

an, von der aus der Nutzer des Dienstes den Aufruf absetzen kann.

Gewohnlich erfolgt die Integration des Dienstes auf Programmierebe-

ne, um die Funktionalitat fur weitere Implementierungen verwenden zu

konnen. An dieser Stelle besteht nun aber die Anforderung, ein Frontend

(GUI) zur Verfugung zu stellen, das die Eingabe der dienstspezifischen

Parameter erlaubt und gleichzeitig die Ruckgabewerte des Web Service

dem Benutzer visualisiert. Dies ist im Rahmen der vorliegenden Arbeit

nur teilweise moglich: Je nach Datentyp der Ubergabeparameter ist eine

Tastatureingabe nicht moglich. Beispielsweise kann es sich um ein Objekt

der Klasse java.lang.Byte[] handeln, das nicht textuell als String

eingetippt werden kann.

• RPC-Stub

Letztlich fordert auch die Clientseite zur Kommunikation uber RPC ein

lokales”Stellvertreterobjekt“ der Web Service Schnittstelle.

7.2 Anforderungen an Generic Web Services

Prinzipiell lassen sich die an die Applikation Generic Web Services zu stellen-

den Anforderungen analog zu Abschnitt 7.1 in client- und serverseitige trennen.

Da hier jedoch die Benutzerinteraktion eine wichtige Rolle spielt, soll im Fol-

genden in Anlehnung an das Ebenen- und Schichtenmodell (siehe Abschnitt

1) von Anforderungen an die Prasentations- und Applikationskomponente ge-

sprochen werden.

Prasentationskomponente

Die Prasentationskomponente ist dafur verantwortlich, samtliche generischen

Informationen im Rahmen der Web Service Generierung mit dem Anwender

abzustimmen. Im Einzelnen definieren sich diese benutzerspezifischen Daten

wie folgt:

• Datenbank-Adapter

Der Benutzer muss als Grundlage fur den Zugriff auf ein Datenhaltungs-

system (SAP R/3 oder relationales Datenbanksystem) die gewunschte

Datenbank-Adapterklasse auswahlen.

59

7.2. Anforderungen an Generic Web Services

• Verbindungsdaten

Auf Basis der ausgewahlten Adapterklasse mussen die entsprechenden

Verbindungsdaten der Applikation Generic Web Services mitgeteilt wer-

den.

• Metadaten

Die Darstellung der prasentierten Metadaten, die Generic Web Services

uber die Verbindung aus der Datenquelle extrahiert hat, erfordert vom

Anwender die Auswahl, welche dieser Metadaten als Datentypen fur die

Ubergabeparameter der Web Service Methode dienen sollen.

• package-Deklaration

Die zu generierenden Dateien werden in das benutzerdefinierte package-

Verzeichnis erstellt und Java Klassen mit entsprechender package-

Deklaration im Generierungsprozess compiliert.

• Web Service Name

Der Name des erzeugten Web Service ist benutzerdefiniert.

• Web Service Endpoint

Der Web Service Endpoint definiert in WSDL die Adresse, unter der der

generierte Web Service aufgerufen werden kann.

• Web Service Methoden

Der Benutzer muss auf Grundlage der ausgewahlten Metadaten die

Schnittstellenmethoden des Web Service definieren. Der Methodenna-

me muss ubergeben werden, ebenso wie Datentypen der Ruckgabe- und

Ubergabeparameter der Methode. Der Anwender muss selbst definieren

konnen, wieviele Methoden mit welchen Signaturen generiert werden.

Zusatzlich muss bei der Verwendung von nicht-SAP Adapterklassen defi-

niert werden konnen, welche Datenmanipulation die Web Service Imple-

mentierung auf den Daten ausfuhrt.

• Zusatzliche benutzerspezifischen Informationen

– RPC-Skeleton

Der Benutzer legt fest, ob eine RPC-Skeleton-Klasse generiert wird

oder nicht.

– Web Service Deployment Descriptor (WSDD)

Der Benutzer legt fest, ob eine WSDD-Datei fur das Deployment

und/oder das Undeployment des Web Service generiert werden soll.

– SOAP-Logger

Der Benutzer kann optional die Generierung eines SOAP-Loggers

60

7.2. Anforderungen an Generic Web Services

veranlassen. Dieser dokumentiert bei Aufruf des Web Service die

gesendeten und empfangenen SOAP Nachrichten.

– Web Service Invocation Framework (WSIF)

Die Verfugbarkeit des WSIF stellt zwar einserseits eine Anforderung

an den Web Service Client dar, andererseits ist es dem Benutzer

uberlassen, davon Gebrauch zu machen.

• Download

Letztlich muss der Anwender die von Generic Web Services generierten

Dateien auf seinen lokalen Rechner downloaden konnen.

Applikationskomponente

Die Anforderungen an die Applikationskomponente von Generic Web

Services sind in vier Punkten zu nennen:

• Datenbank-Adapter

Generic Web Services muss dynamisch bei Programmstart nach vorhan-

denen Datenbank-Adapterklassen suchen und somit dem Benutzer die

Auswahl ermoglichen.

• Datenhaltung

Generic Web Services muss uber Datenstrukturen verfugen, die es er-

lauben, die obigen Benutzerdaten wahrend der gesamten Zeit der Benut-

zerinteraktion zu sammeln, damit sie bei Start des Generierungsprozesses

verfugbar sind.

• Generierungsprozess

Generic Web Services generiert in eigenstandigem Ablauf alle notwen-

digen und eventuell optional vom Benutzer gewunschten Web Service

Komponenten.

• Web Service (Un-)Deployment

Die Applikation muss die Moglichkeit bieten, ein automatisches Deployen

der erzeugten Web Services durchzufuhren.

61

Kapitel 8

Entwurf von Generic Web

Services

Die technische Umsetzung der im vorherigen Kapitel beschriebenen Anforde-

rungen, d. h. die Implementierung von Generic Web Services erfordert einer-

seits die Wahl einer geeigneten Technologie, die es erlaubt, uber eine graphi-

sche Oberflache die Benutzerinteraktion zu ermoglichen und andererseits einige

Softwarekomponenten, die den eigentlichen Web Service Generierungsprozess

unterstutzen. Dies fuhrt zunachst zu Abschnitt 8.1.

8.1 Vorbetrachtungen

Wahl der Technologie

Dass bei der Wahl einer Technologie zur Realisierung von Generic Web

Services lediglich Java Konzepte in Betracht kommen, liegt auf der Hand.

Die Tatsache, dass es bei der praktischen Nutzung von Generic Web Services

nicht zwingend gegeben sein muss, dass der Rechner, der die Anwendung

ausfuhrt und den Web Service generiert auch gleichzeitig der Rechner ist,

auf dem dieser Dienst dann in einer SOAP Engine verfugbar ist, legt nahe,

die Benutzerfuhrung uber dynamisch erzeugte HTML-Seiten umzusetzen. Die

Wahl fiel letztlich auf die Java Servlet-Technologie.

Zudem bietet der Einsatz von Servlets programmiertechnische Vorteile. Ein

einzelner Generierungsworkflow wird an ein HttpSession-Objekt gebunden,

so dass temporar benotigte Daten uber die Benutzer-Session gespeichert wer-

den konnen.

Art der Benutzerfuhrung

Um dem Anwender eine klare und moglichst intuitiv verstandliche Vor-

gehensweise fur die Generierung von Web Services zu bieten, bietet es sich

62

8.2. Servlet-basierter Aufbau

an, eine Art”Wizard“ zu realisieren, d. h. die Moglichkeit einer schrittweisen

Durchfuhrung samtlicher erforderlichen Eingaben und Konfigurationen zu

ermoglichen.

8.2 Servlet-basierter Aufbau

Im Ganzen umfasst Generic Web Services die Realisierung einer Architektur

mit vier Java Servlets, die von einem statischen HTML-Framework aus aufge-

rufen werden. Im Einzelnen handelt es sich um:

• GenerateWebServicesServlet : Das Servlet beinhaltet den eigentli-

chen Generierungsprozess der Web Services.

• DeployWebServicesServlet : Das Servlet deployed einen Web Service,

der als jar-Datei vorliegt in einer per URL definierten Axis Umgebung.

• ShowWebServicesServlet : Das Servlet greift auf eine beliebige Axis

Installation zu und liest die darin deployten Web Services aus.

• RegisterWebServicesServlet : Das Servlet deutet die Web Service

Komponente UDDI an. Da eine UDDI Anbindung nicht im Rahmen der

Arbeit zu betrachten ist, leistet das Servlet keine Funktionalitat. Dennoch

ist das Grundgerust vorhanden.

Jedes dieser Servlets implementiert das Interface-Servlet IServlet, wel-

ches Zugriffsmethoden auf die jeweils zugehorigen IServletRequest- und

IServletResponse-Implementierungen bietet.

63

Kapitel 9

Implementierung

9.1 Datenbank-Adapter

Eine wichtige Komponente von Generic Web Services stellt der Datenbank-

Adapter dar.

Es besteht die Anforderung, eine weitestgehend modulare und auf Interfa-

ces basierende Programmstruktur zu schaffen, so dass zukunftig die Moglichkeit

gegeben ist, auf einfache Weise weitere Datenhaltungssysteme zu integrieren.

Ein Datenbank-Adapter beruht auf einer Implementierung des Interface

IConnect, das folgende Methoden bietet:

• setConnectData(Properties p) : setzt die Verbindungsdaten des

Properties-Objektes in eine Instanz von ConnectData.

• getConnectData() : liefert die ConnectData-Instanz.

• open() : offnet eine Datenbank-Verbindung und gibt das Verbindungs-

objekt als Object zuruck.

• close() : schließt die Verbindung zur Datenbank.

• getMetadataImplClass() : gibt die Klasse zuruck, die die Metadaten

der Datenquelle ausliest.

• hasQueryTypes() : spezifiziert, ob die angeschlossene Datenbank

SELECT-, UPDATE-, INSERT- und DELETE-Anfragen unterstutzt.

Dabei sorgt die Klasse ConnectData fur die Speicherung der relevanten

Verbindungsdaten.

Die vorliegende Version von Generic Web Services beinhaltet bereits drei

Implementierungen einer Adapterklassen, zur Anbindung von SAP R/3, MyS-

QL und ORACLE. Die Beziehung der Klassen untereinander zeigt die folgende

Abbildung 9.1 in UML-Notation:

64

9.2. Generierungsprozess

Abbildung 9.1: Schnittstellen der Datenbank-Adapterklassen

9.2 Generierungsprozess

Die Generierung der Web Service Komponenten erfolgt mit Unterstutzung der

SOAP Implementierung Axis der Apache Software Foundation. Dieses Paket

liefert neben einer Java SOAP Engine verschiedene andere Werkzeuge und

Klassen, die das automatische Erzeugen von Web Service Komponenten er-

laubt.

Bekannte Vertreter sind sicherlich Java2WSDL und WSDL2Java. Aller-

dings erfullten die von diesen Klassen generierten Web Service Geruste in vie-

len Details nicht die Anforderungen. Beispielsweise hat eine Manipulation der

Web Service Methodenparameternamen in keinster Weise Einfluß auf die Be-

zeichnung der Parameter innerhalb der WSDL. Da die WSDL allerdings die

65

9.3. Web Service Invocation Framework (WSIF)

korrekte Methodensignatur beschreiben soll, konnte alleine aus diesem Grund

nicht auf Java2WSDL zuruckgegriffen werden.

9.3 Web Service Invocation Framework (WSIF)

Das WSIF implementiert den Web Service Client. Der Begriff”Framework“

heisst in diesem Zusammenhang, dass ein HTML-Frontend den Aufruf des

Web Service Client ubernimmt.

66

Kapitel 10

Einsatzbeispiel

Um das Generic Web Services Frontend im praktischen Einsatz vorzustellen,

wird es in diesem Kapitel darum gehen, fur den bereits bekannten Funktions-

baustein BAPI COMPANY GETLIST die notwendigen Schritte von der Gene-

rierung des Web Service, uber das Deployen bis hin zum Aufruf darzustellen.

Gegebenenfalls konnen die Parameter des RFM in Kapitel 4, Abschnitt 4.5.5

uber die Dialog-Abbildungen des SAP Systems in Erinnerung gerufen werden.

Es werden die wichtigsten GUI-Elemente und Funktionalitaten am Beispiel

erlautert. Die nicht explizit erwahnten sind dagegen intuitiv verstandlich.

10.1 Generierung

Zunachst wird der Web Service generiert, der den Aufruf von

BAPI COMPANY GETLIST uber JCo implementiert.

67

10.1. Generierung

Auswahl der Datenbank-Adapterklasse

Generic Web Services stellt beim Aufruf alle verfugbaren Adapterklassen

zur Auswahl wie in Abbildung 10.1 zu sehen ist.

Abbildung 10.1: Dialog: Auswahl der Datenbank-Adapterklasse

68

10.1. Generierung

Eingabe der Verbindungsdaten

Mit der Wahl der Adapterklasse werden entsprechend ihrer Implementierung

Verbindungsdaten benotigt. Dazu gehort auch – wie im Falle eines SAP

R/3-Systems – der Name des zu nutzenden Funktionsbausteins. Abbildung

10.2 stellt die zugehorige Oberflache dar.

Abbildung 10.2: Dialog: Pflege der Verbindungsdaten

69

10.1. Generierung

Auswahl der Metadaten

Nach erfolgreicher Anmeldung an dem System werden die Metadaten des

Funktionsbausteins ausgelesen und gemaß der Abbildung 10.3 dargestellt.

Abbildung 10.3: Dialog: Auswahl der Metadaten

Der Tabellenkopf (rote Markierung) definiert die ausgelesenen RFM

Parameter-Metadaten:

• Structure : stellt alle Parameter als Baumstruktur dar. Ein top-level

Knoten des Baumes reprasentiert einen Parameter mit seinem Namen,

unabhangig von seinem Datentyp. Ist dieser Parameter vom ABAP Dic-

tionary Datentyp Struktur oder Tabelle, besitzt er Kindelemente,

namlich seine Felder, die ebenfalls uber ihre Namen dargestellt sind. Die

Namen sind editierbar, da sie letztlich die Signatur der Web Service Me-

thode mitbestimmen und somit in den Schnittstellenbeschreibungen wie-

derzufinden sind.

• Parameter/Return : kennzeichnet den Parameter als Ubergabe-

oder Ruckgabeparameter. Im Falle eines Tabellenparametertyps

(COMPANY LIST) ist beides moglich. Die Eigenschaft wird auf die Kind-

knoten vererbt.

• Type : bezeichnet den ABAP Dictionary Datentyp des Parameter.

• Parameter/Return Array Type : definiert den zugehorigen Type als

Array Typ, d. h. wird der Parameter als Ubergabeparameter verwendet,

70

10.1. Generierung

ist ein Array dieser Objekte zu ubergeben. Analog dazu wird ein Array-

Objekt von der Methode zuruckgeliefert, wenn die entsprechende Konfi-

guration vorgenommen wurde. Die Eigenschaft ist nicht auf die Kindele-

mente ubertragbar.

Wurden alle fur die Methode gewunschten Parameter ausgewahlt und konfigu-

riert, geht es im nachsten Schritt um die Konfiguration des Web Service.

71

10.1. Generierung

Generelle Eigenschaften

Zu den grundlegenden Konfigurationen des Web Service gehoren sein Name,

die Spezifizierung des Endpoint, also die URL unter der der Dienst erreichbar

ist.

72

10.1. Generierung

Spezielle Funktionalitaten

Hier kann auf verschiedene Arten in den Generierungsprozess eingegriffen wer-

den. So kann beispielsweise die Erzeugung der Stub-Objekte unterbunden wer-

den. Andererseits kann explizit verlangt werden, Web Service Deployment Des-

criptoren oder einen Logging-Mechanismus der SOAP Nachrichten zu erzeugen.

Der WSIF kann ebenfalls optional zu- oder abgeschaltet werden.

73

10.1. Generierung

Web Service Methoden

Auf Basis der Metadaten werden hier die Methodensignaturen der Web Services

benutzerabhangig definiert. Es konnen beliebig viele Methoden mit beliebigen

Parametern (abhangig von der vorherigen Auswahl) definiert werden.

74

10.1. Generierung

Download

Der generierten Klassen und Dateien werden hier – in zwei Packages verpackt

– auf den Client (evtl. zum Deployen) gedownloaded. Zum einen ist dies die

Serverseite des Web Service, zum anderen der Client mit dem servletbasierten

WSIF.

75

10.2. Deployment

10.2 Deployment

Hier kann ein bestimmter Web Service als jar-Paket upgeloaded und als Web

Service in Axis deployed werden.

76

10.3. Aufruf

10.3 Aufruf

10.3.1 WSIF

10.3.2 Web Service

77

Anhang A

ABAP Dictionary Datentypen

Die Tabelle A beschreibt die Konvertierung von elementaren ABAP Dictionary

Datentypen in elementare ABAP Datentypen. Dabei bezeichnet n die Zahl der

Stellen und m die Zahl der Nachkommastellen des Feldes im ABAP Dictionary.

Die elementaren ABAP Datentypen konnen Tabelle 5.1 entnommen werden.

ABAP Dictionary Typ Beschreibung ABAP Typ

ACCP Buchungsperiode im Format JJJJ.MM N(6)

CHAR n String der Lange n C(n)

CLNT Mandant C(3)

CUKY Wahrungsschlussel C(5)

CURR n,m Wahrungsfeld P((n+1)/2) DECIMAL m

DATS Datum D(8)

DEC n,m Rechen- oder Betragsfeld P((n+1)/2) DECIMAL m

FLTP Fließkommazahl F(8)

INT1 1-Byte-Integer, X(1)

Zahlbereich 0 bis 255

INT2 2-Byte-Integer, X(2)

Zahlbereich -32767 bis 32767

INT4 4-Byte-Integer, X(4)

Zahlbereich -2177483647 bis 2177483647

LANG Sprachenschlussel C(1)

LCHR n Zeichenkette beliebiger Lange n, C(n)

mindestens 256 Zeichen

LRAW n Bytefolge beliebiger Lange n, X(n)

mindestens 256 Bytes

NUMC n Ziffernfolge der Lange n N(n)

PREC Genauigkeit eines QUAN Feldes X(2)

QUAN n,m Menge, entspricht DEC P((n+1)/2) DECIMAL m

RAW n Byte-Folge der Lange n X(n)

RAWSTRING Byte-Folge variabler Lange XSTRING

STRING Zeichenkette variabler Lange STRING

78

TIMS Zeit im Format HH.MM.SS T(6)

UNIT n Einheitenschlussel C(n)

VARC n Zeichenkette variabler Lange C(N)

Tabelle A.1: Mapping von ABAP Dictionary Datentypen und ABAP

Datentypen

79

Anhang B

CD-ROM

Die beiliegende CD-ROM enthalt alle erforderlichen Softwarekomponenten zur

Ausfuhrung von Generic Web Services, d. h. zur Generierung von Java Web

Services und deren Bereitstellung (Deployment) unter Microsoft Windows, so-

wie zur Weiterentwicklung der Projektimplementierung. Im Einzelnen sind ent-

halten:

• Im Hauptverzeichnis gibt die HTML-Datei index.htm diese Ubersicht

uber den Inhalt der CD-ROM. Das Dokument installation.pdf

enthalt die Installationsanleitung zu Generic Web Services aus Anhang

C.

• \apps Das Verzeichnis beinhaltet Installationsroutinen bzw. Projektver-

zeichnisse der Open Source Anwendungen im zip-Format, die die We-

bapplikation Generic Web Services benotigt:

– axis-1 1-src.zip

Die SOAP-Implementierung Axis der Apache Software Foundation

einschließlich des Java-Quellcodes.

– commons-fileupload-1.0.zip

Ein Package aus dem Jakarta Commons Projekt der Apache Softwa-

re Foundation. Es bietet eine API zur Realisierung von File-Uploads

fur Webapplikationen.

– j2sdk-1 4 2 03-windows-i586-p.exe

Das Java 2 Software Development Kit (JDK) der Sun Microsystems,

Inc. in der Standard Edition Version.

– jakarta-tomcat-5.0.16.zip

Der Web Application Server Tomcat der Apache Software Founda-

tion.

– xalan-j 2 6 0-bin.zip

80

Die Apache XSLT-Implementierung zur Transformation von XML-

Dokumenten in andere (XML-)Dokumente in Java.

– xerces-j-bin.2.6.2.zip

Die Apache Implementierung eines XML-Parsers in Java.

Zusatzlich sind die Pakete juddi-0.9rc3.zip,

ruddi-1.0-bin-max.zip und uddi4j-bin-2 0 2.zip ent-

halten, die Open Source Java-APIs zum Zugriff auf (offentliche)

UDDI-Registrierungen bieten.

• \doc Hier liegt die API-Dokumentation zu Generic Web Services im

HTML-Format.

• \installed Das enthaltene jakarta-tomcat-5.0.16 -Verzeichnis reprasen-

tiert eine Tomcat-Installation mit integrierten Axis- und Generic Web

Services-Applikationen und allen erforderlichen jar-Dateien.

• \jdbc jco Die in der vorliegenden Version von Generic Web Ser-

vices implementierten Adapter zur Anbindung externer Datenquel-

len erfordern die in diesem Verzeichnis vorhandenen Middleware-

Implementierungsklassen1.

• \source Das Verzeichnis enthalt die Java-Quellcodedateien zu Generic

Web Services.

1Die vorhandene Installation der Datenquellen, die uber diese Klassen angesprochen wer-

den, wird vorausgesetzt.

81

Anhang C

Installationsanleitung

C.1 Installation der Komponenten

Als Webapplikation auf Basis der Java Servlet-Technologie setzt die

Ausfuhrung der Projektimplementierung Generic Web Services die Installation

einiger Softwarekomponenten voraus. In erster Linie sind ein Web Application

Server bzw. Servlet-Container sowie ein Java Development Kit erforderlich. Die

Installationsanleitung beschreibt die Bereitstellung aller notwendigen, bereits

wahrend der Entwicklungsphase verwendeten Open Source Produkte sowie die

Installation und den Aufruf von Generic Web Services und deren Kompo-

nentenanwendungen unter Microsoft Windows. Diese Produkte liegen in den

jeweils getesteten Versionen auf der CD-ROM vor. Bei Einsatz variierender

Produkt-Versionen kann der Installationsverlauf abweichen. Die Verwendung

anderer, gleichartiger, frei verfugbarer oder auch kommerzieller Produkte wird

hier nicht betrachtet1.

Java 2 SDK 1.4.2 03

Die Implementierung von Generic Web Services erfolgte auf Basis des

Java 2 SDK Version 1.4.2 03. Eine weiterfuhrende Entwicklung setzt somit

diese oder eine unter http://java.sun.com frei erhaltliche aktualisierte

Version voraus.

Auch die Ausfuhrung von Generic Web Services bzw. deren Komponenten-

applikationen macht die Installation des Java 2 SDK zwingend notwendig.

Die im nachsten Abschnitt beschriebene Installation des Applikationsservers

erfordert zudem die Definition einer Umgebungsvariablen unter Windows:

1Denkbar ist beispielsweise der Einsatz eines JBoss Application Server oder IBM Web-

Sphere als Alternativen zu dem verwendeten Tomcat Web Application Server der Apache

Software Foundation.

82

C.1. Installation der Komponenten

JAVA HOME

mit Wert

%J2SDK PATH%.

Apache Tomcat 5.0.16

Die in \apps vorliegende Version des Applikationsservers Tomcat erfordert

lediglich ein Entpacken der zip-Datei in ein beliebiges Verzeichnis, nachfol-

gend mit %TOMCAT HOME% bezeichnet. Die Dateien startup.bat und

shutdown.bat in %TOMCAT HOME%\bin ubernehmen den Start- bzw.

Stoppvorgang des Tomcat-Servers.

Optional kann auch das Verzeichnis jakarta-tomcat-5.0.16 aus \installed

kopiert werden. %TOMCAT HOME% ergibt sich entsprechend.

Sollte der Tomcat Standard-Port %TOMCAT PORT% 8080 in Konflikt

stehen mit bestehenden Installationen (beispielsweise einer ORACLE

Datenbank, deren Standard-Installationsroutine der Version 9i einen

HTTP-Server auf Port 8080 installiert), kann dieser uber der Datei %TOM-

CAT HOME%\conf\server.xml umkonfiguriert werden.

Im Hinblick auf die Axis-Installation muss darauf geachtet werden, dass unter

%TOMCAT HOME%\common\lib die Java-Library activation.jar vor-

handen ist. Einigen Tomcat-Versionen liegt diese (und andere hier allerdings

nicht benotigte) standardmaßig nicht bei.

In jedem Fall verlangt Tomcat die Umgebungsvariable %JAVA HOME%.

Apache Axis 1.1

Das Paket axis-1 1.zip enthalt nach Entpacken unter

%AXIS HOME%\webapps das Verzeichnis axis. Dieses wird als Webapplikati-

on in die bestehende Tomcat-Installation nach %TOMCAT HOME%\webapps

kopiert.

Wurde die Tomcat-Installation aus \installed verwendet, ist Axis bereits

enthalten.

Zusatzlich mussen folgende Klassenpfade (%CLASSPATH% -Variable) als

Umgebungsvariable in Windows gesetzt werden:

• %AXIS HOME%\lib\axis.jar

• %AXIS HOME%\lib\axis-ant.jar

• %AXIS HOME%\lib\commons-discovery.jar

• %AXIS HOME%\lib\commons-logging.jar

• %AXIS HOME%\lib\jaxrpc.jar

83

C.2. Installation von Generic Web Services

• %AXIS HOME%\lib\log4j-1.2.8.jar

• %AXIS HOME%\lib\saaj.jar

• %AXIS HOME%\lib\wsdl4j.jar

• %PATH%\xercesImpl.jar2

(in xerces-j-bin.2.6.2.zip)

• %PATH%\xmlParserAPIs.jar2

(in xalan-j 2 6 0-bin.zip oder xerces-j-bin.2.6.2.zip)

Es ist darauf zu achten, eine Tomcat-Version 4.1.x oder hoher zu verwenden.

Andere Servlet-Container konnen eingesetzt werden, wenn sie mindestens Ver-

sion 2.2 der Servlet-API implementieren.

Zur Generierung von Web Services, d. h. zur Ausfuhrung der entsprechenden

Komponentenapplikation von Generic Web Services, ist die Installation von

Axis allerdings nicht zwingend erforderlich, da die hierzu benotigten Axis-

Bibliotheken innerhalb der Projektstruktur von Generic Web Services bereit-

gestellt sind.

C.2 Installation von Generic Web Services

Die unter \installed gelieferte Tomcat-Installation enthalt unter webapps die

Applikation Generic Web Services in gleichnamigem Verzeichnis. Alle erfor-

derlichen jar- und class-Dateien sind innerhalb der ublichen Verzeichnis-

struktur fur Webapplikationen abgelegt:

Abbildung C.1: Verzeichnisstruktur von Generic Web Services

Daruber hinaus sind unter images und scripts Graphiken und Skripte hin-

terlegt, die von HTML-Seiten referenziert werden. Das in WEB-INF\scripts

liegende XSL-Stylesheet wird von der Java-Applikation zur Generierungslauf-

zeit eingelesen. Die Verzeichnishierarchien sind somit beizubehalten.

Das Deployen der Webapplikation in einer bestehenden Tomcat-Umgebung er-

folgt durch Kopieren der Ordnerstruktur GenericWebServices in das entspre-

chende webapps-Verzeichnis.

2%PATH% bezeichnet den absoluten Dateisystempfad.

84

C.3. Aufruf

C.3 Aufruf

Es sei %TOMCAT HOST% die IP-Adresse des Rechners mit aktueller Tomcat-

Installation. Dann ist unter der URL

http://%TOMCAT HOST%:%TOMCAT PORT%/GenericWebServices

ein HTML-Framework zum Aufruf der einzelnen Servlets von Ge-

neric Web Services verfugbar. Sollen diese direkt aufgerufen werden

(beispielsweise aus einer anderen Webapplikation heraus), wird obi-

ge URL durch den zugehorigen Inhalt des Elementes <url-pattern>

in %TOMCAT HOME%\webapps\GenericWebServices\WEB-INF\web.xml

erganzt, standardmaßig konfiguriert mit

• /servlet/GenerateWebServicesServlet,

• /servlet/DeployWebServicesServlet,

• /servlet/ShowWebServicesServlet,

• /servlet/RegisterWebServicesServlet.

Zusatzlich muss dann die Ausgabe der Konsolenmitteilungen im vordefinierten

HTML-Frame unterbunden oder angepasst werden. Hierzu ist in genannter

XML-Datei web.xml (Web Application Deployment Descriptor) der unter

Listing C.1 dargestellte Bereich auszukommentieren bzw. zu modifizieren.

<context-param><param-name>HTML_CONSOLE_FRAME</param-name><param-value>top.frames[1]</param-value><description>Specifies the HTML frame name for output messages

</description></context-param>

Listing C.1: web.xml von Generic Web Services

Der Elementinhalt von <param-value> spezifiziert das HTML-Frame-Objekt

top.frames[1]. Soll die Ausgabe von Informationen zum Generierungspro-

zess zur Laufzeit verhindert werden, ist das Elternelement <context-param>

zu entfernen.

Hinweis zum verwendeten Browser: Sowohl die statisch abgelegten als

auch die serverseitig dynamisch erzeugten Webseiten enthalten neben reinem

HTML-Code auch clientseitig auszufuhrendes Javascript zur Darstellung sowie

zur Realisierung von Benutzereingaben. Erstellt und getestet wurden Design

und korrekte Funktionalitat der Seiten mit dem Microsoft Internet Explorer ab

Version 5.5. Altere Produktversionen oder Browser anderer Hersteller wurden

nicht berucksichtigt.

85

C.4. Installation von Datenquellen-Middleware

C.4 Installation von Datenquellen-Middleware

Voraussetzung fur die Nutzung von integrierten Datenquellen-Adapterklassen

in Generic Web Services (siehe C.5) ist die Verfugbarkeit der datenserverspe-

zifischen Middleware. Diese ist fur alle gangigen Datenbanksysteme (und auch

fur das SAP R/3-System) als jar-Archiv erhaltlich.

SAP Java Connector (JCo)

Das Paket jco-ntintel-1.1.03.zip beinhaltet die verwendet Versi-

on 1.1.03 des Java Connectors fur SAP. Die relevante Windows-Library

librfc32.dll ist in das System32 -Verzeichnis der vorliegenden Windows-

Installation zu kopieren.

Das Archiv jCO.jar stellt die fur Java erforderliche Klas-

senbibliothek. Sie ist Generic Web Services unter %TOM-

CAT HOME%\webapps\GenericWebServices\WEB-INF\lib zur Verfugung

zu stellen3.

Fur zukunftige Entwicklungen liegt JCo zusatzlich in der neueren Version 2.0.5

auf der CD-ROM vor. Die Installation erfolgt analog. Lediglich die Klassenbi-

bliothek tragt hier den Namen sapjco.jar.

JDBC-kompatible Konnektoren

Implementierungen der JDBC API fur relationale Datenbanksysteme

sind analog zur Bereitstellung des SAP JCo in dem lib-Verzeichnis der

Projektstruktur von Generic Web Services als jar-Archiv zu hinterlegen3.

Gemaß den bereits integrierten Adapterklassen (vgl.

C.5) sind die zugehorigen JDBC-Implementierungen

mysql-connector-java-3.0.10-stable-bin.jar und ojdbc14.jar

sowie JCo mit jCO.jar in Generic Web Services vorinstalliert.

C.5 Integration von Datenquellen-Adaptern

Die vorliegende Version von Generic Web Services beinhaltet Java-

Adapterklassen fur die Anbindung einer MySQL- und ORACLE-Datenbank

sowie eines SAP R/3-Systems. Um andere JDBC-kompatible Datenquellen zu

nutzen, mussen entsprechende Adapterklassen implementiert und eingebunden

werden.

Die Erstellung einer Adapterklasse basiert auf dem Java-Interface

de.tsystem.diplom.connect.IConnect, welches implementiert werden

muss. Sie erfasst die erforderlichen Verbindungsdaten und -charakteristika und

3Das Einbinden von Klassenbibliotheken als jar erfordert den Neustart des Tomcat-

Servers.

86

C.5. Integration von Datenquellen-Adaptern

stellt diese dem Generierungsprozess bereit. Informationen uber die Signatur

der Interface-Methoden liefert die in \doc verfugbare API-Dokumentation.

Die Integration einer Implementierungsklasse in Generic Web Services erfolgt

durch Kopieren in das Verzeichnis WEB-INF\classes. Es ist darauf zu achten,

eine dem Package der Adapterklasse entsprechende Verzeichnisstruktur zu

verwenden, die ggf. angelegt werden muss. Zusatzlich erforderliche JDBC-

Treiberklassen sind als jar-Archiv unter WEB-INF\lib abzulegen (siehe C.4).

Die Webapplikation Generic Web Services identifiziert im Rahmen eines

Generierungsprozesses eines Web Services die eingebundenen Implementie-

rungsklassen innerhalb ihres Klassenpfades zur Laufzeit und ermoglicht uber

einen Auswahldialog die Verwendung der Adapter.

87

Abbildungsverzeichnis

1.1 Die drei Ebenen einer Anwendung . . . . . . . . . . . . . . . . 3

1.2 4-Tier-Architektur eines webbasierten Systems . . . . . . . . . 5

1.3 Webbasiertes System mit verteilter Applikationslogik . . . . . . 5

1.4 Webbasiertes System mit Web Services zur verteilten Datenser-

veranbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 RPC mit Stub und Skeleton . . . . . . . . . . . . . . . . . . . . 11

2.2 Service-oriented architecture (SOA) . . . . . . . . . . . . . . . 13

3.1 Web Services architecture (WSA) . . . . . . . . . . . . . . . . . 16

4.1 Schichten eines SAP Business-Objektes . . . . . . . . . . . . . . 29

4.2 ABAP Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Zugriff auf BAPIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 SAP Function Builder . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Importparameter BAPI COMPANY GETLIST . . . . . . . . . . . 38

4.6 Exportparameter BAPI COMPANY GETLIST . . . . . . . . . . . 39

4.7 Tabellenparameter BAPI COMPANY GETLIST . . . . . . . . . . 39

4.8 Struktur des Tabellenparameter BAPI COMPANY GETLIST . . 39

4.9 Ausgabe BAPI COMPANY GETLIST . . . . . . . . . . . . . . . . 40

4.10 ALE Integrationsszenario . . . . . . . . . . . . . . . . . . . . . 41

5.1 SAP Java Connector Architektur . . . . . . . . . . . . . . . . . 43

6.1 JDBC Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 52

9.1 Schnittstellen der Datenbank-Adapterklassen . . . . . . . . . . 65

10.1 Dialog: Auswahl der Datenbank-Adapterklasse . . . . . . . . . 68

10.2 Dialog: Pflege der Verbindungsdaten . . . . . . . . . . . . . . . 69

10.3 Dialog: Auswahl der Metadaten . . . . . . . . . . . . . . . . . . 70

C.1 Verzeichnisstruktur von Generic Web Services . . . . . . . . . 84

88

Tabellenverzeichnis

2.1 Beispiele fur SOA Formate und Protokolle . . . . . . . . . . . . 14

4.1 Beispiele fur SAP Business-Komponenten und ihre Objekte . . 27

5.1 Mapping von ABAP Datentypen und Java Datentypen . . . . . 48

5.2 Java Datentypen und JCo Zugriffsmethoden . . . . . . . . . . . 48

6.1 Mapping von JDBC Datentypen und Java Datentypen . . . . . 55

A.1 Mapping von ABAP Dictionary Datentypen und ABAP Daten-

typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

89

Literaturverzeichnis

[1] CHAPPELL, David A.; Jewell, Tyler: Java Web Services. O’Reilly, 2002.

[2] GISOLFI, Dan: Web services architect, Part 3: Is Web services the rein-

carnation of CORBA? developerWorks, IBMs resource for developers,

2001.

URL: http://www-106.ibm.com/developerworks/webservices/library/ws-

arc3/ [Abruf: 21.09.2004]

[3] IRANI, Romin; BASHA, S. Jeelani: AXIS – Next Generation Java SOAP.

Wrox Press, Mai 2002.

[4] KEMPER, A.; EICKLER, A.: Datenbanksysteme – Eine Einfuhrung. R.

Oldenbourg Verlag, 2. Auflage, 1997.

[5] Microsoft Corporation: COM: Component Object Model Technologies.

URL: http://www.microsoft.com/com/tech/DCOM.asp [Abruf:

29.10.2004]

[6] Object Management Group (OMG): CORBA.

URL: http://www.corba.org [Abruf: 21.09.2004]

[7] Open Applications Group (OAG): SAP AG and Open Applications Group

Announce BAPI Compliance with Open Applications Group Specificati-

ons. 1997.

URL: http://www.openapplications.org/news/pr-info/970825.htm [Ab-

ruf: 28.11.2004]

[8] SAP AG: SAP Help Portal.

URL: http://help.sap.com [Abruf: 16.11.2004]

[9] SCHUESSLER, Thomas G.: Developing Applications with the”SAP Java

Connector (JCo)“. Version 0.8.1. ARAsoft GmbH, 2002.

[10] SCHUESSLER, Thomas G.: Tips and Tricks for SAP Java Connector

(JCo) Client Programming. In: SAP Professional Journal. Ausgabe Janu-

ar/Februar 2004.

90

Literaturverzeichnis

[11] Sun Microsystems, Inc: JDBC Technology.

URL: http://java.sun.com/products/jdbc [Abruf: 28.11.2004]

[12] Systinet Corporation: Introduction to Web Services Architecture. 2002.

[13] TANENBAUM, A. S.; VAN STEEN, M.: Distributed Systems. Prentice

Hall, 2002.

[14] UDDI.org: UDDI.

URL: http://www.uddi.org

[15] World Wide Web Consortium (W3C): HTTP – Hypertext Transfer Pro-

tocol

URL: http://www.w3c.org/Protocols/ [Abruf: 21.09.2004]

[16] World Wide Web Consortium (W3C): Simple Object Access Protocol

(SOAP) 1.1. W3C Note 08 May 2000.

URL: http://www.w3c.org/TR/2000/NOTE-SOAP-20000508/ [Abruf:

21.09.2004]

[17] World Wide Web Consortium (W3C): Extensible Markup Language

(XML).

URL: http://www.w3c.org/XML/ [Abruf: 21.09.2004]

[18] World Wide Web Consortium (W3C): XML Schema.

URL: http://www.w3.org/XML/Schema [Abruf: 21.09.2004]

[19] World Wide Web Consortium (W3C): Web Service Architecture Require-

ments. W3C Working Draft 29 April 2002.

URL: http://www.w3.org/TR/2002/WD-wsa-reqs-20020429 [Abruf:

27.09.2004]

[20] World Wide Web Consortium (W3C): Web Services Description Language

(WSDL) 1.1. W3C Note 15 March 2001.

URL: http://www.w3.org/TR/wsdl [Abruf: 27.09.2004]

[21] Winer, Dave: XML-RPC Specification. Juni 1999.

URL: http://www.xmlrpc.com/spec [Abruf: 01.10.2004]

[22] WEIKUM, G.: Datenbanksysteme. Universitat des Saarlandes, 1998. –

Skript zur Vorlesung.

[23] WUTKA, Mark: J2EE Developer’s Guide. Markt+Technik Verlag, 2002.

91