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.
1 Service Oriented Architecture (SOA) 2
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
1 Service Oriented Architecture (SOA) 3
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
1 Service Oriented Architecture (SOA) 4
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.
3 Business Process Management 10
� 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.
3 Business Process Management 11
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.
3 Business Process Management 12
� 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.
3 Business Process Management 13
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
3 Business Process Management 14
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
3 Business Process Management 15
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
3 Business Process Management 16
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
4 Dokumentation der praktischen Fallstudie 18
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
4 Dokumentation der praktischen Fallstudie 19
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.
4 Dokumentation der praktischen Fallstudie 20
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.
4 Dokumentation der praktischen Fallstudie 21
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
4 Dokumentation der praktischen Fallstudie 22
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.
4 Dokumentation der praktischen Fallstudie 23
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
4 Dokumentation der praktischen Fallstudie 24
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,
4 Dokumentation der praktischen Fallstudie 25
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.
4 Dokumentation der praktischen Fallstudie 26
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
4 Dokumentation der praktischen Fallstudie 27
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 {
4 Dokumentation der praktischen Fallstudie 28
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.
4 Dokumentation der praktischen Fallstudie 29
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
4 Dokumentation der praktischen Fallstudie 30
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
Literaturverzeichnis 33
Stollenwerk, Daniel: Enterprise SOA Development Handbook: End-to-End
Guide for Enterprise SOA Development. 2008