SOA und SAP Netweaver BPM. Frank Weisser Business Software Engineering Wintersemester 2010/2011 vorgelegt am: 23. Januar 2011

Transkript

1 SOA und SAP Netweaver BPM Autoren: Vorlesung: Florian Kalisch Frank Weisser Business Software Engineering Wintersemester 2010/2011 vorgelegt am: 23. Januar 2011

2

3 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.

4 Inhaltsverzeichnis II Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkuerzungsverzeichnis II III IV IV 1 Service Oriented Architecture (SOA) SOA-Ansatz Abgrenzung zu bekannten Ansätzen Enterprise SOA Enterprise SOA Architektur Enterprise SOA Lebenszyklus Business Process Management BPM Tools Die möglichen Modellierungselemente des Process Composer Dokumentation der praktischen Fallstudie Vorgehensweise Anforderungen Installation Phase 1 - Geschafätsprozessmodellierung Vorbedingung Modellierung des Geschäftsprozesses Konguration Anlegen des Mappings Deployment und Test Phase 2 - Webserviceerstellung Phase 3- - Integration der Webservices in den Geschäftsprozess Fazit Literaturverzeichnis Index

5 Abbildungsverzeichnis III Abbildungsverzeichnis Abbildung 1 Web-Services-Dreieck Abbildung 2 EnterpriseSOA Abbildung 3 Entwicklung einer SOA Referenzarchitektur für SAP Abbildung 4 Enterprise Service Repository und Service Registry Abbildung 5 Enterprise SOA Lebenszyklus Abbildung 6 Process Integration Abbildung 7 Phase 1 - Geschaftsprozess Abbildung 8 Phase 1 - SAP User Management Konsole Abbildung 9 Phase 1 - Element Kontextmenü Abbildung 10 Phase 1 - Default Tasks Abbildung 11 Phase 1 - Wizard UI Creation Abbildung 12 Phase 1 - SAP Java Application Server Verwaltung - Startseite Abbildung 13 Phase 1 - Browse Principals Abbildung 14 Phase 1 - Add new SAP System Abbildung 15 Phase 1 - Mapping Process Abbildung 16 Phase 1 - Mapping Properties Abbildung 17 Phase 1 - Deploy DCs Abbildung 18 Phase 1 - Process-Repository - Liste der Komponenten.. 26 Abbildung 19 Phase 1 - Process-Repository - Komponentendetails Abbildung 20 Phase 1 UserA Zentraler Arbeitsvorrat Abbildung 21 Phase 1 UserA Eingabe der Daten Abbildung 22 Phase 2 - Web Service Wizard Abbildung 23 Phase 2 - View Servers Abbildung 24 Phase 3 - Web Service in Geschäftsprozess Abbildung 25 Phase 3 - Automated Activity Einstellungen Melzer. 2 Stollenwerk. 3 Baumgartl/Mebus/Seemann. 4 Baumgartl/Mebus/Seemann. 5 SAP SAP NetWeaver Business Process Management: Components & Tools of SAP Netweaver.

6 Abkuerzungsverzeichnis IV Tabellenverzeichnis Tabelle 1 Pool und Lane Tabelle 2 Activity Tabelle 3 Gateways Tabelle 4 Artefakte Abkuerzungsverzeichnis B2B BAM BPM CE CORBA DCOM EAR esoa ESR IDL IT PI SOA SOAP SR UDDI WSDL XML Business to Business Business Activity Monitoring Business Process Management Composition Environment Common Object Request Broker Architecture Distributed Component Object Model Enterprise Archive Enterprise Service Oriented Architecture Enterprise Service Repository Interface Denition Language Information Technology Process Integration Service Oriented Architecture Simple Object Access Protocol Service Registry Universal Description Discovery and Integration Web Services Description Language extensible Markup Language

7 1 Service Oriented Architecture (SOA) 1 1 Service Oriented Architecture (SOA) Für Serviceorientierte Architekturen existiert im Moment keine einheitliche Denition. 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 Denitionen wurden ausgewählt um einen Überblick zu geben: ˆ Melzer 6 :Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und oen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht. ˆ IBM 7 : Serviceorientierte Architektur ist ein geschäftsorientierter IT- Architekturansatz, der die integration ihres Unternehmens als verknüpfte, wiederverwendbare Geschäftsanwendungen oder -services unterstützt. Mit dem Smart SOA-Konzept können Sie eine serviceorientierte Architektur auch in Ihrer Umgebung verwirklichen. ˆ Microsoft 8 : Unternehmen brauchen eziente IT-Systeme, um ihre Geschäftsprozesse zu verbessern und wettbewerbsfähig zu bleiben. Viele Projekte und Anwendungen erfordern die Nutzung von Geschäftslogik über mehrere Kanäle und Nutzergruppen hinweg. Hier kommt die dienstorientierte IT-Architektur (Service-Oriented Architecture) ins Spiel. SOA beschreibt eine Software-Infrastruktur, in der die wesentlichen Funktionen einer Anwendung bzw. Softwaremodule als Service organisiert sind. Services können beliebig verteilt sein und lassen sich dynamisch zu Geschäftsprozessen verbinden. SOA legt hierbei die Schnittstellen fest, über die andere Systeme via Netzwerk diese Dienste nutzen können. Services tauschen dadurch unabhängig von den zugrunde liegenden technischen Plattformen Daten aus. Zwingende Abhängigkeiten der monolithischen Architekturen 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 den 6 Melzer. 7 IBM. 8 Microsoft.

8 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 XMLbasierte Nachrichten, das unabhängig von Programmiersprachen und Betriebssystemen 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. Deniert die Schnittstellen der Webservices (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): Standardisierter Verzeichnisdienst für Webservices. Metadaten des Webservices(Informationen zum Aunden der Services, Eigenschaften des Webservice und allgemeine Anforderungen) werden gespeichert und können abgerufen werden. Ein Nutzer kann somit nach einem registrierten Webservice suchen. Die folgende Grak 1 auf der nächsten Seite gibt einen Überblick über die Komponenten 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 verweist. 4. Diensnutzer frägt mit Hilfe der Beschreibung den gesuchten Dienst an beim Dienstanbieter. 5. Dienst kann nun vom Dienstnutzer benutzt werden. 9 Melzer2007

9 1 Service Oriented Architecture (SOA) 3 Abbildung 1: Web-Services-Dreieck Abgrenzung zu bekannten Ansätzen Der SOA-Ansatz ist nicht gerade neu, die Vorgänger sind z.b. DCOM (Distributed 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 Programmiersprachen sind. Die Technologie CORBA ist zwar ebenfalls unabhängig von

10 1 Service Oriented Architecture (SOA) 4 der Programmiersprache, setzt aber dabei fuer die Kommunikation auf die Interface Denition Language (IDL). Die Webservices bauen dagegen auf SOAP (Simple 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 Catterfeld/Zimpel.

11 2 Enterprise SOA 5 2 Enterprise SOA Abbildung 2: EnterpriseSOA 12 Die Enterprise SOA wird mit Hilfe von Services aufgebaut. Die Services haben folgende Eigenschaften 11 : ˆ 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 Webservices 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 einieÿ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 11 Baumgartl/Mebus/Seemann. 12 Stollenwerk.2008

12 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 Denition für SOA liefert. Die Autoren geben aber eine Referenzarchitektur 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 serviceorientierten Schicht dar. ˆ Service: Der Service bildet die eigentliche Geschäftsfunktionalität ab. Ein Service enthält einen Servicevertrag (Contract), welcher mittels einer Schnittstellendenition 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 (Anwenderaufrufe). ˆ 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. 13 Baumgartl/Mebus/Seemann. 14 Baumgart Baumgart1.2010

13 2 Enterprise SOA 7 Abbildung 3: Entwicklung einer SOA Referenzarchitektur für SAP 14 Abbildung 4: Enterprise Service Repository und Service Registry 15

14 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 Denition der Geschäftsanforderungen. 2. Die Services werden nach den gegebenen Anforderungen modelliert. 3. Denition der Services. 4. Implementation und Entwicklung der Services. 5. Beschreibung und Ermittlung der Services für die ermittelten Anforderungen. 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.

15 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 allem die Ezienz der Geschäftsprozesse kann damit verbessert werden, sowie Fehlerreduzierung in sich wiederholenden komplexen Aufgaben und wengier Kosten für das Exception-Handling BPM Tools Folgenden Tools werden von SAP NetWeaver BPM angeboten 17 : ˆ Process Composer: Ermöglicht den Architekten und Entwicklern der Prozesse, Geschäftsprozessmodelle zu entwerfen. Jedes Modell deniert 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 vereinheitlichte Entwicklungs- und Deploymentumgebung dar. Im einzelnen sind diese Komponenten 18 : ˆ 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. 16 SAP Komponenten & Werkzeuge von SAP NetWeaver: SAP NetWeaver Portal. 17 SAP Komponenten & Werkzeuge von SAP NetWeaver: SAP NetWeaver Portal. 18 SAP SAP NetWeaver Business Process Management: Components & Tools of SAP Netweaver.

16 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, Modikation und Optimierung der Geschäftsregeln. Das Business Rules Management bringt verschiedene Werkzeuge mit: Rules Composer: Ermöglicht es Geschäftsregeln zu entwerfen und modizieren, mit Hilfe von gebräuchlichen representativen Formaten, wie z.b. Entscheidungstabellen. Rules Analyzer: Benutzer können damit die bestehenden Geschäftsregeln testen, verbessern, optimieren und analysieren. Rules Manager: Damit lassen sich die Geschäftsregeln auch in einem gemeinschaftlichen webbasierten Arbeitsumfeld verwalten und bearbeiten. Rules Repository: Ermöglicht die Versionierung der Regeln, sowie die Verwaltung und Kontrolle der Berechtigungen, Alarmsignale und weitere Repository Dienste. Rules Engine: Integriert die Geschäftsregeln in die Laufzeitumgebung der SAP NetWeaver Composition Environment. ˆ Process Integration (PI): Die Prozessintegration arbeitet mit oenen Standards und führt zu einer prozessorientierten Zusammenarbeit der Komponenten 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 Modikation vollständig verwaltet werden. Die Prozessintegration beinhaltet dafür selbst einige Komponenten: Enterprise Services Repository: Zentrale Komponente für die Denition, Aufrufen und Verwaltung von Diensten und anderen Geschäftsobjekten. Enthalten sind die Denitionen und Metadaten der Dienste und Prozesse, gleichzeitig beinhaltet es eine zentrale Modellierungsund Designumgebung zum Anlegen und Verwenden von Diensten. Enterprise Service Bus: Weitere Zentrale Komponente für die Integration zwischen Anwendungen. Diese Komponente ermöglicht eine sichere, standardadisierte, zuverlässige und skalierbare Kommunikation zwischen den Anwendungen, der Anbieter und Nutzer, über die gesamte Systemlandschaft hinweg.

17 3 Business Process Management 11 Abbildung 6: Process Integration 19 BAM (Business Activity Monitoring): Ermöglicht das Prozessmonitoring 20. ˆ SAP NetWeaver Portal 21 : Die wichtigsten Informationen und Anwendungen 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 zusammenführt. 20 SAP SAP EM as compared to BPM,BAM and CEP. 21 SAP SOA-Middleware.

18 3 Business Process Management 12 Zusammenarbeit: Anwendungen können mit Hilfe des Portals gemeinsam genutzt werden. Verschiedene Tools wie virtuelle Arbeitsräume oder Diskussionsforen ermöglichen eine eziente Zusammenarbeit, auÿerdem können externe Tools wie Instant-Messaging, Webkonferenzen oder Groupware integriert werden. Knowledge-Management: Das Portal beinhaltet auch Wissensmanagement, Dienste die den Anwendern die Suche nach Informationen erleichtern, sowie deren Organisation. ˆ SAP NetWeaver Identity-Management: Ermöglicht die zentrale Verwaltung von Benutzerprolen und Zugrisberechtigungen. 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 AG.

19 3 Business Process Management 13 Pool und Lane Ein Pool steht für eine grasche Separierung mehrer Teilnehmer an einem Prozess. Das kann eine spezielle Business Entität sein, wie zum Beispiel eine Firma. Es kann auch eine speziellere Business-Rolle sein, wie Hersteller, Käufer oder Verkäufer. Beim Anlegen eines neuen Prozesses wird automatisch ein Default-Pool mit angelegt, da mindestens ein Pool vorhanden sein muss. Ein Pool stellt einen Container für einen Sequence-Flow zwischen mehreren Activities dar. Die Interaktion zwischen mehreren Pools, welche beispielsweise im B2B-Kontext auftreten kann, wird mittels Messages abgewickelt.eine Lane stellt eine Sub-Partition innerhalb eines Prozesses dar. Ein Pool hat seinerseits wieder mindestens eine Lane. Sie werden dazu benutzt, die Activities innerhalb eines Pools zu organisieren. Lanes repräsentieren interne Rollen wie Angestellter oder Manager. Events Ein Event beeinusst den Fluss innerhalb eines Prozesses und hat einen Grund oder Ziel. Folgende Events sind möglich: ˆ Start-Event: Diese denieren, an welcher Stelle ein Prozess beginnt. Jeder Prozess muss ein Start- Event besitzen. ˆ Intermediate-Event: Events dieser Art treten zwischen dem Start und dem Ende eines Prozesses auf und beeinussen den Fluss des Prozesses. Sie können dazu benutzt werden, auf bestimmte Events zu warten oder den Prozess für eine gewisse Zeit anzuhalten. ˆ End Event: Diese denieren, an welchem Punkt ein Prozess endet. Sie können ein spezisches Resultat besitzen, wie zum Beispiel das Senden einer Nachricht. Tabelle 1: Pool und Lane

20 3 Business Process Management 14 Activity Eine Activity steht für eine durchzuführende Arbeit innerhalb eine Business Prozesses: ˆ Abstract Activity: Diese Activities haben keinen speziellen Typ und können dafür benutzt werden, wenn zum Beispiel ein Entwurf eines Prozesses angefertigt wird. Eine Konvertierung in eine der nachfolgenden Aktivitäten ist möglich. ˆ Human Activity: Diese Art von Aktivitäten werden durch einen Benutzer des Systems durchgeführt. Dazu muss dem Element eine Task zugeordnet werden. Sobald der Prozessuss eine Activity diesen Typs erreicht, erscheint der auszuführende Task in der Universal Worklist. Die Konguration eines Input- und Outputmappings ist nötig. ˆ Automated Activity: Eine automatisierte Activity wird durch ein System durchgeführt. Dazu muss eine Service-Interface-Denition und eine Operation der Activity zugewiesen werden. ˆ Referenced Sub Process: Ein referenzierter Subprozess ist eine grasche Repräsentation eines eigenständigen Prozesses. Die Kommunikation zwischen diesem und der Aktivität funktioniert über Input- und Outputmapping. ˆ Embedded Sub Process: Ein eingebetteter Subprozess ist deniert durch einen Fluss aus mehreren Aktivitäten. ˆ Mapping Activity: Eine Mapping Activity kann benutzt werden, um komplexe Data Objects in einfachere zu transformieren. ˆ Reporting Activity: Reporting Activities können dazu benutzt werden, Daten aus dem Prozesskontext zu sammeln und darauf analytische Auswertungen durchzuführen. ˆ Notication: Notications werden dazu benutzt -Nachrichten aus dem Prozess heraus zu senden. Tabelle 2: Activity

21 3 Business Process Management 15 Gateways Gateways dienen dem Aufteilen und Zusammenführen des Prozessusses innerhalb eines Prozesses. Folgende Typen sind möglich: ˆ Abstract Gateways: Diese abstrakten Gateways haben keinen speziellen Typ und dienen dazu, eine Aufsplittung oder ein Zusammenführen innerhalb eines Prozessentwurfs zu demonstrieren. Eine spätere Typisierung in einen der nachfolgenden Typen ist möglich ˆ Exclusive Choice: Hierbei wird eine exklusive Auswahl innerhalb des Prozessusses getroen. Hinter einem exklusiven Gateway steht eine Bedingung, zu derer es Auswahlmöglichkeiten, die sogenannten Gates, gibt. Die Auswahl wird aufgrund der Prozessdaten gewählt. ˆ Event Based Choice: Die Entscheidung, an welchem Gate der Prozessuss fortgeführt werden muss, wird anhand von auftretenden Events entschieden. ˆ Parallel Split: Dieses Gateway wird dazu benutzt, eine Parallelisierung in den Prozessuss zu integrieren. Diese explizite Denition ist nicht nötig, da von einer Activity auch mehrere Prozessüsse abgehen können, jedoch führt die Darstellung durch ein paralleles Gateway zu einer Erhöhung der Übersichtlichkeit. ˆ Uncontrolled Merge: Vereint alternative Prozess- üsse. ˆ Parallel Join: Mit dem parrallelen Join Gateway können parallele Pfade vereint werden. Dieses Gateway sollte jedoch immer mit einem Parralel Join Gateway benutzt werden. Tabelle 3: Gateways

22 3 Business Process Management 16 Artefakte Artefakte werden dazu benutzt, zusätzliche Informationen über den Prozess bereitzustellen. Dazu können sie mit anderen Elementen über Assoziationspfeile verbunden werden. Zwei verschiedene Typen sind möglich: ˆ Data Objects: Data Objects dienen dazu typisierte Daten Prozessweit zu speichern. Diese Zwischenspeicherung kann beispielsweise dazu benutzt werden, um durch Benutzer eingegebenene Daten für spätere Weiterverwendung im Prozess zwischenzuspeichern. ˆ Annotation: Annotations stellen weitergehende textuelle Informationen zu dem Prozess und im Speziellen zu anderen graschen Elementen bereit. Tabelle 4: Artefakte

23 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 dazugehörigen Webservices ist in den darauolgenden 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 Fazit welches die Anforderungen und die Zieldenitionen 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 Netweaver 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 Implementierung. 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

24 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 Geschäftsprozesses ab, welcher zwei menschliche Benutzer umfasst und deren Datenuss in der Weitergabe einer von Benutzer 1 getätigten Eingabe an Benutzer 2 zur Darstellung besteht. Damit ist eine beispielhafte Geschäftsprozessmodellierung aufgezeigt. 2. Phase Diese Phase deckt das Entwickeln eines Webservice und dessen erfolgreiches Deployment an den SAP Application Server ab. Zu Demonstrationszwecken 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ändert 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 Anforderungen zu vernachlässigen sind. 4.3 Installation Aus den denierten Anforderungen ergibt sich, dass die zu installierende SAP Netweaver CE Version die Modellierung von Geschäftsprozessen unterstützen muss. Dazu kommt die Version SAP NetWeaver CE 7.2 Trial zum Einsatz. Um die Installation erfolgreich durchführen zu können, müssen folgende Punkte beachtet werden: 1. Generelles Problem mit 64 bit Betriebssystemen 2. Die spezizierten Betriebssystemanforderungen müssen eingehalten werden 3. Microsoft Windows XP Professional SP 2 (or higher) 4. Microsoft Windows Vista 32 bit 5. Microsoft Windows Server bit

25 4 Dokumentation der praktischen Fallstudie 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 Prozesse 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 von 23 angelehnt ist. Dafür ist der oben denierte Geschäftsprozess umgesetzt, welcher fertig modelliert wie folgt aussieht: Abbildung 7: Phase 1 - Geschaftsprozess Vorbedingung Bevor mit der Modellierung des Geschäftsprozesses begonnen wird, sollte sichergestellt werden, dass das SAP-System alle benötigten Instanzen und Prozesse gestartet hat. Folgende Punkte sollten zuvor positiv bestätigt sein: 23 Steen Ulmer.

26 4 Dokumentation der praktischen Fallstudie 20 Abbildung 8: Phase 1 - SAP User Management Konsole 1. Hochfahren der Datenbank MaxDB. Dieser Systemprozess muss manuell gestartet 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 Ulmer 24 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 24 Steen Ulmer.

27 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

28 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. Ausgabeelemente in der Useroberäche wiedernden sollen. Im Schritt Create User Interface Component for each Task besteht die Möglichkeit, 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 Konguration In diesem Unterkapitel wird beschrieben, welche Kongurationen nötig sind, damit der Geschäftsprozess, welcher die Interaktion zweier Benutzer erfordert, ablauähig ist. Der erste Bereich der Kongurationen wird auf dem SAP-System vorgenommen. Da im Rahmen dieses Moduls an keinem vorkonguriertem System gearbeitet wird und somit auch noch keine Benutzer angelegt sind, muss dies durchgeführt werden, da der Geschäftsprozess sowohl den SDN_User_A, als auch SDN_User_B erfordert.

29 4 Dokumentation der praktischen Fallstudie 23 Dazu wird die Startseite 25 des SAP NetWeaver Application Server Java über folgendes URL-Muster aufgerufen, welches bei lokalem Zugri wie folgt lauten muss: 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 Kongurationen 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 vorherigen 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 Congure Server Default... aufgerufen und das aktuelle System dort angelegt 25 Zentrale Seite zur Verwaltung des Application Servers

30 4 Dokumentation der praktischen Fallstudie 24 Abbildung 13: Phase 1 - Browse Principals wurde. Am Beispiel des hier vorliegenden Testsystems lautet die Konguration: 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 Anlegen des Mappings Mit Mappings werden die Ein- und Ausgabedaten der verschiedenen Activities speziert. 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 speziziert werden, welche der Web Service verarbeiten soll,

31 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 gleichnamigen Data Objects des Prozesskontexts 26 verbunden. Diese dienen als Zwischenspeicher für die Usereingaben und müssen analog im Input Mapping der Activity Display Name Age verbunden werden 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 durchgeführt werden, was über Rechtsklick auf das Projekt im Project Explorer / Development 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. 26 Der Prozesskontext stellt einen Bereich dar, auf den über mehrere Lanes hinweg zugegrien werden kann.

32 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 Kongurationsmanagement / 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 auf Seite 22) und im sich neu önenden Fenster erneutem Klick

33 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 abgearbeitet werden. Dazu muss sich User_A einloggen. Dies kann er über die URL 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 Prozessuss 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 konzentriert 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 deniert und die dazugehörige Java-Klasse entwickelt. Das Interface: package com.study.bse; public interface AddLocal {

34 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 denierten 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ätzliche 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 Application Servers getestet werden. Durch Angabe der URL und der WSDL ( kann der Service getestet werden.

35 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 eingegeben, welche dann in den Data Objects FirstNumber und SecondNumber zwischengespeichert werden. Die automated Activity AddNumbers, welche den Webservice darstellt, erhält als Input die FirstNumber und SecondNumber aus dem Prozesskontext 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

36 4 Dokumentation der praktischen Fallstudie 30 Abbildung 24: Phase 3 - Web Service in Geschäftsprozess Service Interface / Import WSDL... geschieht. Dort kann dann Remote Location / 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