Enterprise SOA und SAP NetWeaver BPM - · PDF fileI Zusammenfassung Diese Arbeit...

SOA und SAP Netweaver BPM

Autoren: Florian Kalisch

Frank Weisser

Vorlesung: Business Software Engineering

Wintersemester 2010/2011

vorgelegt am: 23. Januar 2011

I

Zusammenfassung

Diese Arbeit beschäftigt sich mit der Enterprise SOA von SAP und

dem SAP NetWeaver Business Process Management (BPM). Die Arbeit

vermittelt einen einfachen Einstieg in BPM und zeigt die Tools und

Möglichkeiten auf um Enterprise Services zu erstellen. Es soll aufgezeigt

werden, wie sich die Enterprise SOA von SAP gegenüber anderen Ansätzen

abgrenzt.

In einer praktischen Fallstudie, soll in der ersten Phase, die Arbeit mit

dem Process Composer (Tool im BPM) vermittelt werden. In der zweiten

Phase wird das Entwickeln und Deployment von Webservices aufgezeigt

und in der dritten Phase wird die zwei Phasen zusammengeführt.

Inhaltsverzeichnis II

Inhaltsverzeichnis

Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV

Abkuerzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV

1 Service Oriented Architecture (SOA) . . . . . . . . . . . . . . . . . . . . . . 1

1.1 SOA-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Abgrenzung zu bekannten Ansätzen . . . . . . . . . . . . . . . . . 3

2 Enterprise SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Enterprise SOA Architektur . . . . . . . . . . . . . . . . . . . . . 6

2.2 Enterprise SOA Lebenszyklus . . . . . . . . . . . . . . . . . . . . 8

3 Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 BPM Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Die möglichen Modellierungselemente des Process Composer . . . 12

4 Dokumentation der praktischen Fallstudie . . . . . . . . . . . . . . . . . . . 17

4.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 Phase 1 - Geschafätsprozessmodellierung . . . . . . . . . . . . . . 19

4.4.1 Vorbedingung . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5 Modellierung des Geschäftsprozesses . . . . . . . . . . . . . . . . 20

4.5.1 Kon�guration . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5.2 Anlegen des Mappings . . . . . . . . . . . . . . . . . . . . 24

4.5.3 Deployment und Test . . . . . . . . . . . . . . . . . . . . . 25

4.6 Phase 2 - Webserviceerstellung . . . . . . . . . . . . . . . . . . . . 27

4.7 Phase 3- - Integration der Webservices in den Geschäftsprozess . . 29

5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Abbildungsverzeichnis III

Abbildungsverzeichnis

Abbildung 1 Web-Services-Dreieck1 . . . . . . . . . . . . . . . . . . . . 3

Abbildung 2 EnterpriseSOA2 . . . . . . . . . . . . . . . . . . . . . . . 5

Abbildung 3 Entwicklung einer SOA Referenzarchitektur für SAP3 . . . 7

Abbildung 4 Enterprise Service Repository und Service Registry4 . . . 7

Abbildung 5 Enterprise SOA Lebenszyklus . . . . . . . . . . . . . . . . 8

Abbildung 6 Process Integration5 . . . . . . . . . . . . . . . . . . . . . 11

Abbildung 7 Phase 1 - Geschaftsprozess . . . . . . . . . . . . . . . . . 19

Abbildung 8 Phase 1 - SAP User Management Konsole . . . . . . . . . 20

Abbildung 9 Phase 1 - Element Kontextmenü . . . . . . . . . . . . . . 21

Abbildung 10 Phase 1 - Default Tasks . . . . . . . . . . . . . . . . . . . 21

Abbildung 11 Phase 1 - Wizard UI Creation . . . . . . . . . . . . . . . . 22

Abbildung 12 Phase 1 - SAP Java Application Server Verwaltung - Start-

seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Abbildung 13 Phase 1 - Browse Principals . . . . . . . . . . . . . . . . . 24

Abbildung 14 Phase 1 - Add new SAP System . . . . . . . . . . . . . . 24

Abbildung 15 Phase 1 - Mapping Process . . . . . . . . . . . . . . . . . 25

Abbildung 16 Phase 1 - Mapping Properties . . . . . . . . . . . . . . . . 25

Abbildung 17 Phase 1 - Deploy DCs . . . . . . . . . . . . . . . . . . . . 26

Abbildung 18 Phase 1 - Process-Repository - Liste der Komponenten . . 26

Abbildung 19 Phase 1 - Process-Repository - Komponentendetails . . . . 26

Abbildung 20 Phase 1 UserA Zentraler Arbeitsvorrat . . . . . . . . . . . 27

Abbildung 21 Phase 1 UserA Eingabe der Daten . . . . . . . . . . . . . 27

Abbildung 22 Phase 2 - Web Service Wizard . . . . . . . . . . . . . . . 29

Abbildung 23 Phase 2 - View Servers . . . . . . . . . . . . . . . . . . . . 29

Abbildung 24 Phase 3 - Web Service in Geschäftsprozess . . . . . . . . . 30

Abbildung 25 Phase 3 - Automated Activity Einstellungen . . . . . . . . 30

1Melzer.2Stollenwerk.3Baumgartl/Mebus/Seemann.4Baumgartl/Mebus/Seemann.5SAP SAP NetWeaver Business Process Management: Components & Tools of SAP Netweaver.

Abkuerzungsverzeichnis IV

Tabellenverzeichnis

Tabelle 1 Pool und Lane . . . . . . . . . . . . . . . . . . . . . . . . 13

Tabelle 2 Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Tabelle 3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Tabelle 4 Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Abkuerzungsverzeichnis

B2B . . . . . . . . . . . . Business to Business

BAM . . . . . . . . . . . Business Activity Monitoring

BPM . . . . . . . . . . . Business Process Management

CE . . . . . . . . . . . . . Composition Environment

CORBA . . . . . . . . Common Object Request Broker Architecture

DCOM . . . . . . . . . Distributed Component Object Model

EAR . . . . . . . . . . . Enterprise Archive

eSOA . . . . . . . . . . Enterprise Service Oriented Architecture

ESR . . . . . . . . . . . . Enterprise Service Repository

IDL . . . . . . . . . . . . Interface De�nition Language

IT . . . . . . . . . . . . . . Information Technology

PI . . . . . . . . . . . . . . Process Integration

SOA . . . . . . . . . . . Service Oriented Architecture

SOAP . . . . . . . . . . Simple Object Access Protocol

SR . . . . . . . . . . . . . Service Registry

UDDI . . . . . . . . . . Universal Description Discovery and Integration

WSDL . . . . . . . . . Web Services Description Language

XML . . . . . . . . . . . eXtensible Markup Language

1 Service Oriented Architecture (SOA) 1

1 Service Oriented Architecture (SOA)

Für Serviceorientierte Architekturen existiert im Moment keine einheitliche De�-

nition. Einige sind aus der geschäftsorientierten Sicht, andere aus der technischen

Sicht gewählt. Es gibt dabei zwar überschneidungen, allerdings sind nicht immer

alle wichtigen Aspekte enthalten. Folgende De�nitionen wurden ausgewählt um

einen Überblick zu geben:

� Melzer6:�Unter einer SOA versteht man eine Systemarchitektur, die viel-

fältige, verschiedene und eventuell inkompatible Methoden oder Applika-

tionen als wiederverwendbare und o�en zugreifbare Dienste repräsentiert

und dadurch eine plattform- und sprachenunabhängige Nutzung und Wie-

derverwendung ermöglicht.�

� IBM7: �Serviceorientierte Architektur ist ein geschäftsorientierter IT-

Architekturansatz , der die integration ihres Unternehmens als verknüpf-

te, wiederverwendbare Geschäftsanwendungen oder -services unterstützt.

Mit dem Smart SOA-Konzept können Sie eine serviceorientierte Architek-

tur auch in Ihrer Umgebung verwirklichen.�

� Microsoft8: Unternehmen brauchen e�ziente IT-Systeme, um ihre Ge-

schäftsprozesse zu verbessern und wettbewerbsfähig zu bleiben. Viele Pro-

jekte und Anwendungen erfordern die Nutzung von Geschäftslogik über

mehrere Kanäle und Nutzergruppen hinweg. Hier kommt die dienst-

orientierte IT-Architektur (Service-Oriented Architecture) ins Spiel.

SOA beschreibt eine Software-Infrastruktur, in der die wesentlichen Funk-

tionen einer Anwendung bzw. Softwaremodule als Service organisiert sind.

Services können beliebig verteilt sein und lassen sich dynamisch zu Ge-

schäftsprozessen verbinden. SOA legt hierbei die Schnittstellen fest, über

die andere Systeme via Netzwerk diese Dienste nutzen können. Services tau-

schen dadurch unabhängig von den zugrunde liegenden technischen Platt-

formen Daten aus. Zwingende Abhängigkeiten der monolithischen Architek-

turen und zwischen bestimmten Client-/Server-Architekturen sind damit

aufgelöst.

In einer SOA gibt es drei verschiedene Rollen: Anbieter, Nutzer, Vermittler. Die

Anbieter verö�entlichen Ihre Dienste in einem Verzeichnis. Die Nutzer können

in dem Verzeichnis nach Diensten suchen und bekommen einen Verweis auf den6Melzer.7IBM.8Microsoft.


ausgewählten Dienst. Mit der Beschreibung aus diesem Verweis können Sie beim

Diensteanbieter anfragen und den Dienst anschlieÿend nutzen.

1.1 SOA-Ansatz

Eine Serviceorientierte Architektur besteht aus folgenden Basiskomponenten:

� SOAP (Simple Object Access Protocol): Netzwerkprotokoll für XML-

basierte Nachrichten, das unabhängig von Programmiersprachen und Be-

triebssystemen ist. Dieses standardisierte Nachrichtenprotokoll ermöglicht

die Kommunikation zwischen verteilten Anwendungen.

� WSDL (Web Services Description Language): Eine Beschreibungssprache

für Webservices auf Basis von XML. De�niert die Schnittstellen der Webser-

vices (Service, Endpoint und Binding), d.h. WSDL legt fest um was für

einen Service es sich handelt, wo der Service aufgefunden und wie dieser

erreicht werden kann.

� UDDI (Universal Description Discovery and Integration): Standar-

disierter Verzeichnisdienst für Webservices. Metadaten des Webser-

vices(Informationen zum Au�nden der Services, Eigenschaften des Webser-

vice und allgemeine Anforderungen) werden gespeichert und können abge-

rufen werden. Ein Nutzer kann somit nach einem registrierten Webservice

suchen.

Die folgende Gra�k 1 auf der nächsten Seite gibt einen Überblick über die Kom-

ponenten von SOA. Die Aktionen werden in folgender Reihenfolge durchgeführt:

1. Verö�entlichen der WSDL für den Webservice im Verzeichnisdienst.

2. Dienstnutzer sucht Dienst über SOAP-Anfrage an UDDI.

3. Diensteverzeichnis gibt WSDL an Dienstnutzer, welche auf den Dienst ver-

weist.

4. Diensnutzer frägt mit Hilfe der Beschreibung den gesuchten Dienst an beim

Dienstanbieter.

5. Dienst kann nun vom Dienstnutzer benutzt werden.

9Melzer2007


Abbildung 1: Web-Services-Dreieck9

1.2 Abgrenzung zu bekannten Ansätzen

Der SOA-Ansatz ist nicht gerade neu, die Vorgänger sind z.B. DCOM (Dis-

tributed Component Object Model) oder auch CORBA (Common Object

Request Broker Architecture). SOA ist lediglich eine Weiterentwicklung aus

diesen Technologien, die sich auf Dauer nicht durchsetzen konnten. CORBA

war zu komplex, das führte dazu, dass viele Hersteller ihre eigenen Varianten

von CORBA erstellten. DCOM konnte sich nicht durchsetzen, da es nicht

plattformunabhängig ist. Mit Hilfe neuer Internetstandards können heutige

Webservices Applikationen einfach integrieren, was vorher nicht möglich war.

Heute verwenden serviceorientierte Architekturen meist Webservices, dennoch

ist �SOA != Webservices�. Serviceorientierte Architekturen lassen sich nämlich

auch mit CORBA oder Enterprise Java Beans implementieren.

Der Vorteil der Webservices besteht darin, dass sie unabhängig von den Program-

miersprachen sind. Die Technologie CORBA ist zwar ebenfalls unabhängig von


der Programmiersprache, setzt aber dabei fuer die Kommunikation auf die Inter-

face De�nition Language (IDL). Die Webservices bauen dagegen auf SOAP (Sim-

ple Object Access Protocol) mit XML. Durch die schnelle Verbreitung von XML

und die mangelnde Akzeptanz für CORBA haben sich schlieÿlich die Webservices

durchsetzen können.

Die Serviceorientierte Architektur erfüllt heute alle Anforderungen in Integration,

Optimierung und Unabhängigkeit, durch zunehmende Vernetzung innerhalb der

Unternehmen, Prozessorientierung (�exible Services) und Wiederverwendung von

Standards.10

10Catterfeld/Zimpel.

2 Enterprise SOA 5

Abbildung 2: EnterpriseSOA12

2 Enterprise SOA

Die Enterprise SOA wird mit Hilfe von Services aufgebaut. Die Services haben

folgende Eigenschaften11 :

� wiederverwendbar

� standardisiert

� ermöglichen Interaktion über standardisierte Infrastruktur

� gesammelt aus einem Services Repository aufrufbar

� erweiterbar

� kombinierbar

Die Abbildung 2 zeigt den Vergleich zwischen einer reinen SOA mit Webser-

vices und einer EnterpriseSOA. Die eSOA bringt die Geschäftsprozesse mit ein

in die Services. Dadurch gewährleistet SAP, dass die langjährige Erfahrung die

im Business Bereich besteht mit in die neue Infrastruktur ein�ieÿen kann. Durch

ein einheitliches Repository sind alle Services zentral gelagert und können einfach

aufgerufen werden. Die Wiederverwendbarkeit der einzelnen Komponenten eines

Systems (hier Services) ist ein wichtiger Faktor beim Einsatz von SOA. Dadurch

11Baumgartl/Mebus/Seemann.12Stollenwerk.2008

2 Enterprise SOA 6

wird das ganze System qualitativ verbessert, das System wird leichter wartbar

und erweiterbar.

2.1 Enterprise SOA Architektur

Die Enterprise SOA von SAP baut auf den Strukturen des SOA-Ansatzes auf,

siehe Unterkapitel 1.1 auf Seite 2. Baumgartl et al.13 stellen fest, dass SAP selbst

keine eigene De�nition für SOA liefert. Die Autoren geben aber eine Referenzar-

chitektur für SOA vor, die in Abbildung 3 auf der nächsten Seite dargestellt wird.

Die Architektur besteht aus den vier wesentlichen Teilen: Anwendungsfrontend,

Service, Services Repository und Service Bus:

� Anwendungsfrontend: Regelt die Datenausgabe und die Steuerung der

Geschäftsprozesse. Es stellt in der Regel die oberste Schicht in der service-

orientierten Schicht dar.

� Service: Der Service bildet die eigentliche Geschäftsfunktionalität ab.

Ein Service enthält einen Servicevertrag (Contract), welcher mittels einer

Schnittstellende�nition in WSDL beschrieben wird. Des weiteren besteht

ein Service aus der Implementierung, welche wiederum Geschäftslogik und

Daten beinhaltet. In SAP wird die Serviceschnittstelle im Enterprise Service

Repository (ESR) und in der Services Registry modelliert und beschrieben.

� Services Repository: Hier werden alle Informationen bereitgestellt die

für den Aufruf des Webservices wichtig sind. Das Services Repository stellt

die zentrale Informationsquelle für das Anwendungsfrontend dar (Anwen-

deraufrufe).

� Service Bus: Der Services Bus verbindet die Services mit den umliegenden

Applikationen und Frontends. In SAP nimmt diese Position die NetWeaver

Process Integration (PI) ein.

Die Abbildung 4 auf der nächsten Seite zeigt das Zusammenspiel des Enterprise

Services Repository und der Service Registry mit den anderen Komponenten in

einem SAP-System. Der Provider publiziert einen neuen Service mit Hilfe der SR,

welche auf das ESR referenziert in welchem die WSDL liegt. Der Consumer ruft

über die PI den Service auf oder mit direkter Verbindung (durch WSDL) an den

Serviceendpunkt.

13Baumgartl/Mebus/Seemann.14Baumgart1.201015Baumgart1.2010

2 Enterprise SOA 7

Abbildung 3: Entwicklung einer SOA Referenzarchitektur für SAP14

Abbildung 4: Enterprise Service Repository und Service Registry15

2 Enterprise SOA 8

Abbildung 5: Enterprise SOA Lebenszyklus

2.2 Enterprise SOA Lebenszyklus

Die Abbildung 5 zeigt den Lebenszyklus der Entwicklung einer SOA:

1. Oben im Bild startet der Zyklus mit der De�nition der Geschäftsanforde-

rungen.

2. Die Services werden nach den gegebenen Anforderungen modelliert.

3. De�nition der Services.

4. Implementation und Entwicklung der Services.

5. Beschreibung und Ermittlung der Services für die ermittelten Anforderun-

gen.

6. Services werden konsumiert.

Sollten neue Geschäftsanforderungen kommen, so muss geschaut werden inwiefern

die vorhandenen Services diese umsetzen können. Falls einige Anforderungen nicht

erfüllt werden, sollte der oder die neuen Geschäftsprozesse so modelliert werden,

dass sie leicht zu integrieren und wiederverwendbar sind.

3 Business Process Management 9

3 Business Process Management

Das SAP NetWeaver Business Process Management (SAP NetWeaver BPM)

Komponente ist in die Composition Environment (CE) eingebettet und hilft die

Geschäftsprozesse, welche auf allgemeinen Modellen basieren, zu dokumentieren,

modellieren, auszuführen und zu überwachen (auswerten, gegensteuern). Vor al-

lem die E�zienz der Geschäftsprozesse kann damit verbessert werden, sowie Feh-

lerreduzierung in sich wiederholenden komplexen Aufgaben und wengier Kosten

für das �Exception-Handling�.16

3.1 BPM Tools

Folgenden Tools werden von SAP NetWeaver BPM angeboten17:

� Process Composer: Ermöglicht den Architekten und Entwicklern der Pro-

zesse, Geschäftsprozessmodelle zu entwerfen. Jedes Modell de�niert klare

Regeln und Ausnahmen für Mitarbeiter oder Anwendungen durchgeführten

Prozessschritte. Einen Überblick der Möglichkeiten im Process Composer

erhalten Sie im Unterkapitel 3.2 auf Seite 12.

� Process Server: Prozessmodelle können ohne Übersetzungen zwischen

Modell und Quellcode ausgeführt werden und ist dabei voll in SAP Net-

Weaver Composition Environment integrierbar.

� Process Desk: Erlaubt es den Anwendern während der Laufzeit auf

Geschäftsprozesse zuzugreifen.Die Anwender können kontextabhängig ihre

Aufgaben überblicken.

Da der Business Process Manager auch mit anderen Komponenten von SAP Net-

Weaver zusammenarbeitet, stellen diese zusammen eine mächtige und verein-

heitlichte Entwicklungs- und Deploymentumgebung dar. Im einzelnen sind diese

Komponenten18:

� SAP NetWeaver Composition Environment: Liefert einen Eclipse-basierte

Umgebung für die Gestaltung/Komposition der Geschäftsprozesse, einen

Java-EE Application Server der die Prozesse anbietet, ein Enterprise Service

Repository für die Suche und Registrierung von Diensten und zusätzliche

Funktionalitäten für das Software Liefecycle Management.

16SAP Komponenten & Werkzeuge von SAP NetWeaver: SAP NetWeaver Portal.17SAP Komponenten & Werkzeuge von SAP NetWeaver: SAP NetWeaver Portal.18SAP SAP NetWeaver Business Process Management: Components & Tools of SAP Netweaver.


� SAP Netweaver Business Rules Management: Liefert die Komponenten für

alle Phasen im Lebenszyklus der Geschäftsregeln, d.h. Optimierung der

Entwurfsphase, Ausführungsphase, Modi�kation und Optimierung der Ge-

schäftsregeln. Das Business Rules Management bringt verschiedene Werk-

zeuge mit:

� Rules Composer: Ermöglicht es Geschäftsregeln zu entwerfen und mo-

di�zieren, mit Hilfe von gebräuchlichen representativen Formaten, wie

z.B. Entscheidungstabellen.

� Rules Analyzer: Benutzer können damit die bestehenden Geschäftsre-

geln testen, verbessern, optimieren und analysieren.

� Rules Manager: Damit lassen sich die Geschäftsregeln auch in einem

gemeinschaftlichen webbasierten Arbeitsumfeld verwalten und bear-

beiten.

� Rules Repository: Ermöglicht die Versionierung der Regeln, sowie die

Verwaltung und Kontrolle der Berechtigungen, Alarmsignale und wei-

tere Repository Dienste.

� Rules Engine: Integriert die Geschäftsregeln in die Laufzeitumgebung

der SAP NetWeaver Composition Environment.

� Process Integration (PI): Die Prozessintegration arbeitet mit o�enen Stan-

dards und führt zu einer prozessorientierten Zusammenarbeit der Kompo-

nenten von SAP aber auch von Fremdanbietern, siehe Abbildung 6 auf

der nächsten Seite. Die Geschäftsprozesse können somit vom Design, über

die Entwicklung und Inbetriebnahme, bis hin zur Modi�kation vollstän-

dig verwaltet werden. Die Prozessintegration beinhaltet dafür selbst einige

Komponenten:

� Enterprise Services Repository: Zentrale Komponente für die De�ni-

tion, Aufrufen und Verwaltung von Diensten und anderen Geschäfts-

objekten. Enthalten sind die De�nitionen und Metadaten der Dienste

und Prozesse, gleichzeitig beinhaltet es eine zentrale Modellierungs-

und Designumgebung zum Anlegen und Verwenden von Diensten.

� Enterprise Service Bus: Weitere Zentrale Komponente für die Inte-

gration zwischen Anwendungen. Diese Komponente ermöglicht eine

sichere, standardadisierte, zuverlässige und skalierbare Kommunikati-

on zwischen den Anwendungen, der Anbieter und Nutzer, über die

gesamte Systemlandschaft hinweg.


Abbildung 6: Process Integration19

� BAM (Business Activity Monitoring): Ermöglicht das Prozessmonito-

ring20.

� SAP NetWeaver Portal21: Die wichtigsten Informationen und Anwendun-

gen können in ein Unternehmensportal integriert werden. Das Portal hat

folgende Eigenschaften und Funktionen:

� Portalinfrastrukturmanagement: Bietet eine personalisiert und sichere

Anwenderober�äche, die Unternehmensanwendungen, Informationen

und Prozesse auf Basis von SAP-Anwendungen übersichtlich zusam-

menführt.

20SAP SAP EM as compared to BPM,BAM and CEP.21SAP SOA-Middleware.


� Zusammenarbeit: Anwendungen können mit Hilfe des Portals gemein-

sam genutzt werden. Verschiedene Tools wie virtuelle Arbeitsräume

oder Diskussionsforen ermöglichen eine e�ziente Zusammenarbeit, au-

ÿerdem können externe Tools wie Instant-Messaging, Webkonferenzen

oder Groupware integriert werden.

� Knowledge-Management: Das Portal beinhaltet auch Wissensmanage-

ment, Dienste die den Anwendern die Suche nach Informationen er-

leichtern, sowie deren Organisation.

� SAP NetWeaver Identity-Management: Ermöglicht die zentrale Verwal-

tung von Benutzerpro�len und Zugri�sberechtigungen. Das Identity-

Management arbeitet Rollenbezogen, so kann eindeutig zugewiesen werden

auf welche Systeme ein Benutzer zugreifen kann.

3.2 Die möglichen Modellierungselemente des Process

Composer

Im Folgenden werden nun die wichtigsten Symbole vorgestellt in den Tabellen 1

auf der nächsten Seite, 2 auf Seite 14, 3 auf Seite 15 und 4 auf Seite 16. Diese

Beschreibung ist angelehnt an die SAP Dokumentation,�Using BPMN Process

Models�22.

22AG.


Pool und Lane

Ein Pool steht für eine gra�sche Separierung mehrerTeilnehmer an einem Prozess. Das kann eine spezielleBusiness Entität sein, wie zum Beispiel eine Firma. Eskann auch eine speziellere Business-Rolle sein, wie Her-steller, Käufer oder Verkäufer. Beim Anlegen eines neu-en Prozesses wird automatisch ein Default-Pool mit an-gelegt, da mindestens ein Pool vorhanden sein muss. EinPool stellt einen Container für einen Sequence-Flow zwi-schen mehreren Activities dar. Die Interaktion zwischenmehreren Pools, welche beispielsweise im B2B-Kontextauftreten kann, wird mittels Messages abgewickelt.EineLane stellt eine Sub-Partition innerhalb eines Prozes-ses dar. Ein Pool hat seinerseits wieder mindestens eineLane. Sie werden dazu benutzt, die Activities innerhalbeines Pools zu organisieren. Lanes repräsentieren interneRollen wie Angestellter oder Manager.Events

Ein Event beein�usst den Fluss innerhalb eines Prozes-ses und hat einen Grund oder Ziel. Folgende Events sindmöglich:

� Start-Event: Diese de�nieren, an welcher Stelle einProzess beginnt. Jeder Prozess muss ein Start-Event besitzen.

� Intermediate-Event: Events dieser Art treten zwi-schen dem Start und dem Ende eines Prozesses aufund beein�ussen den Fluss des Prozesses. Sie kön-nen dazu benutzt werden, auf bestimmte Eventszu warten oder den Prozess für eine gewisse Zeitanzuhalten.

� End Event: Diese de�nieren, an welchem Punktein Prozess endet. Sie können ein spezi�sches Re-sultat besitzen, wie zum Beispiel das Senden einerNachricht.

Tabelle 1: Pool und Lane


Activity

Eine Activity steht für eine durchzuführende Arbeit in-nerhalb eine Business Prozesses:

� Abstract Activity: Diese Activities haben keinenspeziellen Typ und können dafür benutzt werden,wenn zum Beispiel ein Entwurf eines Prozessesangefertigt wird. Eine Konvertierung in eine dernachfolgenden Aktivitäten ist möglich.

� Human Activity: Diese Art von Aktivitäten wer-den durch einen Benutzer des Systems durchge-führt. Dazu muss dem Element eine Task zugeord-net werden. Sobald der Prozess�uss eine Activitydiesen Typs erreicht, erscheint der auszuführendeTask in der Universal Worklist. Die Kon�gurationeines Input- und Outputmappings ist nötig.

� Automated Activity: Eine automatisierte Activitywird durch ein System durchgeführt. Dazu musseine Service-Interface-De�nition und eine Opera-tion der Activity zugewiesen werden.

� Referenced Sub Process: Ein referenzierter Sub-prozess ist eine gra�sche Repräsentation eines ei-genständigen Prozesses. Die Kommunikation zwi-schen diesem und der Aktivität funktioniert überInput- und Outputmapping.

� Embedded Sub Process: Ein eingebetteter Subpro-zess ist de�niert durch einen Fluss aus mehrerenAktivitäten.

� Mapping Activity: Eine Mapping Activity kannbenutzt werden, um komplexe Data Objects in ein-fachere zu transformieren.

� Reporting Activity: Reporting Activities könnendazu benutzt werden, Daten aus dem Prozesskon-text zu sammeln und darauf analytische Auswer-tungen durchzuführen.

� Noti�cation: Noti�cations werden dazu benutztEmail-Nachrichten aus dem Prozess heraus zu sen-den.

Tabelle 2: Activity


Gateways

Gateways dienen dem Aufteilen und Zusammenführendes Prozess�usses innerhalb eines Prozesses. FolgendeTypen sind möglich:

� Abstract Gateways: Diese abstrakten Gatewayshaben keinen speziellen Typ und dienen dazu, eineAufsplittung oder ein Zusammenführen innerhalbeines Prozessentwurfs zu demonstrieren. Eine spä-tere Typisierung in einen der nachfolgenden Typenist möglich

� Exclusive Choice: Hierbei wird eine exklusive Aus-wahl innerhalb des Prozess�usses getro�en. Hintereinem exklusiven Gateway steht eine Bedingung,zu derer es Auswahlmöglichkeiten, die sogenann-ten Gates, gibt. Die Auswahl wird aufgrund derProzessdaten gewählt.

� Event Based Choice: Die Entscheidung, an wel-chem Gate der Prozess�uss fortgeführt werdenmuss, wird anhand von auftretenden Events ent-schieden.

� Parallel Split: Dieses Gateway wird dazu benutzt,eine Parallelisierung in den Prozess�uss zu inte-grieren. Diese explizite De�nition ist nicht nötig,da von einer Activity auch mehrere Prozess�üs-se abgehen können, jedoch führt die Darstellungdurch ein paralleles Gateway zu einer Erhöhungder Übersichtlichkeit.

� Uncontrolled Merge: Vereint alternative Prozess-�üsse.

� Parallel Join: Mit dem parrallelen Join Gatewaykönnen parallele Pfade vereint werden. Dieses Ga-teway sollte jedoch immer mit einem Parralel JoinGateway benutzt werden.

Tabelle 3: Gateways


Artefakte

Artefakte werden dazu benutzt, zusätzliche Informatio-nen über den Prozess bereitzustellen. Dazu können siemit anderen Elementen über Assoziationspfeile verbun-den werden. Zwei verschiedene Typen sind möglich:

� Data Objects: Data Objects dienen dazu typisierteDaten Prozessweit zu speichern. Diese Zwischen-speicherung kann beispielsweise dazu benutzt wer-den, um durch Benutzer eingegebenene Daten fürspätere Weiterverwendung im Prozess zwischenzu-speichern.

� Annotation: Annotations stellen weitergehendetextuelle Informationen zu dem Prozess und imSpeziellen zu anderen gra�schen Elementen bereit.

Tabelle 4: Artefakte

4 Dokumentation der praktischen Fallstudie 17

4 Dokumentation der praktischen Fallstudie

Um die in den vorherigen Kapiteln theoretisch betrachteten Themenkomplexe der

Enterprise SOA sowie des Business Process Modeling von einem anschaulichen

Standpunkt aus zu betrachten, wurde eine praktische Fallstudie durchgeführt.

Dieses Kapitel zeigt einerseits die Anforderungen an diese Fallstudie auf, gibt

einen Überblick über die zugrunde liegende Vorgehensweise und dokumentiert

die erzielten Ergebnisse.

4.1 Vorgehensweise

Zu Beginn der Fallstudie wurden die Anforderungen an das Projekt festgehalten.

Dadurch wurde festgelegt, welche Ziele erreicht werden müssen, sowie auf welchem

Weg dies zu geschehen hat. Diese sind nachzulesen im Abschnitt Anforderungen.

Vor dem praktischen Umsetzen der Anforderungen stand die Installation eines

lau�ähigen SAP Systems. Dies wird dargestellt unter dem Punkt Installation. Die

Realisierung der Geschäftsprozessmodellierung sowie die Erstellung des dazuge-

hörigen Webservices ist in den darau�olgenden zwei Unterkapiteln eingegliedert.

Da während der gesamten praktischen Phase Probleme auftraten, werden diese

unter dem Punkt Probleme aufgezeigt. Am Ende dieses Kapitels steht ein Fa-

zit welches die Anforderungen und die Zielde�nitionen gegenüberstellt sowie die

Fallstudie abschlieÿend betrachtet.

4.2 Anforderungen

Als Intention dieser praktischen Fallstudie steht im Vordergrund, einen Einblick

in die Modellierung von Geschäftsprozessen mittels der BPMN und dem Net-

weaver Developer Studio zu vermitteln. Aufgrund der hohen Systemkomplexität

des SAP Netweaver Composition Environment und der Tatsache, dass den

Lesern dieser Arbeit ein einfacher Zugang zur Business Process Modellierung

mittels SAP Netweaver BPM ermöglicht werden soll, kann das Ziel der Arbeit

keine detailgetreue Modellierung eines realen Geschäftsprozesses sein. Als

anschauliches Ziel für das Fallbeispiel ist sowohl ein Geschäftsprozess mittels

BPMN im Netweaver Developer Studio zu realisieren, als auch die Umsetzung

und Bereitstellung eines Webservices anhand einer prototypischen Implemen-

tierung. Zusätzlich ist der Webservice in den Geschäftsprozess einzubinden. Als

zugrunde liegenden Vorgehensprozess wird ein inkrementeller gewählt, da zum

Zeitpunkt des Beginns der Praxisphase noch kein Anwendungswissen in Bezug

auf die SAP Plattform existiert und somit die Gesamtkomplexität nach dem


Divide-And-Conquer herunter gebrochen werden kann. Die Realisierung erfolgt

in drei Phasen, welche folgende funktionale Anforderungen beinhalten:

1. Phase Dieser Teilschritt deckt die Modellierung eines einfachen Ge-

schäftsprozesses ab, welcher zwei menschliche Benutzer umfasst und de-

ren Daten�uss in der Weitergabe einer von Benutzer 1 getätigten Eingabe

an Benutzer 2 zur Darstellung besteht. Damit ist eine beispielhafte Ge-

schäftsprozessmodellierung aufgezeigt.

2. Phase Diese Phase deckt das Entwickeln eines Webservice und dessen er-

folgreiches Deployment an den SAP Application Server ab. Zu Demonstra-

tionszwecken soll dieser Service lediglich zwei Zahleneingaben erhalten und

deren Summe berechnen.

3. Phase Nachdem die Grundlagen in den Phasen Eins und Zwei dem Leser

nahe gebracht wurden, gilt es in der letzten Phase die beiden Vorherigen

zu vereinen. Dazu wird als zusätzlicher Akteur im Geschäftsprozess der

Webservice eingeführt. Der bestehende Prozess muss dahingehend abgeän-

dert werden, dass Benutzer 1 zwei Zahleneingaben vornimmt, welche an

den Webservice weitergeleitet werden. Die berechnete Summe der Zahlen

soll dann Benutzer 2 angezeigt werden.

Wie bereits erwähnt, werden lediglich prototypische Implementierungen

vorgenommen, sodass für unseren Anwendungsfall nichtfunktionale Anfor-

derungen zu vernachlässigen sind.

4.3 Installation

Aus den de�nierten Anforderungen ergibt sich, dass die zu installierende SAP Net-

weaver CE Version die Modellierung von Geschäftsprozessen unterstützen muss.

Dazu kommt die Version SAP NetWeaver CE 7.2 Trial zum Einsatz. Um die In-

stallation erfolgreich durchführen zu können, müssen folgende Punkte beachtet

werden:

1. Generelles Problem mit 64 bit Betriebssystemen

2. Die spezi�zierten Betriebssystemanforderungen müssen eingehalten werden

3. Microsoft Windows XP Professional SP 2 (or higher)

4. Microsoft Windows Vista 32 bit

5. Microsoft Windows Server 2008 32bit


6. Empfohlen wird eine englische Windows Version

7. Ein Deaktivieren bzw. Deinstallieren von Avira AntiVir ist erforderlich

8. Mindestens 3 GB Arbeitsspeicher ist zwingend notwendig, damit alle Pro-

zesse des Netweaver Applicationservers nach durchgeführter Installation

starten

In dieser Version kommt als Betriebssystem ein englisches Windows Vista 32 bit

zum Einsatz, welches innerhalb einer virtuellen Maschine mit 4 GB Hauptspeicher

betrieben wird.

4.4 Phase 1 - Geschafätsprozessmodellierung

Die Anforderungen führen bereits eine Einteilung in Phasen ein. Dieses Kapitel

beschreibt die Phase 1, welche an das Tutorial von23 angelehnt ist. Dafür ist der

oben de�nierte Geschäftsprozess umgesetzt, welcher fertig modelliert wie folgt

aussieht:

Abbildung 7: Phase 1 - Geschaftsprozess

4.4.1 Vorbedingung

Bevor mit der Modellierung des Geschäftsprozesses begonnen wird, sollte sicher-

gestellt werden, dass das SAP-System alle benötigten Instanzen und Prozesse

gestartet hat. Folgende Punkte sollten zuvor positiv bestätigt sein:

23Ste�en Ulmer.


Abbildung 8: Phase 1 - SAP User Management Konsole

1. Hochfahren der Datenbank MaxDB. Dieser Systemprozess muss manuell ge-

startet werden, da dies die Standardeinstellung bei den Windows-Diensten

ist.

2. Erfolgreicher Start des Prozesses jstart.exe, was an dem grünen Symbol

neben Frank5 0 erkannt werden kann. Steht zu wenig Arbeitsspeicher zur

Verfügung, kann dieser Prozess nicht komplett gestartet werden.

3. Auch die Systeminstanz Frank5 1 sollte, ebenfalls erkennbar an einem grü-

nen Symbol, erfolgreich hochgefahren worden sein.

4.5 Modellierung des Geschäftsprozesses

Da diese Modellierung an das Tutorial von Ulmer24 angelehnt ist, werden im

Folgenden nur die jeweils wichtigsten Schritte erläutert, sowie wichtige Hinweise,

welche nicht durch das Tutorial abgedeckt sind, beschrieben.

Der Wizard zur Anlage eines neuen Prozesses ermöglicht es bereits, einen Pool

standardmäÿig anzulegen, sowie diesem einen Namen zu geben und ihm Lanes

hinzuzufügen, was in unserem Fall dazu führt, dass der Pool MyNameAge sowie

die beiden Lanes, mit den Namen User_A und User_B angelegt werden, sowie

ein Start- und Endevent für den Prozess.

Die beiden Activities, sowie die beiden Data Objects können über die Palette des

Process Composer ausgewählt, im Prozess platziert sowie entsprechend benannt

24Ste�en Ulmer.


werden. Dadurch werden die jeweiligen abstrakten Typen hinzugefügt, welche

per Rechtsklick / Change Type in die konkreten Ausprägungen konvertiert

werden können. Alternativ kann ausgehend von jedem Element (ausgenommen

den Artifacts) ein nues Element erzeugt und automatisch mit dem vorherigen

Element verbunden werden. Das ist zu erreichen, indem der Mauszeiger über das

Element platziert wird. Ein Beispiel dazu sieht folgendermaÿen aus:

Abbildung 9: Phase 1 - Element Kontextmenü

In diesem Fall soll dem Start-Event eine neue Activity hinzugefügt werden, welche

vom Typ Human sein soll.

Als nächster Schritt müssen die automatisch zugewiesenen Default-Tasks zu den

Activities, welche unter den Eigenschaften zu �nden sind, entfernt werden.

Abbildung 10: Phase 1 - Default Tasks

Dazu ist in der Task Dropdown-Box <None> auszuwählen. Dies ist wichtig,

da jeder Human Activity später eine automatisch generierte Web Dynpro

Benutzerober�äche zugeweisen wird.

Anschlieÿend können den Data Objects in den Eigenschaften die Datentypen

zugewiesen werden. Das Datenobjekt Name muss vom Typ String sein und

Age ist vom Typ int. Nun folgt das Zuweisen der Tasks zu den Activities. Das

erreicht man durch Rechtsklick auf den Prozess. Ein Klick auf Apply Template


startet einen Wizard zur Erstellung, welcher nach erfolgreicher Ausführung im

Hintergrund das WebDynpro User-Interface erzeugt und den Aktivitäten die

zugehörigen Tasks zuweist. Zu beachten ist einerseits, dass bei der nachfolgenden

Stelle im Wizard

Abbildung 11: Phase 1 - Wizard UI Creation

sowohl für die Tasknamen Fill Name Age sowie Display Name Age beide Data

Objects (Age, Name) selektiert werden, da diese sich als Ein- bzw. Ausgabeele-

mente in der Userober�äche wieder�nden sollen.

Im Schritt Create User Interface Component for each Task besteht die Möglich-

keit, die UI-Technologie für das zu generierende User Interface auszuwählen. Die

Generierung startet nach der Eingabe der nötigen Projekt-Parameter für die zu

erzeugende Development Component, welche über eine Klick auf New erreicht

werden kann.

4.5.1 Kon�guration

In diesem Unterkapitel wird beschrieben, welche Kon�gurationen nötig sind,

damit der Geschäftsprozess, welcher die Interaktion zweier Benutzer erfordert,

ablau�ähig ist.

Der erste Bereich der Kon�gurationen wird auf dem SAP-System vorgenommen.

Da im Rahmen dieses Moduls an keinem vorkon�guriertem System gearbeitet

wird und somit auch noch keine Benutzer angelegt sind, muss dies durchge-

führt werden, da der Geschäftsprozess sowohl den SDN_User_A, als auch

SDN_User_B erfordert.


Dazu wird die Startseite25 des SAP NetWeaver Application Server Java über

folgendes URL-Muster

http://<ip>:<port>/startPage

aufgerufen, welches bei lokalem Zugri� wie folgt lauten muss:

http://localhost:50000/startPage .

Abbildung 12: Phase 1 - SAP Java Application Server Verwaltung -

Startseite

Der dortige Menüpunkt User Management führt nach zuvoriger Anmeldung

als Administrator zur Benutzerverwaltung. Dort sind zwei Benutzer (Log-On

ID: SDN_User_A, SDN_User_B) anzulegen mit identischem Log-On und

Last-Name. Beide User erhalten im Anschluss zwei Rollen mit der Beschreibung

BPEM End User und Every User Core Role. Der User Administrator muss noch

die Rolle SAP_BPM_SuperAdmin erhalten, da sonst sich später der Prozess

nicht starten lassen kann.

Die restlichen Kon�gurationen müssen im SAP NetWeaver Development Studio

durchgeführt werden.

Während die zwei Lanes User_A sowie User_B zwar angelegt wurden, so fehlt

dennoch eine Verknüpfung zwischen Lane und den Benutzern, welche im vorheri-

gen Schritt angelegt wurden. Diese Verbindung wird über die Eigenschaften der

einzelnen Lane bewerkstelligt. Der zugehörige Menüpunkt dafür lautet Potential

Owners und weiter Choose one or more UME principals. Nach Klicken auf den

Button Choose... wird folgender Dialog angezeigt.

Dabei ist zu berücksichtigen, dass keine Suche möglich ist, bevor nicht zuvor

Con�gure Server Default... aufgerufen und das aktuelle System dort angelegt

25Zentrale Seite zur Verwaltung des Application Servers


Abbildung 13: Phase 1 - Browse Principals

wurde. Am Beispiel des hier vorliegenden Testsystems lautet die Kon�guration:

Abbildung 14: Phase 1 - Add new SAP System

Die Instance Number bezeichnet die Instanznummer des SAP Java Application

Server.

Ein weiterer wichtiger Aspekt, ohne welchen der Ablauf später nicht gestartet

werden kann, ist die Zuweisung des Administrators zum Pool. Diese Festlegung

wird unter den Eigenschaften des Pools, unter Administrators (Choose one or

more UME principals) durchgeführt.

4.5.2 Anlegen des Mappings

Mit Mappings werden die Ein- und Ausgabedaten der verschiedenen Activities

spezi�ert. Bei einer Human Activity bezieht sich das Mapping auf die Daten,

welche diese Activity zur Verarbeitung bekommt, bzw. die Daten, welche durch

den Benutzer eingegeben wurden. Bei einer Automated Activity ist dies ähnlich.

Auch hier muss spezi�ziert werden, welche der Web Service verarbeiten soll,


sowie was mit den berechneten Daten geschehen soll. Nachfolgend wird anhand

von zwei Abbildungen ein Beispiel für ein solches Mapping gegeben:

Nach der Selektion der Activity Fill Name Age

Abbildung 15: Phase 1 - Mapping Process

und Navigation in das Output Mapping in den Eigenschaften, kommt folgende

Seite zum Vorschein:

Abbildung 16: Phase 1 - Mapping Properties

Ein Mapping zwischen den Attributen wird mittels Drag and Drop angelegt. Die

Attribute Age und Name der Aktivity Fill Name Age wurden mit den gleichna-

migen Data Objects des Prozesskontexts26 verbunden. Diese dienen als Zwischen-

speicher für die Usereingaben und müssen analog im Input Mapping der Activity

Display Name Age verbunden werden.

4.5.3 Deployment und Test

Dieses Kapitel behandelt schlussendlich das Deployen des Geschäftsprozesses und

den Test des Ablaufes. Vor dem Deployen sollte ein Build des Projektes durchge-

führt werden, was über Rechtsklick auf das Projekt im Project Explorer / Deve-

lopment Component / Build möglich ist. In jedem Fall muss im folgenden Dialog

das Projekt für den Geschäftsprozess als auch das automatisch angelegte Projekt

für das Userinterface (in diesem Fall trägt dies den Namen dc_wd_my_test)

ausgewählt werden.

26Der Prozesskontext stellt einen Bereich dar, auf den über mehrere Lanes hinweg zugegri�enwerden kann.


Abbildung 17: Phase 1 - Deploy DCs

Nach dem Build kann innerhalb des selben Menüs Deploy... aufgerufen werden,

wodurch der Prozess an den SAP Java Application Server übertragen wird. Für

das Testen muss der Geschäftsprozess gestartet werden. Dazu ist auf der Startseite

des SAP Java Application Servers [siehe Abbildung 12 auf Seite 23] der Menü-

punkt SAP NetWeaver Administrator aufzurufen und unter dem Reiter Kon�gu-

rationsmanagement / Prozesse und Aufgaben / Prozess-Repository gelangt man

zu den deployten Prozessen. Folgende zwei Abbildungen zeigen, was ausgewählt

werden muss, damit der richtige Prozess gestartet werden kann.

Abbildung 18: Phase 1 - Process-Repository - Liste der Komponenten

Abbildung 19: Phase 1 - Process-Repository - Komponentendetails

In der Abbildung 18 ist die deployte Development Component auszuwählen, was

in diesem Beispiel den Namen dc_my_test trägt. Im Anschluss ist noch der Name

des Geschäftsprozesses auszuwählen, was in Abbildung 19 dargestellt wird. Durch

Klick auf Prozess starten (ist dieser Button ausgegraut, dann fehlt dem aktuell

angemeldeten User, hier der Administrator, die entsprechende Rolle. Siehe dazu

das Kapitel 4.5.1 auf Seite 22) und im sich neu ö�nenden Fenster erneutem Klick


auf Prozess starten, wird der Prozess gestartet. Dies lässt sich für einen späteren

Produktiveinsatz auch mittels eines Webservices automatisieren.

Da der Prozess nun gestartet wurde, kann der Geschäftsprozess abgearbei-

tet werden. Dazu muss sich User_A einloggen. Dies kann er über die URL

http://localhost:50000/irj/portal tun. Abbildung 20 zeigt den Bildschirm nach

dem Login, in welchem die anstehenden Tasks zu sehen sind.

Abbildung 20: Phase 1 UserA Zentraler Arbeitsvorrat

Hier ist der Task Fill Name Age zu sehen, welcher durch den Start des Prozesses

erstellt wurde. User_A muss nun diesen Task abarbeiten. Dies kann er durch

Klick darauf tun. Folglich ö�net sich das User Interface für die nötige Eingabe,

was Abbildung 21 zeigt.

Abbildung 21: Phase 1 UserA Eingabe der Daten

Ein Klick auf Approve beendet den Task und der Prozess�uss geht weiter an

User_B. Dieser loggt sich ebenfalls ein und �ndet einen entsprechenden Task in

seinem Arbeitsvorrat. Ö�net er seinen Task, dann werden ihm die Eingaben von

User_A angezeigt.

4.6 Phase 2 - Webserviceerstellung

Während in Phase 1 ein einfacher Geschäftsprozess entwickelt wurde, so konzen-

triert sich Phase 2 auf die Erstellung eines Web-Services. Aus den Anforderungen

geht hervor, dass der Web Service zwei Zahlen entgegen nehmen soll, diese

Addieren und als Ergebnis die Summe zurückliefern. Als erster Schritt wird das

Interface de�niert und die dazugehörige Java-Klasse entwickelt.

Das Interface:

package com.study.bse;

public interface AddLocal {


public int addNow (int a, int b);

}

Die Implementierung:

package com.study.bse;

public class Add implements AddRemote, AddLocal {

// Implementation of the Web Service

public int addNow(final int a, final int b) {

return a+b;

}

// Default constructor.

public Add() {

}

}

Die Bereitstellung des Web Service kann über einen Wizard geschehen. Dabei

gibt es zwei verschiedene Möglichkeiten:

1. Bottom up Java bean Web Service

Ausgehend von einem bereits de�nierten Interface wird die zugehörige

WSDL generiert.

2. Top down Java bean Web Service

Ausgehend von einer WSDL wird das Java Interface automatisch erstellt.

Beide Möglichkeiten können über den Wizard (Abbildung 22 auf der nächsten

Seite) erstellt werden. Dazu ist ein Rechtsklick auf z.B. das Interface nötig und

in dem dann erscheinenden Kontextmenü unter Web Services muss Create Web

Service gewählt werden. Nach Auswahl der Service implementation (muss lauten

Package.InterfaceName) und Einstellen der Web service runtime auf SAP Net-

Weaver, sowie entsprechendes Einstellen der Regler. Das Beenden des Wizards

führt dazu, dass ein EAR Projekt angelegt wird. Dieses kann dann an den Server

deployed werden. Dazu muss über Window / Show View / Servers eine zusätz-

liche Sicht eingeblendet werden (Ergebnis siehe Abbildung 23 auf der nächsten

Seite) und durch Rechtsklick auf den Server / Add and Remove Projects... das

EAR Projekt hinzugefüht werden.

Wurde das Projekt erfolgreich deployed, so kann der Web Service unter dem

Menüpunkt Web Services Navigator auf der Startseite des SAP Java App-

lication Servers getestet werden. Durch Angabe der URL und der WSDL

(http://Frank5:50000/AddService/Add?wsdl), kann der Service getestet werden.


Abbildung 22: Phase 2 - Web Service Wizard

Abbildung 23: Phase 2 - View Servers

4.7 Phase 3- - Integration der Webservices in den

Geschäftsprozess

Diese Phase gibt einen kurzen Überblick über die Integration eines Web Service

in einen Geschäftsprozess. Aufbauend auf dem Wissen aus Phase 1, wurde der

Geschäftsprozess aus Abbildung 24 auf der nächsten Seite modelliert.

In der Activity Input Numbers werden zwei Zahlen von einem Benutzer eingege-

ben, welche dann in den Data Objects FirstNumber und SecondNumber zwischen-

gespeichert werden. Die automated Activity AddNumbers, welche den Webservice

darstellt, erhält als Input die FirstNumber und SecondNumber aus dem Prozess-

kontext und berechnet die Addition dieser, welche als Ergebnis zurückgeliefert

wird und in dem Data Object Calculated gespeichert wird. Die Activity Display

result zeigt beide Eingaben sowie das Ergebnis einem zweiten Benutzer an. Damit

der Web Service bekannt ist, muss zuerst die WSDL importiert werden, was über


Abbildung 24: Phase 3 - Web Service in Geschäftsprozess

Service Interface / Import WSDL... geschieht. Dort kann dann Remote Locati-

on / File System ausgewählt werden, wodurch die URL der WSDL angegeben

werden muss. Ein Klick auf Finish beendet den Importvorgang. Jetzt müssen die

Eigenschaften der automated Activity AddNumbers eingegeben werden, wie in

Abbildung 25 dargestellt.

Abbildung 25: Phase 3 - Automated Activity Einstellungen

5 Fazit 31

5 Fazit

Um mit SAP und dem Business Process Management zu arbeiten, muss man sich

erst einen Überblick verscha�en können, über die Tools und Zusammenhänge des

SAP NetWeaver BPM. Damit bekommt man auch gleichzeitig einen Einblick in

die Enterprise SOA von SAP. Wenn dies geglückt ist, kann mit einem kleinen

Beispielprojekt, wie man es in dieser Arbeit �ndet, fortgefahren werden. An die-

sem Punkt sieht man wie mächtig die Enterprise SOA von SAP ist und wieviele

Möglichkeiten in solch einer Architektur bestehen.

Beim Beispielprojekt dieser Arbeit konnte die Integration (Phase 3) nicht kom-

plett vollzogen werden (Annahme: Kon�gurationsfehler), dennoch können folgen-

de Lektionen in dieser Arbeit vermittelt werden:

� Überblick Enterprise SOA von SAP

� Tools von SAP Netweaver BPM

� Einstieg Webservices erstellen

� Einstieg Geschäftsprozesse modellieren mit Process Composer

Literaturverzeichnis 32

Literaturverzeichnis

AG, S. A.P: Using BPMN Process Models - SAP Documentati-

on. 23.11.2010 〈URL: http://help.sap.com/saphelp_nw72/helpdata/en/1e/b250a408ff44c28ea7f1a53b5e7791/content.htm〉 � Zugri� am 23.01.2011

Baumgartl, Axel/Mebus, Frank/Seemann, Volker: Das SOA-Praxisbuch

für SAP. 1. Auflage. Bonn: Galileo Press, 2010, ISBN 978�3�8362�1445�2

Catterfeld, Christopher/Zimpel, Helmut: SOA im Mittelstand. 〈URL:http://www.sage.de/upload/download/com/presse/SOA_im_Mittelstand_

Orientierung_f%C3%BCr_die_Praxis_aus_ERP-Management.pdf〉

IBM: IBM - SOA - Serviceorientierte Architektur von IBM. 〈URL:http://www-01.ibm.com/software/de/solutions/soa/?ca=ebf_de&me=

w&met=de_SW_LP〉

Melzer, Ingo: Service-orientierte Architekturen mit Web Services: Konzepte -

Standards - Praxis. 2. Auflage. Heidelberg: Spektrum Akad. Verl., 2007,

ISBN 978�3�8274�1885�2

Microsoft: SOA(Service Oriented Architecture). 〈URL: http://msdn.microsoft.com/de-de/library/bb979400.aspx〉

SAP: Komponenten & Werkzeuge von SAP NetWeaver: SAP NetWeaver Por-

tal. 〈URL: http://www.sap.com/germany/plattform/netweaver/components/netweaverportal/index.epx〉

SAP: SAP EM as compared to BPM,BAM and CEP. 〈URL: http://wiki.sdn.sap.com/wiki/display/SCM/SAP+EM+as+compared+to+BPM,+BAM+and+CEP〉

SAP: SAP NetWeaver Business Process Management: Components &

Tools of SAP Netweaver. 〈URL: http://www.sap.com/platform/netweaver/components/sapnetweaverbpm/index.epx〉 � Zugri� am 21.01.2011

SAP: SOA-Middleware. 〈URL: http://help.sap.com/saphelp_nwpi711/

helpdata/de/48/e73fdfe10d740ee10000000a421937/content.htm〉 � Zu-

gri� am 21.01.2011

Ste�en Ulmer: SAP NetWeaver BPM Tutorial for Beginners:

My Name and Age - BPM Tutorial. 16.08.2010 〈URL:http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/

library/uuid/307336b8-098c-2d10-be9c-d41ae345f0ff?QuickLink=

index&overridelayout=true〉 � Zugri� am 20.12.2010

http://help.sap.com/saphelp_nw72/helpdata/en/1e/b250a408ff44c28ea7f1a53b5e7791/content.htm

http://help.sap.com/saphelp_nw72/helpdata/en/1e/b250a408ff44c28ea7f1a53b5e7791/content.htm

http://www.sage.de/upload/download/com/presse/SOA_im_Mittelstand_Orientierung_f%C3%BCr_die_Praxis_aus_ERP-Management.pdf

http://www.sage.de/upload/download/com/presse/SOA_im_Mittelstand_Orientierung_f%C3%BCr_die_Praxis_aus_ERP-Management.pdf

http://www-01.ibm.com/software/de/solutions/soa/?ca=ebf_de&me=w&met=de_SW_LP

http://www-01.ibm.com/software/de/solutions/soa/?ca=ebf_de&me=w&met=de_SW_LP

http://msdn.microsoft.com/de-de/library/bb979400.aspx

http://msdn.microsoft.com/de-de/library/bb979400.aspx

http://www.sap.com/germany/plattform/netweaver/components/netweaverportal/index.epx

http://www.sap.com/germany/plattform/netweaver/components/netweaverportal/index.epx

http://wiki.sdn.sap.com/wiki/display/SCM/SAP+EM+as+compared+to+BPM,+BAM+and+CEP

http://wiki.sdn.sap.com/wiki/display/SCM/SAP+EM+as+compared+to+BPM,+BAM+and+CEP

http://www.sap.com/platform/netweaver/components/sapnetweaverbpm/index.epx

http://www.sap.com/platform/netweaver/components/sapnetweaverbpm/index.epx

http://help.sap.com/saphelp_nwpi711/helpdata/de/48/e73fdfe10d740ee10000000a421937/content.htm

http://help.sap.com/saphelp_nwpi711/helpdata/de/48/e73fdfe10d740ee10000000a421937/content.htm

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/307336b8-098c-2d10-be9c-d41ae345f0ff?QuickLink=index&overridelayout=true



Literaturverzeichnis 33

Stollenwerk, Daniel: Enterprise SOA Development Handbook: End-to-End

Guide for Enterprise SOA Development. 2008

Enterprise SOA und SAP NetWeaver BPM - · PDF fileI Zusammenfassung Diese Arbeit...

Documents

Transcript of Enterprise SOA und SAP NetWeaver BPM - · PDF fileI Zusammenfassung Diese Arbeit...