Technische Universität Dresden - Fakultät Informatik Institut für Systemarchitektur - Lehrstuhl Rechnernetze. bearbeitet von

Transkript

1 Technische Universität Dresden - Fakultät Informatik Institut für Systemarchitektur - Lehrstuhl Rechnernetze DIPLOMARBEIT EVALUIERUNG VON WORKFLOWTECHNOLOGIEN IM SAP NETWEAVER UMFELD bearbeitet von MATTHIAS SIEGMUND geboren am in Zittau Eingereicht am Hochschullehrer: Betreuer TU Dresden: Betreuer sd&m: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Dr. Iris Braun Dr. Stefan Fuchs

2

3 Erklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig, unter Angabe aller Zitate und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe. München, den Matthias Siegmund

4

5 Danksagung Cui honorem, honorem. Ich möchte mich an dieser Stelle bei allen Personen bedanken, die mir bei der Erstellung dieser Diplomarbeit geholfen haben.

6

7 Abstract Serviceorientierte Architekturen (SOA) und damit verbundene Prozessbeschreibungssprachen wie BPEL sind derzeit in aller Munde. Doch bieten sie wirklich einen Mehrwert oder sind sie in erster Linie Marketingmittel? Die vorliegende Arbeit soll diese Frage klären und geht dabei im Speziellen auf die SOA Plattform NetWeaver der SAP AG ein. Hierfür werden zunächst die theoretischen Grundlagen einer serviceorientierten Architektur aufgezeigt und mit bisherigen Integrationsansätzen verglichen. Die Vorteile einer serviceorientierten Architektur zeigen sich dabei vor allem in der Flexibilität und Skalierbarkeit. Anschließend werden die in SAP NetWeaver zur Verfügung stehenden Technologien zur Beschreibung, Modellierung und Steuerung von Prozessen gegenübergestellt. Dabei stellt man schnell fest, dass sich die Technologien teilweise sehr stark ähneln, jedoch aufgrund dieser theoretischen Betrachtung noch keine klare Aussage über die Vor- und Nachteile getroffen werden kann. Aufgrund dessen wird der theoretische Vergleich dieser Technologien im Anschluss durch die Implementierung eines Beispielprozesses aus dem Bankwesen ergänzt. Dafür werden die Prozessbeschreibungssprachen SAP Business Workflow, Guided Procedures und cross-component Business Process Management hinsichtlich Stabilität, Performance und Benutzerinteraktion untersucht. Abschließend erfolgt eine kritische Bewertung dieser Technologien und ein Ausblick auf die kommende SAP Prozessbeschreibungssprache Galaxy, welche die SAP Landschaft neu gestalten wird.

8

9 Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellcodeverzeichnis XII XV XVII XIX 1 Einleitung Ziel der Arbeit Aufbau der Arbeit Systemintegration in Unternehmen Integrationsplattformen Integrationsarchitekturen Point-to-Point Hub&Spoke Pipeline Serviceorientierte Architekturen SOA Referenzmodell Services Enterprise SOA Workflows Begriffsdefinition Bestandteile Abgrenzung zu Geschäftsprozessen Klassifizierungen von Workflows Workflowtechnologien Application Link Enabling VII

10 3.3.2 Master Data Management Workflow Collaboration Tasks SAP Business Workflow Guided Procedures Business Process Management Vergleich der Workflowtechnologien SAP NetWeaver Architektur von SAP NetWeaver Anwendungen Exchange Infrastructure Portal Composite Application Framework Konzeption Anforderungen Vorstellung des Beispielprozesses Serviceidentifikation Systemlandschaft Implementierung Serviceimplementierung Prozesssteuerung mit dem SAP Business Workflow Prozesssteuerung mit der Process Integration Design Konfiguration Enterprise Composite Services Composite Services im SAP Business Workflows Composite Services im SAP Business Process Management Business Process Monitoring Monitoring von Geschäftsprozessen im SAP Business Workflow Monitoring von Geschäftsprozessen in der Process Integration Fazit Bewertung Verbesserungen

11 7.3 Ausblick A Anhang SOA 95 B Anhang Workflows 97 C Anhang NetWeaver 101 D Anhang Implementierung 103 D.1 WebDynpro Komponente für Human Interaction erstellen D.2 WebDynpro Komponente als Callable Object in Guided Procedure einbinden D.3 Guided Procedures Webservice D.4 Servlet erstellen D.5 Aufruf des Webservices aus dem SAP Business Workflow D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine113 E Inhalt der DVD 125 Literaturverzeichnis 126 Glossar 139

12

13 Abkürzungsverzeichnis ALE API BAPI BI BOR BPE BPEL BPM BRE CAF ccbpm CCMS CE CRM DC EAI EBP ECC EJB EPK ERP ESA ESB GP HTTP IDL IDoc JAAS Application Link Enabling Application Programming Interface Business Application Programming Interface Business Intelligence Business Object Repository Business Process Engine Business Process Execution Language Business Process Management Business Rule Engine Composite Application Framework cross-component BPM Computing Center Management System SAP NetWeaver Composition Environment Customer Relationship Management Development Component Enterprise Application Integration Enterprise Buyer Professional Edition ERP Central Component Enterprise JavaBeans Ereignisgesteuerte Prozesskette Enterprise Resource Planning Enterprise Services Architecture Enterprise Service Bus Guided Procedures Hypertext Transfer Protocol Interface Definition Language Intermediate Document Java Authentication and Authorization Service XI

14 KM LDAP MDA MDM OASIS PI RFC RMI SaaS SAML SCHUFA SCM SOA UDDI UWL W3C Wf-XML WfMC WS-BPEL WSDL XI XML Knowledge Management Lightweight Directory Access Protocol Model Driven Architecture Master Data Management Organization for the Advancement of Structured Information Standards Process Integration Remote Function Call Remote Method Invocation Software as a Service Security Assertion Markup Language Schutzgemeinschaft für allgemeine Kreditsicherung Supply Chain Management Service Oriented Architecture Universal Description Discovery and Integration Universal Worklist World Wide Web Consortium Workflow-Extensible Markup Language Workflow Management Coalition Web Services Business Process Execution Language Web Service Description Language Exchange Infrastructure Extensible Markup Language

15 Abbildungsverzeichnis 1.1 Aufbau der Arbeit sd&m Referenzarchitektur für Integrationsplattformen Punkt-zu-Punkt Verbindung Hub & Spoke Architektur Pipeline Topologie Serviceorientierte Architektur Zusammenspiel SOA-Referenzmodell und der Referenzarchitektur SOA Referenzmodell Nutzung eines Services Nutzung eines Services in einer ESOA Abgrenzung Geschäftsprozess und Workflow Gegenüberstellung der Workflowtypen Application Link Enabling MDM Workflowmodellierung mit Hilfe von Microsoft Visio Erstellung von Collaboration Tasks in der Universal Worklist Technische Grundlagen des SAP Business Workflow Guided Procedures Komponenten der Design Time Zusammenhang von UWL, ccbpm und SAP Business Workflow Grafische Modellierung eines ccbpm im Integration Builder SAP NetWeaver Stack Abdeckung der Referenzarchitektur durch die XI SAP NetWeaver Portal Single Sign-On Generischer Kreditprozess Prozessdetails Kreditentscheidung Prozessdetails Kredit betreuen XIII

16 5.4 Prozessdetails Notleidende Kreditprozesse betreuen Ablaufplan Kreditentscheidung Benötigte Systemlandschaft für die Realisierung des Beispielprozesses WebDynpro Komponente der Dateneingabe WebDynpro Komponenten der Sicherheitsbewertung WebDynpro-Komponenten der Kreditentscheidung Webserviceaufruf per ABAP Proxy Guided Procedure zur Bewertung der Sicherheiten Bestandteile der Kommunikation zwischen SAP Business Workflow und Guided Procedures Geschäftsprozess Kreditentscheidung im SAP Business Workflow Architektur SAP Integration Server - Adapter Engine vs. Proxy Message-Mapping im Integrationsprozess Integrationsprozess Kreditentscheidung Konfiguration der Aktivität als Sub-Workflow Composite Service mit Hilfe von SAP Business Workflow Verwendung von Step Groups Workflow-Protokoll zur Überwachung von SAP Business Workflows.. 87 A.1 Bestandteile einer serviceorientierten Architektur A.2 Aufbau eines Services B.1 Workflowreferenzmodell B.2 Schematische Darstellung eines Integrationsprozesses B.3 Gegenüberstellung von Workflowtechnologien in SAP B.4 Dialoggesteuerte Modellierung einer Guided Procedure C.1 Architektur Process Integration C.2 Prozess der Nachrichtenzustellung innerhalb des Integration Servers D.1 Implemented Interface der WebDynpro Komponenten einstellen D.2 Integration der WebDynpro Komponente in die Guided Procedure D.3 Guided Procedures Webservice D.4 Generierung eines Java Proxys D.5 Neuen Service im SAP System registrieren D.6 Neuen Service anlegen

17 D.7 Serviceparameter festlegen D.8 Aufgabe generieren D.9 Aufgabe im Workflow Builder einfügen D.10 SLD - Anlegen eines Produktes und der dazugehörigen Softwarekomponente D.11 SLD - Zuordnung Produkt zu einem Technischen System D.12 Design - Softwarekomponente aus SLD importieren D.13 Design - Namespace für Softwarekomponente anlegen D.14 Design - Integrationsprozess erstellen D.15 Design - WSDL Beschreibung des Webservices importieren D.16 Design - Message-Interface anlegen D.17 Design - Container für die Message-Interfaces anlegen D.18 Design - Senden-Schritt in den Integrationsprozess einfügen D.19 Design - Korrelation erstellen D.20 Design - Korrelation im Sendeschritt aktivieren D.21 Design - Empfangen-Schritt in Integrationsprozess einfügen D.22 Design - Empfangen-Schritt zum Starten des Integrationsprozesses D.23 Konfiguration - Import des Integrationsprozesse aus dem Integration Repository D.24 Konfiguration - Empfänger- und Senderinterfaces D.25 Konfiguration - Kommunikationskanal erstellen D.26 Konfiguration - Empfängerermittlung anlegen D.27 Konfiguration - Interfaceermittlung D.28 Konfiguration - Empfängervereinbarung D.29 Konfiguration - Kommunikationskanal Callback D.30 Konfiguration - Senderermittlung Callback D.31 Konfiguration - Empfängerermittlung Callback D.32 Konfiguration - Interfaceermittlung Callback D.33 Integrationsprozess mit Hilfe des HTTP Clients testen

18

19 Tabellenverzeichnis 3.1 Funktionen des MDM Workflows Funktionen des SAP Business Workflows Prozessschritte des ccbpm Vergleich der Workflowtechnologien Vergleich der Workflows anhand der Referenzarchitektur E.1 Inhalt der DVD XVII

20

21 Quellcodeverzeichnis 6.1 Pseudocode des StartBusinessProcess Webservice Auszug aus dem CheckSecurities Webservice Pseudocode CheckRating Webservice Pseudocode Result Webservice Pseudocode des ABAP Proxys Pseudocode des Java Servlets Pseudocode des Guided Procedures Webservice Pseudocode für den Callback vom Webservice zum Integrationsprozess 83 D.1 WebDynpro Komponente - Auszug 1 aus dem ComponentController D.2 WebDynpro Komponente - Auszug 2 aus dem ComponentController D.3 WebDynpro Komponente - Auszug 3 aus dem ComponentController D.4 Guided Procedures Webservice - Auszug D.5 Servlet - Auszug XIX

22

23 Kapitel 1 Einleitung Alea iacta est! Julius Caesar Die heutige Zeit ist in vielen Bereichen des täglichen Lebens von einer hoher Innovationsdichte und damit verbundenen kurzen Produktlebenszyklen geprägt. Unternehmen sind dadurch gezwungen, möglichst schnell und effizient auf Entwicklungen im Markt zu reagieren. Zu diesem Zweck müssen auf der einen Seite die Geschäftsprozesse gezielt gesteuert werden und auf der anderen Seite muss es möglich sein, die bestehende Softwarelandschaft im Unternehmen schnell an Änderungen anzupassen. Dies ist allerdings bei einem Großteil der herkömmlichen Software nicht ohne weiteres möglich. Ein weiteres Problem besteht in der Vielschichtigkeit der Softwarelandschaft. Unternehmen setzen vermehrt Standardsoftware ein, nutzen aber in vielen Bereichen speziell entwickelte Anwendungen. Geschäftsprozesse sind aber in der Regel anwendungsübergreifend, wodurch Mittel und Wege gefunden werden müssen, Geschäftsprozesse über Anwendungs- und Systemgrenzen hinweg zu modellieren und zu steuern. Serviceorientierte Architekturen versprechen eine Lösung für beide Probleme. Zum einen sollen sie die gewünschte Flexibilität und Nähe an den Geschäftsprozessen bieten, zum anderen soll es in Kombination mit Prozesssteuerungskomponenten möglich werden, heterogene Systeme zu verbinden und somit anwendungsübergreifende Geschäftsprozesse zu steuern. 1

24 Kapitel 1 Einleitung 1.1 Ziel der Arbeit Die SAP AG bietet als technische Grundlage für serviceorientierte Architekturen die Plattform SAP NetWeaver an. In dieser existieren jedoch verschiedene Technologien zur Prozessmodellierung und Steuerung, wobei die Vor- und Nachteile der einzelnen Prozesssteuerungskomponenten weitgehend unbekannt sind. In der vorliegenden Arbeit wird aus diesem Grund ein Vergleich der Technologien im SAP NetWeaver Umfeld vollzogen, um die Eigenschaften der einzelnen Prozesssteuerungskomponenten aufzuzeigen. Besonderen Wert wird dabei auf die Technologien Business Process Engine, Guided Procedures und SAP Workflow gelegt. Diese sind die zentralen Bausteine, um Dienste und Anwendungen im Sinne einer serviceorientierten Architektur zu orchestrieren. Es wird evaluiert, welchen Reifegrad diese Technologien bereits erreicht haben, für welchen Einsatzbereich sie geeignet sind und ob es mit ihrer Hilfe möglich ist, anwendungsübergreifende Geschäftsprozesse zu modellieren. Alle Technologien werden im Rahmen der Implementierung eines Praxisbeispiels aus dem Bereich Banken getestet und hinsichtlich ihrer Stabilität, Skalierbarkeit und Performance untersucht. Besonderer Augenmerk wird dabei auf die Umsetzung von Human Workflows und die Kommunikation mit anderen Technologien gelegt. 1.2 Aufbau der Arbeit Die vorliegende Arbeit gliedert sich in einen theoretischen Teil, welcher die Grundlagen und Technologien erläutert, sowie einen praktischen Teil, in welchem die Ergebnisse der Arbeit präsentiert werden. Dazu werden in Kapitel 2 die Grundlagen der Integration von Anwendungen und Systemen vorgestellt. Anschließend wird eine Referenzarchitektur aufgezeigt, anhand derer verschiedene Möglichkeiten der Integration verglichen werden. Daraufhin wird das Prinzip der serviceorientierten Architektur als Basis für Integrationsplattformen untersucht. Darauf aufbauend werden in Kapitel 3 verschiedene Workflowtechnologien verglichen und ihre Eignung für Integrationsplattformen aufgezeigt. Davor wird zunächst eine Definition von Workflows gegeben und eine Klassifikation dieser vorgestellt. Der Abschluss des theoretischen Teils bildet die Vorstellung von SAP NetWeaver als Architekturgrundlage für die Realisie- 2

25 1.2 Aufbau der Arbeit rung einer serviceorientierten Integrationsplattform. Daraufhin erfolgt in Kapitel 5 die Konzeption, in welcher die Prozesse modelliert und mögliche Probleme bei dem Zusammenspiel der einzelnen Technologien aufgezeigt werden. Kapitel 6 zeigt nachfolgend Lösungsmöglichkeiten anhand einer prototypischen Umsetzung auf, bevor eine abschließende Bewertung der evaluierten Technologien erfolgt. Kapitel 1 Einleitung Theorie Kapitel 2 Systemintegration Kapitel 3 Workflows Kapitel 4 SAP NetWeaver Kapitel 5 Konzeption Praxis Kapitel 6 Implementierung Kapitel 7 Fazit Abbildung 1.1: Aufbau der Arbeit 3

26 Kapitel 1 Einleitung 4

27 Kapitel 2 Systemintegration in Unternehmen Tempora mutantur, nos et mutamur in illis. Redewendung Die softwaretechnische Infrastruktur in Unternehmen ist heutzutage von einer Vielzahl von Siloanwendungen für die unterschiedlichste Einsatzzwecke geprägt. ERP-Systeme zur Warenabwicklung existieren parallel zu CRM-Systemen zum Kundenmanagement und Lagacy-Systeme aus längst vergangenen Zeiten. Allen Systemen gemein ist, dass diese eine eigene Datenbasis besitzt und sie aufgrund fehlender Standards nicht oder nur sehr schwer mit anderen Systemen kommunizieren können. Man wünscht sich hierfür eine Möglichkeit, mit der die verschiedenen Systeme miteinander kombiniert werden können und eine einheitliche Infrastruktur geschaffen werden kann. Integrationsplattformen sollen einen Ausweg aus diesem Dilemma bieten (vgl. [KHB + 04]). In der Softwareentwicklung findet deswegen zurzeit ein Umdenken statt. Man möchte weg von unflexiblen, monolithischen Anwendungen. Software as a Service wird hierfür als The next big thing betrachtet und ist derzeit Gegenstand vieler Diskussionen (vgl. [Kno06]). Damit soll es möglich sein, Software aus Bausteinen zusammenzusetzen und somit eine hohe Flexibilität zu erreichen, um schneller auf Änderungen reagieren zu können. Die Softwaretechnologie befindet sich demzufolge in einem Paradigmenwechsel. 5

28 Kapitel 2 Systemintegration in Unternehmen Die Grundlagen einer solchen flexiblen Anwendungslandschaft stellt das Architekturprinzip der serviceorientierten Architektur dar, welche in Kapitel 2.3 beschrieben wird. Zuvor werden jedoch die Grundlagen einer Integrationsplattform aufgezeigt und eine Referenzarchitektur vorgestellt, welche einen Vergleich der verschiedenen Technologien ermöglichen soll. Daraufhin wird in Kapitel 2.2 ein Überblick über verschiedene Möglichkeiten der Integration gegeben und Vor- und Nachteile dieser dargelegt. 2.1 Integrationsplattformen Die zunehmende Vernetzung heterogener Anwendungen in Unternehmen zu komplexen Anwendungslandschaften ist nur möglich, wenn eine entsprechende technische Grundlage dafür existiert. Integrationsplattformen stellen diese Infrastruktur zur Verfügung und ermöglichen so die Kommunikation verschiedener Komponenten, ohne dass diese dafür angepasst werden müssen - was bei vielen Anwendungen ohnehin nicht möglich ist (vgl. [EHH + 08, Seite 257]). Zurzeit existiert eine Vielzahl solcher Integrationsplattformen, die auf unterschiedlichen Prinzipien basieren. Dies erschwert den Vergleich ungemein, da sich die Plattformen in der verwendeten Architektur sehr stark unterscheiden. Es wird demzufolge ein Mittel benötigt, dass als einheitliches Vergleichskriterium dient und alle Anwendungsfälle abdeckt. Eine Referenzarchitektur stellt eine solche Möglichkeit dar. Die sd&m AG hat hierfür eine Referenzarchitektur entwickelt, dargestellt in Abbildung 2.1, mit welcher es möglich ist, Integrationsplattformen miteinander zu vergleichen und entsprechend der Anforderungen die geeignetste auszuwählen (vgl. [EHH + 08, Seite 257]). Diese Referenzarchitektur für Integrationsplattformen wird nachfolgend erläutert. Referenzarchitektur Eine Referenzarchitektur in der Softwarearchitektur stellt ein idealtypisches Muster der zu modellierenden Anwendung dar. Sie basiert im Allgemeinen auf einem Referenzmodell, welches die Zerlegung eines bekannten Problems in Teilprobleme widerspiegelt. Aufgabe der Referenzarchitektur ist es, diesen Teilproblemen Softwarebausteine und Funktionen zuzuordnen. Len Bass definiert eine Referenzarchitektur demnach wie folgt: 6

29 2.1 Integrationsplattformen A reference architecture is a reference model, mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them. [BCK03, Seite 25] Die Referenzarchitektur von sd&m lässt sich auf oberster Ebene in Online Dienste und Offline Dienste unterteilen. Die Offline Dienste sind dabei für den eigentlichen Betrieb der Integrationsplattform nicht notwendig, sondern stellen Entwicklungs- und Konfigurationsweckzeuge zur Verfügung. Die Online Dienste hingegen spiegeln die Kernfunktionalitäten der Integrationsplattform wider und lassen sich in die folgenden Komponenten zerlegen (vgl. [EHH + 08, Seite 261 ff]). Repository Im Repository werden alle Artefakte verwaltet, die von anderen Komponenten genutzt werden. Das Repository kann dabei je nach Art der gespeicherten Informationen weiter verfeinert werden. Kommunikation Die Realisierung der technischen Anbindung der heterogenen Anwendungen übernehmen die Kommunikationsdienste der Referenzarchitektur. Sie stellen Funktionen zur Adressierung, Übertragung und Protokollierung zur Verfügung. Transformation Aufgaben der Datenwandlung und des Mappings auf fachlicher und technischer Ebene übernehmen die Transformationsdienste in der Referenzarchitektur. Prozesssteuerung Die Dienste der Prozesssteuerung sind hauptsächlich für die Orchestrierung von Services zur Realisierung von Geschäftsprozessen verantwortlich. Ferner stellen sie Funktionen zur Automatisierung und Verwaltung zur Verfügung. Sicherheit Die Gewährleistung der Vertraulichkeit und der Integrität von Informationen wird durch Dienste der Komponente Sicherheit realisiert. Workflow In der Komponente Workflow werden Dienste zur Realisierung automatisierter Prozesse und der Benutzerinteraktion zur Verfügung gestellt. 7

30 Kapitel 2 Systemintegration in Unternehmen Laufzeitmanagement Querschnittsfunktionen zur Verwaltung und Überwachung der Plattform werden von Diensten des Laufzeitmanagements realisiert. Online Dienste Offline Dienste Laufzeitmanagement Sicherheit Workflow-Management Repository Entwicklung Monitoring Identifizierung& Authentifizierung Postkorb Dialog- Einsprung Organisations- Repositiory Prozessmodellierung Prozess-Steuerung Ausfallsicherheit Zugriffsschutz Business Activity Monitoring Transaktionen & Rollback Prozess- Repository Transformationsmodellierung Transformation Lastverteilung Fachliche Transformation Ereignisverwaltung Prozess Engine Service- Repository Adapter- Entwicklung Kommunikation Fehlerbehandlung Technische Transformation Adressierung Lieferung Protokollierung Konfigurationsmanagement Anwendungslandschaft Abbildung 2.1: sd&m Referenzarchitektur für Integrationsplattformen nach [EHH + 08] 2.2 Integrationsarchitekturen Betrachtet man die Entwicklung im Bereich der System- und Anwendungsintegration, fällt auf, dass es drei verschiedene Architekturtrends gab, welche nachfolgenden vorgestellt werden. Dabei wird besonderes Augenmerk auf die Vor- und Nachteile der jeweiligen Architektur gelegt. Des Weiteren werden die vorgestellten Architekturen hinsichtlich der Referenzarchitektur verglichen und eingeordnet Point-to-Point Zu Beginn der Integrationsbemühungen gab es aufgrund fehlender Standards keine andere Möglichkeit, als jedes System einzeln miteinander zu verbinden, wie in Abbildung 2.2 dargestellt ist. Diese Punkt-zu-Punkt Verbindungen führten jedoch schnell zu einer kombinatorischen Explosion der Schnittstellen, da für jedes neu hinzukommende System neue Schnittstellen implementiert werden müssen. Die Kosten für eine derartige 8

31 2.2 Integrationsarchitekturen Integration steigen somit exponentiell zu der Anzahl genutzter Systeme. Ein weiterer Nachteil der Punkt-zu-Punkt Integration ist, dass eine Wiederverwendung der Schnittstellen aufgrund der hohen Spezialisierung kaum möglich ist (vgl. [Thi06]). Ebenso sind die in der Regel sehr gut organisierten Geschäftsprozesse nur unzureichend auf die Anwendungssysteme übertragbar. Geschäftsobjekte werden oft redundant in verschiedenen Anwendungssystemen gehalten, Funktionalitäten der Anwendungen überlappen sich (vgl. [EHH + 08]). Dadurch kommt es zu Unklarheiten und Problemen bei der Übertragung von Geschäftsprozessen auf die Anwendungen. Bei dem Versuch, Integrationsplattformen auf Basis von Punkt-zu-Punkt Verbindungen in die vorgestellte Referenzarchitektur einzuordnen, fällt schnell auf, dass es sich hierbei nur um eine sehr simple Technologie handelt. Die Komponenten Laufzeitmanagement, Sicherheit und Repository werden de Facto nicht unterstützt. Die anderen Komponenten werden, je nach Bedarf, durch die Schnittstellen implementiert. Die Gestaltungsziele Effektivität, Effizienz und Agilität [...] einer Integrationsplattformen lassen sich somit nur schwer verwirklichen [EHH + 08]. Eine Architektur auf Grundlage von Punkt-zu-Punkt Verbindungen eignet sich demzufolge nur, wenn die Zahl der Systeme sehr klein ist und abzusehen ist, dass sich dies auch nicht ändern wird. Dann ist diese Form allerdings die günstigste und schnellste Variante eine Integrationsplattform zu implementieren (vgl. [Sch06]). Clients/Applications Enterprise systems Abbildung 2.2: Punkt-zu-Punkt Verbindung nach [Thi06], [Wal06] 9

32 Kapitel 2 Systemintegration in Unternehmen Hub&Spoke Die Nachfolge der Punkt-zu-Punkt Topologie traten die Hub&Spoke Architekturen an. Diese basieren auf einem zentralen Hub (Knoten), der alle angeschlossenen Systeme miteinander verbindet (siehe Abbildung 2.3). Der Hub fungiert somit als zentrale Drehscheibe, die Nachrichten empfängt, transformiert und zu den jeweiligen Systemen weiterleitet. Die Zahl der Schnittstellen steigt somit im Gegensatz zur Punkt-zu-Punkt Topologie nur proportional zur Anzahl der verwendeten Systeme. Dadurch wird der Integrationsaufwand gegenüber den Punkt-zu-Punkt-basierten Lösungen sehr stark reduziert (vgl. [EHH + 08, Seite 115 f]). Interfaces Interfaces EAI Clients/Applications Enterprise systems Abbildung 2.3: Hub & Spoke Architektur nach [Thi06] Ein wesentlicher Nachteil dieser Topologie ist jedoch, dass der zentrale Hub ein Single Point of Failure darstellt - sowohl in Bezug auf die Verfügbarkeit als auch im Hinblick auf die Performance (vgl. [NFNH06, Seite 32]). Fällt der Hub aus, können die angeschlossenen Systeme nicht mehr miteinander kommunizieren. Abhilfe schafft hier nur eine dynamische Skalierung des Hubs. Die Abdeckung der Referenzarchitektur ist bei solchen Integrationsplattformen im Allgemeinen wesentlich besser als bei einer Punkt-zu-Punkt basierten Lösung. Die Komponenten Kommunikation, Transformation, Laufzeitmanagement, Workflow und Sicherheit sind grundlegend, wohingegen Repository, Prozesssteuerung und Entwicklung im Allgemeinen optional sind. 10

33 2.2 Integrationsarchitekturen Integrationsplattformen die auf einer solchen Architektur aufbauen, stellen meist datenorientierte Ansätze mit gemeinsamer Datenbasis oder funktionsorientierte Ansätze via RFC oder RMI dar. Allerdings lösen die Hub&Spoke Systeme nicht das Problem der unterschiedlichen Benutzeroberfläche, welches von vielen Benutzern immer wieder als störend empfunden wird (vgl. [KHB + 04]) Pipeline Eine weitere Möglichkeit Integrationsplattformen zu realisieren stellen sogenannte Pipeline- oder Busarchitekturen dar. Im Gegensatz zu der Hub&Spoke Topologie existiert hier kein zentraler Knoten im Netzwerk, der alle Systeme miteinander verbindet. Sie sind vielmehr an eine abstrakte Kommunikationsschicht angeschlossen wie in Abbildung 2.4 dargestellt ist. Durch diese Abstraktion können heterogene Systeme sehr einfach integriert werden. Jedoch erkauft man sich diese Flexibilität mit einem höherem Entwicklungsaufwand, im Vergleich zu den Punkt-zu-Punkt und Hub&Spokes Ansätzen. Integrationsplattformen auf Basis einer solchen Architektur realisieren im Allgemeinen nachrichtenorientierte oder auch GUI-orientierte Ansätze. Erst dadurch wird es möglich nicht nur Daten und Funktionen über Anwendungsgrenzen hinweg zu nutzen sondern auch systemübergreifende Prozesse und einheitlichen Benutzerobenflächen zu realisieren. Eine solche Topologie ist somit eine sehr gute Grundlage für eine serviceorientierte Architektur, auf welche im folgenden Kapitel näher eingegangen wird. Core Functions Metadata Security Management Routing Bus Clients/Applications Abbildung 2.4: Pipeline Topologie nach [Thi06], [Wal06] 11

34 Kapitel 2 Systemintegration in Unternehmen 2.3 Serviceorientierte Architekturen Das Konzept der serviceorientierten Architektur, kurz SOA, ist in erster Linie ein Managementkonzept, das darauf abzielt, eine flexible, an den Geschäftsprozessen orientierte IT-Infrastruktur vorzustellen. Grundgedanke einer solchen serviceorientierten Architektur ist die Kapselung von Funktionen in klar definierte, voneinander unabhängige Services. Aus technischer Sicht lässt sich eine serviceorientierten Architektur in drei Kernkomponeten unterteilen. Neben den bereits erwähnten Services gibt es noch den Servicenutzer und das Servicregistry. Die daraus resultierende Architektur ist in Abbildung 2.5 dargestellt und wir auch häufig als das magische SOA Dreieck bezeichnet. Serviceregistry Service Servicenutzer Abbildung 2.5: Serviceorientierte Architektur nach [WCL + 05], [Wal06] SOA Referenzmodell Da das Gebiet der serviceorientierten Architekturen zur Zeit sehr stark in Bewegung ist und es keine einheitliche Definition gibt, wurde von der Organization for the Advancement of Structured Information Standards ein SOA Referenzmodell vorgestellt, welches eine einheitliche Basis der Kommunikation schaffen soll. Dafür wird ein minimales Set an Entitäten sowie Beziehungen zwischen diesen definiert, welche vollständig unabhängig von spezifischen Standards, Technologien und Implementierungen sind (vgl. [Lie07]). 12

35 2.3 Serviceorientierte Architekturen Im Vergleich zu der in Kapitel 2.1 vorgestellten Refenzarchitektur ist das SOA Referenzmodell somit ein abstraktes Rahmenwerk, das den eigentlichen Kern einer SOA definiert. Die Referenzarchitektur hingegen stellt eine konkrete Abbildung dieses Referenzmodells dar. Eine Applikation auf Basis einer serviceorientierten Architekturen zu implementieren stellt demnach die Anwendung der Referenzarchitektur dar - unter Berücksichtigung der Anforderungen, Ziele sowie zur Verfügung stehender Technologien und Entwurfsmuster. Dieser Zusammenhang zwischen Referenzmodell und Referenzarchitektur während der Entwicklung wird in Abbildung 2.6 verdeutlicht. Abstrakt Referenzmodell geleitet von Input Architekturentwurf Verwandte Arbeit Anforderungen Referenzarchitektur Entwurfsmuster Protokolle Profile Motivation Ziele beachtet abgeleitet Konkrete Architektur Verwandte Modelle beachtet Spezifikationen Standards berücksichtigt hergeleitet aus benutzt Konkrete Implementierung Serviceorientierte Anwendung Abbildung 2.6: Zusammenspiel des SOA Referenzmodells und der Referenzarchitektur bei der Entwicklung einer SOA nach [MLM + 06] Das SOA Referenzmodell besteht im Wesentlichen aus den Schlüsselelementen Visibility, Interaction und Real world effect, die sich um das zentrale Element des Services gruppieren (siehe Abbildung 2.7). Diese drei Kernelemente beschreiben die Eigenschaften und Fähigkeiten eines Services und werden im Nachfolgenden kurz erläutert. Eine detaillierte Beschreibung findet sich in der Spezifikation Reference Model for Service Oriented Architecture unter [MLM + 06]. Visibility Damit Serviceanbieter und Servicenutzer miteinander interagieren können, ist es notwendig, dass diese sich gegenseitig sehen. In einer serviceorientierten Architektur ist diese Sichtbarkeit nicht selbstverständlich und muss explizit erfol- 13

36 Kapitel 2 Systemintegration in Unternehmen gen. Hierfür müssen sich die Partner kennen, sie müssen erreichbar und gewillt sein, miteinander zu interagieren. Es müssen demzufolge Vereinbarungen über Zugriffs- und Antwortmechanismen definiert werden (vgl. [MLM + 06], [RB07]). Interaction Die Interaktion mit dem Service findet im Allgemeinen durch den Austausch von Nachrichten zwischen Serviceanbieter und Servicenutzer statt. Es ist allerdings auch möglich, ohne direkten Nachrichtenaustausch zu interagieren, zum Beispiel über Änderungen an gemeinsam genutzte Ressourcen. Damit eine Interaktion jedoch stattfinden kann, ist es notwendig, die relevanten Informationen über den Service zu kennen. Hierfür werden Verhaltensmodelle, welche zur Beschreibung der Aktivitäten und Prozessabläufe dienen und Informationsmodelle, welche der Beschreibung der Struktur und der Semantik der Daten dienen, definiert. Sowohl Informationsmodelle als auch Verhaltensmodelle werden durch die Servicebeschreibung bereitgestellt (vgl. [MLM + 06]). Real world effect Der Servicenutzer ist im Allgemeinen bestrebt, den Serviceanbieter dazu zu bringen, Arbeit für ihn zu erledigen. Das daraus resultierende Ergebnis einer Interaktion - beispielsweise die Buchung eines Flugtickets durch einen entsprechenden Service - wird als Real world effect bezeichnet und stellt den eigentlichen Zweck der Nutzung eines Services dar (vgl. [MLM + 06], [RB07]). Neben diesen drei Schlüsselelementen gibt es noch die Elemente Contract & Policy, Execution Context und das bereits erwähnte Element Service Description. Unter dem Punkt Contract & Policy werden Beschränkungen und Bedingungen zusammengefasst, die für die Ausführung eines Services gelten. Diese werden meist vom Serviceanbieter aufgestellt und sollen sowohl die Sicherheit als auch die Qualität des Services sicherstellen. Des Weiteren werden hierunter auch die durch die Servicenutzung anfallende Kosten festgelegt. Die Menge aller Elemente, die Teil der Interaktion sind, wird unter dem Punkt Execution Context zusammengefasst. Die Service Description beschreibt die Funktionalität des Services, den Zugriff auf diesen und zu berücksichtigende Richtlinien und Verträge. 14

37 2.3 Serviceorientierte Architekturen Reachability Awareness Willingness Visibility Service description Execution Context Behavior model Action model Process model Service Shared state Interaction Service Interface Real world effect Functionality Interaction model Semantics Structure Contract & Policy Assertions Agreements Enforcement Abbildung 2.7: SOA Referenzmodell nach [MLM + 06] Services Services stellen im Kontext serviceorientierten Architekturen Softwarekomponenten dar, welche lokal oder über ein Netzwerk genutzt werden können (vgl. [DJM05, Seite 12]). Sie sind somit die elementaren Bestandteile einer SOA und beinhalten die eigentliche Implementierung der Geschäftslogik, welche dem Nutzer allerdings vollständig verborgen bleibt. Neben der Implementierung besteht ein Service außerdem noch aus einer Menge von Schnittstellen und einem Servicevertrag (siehe Abbildung A.2). Der Servicevertrag enthält dabei Informationen über die Funktionen, Datentypen und den Zweck des Services. Der Zugriff und somit die Kommunikation mit dem Service erfolgt über Schnittstellen, diese stellen somit die Funktionalität des Services nach außen zur Verfügung. (vgl. [KBS07, Seite 78 ff]). Entwicklung eines Services Bei dem Design und der Implementierung von Services sollten bestimmte Regeln eingehalten werden, um eine hohe Qualität zu gewährleisten. Ein Teil dieser Regeln ist bereits aus anderen Gebieten der Softwaretechnologie bekannt (vgl. [GJM02]), andere 15

38 Kapitel 2 Systemintegration in Unternehmen sind speziell auf das Gebiet der serviceorientierten Architekturen zugeschnitten. Die wichtigsten Regeln werden im Folgenden kurz vorgestellt. Hohe Kohärenz, Geringe Kopplung Der Zusammenhalt innerhalb eines Services soll möglichst groß, die Kopplung der Services untereinander jedoch möglichst lose sein. Dies bedeutet also, dass die fachliche Funktionalitäten innerhalb eines Services möglichst ähnlich sein sollen. Von außen darf jedoch kein Zugriff auf Daten und Attribute innerhalb des Services erfolgen (vgl. [GJM02]). Grobgranularität Bei der Entwicklung von Services sollte darauf geachtet werden, dass nur so wenig Services wie möglich, jedoch so viele wie notwendig entworfen werden. Zu breit angelegte Services, die zu viele Funktionalitäten in sich kapseln, verhindern die Wiederverwendbarkeit und sind nicht flexibel genug. Zu feingranulare Services auf der anderen Seite treiben jedoch die fachliche und technische Komplexität in die Höhe (vgl. [SH07]). Kontexfreiheit Zur Verhinderung von sog. Control Misunderstandings dürfen Services kein Wissen über den Ausführungskontext besitzen (vgl [RMSD07]). Keine zyklischen Abhängigkeiten Zyklische Abhängigkeiten können zu Verklemmungssituationen führen und somit die Bearbeitung behindern (vgl. [GJM02]. Technikneutralität Services stellen ausschließlich fachliche Funktionalitäten nach außen zur Verfügung, Implementierungsdetails (wie die verwendete Programmiersprache oder die technische Infrastruktur) bleiben dem Nutzer verborgen (vgl. [HHV06]). Referenzfreiheit Operationsaufrufe sollten stets call-by-value und niemals call-by-reference erfolgen, dadurch wird eine zu starke Kopplung zwischen der rufenden und der gerufenen Komponente verhindert (vgl. [HHV06]). 16

39 2.3 Serviceorientierte Architekturen Idempotenz Um die Anforderungen Wiederholbarkeit und Zusicherbarkeit sicher zu stellen, sollten Services idempotent sein. Sie müssen also bei mehrmaligem Aufruf mit den selben Parametern immer dasselbe Ergebnis zurückliefern [EHH + 08]. Nutzung eines Services Das SOA Paradigma sieht zwei Konzepte zur Nutzung eines Services vor. Zum Einen kann ein Service bereits während der Entwicklungszeit in die Software eingebunden werden, was im Allgemeinen als statische Bindung bezeichnet wird. Andererseits können Services zur Laufzeit ermittelt und dynamisch eingebunden werden. Die statische Bindung von Services ist ein vergleichsweise einfaches Vorgehen. Der Entwickler sucht einen passenden Service per Hand und bindet diesen ein. Die Verantwortung liegt somit vollständig in den Händen des Entwicklers. In der Regel ist dieses Vorgehen für die meisten Zwecke ausreichend, birgt aber Probleme, wenn sich Services ändern. Dann muss der Entwickler einen anderen Service suchen und unter Umständen die Software anpassen (vgl. [KBS07, Seite 81 ff]). Dieser Nachteil kann durch die dynamische Bindung von Services zur Laufzeit umgangen und dadurch eine höhere Flexibilität erreicht werden. Hierfür benötigt man allerdings neben den eigentlichen Services zusätzlich noch das Wissen Was es für Services gibt und Wo man diese findet. Man benötigt demzufolge eine Art Gelbe Seiten für Services. Dieses Serviceverzeichnis wird im SOA Paradigma durch das Serviceregistry beschrieben. Services können sich bei diesem Serviceregistry registrieren und Informationen für potentielle Nutzer veröffentlichen. Anders als die Gelben Seiten ist das Serviceregistry jedoch dezentral organisiert, das bedeutet, es kann mehrere dieser Verzeichnisse geben, die unter Umständen unterschiedliche Services beinhalten. Es ist zum Beispiel denkbar, dass es firmeninterne und öffentliche Servicregistrys gibt (vgl. [DJM05, Seite 15]). Auffinden eines Services Das Auffinden eines Dienstes ist in Abbildung 2.8 dargestellt und geschieht in 5 Schritten. Im ersten Schritt veröffentlicht der Serviceanbieter den zur Verfügung gestellten Service bei einem Serviceregistry. Hierfür werden alle zur Benutzung des Service be- 17

40 Kapitel 2 Systemintegration in Unternehmen nötigten Informationen, wie die Adresse des Services, zur Verfügung stehende Methoden oder eine Beschreibung des Services an das Verzeichnis gesandt. Daraufhin kann ein potentieller Nutzer diesen Service auffinden und verwenden. Dazu sendet das Serviceregistry einen Verweis auf die Servicebeschreibung an den Nutzer. Anhand dieser erfährt der Nutzer weitere Einzelheiten über den Service und kann letztendlich den Service benutzen. 4. Abfrage der Beschreibung 5. Nutzung Servicenutzer 3. Verweis auf Dienst 2. Suchen 1. veröffentlichen Service Serviceregistry Abbildung 2.8: Nutzung eines Services nach [WCL + 05] Enterprise SOA Enterprise Services Architecture requires a new way of thinking. The old identify the problem an write the code to solve it approach is no langer valid, if it ever was. Instead, ESA starts with top-down business issues and descends - deliberately, but elegantly - down to the IT Level. [SRB06] Das im vorangegangenen Kapitel beschriebene, klassische Konzept der SOA ist in erster Linie für kleinere Anwendungen geeignet. Das Problem einer grundlegenden SOA ist die starke Integration der Geschäftsprozesse. Will man jedoch auf Grundlage dieser Architektur systemübergreifende und unternehmensweite Anwendungen entwickeln, macht es Sinn, diese Architektur um eine Schicht zur Prozesssteuerung oder Kapselung von Lagacysystemen zu erweitern. Durch eine solche prozessfähige SOA erreicht man eine schlankere und flexiblere Anwendung (vgl. [KBS07]). Krafzig schlägt dafür in [KBS07] eine Unterteilung in die Komponenten Enterprise Services, Anwendungsfrontend, Service Repository und Service Bus vor. 18

41 2.3 Serviceorientierte Architekturen Enterprise Services Applikationsübergreifende Services zur Abstraktion von Geschäftsprozessen, welche aus einfacheren Services zusammengesetzt sind bzw. diese steuern, werden auch Enterprise Services genannt (vgl. [KHB + 04, Seite 224 f]). Sie unterscheiden sich demzufolge von einfachen Services durch die höhere Abstraktion und größere Nähe an den Geschäftsprozessen. Im Umfeld von SAP NetWeaver werden Enterprise Services häufig auch als Composite Services bezeichnet. Anwendungsfrontend Die Schnittstelle zum Benutzer wird durch das Anwendungsfrontend dargestellt. Es handelt sich hierbei um das aktive Element einer SOA, welches Services initiiert und kontrolliert. Das Anwendungsfrontend kann dabei in unterschiedlichsten Ausprägungen und Formen realisiert werden, etwa als Webanwendung oder als Rich-Client (vgl. [KBS07, Seite 78], [NKK07, Seite 40]). Service Repository Mit zunehmender Größe der Software werden mitunter sehr viele Services benötigt. Es bietet sich ein zentrales Service Repository an, um nicht den Überblick zu verlieren und die Wiederverwendbarkeit zu fördern. Ein solches Service Repository ist sozusagen ein Sammelbecken für Services aller Art. Zusätzlich zu den Services und deren Servicevertrag, hält das Service Repository Informationen zu den einzelnen Services bereit, die vom Servicevertrag nicht unterstützt werden - wie zum Beispiel Zugriffsrechte, Leistung und Skalierbarkeit (vgl. [KBS07, Seite 80]). Ohne eine solche zentrale Stelle, die alle Services kennt, ist es nicht möglich, Services dynamisch zur Laufzeit einzubinden. Enterprise Service Bus Das letzte Glied in der Kette einer serviceorientierten Architektur ist der Enterprise Service-Bus, auch ESB abgekürzt, welcher die Vernetzung der einzelnen Services, des Anwendungsfrontends und des Services Repositories herstellt. Da die Services in unterschiedlichsten Sprachen implementiert sein können, muss der Service-Bus sowohl eine sehr hohe Heterogenität gegenüber den verwendeten Technologien als auch gegenüber den verwendeten Kommunikationsprotokollen aufweisen (vgl. [KBS07, Seite 174 ff]). Ein Service Bus hat somit zum Ziel, 19

42 Kapitel 2 Systemintegration in Unternehmen Punkt-zu-Punkt Verbindungen zwischen verschiedenen Systemen durch einen einheitliche Plattform zu ersetzten. Ein ESB kann jedoch nicht als eine Komponente betrachtet werden, er besteht vielmehr aus einer Reihe von ESB Services, die nachrichtenorientiert miteinander vernetzt sind. Dies hat im Vergleich zu EAI Plattformen den Vorteil, dass es keinen Single Point Of Failure gibt und die Verfügbarkeit und Skalierbarkeit gewährleistet wird (vgl. [NFNH06, Seite 33]). Die Kommunikation zwischen Service, Benutzer und Registry wird in einer Enterprise SOA vollständig über den Service Bus abgewickelt. Das magische SOA-Dreieck wird somit um diese Komponente erweitert. Die im vorangegangenem Kapitel vorgestellt Nutzung eines Services verändert sich in einer Enterprise SOA wie in Abbildung 2.9 dargestellt, da es keine direkte Kommunikation zwischen den einzelnen Komponenten mehr gibt. Servicenutzer Service Serviceregistry Abbildung 2.9: Nutzung eines Services in einer ESOA mit Service Bus nach [WCL + 05] um Die Vorteile einer serviceorientierten Architektur liegen auf der Hand. Der modulare Aufbau ermöglicht die gewünschte Flexibilität und somit die notwendige Schnelligkeit, um Änderungen umzusetzen. Die Lücke zwischen IT Systemen und Geschäftsprozessen wird durch die enge Kopplung geschlossen. Des Weiteren ist es durch die Abstraktion der Zwischenschicht möglich, bestehende Systeme und Best-of-Bread Komponenten in eine solche Architektur zu integrieren (vgl. [Buc05]). 20

43 2.3 Serviceorientierte Architekturen Es bleibt allerdings auch festzustellen, dass man [...] den Schalter nicht einfach auf SOA umstellen [...] kann [Wac07]. Bestehende IT Landschaft sind häufig über Jahre gewachsen und beinhalten oft Millionen Zeilen Code, was das ganze Vorgehen erschwert. Hier sind sowohl Erfahrung als auch konkrete Vorgehensmodelle gefragt, die bei der Bewältigung einer solchen Umstellung helfen können. 21

44 Kapitel 2 Systemintegration in Unternehmen 22

45 Kapitel 3 Workflows Suum cuique per me uti atque frui licet. Marcus Porcius Cato Censorius In jedem Unternehmen fallen tagtäglich eine Unmenge von sich wiederholenden Aufgaben an. Die manuelle Ausführung dieser Aufgaben ist oft ineffizient und verschlingt unnötig viel Zeit. Eine Automatisierung dieser Vorgänge mit dem Ziel der Beschleunigung und Qualitätssicherung ist somit wünschenswert. Workflows realisieren genau diesen Wunsch nach Automatisierung im Bereich der Softwaretechnologie. In dem folgenden Kapitel werden zunächst die Grundlagen von Workflows und Geschäftsprozessen geklärt und anschließend ein Klassifikation von Workflows aufgezeigt. Danach werden verschiedene Technologien zur Realisierung solcher Workflows aus dem SAP NetWeaver Umfeld vorgestellt und deren Einsatzgebiete und Möglichkeiten dargelegt. 3.1 Begriffsdefinition Die Workflow Management Coalition, WfMC abgekürzt, definiert einen Workflow als: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. [All01] 23

46 Kapitel 3 Workflows Demzufolge ist ein Workflow eine möglichst detaillierte Arbeitsanweisung mit dem Ziel der Automatisierung der darin enthaltenen Arbeitsschritte. Innerhalb eines Workflows werden [...] Informationen oder auch Dokumente unter Berücksichtigung von Regeln oder definierten Verfahren von einer zuständigen Stelle zur nächsten weitergereicht [Kam05]. Typische Szenarien eines Workflows sind das Zuweisen einer Aufgabe an einen bestimmten Bearbeiter, die Statusüberprüfung von Aufgaben oder das Einholen von Genehmigungen. Ziel dabei ist es, die Prozesse zu beschleunigen, nachvollziehbar und wiederholbar zu gestalten, um damit verbunden die Qualität der Bearbeitung zu steigern (vgl. [Dar01]) Bestandteile Workflows bestehen im Wesentlich aus den drei Komponenten Aktivität, organisatorische Einheit und Informationsobjekt. Die Aktivität spiegelt den Arbeitsschritt wider, der durch den Workflow realisiert wird. Als organisatorische Einheit werden Personen oder Systeme bezeichnet, die an der Bearbeitung von Aufgaben beteiligt sind. Das Dokument oder die Daten, die während der Bearbeitung anfallen, werden unter dem Begriff der Informationsobjekte zusammengefasst (vgl. [COI03]). Zusätzlich zu diesen drei Kernkomponenten können optional auch Regeln, oft auch als Business Rules bezeichnet, zur Ablaufsteuerung festgelegt werden, anhand welcher die Bearbeitung des Workflows beeinflusst wird. Business Rules finden häufig Verwendung, wenn Werte aus dem Workflow gegenüber schnelllebigen Konstanten geprüft werden. Ein einfaches Beispiel hierfür ist die Entscheidung der Kreditwürdigkeit, welche sich an Einkommensgrenzen orientiert. Die Grenzen werden separat in Regeln festgehalten, auf welche der Workflow zugreifen kann. Dadurch erreicht man auf der einen Seite eine klare Trennung zwischen fachlicher Logik und Programmcode des Workflows, auf der anderen Seite muss der Workflow bei Änderungen der Grenzen nicht neu ausgeliefert werden (vgl. [Dun06]). 24

47 3.2 Klassifizierungen von Workflows Abgrenzung zu Geschäftsprozessen Die Begriffe Geschäftsprozess und Workflow werden häufig synonym gebraucht, und je nach Blickwinkel und Verwendung unterschiedlich definiert (vgl. [All05]). Für die Betrachtung automatisierter Systeme ist es jedoch sehr wichtig, diese Begriff klar voneinander abzugrenzen. Während ein Workflow eine detaillierte Beschreibung eines auszuführenden Arbeitsschrittes widerspiegelt, ist ein Geschäftsprozess eine allgemeinere, strategischere Sicht auf eine Abfolge betriebswirtschaftlicher Aufgaben (vgl. [Gad02]). Hierbei werden lediglich Eingabeinformationen, beteiligte Personen und gewünschte Resultate beschrieben. Wie dieses Resultat im Detail erzielt wird, bleibt jedoch im Verborgenen und muss mit Hilfe eines Workflows weiter spezifiziert werden. Abbildung 3.1 verdeutlicht diesen Zusammenhang zwischen Workflows und Geschäftsprozessen. Geschäftsprozess Sub- Prozess Sub- Prozess Sub- Prozess Aktivität Aktivität Aktivität Workflow Workflow Workflow Grenze zwischen Geschäftsprozess und Workflow Manuell Anwendungsgestützt Abbildung 3.1: Abgrenzung Geschäftsprozess und Workflow nach [Fre04] 3.2 Klassifizierungen von Workflows Da es sehr unterschiedliche Einsatzgebiete von Workflows gibt, hat es sich der besseren Übersicht wegen als vorteilhaft erwiesen, Workflows anhand ihrer Strukturiertheit und Prozessorientierung in verschiedene Kategorien einzuteilen. Die folgende Unterteilung in allgemeiner Workflow, fallbasierter Workflow und Ad-hoc-Workflow orientiert sich dabei an der Definition von Gadatsch in [Gad02]. Es bleibt allerdings festzu- 25

48 Kapitel 3 Workflows stellen, dass eine klare und detaillierte Abgrenzung von Workflows aufgrund der zunehmenden Vermischung kaum noch möglich ist und die Unterteilung nur das breite Anwendungsspektrum aufzeigt (vgl. [Kam03, Seite 31 ff]). Allgemeiner Workflow Ein allgemeiner Workflow weißt von den drei hier vorgestellten Kategorien die höchste Strukturiertheit auf und ist somit der Workflow im klassischen Sinne. Durch diese Art von Workflows unterstütze Prozesse sind höchst zeitkritisch und sehr repetitiv. Durch die hohe Anzahl von zu bearbeitenden Prozessen, ist hier eine hohe Performance und Transaktionsbasiertheit notwendig, wodurch diese Workflows auch als Produktionsworkflows oder Transaktionsworkflows bezeichnet werden (vgl. [All01]). Die Abläufe innerhalb eines allgemeinen Workflows sind sehr stark vordefiniert und lassen dem Bearbeiter wenige Freiheiten. Beispiele für solche Workflows sind Prozesse zur Schadensabwicklung in Versicherungen oder auch Bestellabwicklungen in Versandhäusern (vgl. [Hin05]). Fallbasierter Workflow Im Vergleich zu allgemeinen Workflows sind fallbasierte Workflows weit weniger strukturiert und weisen auch keine so starre Ablaufsteuerung auf. Hier hat der Bearbeiter demzufolge wesentlich mehr Freiheiten während der Bearbeitung. Fallbasierte Workflows sind im Allgemeinen nicht zeitkritisch und dienen in erster Linie der Ersetzung von bisher papierbasierten Abläufen, weswegen sie auch als administrative Workflows bezeichnet werden (vgl. [Kam03, Seite 33]). Auch wiederholen sich diese Workflows in der Regel weit weniger häufig als allgemeine Workflows. Beispiele für diese Art von Prozessen sind die Einstellung oder Entlassung eines Mitarbeiters und damit verbundene Abläufe (vgl. [Hin05]). Ad-hoc-Workflow Im Gegensatz zu allgemeinen und fallbasierten Workflows, welche sich bereits im Voraus planen und modellieren lassen, sind Ad-hoc-Workflows nicht strukturierbar und somit auch nicht modellierbar. Das Routing des Workflows wird erst zur Laufzeit durch den Benutzer festgelegt und lässt diesem somit sehr viele Freiheiten während der Bearbeitung (vgl. [Kam03, Seite 33]). Ad-hoc-Workflows zeichnen sich durch ihre Einzigartigkeit aus. Sicherheitsanforderungen oder Performance spielen hierbei in der Regel keine Rolle (vgl. [All01]). Aus diesem Grund 26

49 3.2 Klassifizierungen von Workflows werden Ad-hoc-Workflow auch als Low-Cost-Workflows bezeichnet. Beispiele für Ad-hoc-Workflows sind das Einholen von Genehmigungen, die Weiterleitung von Korrespondenzen oder das Review von Dokumenten, hierbei muss der Bearbeiter die gewünschte Zielperson selbst definieren (vgl. [Kam03, Seite 33]. Der Zusammenhang zwischen Performance, Flexibilität, Komplexität und Automatisierbarkeit der verschiedenen Workflowtypen wird anhand der folgenden Abbildung verdeutlicht. Es ist deutlich erkennbar, dass der Hauptnachteil allgemeiner Workflows die schlechte Flexibilität ist. Im Gegensatz dazu sind fallbasierte Workflows sehr gut modifizierbar, bieten jedoch weniger Möglichkeiten der Automatisierbarkeit. Die Gruppe der Ad-hoc-Workflows sind per Definition nicht für die Automatisierung geeignet, sondern werden von Fall zu Fall individuell erstellt. Allgemeiner Workflow Fallbasierter Workflow Wiederholfaktor Wiederholfaktor Modifizierbarkeit Komplexität Modifizierbarkeit Komplexität Automatische Verarbeitung Planbarkeit Automatische Verarbeitung Planbarkeit Ad-hoc-Workflow Wiederholfaktor Modifizierbarkeit Komplexität Automatische Verarbeitung Planbarkeit Abbildung 3.2: Gegenüberstellung der Workflowtypen. Allgemeiner (oben links), Fallbasierter (oben rechts) und Ad-hoc-Workflow (unten mitte) nach [COI03] 27

50 Kapitel 3 Workflows 3.3 Workflowtechnologien Anhand der im vorangegangenen Kapitel aufgezeigten Klassifikation von Workflows, werden nun die wichtigsten Workflowtechnologien innerhalb von SAP NetWeaver dargestellt und in diese Klassifikation eingeordnet. Dabei wird besonderer Wert auf die Technologien SAP Business Workflow, Guided Procedures und Business Process Management gelegt, da diese die größte Verbreitung aufweisen Application Link Enabling Die Integrationstechnologie Application Link Enabling (ALE) dient in erster Linie dem Nachrichtenaustausch zwischen verschiedenen SAP R/3 Systemen und der Synchronisation von Stammdaten in homogenen verteilten Systemen. ALE ist, seit Release 3.0, Bestandteil von SAP R/3 und gehört zu der Komponente Business Framework. In SAP NetWeaver ist ALE Bestandteil des NetWeaver Application Server ABAP. Die Kommunikation zum Synchronisieren der Daten erfolgt bei ALE asynchron, zum lesen der Daten nutzt ALE allerdings eine synchrone Kommunikation. Bei der Synchronisation der Daten, dargestellt in Abbildung 3.3, erzeugt ALE dabei zunächst ein Intermediate Document (IDoc), das als Container für die eigentlich Daten fungiert und mit zusätzlichen Informationen für das jeweilige Zielsystem angereichert wird. Dieses IDoc wird anschließend per Remote Function Call an das Zielsystem übermittelt. Dort angekommen wird es mittels ALE eingelesen und an die entsprechende Anwendung übertragen. Ein weiteres wichtiges Merkmal von ALE ist, dass die Datenintegration nicht über eine zentrale Datenbank erfolgt, sondern immer auf lokale Daten zugegriffen wird. Die Datenhaltung ist somit redundant (vgl. [SAP07j]). Aufgrund dieser redundanten Datenhaltung hat ALE allerdings den Nachteil, dass es hierbei unter Umständen zu inkonsistenten Daten kommen kann, wenn zwei Clients auf den selben Datensätzen arbeiten und diese synchronisieren wollen. Hier müsste eine Datenkonsolidierung stattfinden, dies ist aber in ALE nicht enthalten. Des Weiteren bietet ALE keine Möglichkeit zum Auffinden von Dubletten (vgl. [HK07, Seite38 ff]). Typische Anwendungsfelder für ALE sind die Stammdatenverwaltung und die Benutzerverwaltung. Allerdings ist ALE aufgrund der Redundanz nur für ein homogenes R/3 basiertes Stammdatenmanagement geeignet, nicht aber für heterogene oder ser- 28

51 3.3 Workflowtechnologien viceorientierte Architekturen. Für ein zentrales Stammdatenmanagement innerhalb einer serviceorientierten Architektur sind Master Data Management Ansätze besser geeignet. DB 1 ALE ERP 1 IDoc RFC ERP 2 IDoc DB 2 Abbildung 3.3: Application Link Enabling nach [HK07] 29

52 Kapitel 3 Workflows Master Data Management Workflow Dort wo ALE zur Stammdatenverwaltung nicht mehr ausreicht, nämlich in verteilten serviceorientierten Architekturen, kann das SAP Master Data Management eingesetzt werden. SAP Master Data Management (MDM) ist optionaler Bestandteil von NetWeaver und in der Komponente Information Integration angesiedelt. Dies hat den Vorteil das alle anderen, auf der NetWeaver Plattform aufbauenden Anwendungen, diese Stammdaten nutzen können. Im Gegensatz zu ALE bietet MDM Funktionen zur Datenkonsolidierung, Dublettenprüfung und zur Historisierung von Daten an (vgl. [HK07, Seite 80 ff]). Der MDM Workflow ist die zentrale Komponente im MDM Data Manager, um prozessbezogene Stammdaten zu pflegen und wird hauptsächlich bei Änderungen am zentralen Datenbestand eingesetzt. Er wird deswegen auch als Data Manager Workflow bezeichnet. Schwerpunkt hierbei liegt auf dem Auslösen von Ad-hoc-Workflows aus dem Data Manager und auf dem automatisierten Starten von Workflows bei Änderungen an Datensätzen (vgl. [HK07, Seite 303]. Dazu stellt der MDM Workflow eine Reihe von Funktionen zur Verfügung, die wichtigsten werden in der nachfolgenden Tabelle aufgezeigt. Funktion Symbol Beschreibung Process Verarbeitungsschritt innerhalb eines Workflows. Group Validate Gruppierung von mehreren Schritten. Führt eine Validierung durch. Approve Änderungen müssen von einem Benutzer genehmigt werden. Notify Schickt eine Nachricht mit den Stammdaten an einen definierten Empfänger. Branch Abhängig von einem Ereignis kann sich die Verarbeitung verzweigen. Merge Verschiedene Verarbeitungen können zu einem Zweig zusammengeführt werden. Connect Verbindet einen Schritt mit einem anderen Workflow. Match Führt ein Wertematching durch. Tabelle 3.1: Funktionen des MDM Workflows nach vgl. [SAP07m] 30

53 3.3 Workflowtechnologien Ein weiterer interessanter Punkt des MDM Workflows ist die grafische Modellierung mit Hilfe von Microsoft Visio, die in Abbildung 3.4 dargestellt ist. Dazu wird Microsoft Visio als Plug-in in den Data Manager integriert und vorgefertigte Bausteine werdem für die Modellierung bereitgestellt, die die oben genannten Funktionalitäten abdecken. Jeder dieser Bausteine bietet eine Reihe vorgefertigter Parameter an, mit denen das Verhalten des Workflows gesteuert werden kann. Es ist allerdings nicht möglich weitere Parameter hinzuzufügen oder komplett neue Bausteine zu entwerfen. Die Möglichkeiten des MDM Workflows sind somit auf die vorgefertigten Funktionen beschränkt. Das Routing des MDM Workflows basiert auf den Nutzern und Rollen, die im MDM Repository hinterlegt sind. Der Zugriff auf ein bereits existierendes Nutzerverzeichnis per LDAP oder ähnlich ist jedoch nicht möglich (vgl. [Lev06]). Abbildung 3.4: MDM Workflowmodellierung mit Hilfe von Microsoft Visio 31

54 Kapitel 3 Workflows Collaboration Tasks Mit dem Collaboration Task stellt SAP NetWeaver dem Anwender eine Möglichkeit zur Verfügung, schnell und ohne Programmierkenntnisse Ad-hoc-Workflows zu realisieren. Ziel der Collaboration Tasks ist es, die Zusammenarbeit zu fördern und die Geschwindigkeit der Bearbeitung zu erhöhen. Hauptanwendung der Collaboration Tasks ist demzufolge die Verteilung von Arbeit an andere Mitarbeiter, Forderung nach Feedback oder das Einholen von Informationen bei nicht geklärten Zuständigkeiten (vgl. [Ric05]). Die Modellierung von Collaboration Tasks im SAP NetWeaver Portal geschieht dabei entweder über die Universal Worklist oder über einen Collaboration Room. Der Anwender wird dabei in beiden Fällen von Assistenten durch einen Dialog geführt, wie in Abbildung 3.5 dargestellt. Für die Erstellung von Ad-hoc-Prozessen sind somit keinerlei Vorkenntnisse notwendig. Unabhängig davon, mit welcher Anwendung die Collaboration Tasks erstellt werden, gibt es die vier folgenden vorgefertigten Typen zur Auswahl (vgl. [Gat05]). Single Step Task Der wahrscheinlich am häufigsten genutzte Typ ist der Single Step Standardprozess, welcher generische Aufgaben darstellen kann. Hierbei kann der Benutzer selbst beschreiben, was genau zu tun ist und Mitarbeiter zu Aufgaben hinzufügen. Multi Step Task Der Typ Multi Step Task stellt eine Kombination mehrerer Einzelschritte dar. Der Typ der Einzelschritte kann dabei variieren. Request for Feedback Der vorgefertigte Typ Request for Feedback ermöglicht das schnelle Einholen von Meinungen anderer Mitarbeiter zu Fragestellungen und Problemen. Request for Nomination Wenn unklar ist, wer Aufgaben bearbeiten soll, kann der Typ Request for Nomination genutzt werden. Hiermit können Nachrichten mit Aufgabenbeschreibungen an alle potentiellen Mitarbeiter geschickt werden, welche die Aufgabe übernehmen oder einen anderen geeigneten Mitarbeiter vorschlagen können. 32

55 3.3 Workflowtechnologien Abbildung 3.5: Erstellung von Collaboration Tasks in der Universal Worklist nach [SAP06b], [Ric05] Der Vorteil des Collaboration Tasks gegenüber einer reinen -Kommunikation ist, dass alle daran beteiligten Mitarbeiter den Status der Bearbeitung einsehen können und es somit nicht zu redundanter Bearbeitung und Kommunikation führt. Des Weiteren sind die Zuständigkeiten klar definiert, Aufgaben werden sofort in die Inbox des entsprechenden Mitarbeiters eingetragen und von dort automatisch wieder entfernt, sobald die Bearbeitung erfolgreich abgeschlossen wurde. Darüber hinaus existiert die Möglichkeit, automatische Statusbenachrichtigungen (zum Beispiel bei Terminverzug) zu versenden (vgl. [Ric05]) SAP Business Workflow Der SAP Business Workflow ist der wohl am meist verbreitete Workflow in der SAP Landschaft. Er ist Bestandteil der SAP ABAP Infrastruktur und somit in allen großen SAP Produkten wie SAP R/3, SAP CRM, SAP EBP und SAP NetWeaver enthalten (vgl. [Lev06], [Dar01]). Viele dieser Produkte nutzen den SAP Business Workflow auch, um interne Prozesse zu automatisieren und stellen deswegen bereits viele vorgefertigte Workflows zur Verfügung, die nur noch auf die eigenen Bedürfnisse angepasst werden müssen (vgl. [SAP07t]). 33

56 Kapitel 3 Workflows In den verschiedenen Produkten ist der SAP Business Workflow jedoch teilweise eingeschränkt und auf die jeweiligen Bedürfnisse zurechtgeschnitten. So ist der Workflow zum Beispiel im SAP CRM auf Call-Center Mitarbeiter ausgerichtet und hat einen eigenen grafischen Editor mit eingeschränktem Funktionsumfang im Vergleich zum Workflow Builder (vgl. [BEZ04, Seite 275]). Komponenten Der SAP Business Workflow lässt sich zur Entwurfs- und Laufzeit in vier Bereiche unterteilen, wie in Abbildung 3.6 dargestellt ist. Der Business Workplace repräsentiert dabei die zentrale Anlaufstelle für den Benutzer, hier werden dem Benutzer Workitems angezeigt die er ausführen darf. Bevor der Workflow jedoch ausgeführt werden kann, bedarf es einer Workflowdefinition, welche im Workflow Builder erstellt wird. Bei Aktivierung dieser Workflowdefinition wird automatisch eine Laufzeitversion erstellt, mit welcher gearbeitet werden kann. Die im Workflow ausgeführten Schritte stellen entweder eine Referenz auf eine Aufgabe dar oder beeinflussen den Workflow direkt. Aufgaben beziehen sich immer auf Methoden von Business Objekten, welche im Business Object Repository hinterlegt sind (vgl.[sap07t]). Abbildung 3.6: Technische Grundlagen des SAP Business Workflow [SAP07t] 34

57 3.3 Workflowtechnologien Modellierung Zur Unterstützung der Modellierung steht dem SAP Business Workflow ein grafisches Modellierungswerkzeug namens Workflow Builder zur Seite. Dies ermöglicht die Darstellung der Workflowlogik als Flussdiagramm. Das Erstellen und Bearbeiten von Workflows geschieht per Drag&Drop, dazu bietet der Workflow Builder eine Reihe von vorgefertigten Workflowelementen an. Ein Übersicht über die zur Verfügung stehenden Workflowelemente wird in Tabelle 3.2 dargestellt. Neben der Workflowmodellierung stellt der Workflow Builder auch Funktionen zum Testen und zur Verwaltung von Workflows zur Verfügung. Unterscheidung zwischen SAP Workflow und SAP Webflow Der SAP WebFlow erweitert die Funktionalität des SAP Business Workflows um Möglichkeiten, Workflows über das Internet auszuführen. Hierfür kann zum Beispiel ein XML Dokument an ein anderes System per HTTP gesandt werden oder ein Workflow auf einem entfernten SAP System gestartet werden. Zusätzlich werden Funktionen zum Empfangen und Auswerten von XML Dokumenten zur Verfügung gestellt (vgl. [SAP07y]). Die SAP WebFlow Engine unterstützt zur Kommunikation mit Workflowmanagementsystemen anderer Anbieter das von der WfMC definierte Protokoll Wf-XML. In der Referenzarchitektur der WfMC (siehe Abbildung B.1) stellt Wf-XML eine Implementierung des Interface 4 dar. Wf-XML kann außerdem zur Erstellung systemübergreifender Wokflows genutzt werden (vgl. [RDS06, Seite 378 ff]). Da es allerdings in klassischen Prozessen zunehmend Schritte gibt, die über das Internet abgewickelt werden und ebenfalls auch reine E-Prozesse um lokale Schritte erweitert werden, ist die anfängliche Unterscheidung zwischen der SAP Webflow Engine und dem Vorgänger SAP Business Workflow inzwischen nicht mehr relevant. Die Bezeichnungen SAP Webflow Engine, meist nur SAP Webflow, und SAP Business Workflow werden deswegen synonym gebraucht. Deswegen wird im weiteren Verlauf der Arbeit nur noch von SAP Business Workflow gesprochen, auch wenn es sich dabei um Prozesse handelt, die über das Internet kommunizieren (vgl. [RDS06, Seite 31]). 35

58 Kapitel 3 Workflows Funktionen Eine Übersicht über die vorgefertigten Funktionen des SAP Business Workflows bietet nachfolgende Tabelle. Funktion Symbol Beschreibung Ablaufsteuerung Mit diesem Schritt kann die Ausführung abgebrochen werden und ein Alternativschritt ausgeführt werden. Ad-hoc-Anker Während der Laufzeit kann ein Benutzter an dieser Stelle entscheiden, welcher der hinterlegten Workflows anstelle des Ankers ausgeführt wird. Aktivität Ausführung einer konkreten Aufgabe oder eines Sub- Workflows. Bedingung Entspricht einer If-Than-Else Abfrage; je nach Bedingung werden unterschiedliche Zweige durchlaufen. Benutzerentscheidung Ein Benutzer entscheidet zur Laufzeit anhand vorgegebener Möglichkeiten die weitere Verarbeitung. Containeroperation Wertzuweisungen oder Rechenoperationen für Workflow- Containerelemente unter Anwendung von Konstanten und Daten im Workflow-Container. Dokument aus Vorlage Erzeugung eines Dokumentes anhand einer gewählten Vorlage. Ereigniserzeuger Ein Ereignis wird auf Basis der Daten im Workflow erzeugt. Formular versenden Mehrfachbedingung Paralleler Abschnitt Anhand der Daten im Workflow wird ein Formular angezeigt, bearbeitet oder genehmigt. Vorher definierte Benutzer werden per benachrichtigt. Abhängig der Werte im Workflow werden ein oder mehrere Zweige durchlaufen. Startet die parallele Verarbeitung von Zweigen. UNTIL-Schleife Die Schrittfolge wird bis zur Abbruchbedingung mindestens jedoch einmal durchlaufen. WHILE-Schleife Die Schrittfolge wird solange durchlaufen wie die Bedingung wahr ist. Warten auf Ereignis Workflow stoppt die Bearbeitung bis ein bestimmtes Ereignis eingetreten ist. Web Aktivität Sendet ausgewählte Elemente als XML- oder SOAP- Nachricht per HTTP. Tabelle 3.2: Funktionen des SAP Business Workflows nach [SAP07z] 36

59 3.3 Workflowtechnologien Guided Procedures Guided Procedures sind im Vergleich zu etablierten Workflowtechnologien, wie zum Beispiel dem SAP Business Workflow, noch relativ neu. Diese sind Bestandteil des Composite Application Framework und somit in allen Komponenten von NetWeaver verfügbar. Guided Procedures bieten dem Benutzer ein Framework für die Modellierung von leichtgewichtigen, kollaborativen Geschäftsprozessen über Systemgrenzen hinweg an. Innerhalb von Composite Applications stellen sie somit die Verbindung zwischen der Benutzeroberfläche auf der einen Seite und den Serviceaufrufen auf der anderen Seite dar (vgl. [RS07, Seite 99]). Typische Anwendungsfälle für Guided Procedures sind Prozesse, die abteilungsspezifisch angepasst werden müssen und anschließend in unternehmensweite Prozesse integriert werden. Des Weiteren können Guided Procedures dafür verwendet werden, innerhalb eines Prozesse auf verschiedene SAP oder Nicht-SAP Systeme zuzugreifen (vgl. [BPX07]). Ziel der Guided Procedures ist die einfache und schnelle Entwicklung von Prozessen auch ohne Programmierkenntnisse. Komponenten Guided Procedures unterscheiden zwischen den folgenden fünf Komponenten: Guided Procedures Design Time Die Guided Procedures Design Time stellt die Modellierungsumgebung für Anwender und Entwickler zur Verfügung. Hier wird die Vorlage für den Prozess modelliert. Guided Procedures Runtime Während der Design Time modellierte Prozesse werden zur Laufzeit instanziiert und können anschließend gestartet werden. Zur Laufzeit können Benutzer dem Prozess zugeordnet werden und Aufgaben erfüllen. Guided Procedures Administration and Monitoring Zur Verwaltung, Konfiguration und Überwachung von Guided Procedures stellt das CAF verschiedene Tools bereit. 37

60 Kapitel 3 Workflows Interactive Form Integration Eine Möglichkeit bisher papierbasierte Prozesse abzulösen bietet die Integration von Adobe Forms. Collaboration and Ad-hoc Items Guided Procedures unterstützen die Kollaboration durch rollenbasierten Zugriff auf Ressourcen und Aufgaben. Modellierung Die Modellierung von Guided Procedures erfolgt dialoggestützt mit Hilfe von zahlreichen Assistenten innerhalb des SAP NetWeaver Portals, siehe Abbildung B.4. Dies ermöglicht auch Endnutzern ohne Programmierkenntnisse Workflows zu erstellen und neue Composite Applications zu orchestrieren. Die Entwicklungsobjekte der Design Time unterteilt Guided Procedures in die vier Komponenten Process, Block, Action und Callable Object, nachfolgende Abbildung verdeutlicht deren Zusammenhang. Alle Komponenten werden in der Guided Procedures Gallery abgelegt und verwaltet, dadurch soll eine bessere Strukturierung und erhöhte Wiederverwendbarkeit erreicht werden. Abbildung 3.7: Guided Procedures Komponenten der Design Time [RS07] 38

61 3.3 Workflowtechnologien Process Der Prozess bildet die äußere Hülle des Workflows und enthält verschiedene Blöcke. Er repräsentiert somit den gesamten Geschäftsprozess. Block Ein Block stellt eine Gruppierung von logisch zusammenhängenden Aktionen dar und dient dazu, wiederverwendbare Teilprozesse zusammenzufassen. Er kann beliebig viele Aktionen oder auch Blöcke selbst enthalten. Blöcke in Guided Procedures können entweder von Typ sequentiell, parallel, dynamisch parallel, alternativ oder Precondition/Postcondition Loop sein. Actions Aktionen stellen einzelne, ausführbare Arbeitsschritte innerhalb eines Prozesses dar. Jede Aktion muss dabei mindestens aus einem Callable Object for Execution bestehen, kann aber zusätzlich noch ein Callable Object for Display enthalten. Callable Objects Die eigentliche Implementierung der einzelnen Arbeitsschritte wird allerdings nicht durch Aktionen sondern durch Callable Objects realisiert. Dabei wird zwischen Callable Objects for Display, welche die Benutzeroberfläche widerspiegeln, und Callable Objects for Execution, welche den Serviceaufruf darstellen, unterschieden. Diese Trennung zwischen Aktionen und Callable Objects mag auf den ersten Blick seltsam erscheinen, erlaubt allerdings die getrennte Modellierung durch Businessanalyst und Entwickler. Der Businessanalyst übernimmt die grobe Realisierung bis zur Aktionsebene, die konkrete Implementierung wird anschließend vom Entwickler durchgeführt [KLG07]. SAP NetWeaver stellt bereits eine Vielzahl von ready-to-use Callable Objects zur Verfügung, die die gängisten Business Szenarien abdecken sollten. Eine detaillierte Übersicht dieser findet sich unter [SAP07q]. Es besteht allerdings auch die Möglichkeit, eigene Callable Objects zu entwickeln. Somit lässt sich mit Hilfe von Guided Procedures beliebige Anwendungslogik umsetzen. 39

62 Kapitel 3 Workflows Business Process Management Die neben dem SAP Business Workflow und den Guided Procedures meist verbreitete Workflowtechnologie ist das Business Process Management, welches Teil der SAP Process Integration ist. Im Gegensatz zu Guided Procedures und dem SAP Business Workflow unterstützt das Business Process Management, kurz BPM oder auch ccbpm, die zustandsbehaftete Verarbeitung von Nachrichten. Dadurch ist BPM besonders für langlaufende Workflows geeignet, da der Zustand eines Prozesses auf dem Integration Server persistiert wird. Auch ist es dadurch möglich, termingesteuerte Ereignisse, wie das Warten auf den Empfang weiterer Nachrichten, auszulösen (vgl. [NFNH06, Seite 193 ff], [SAP07l]). Im Kontext des Business Process Management wird zwischen anwendungsübergreifenden Integrationsprozessen und eingebetteten Prozessen unterschieden (vgl. [SAP07l]). Anwendungsübergreifende Integrationsprozesse stellen Prozesse dar, welche über mehrere Systeme hinweg ablaufen. Diese weisen demzufolge meist eine sehr hohe Komplexität auf. Im Gegensatz dazu sind eingebettete Prozesse einfache, nur ein System betreffende Prozesse und somit analog zu dem SAP Business Workflow. Beide interagieren aber sehr stark miteinander, so kann zum Beispiel ein Integrationsprozess Nachrichten an einen Workflow senden oder umgekehrt Nachrichten von einem Workflow empfangen und verarbeiten (dargestellt in Abbildung 3.8). Abbildung 3.8: Zusammenhang von UWL, ccbpm und SAP Business Workflow [HV07] 40

63 3.3 Workflowtechnologien Typische Anwendungsfälle für Integrationsprozesse sind das Sammeln von Nachrichten eines oder mehrerer Interfaces und die Bündelung dieser, beispielsweise wenn mehrere Positionen einer Bestellung zusammengefasst werden sollen. Oder auch die synchrone/asynchrone Kommunikation zwischen verschiedenen Systemen, wofür ein entsprechender Adapter bereitgestellt wird. Da die Business Process Engine ausschließlich über Nachrichten mit Anwendungen auf Backend-Systemen kommuniziert, existiert im Business Process Management keine Möglichkeit Benutzerinteraktionen abzubilden. Hierfür können aber SAP Business Workflows auf dem Backend-System eingebunden werden. Auch werden Prozesse innerhalb von Anwendungen nicht direkt von der Business Process Engine gesteuert, diese können jedoch in systemübergreifende Prozesse eingebettet werden (vgl. [SAP07l]). Die Business Process Engine unterstützt die Geschäftsprozessbeschreibungssprache Business Process Execution Language for Web Services 1.1 (BPEL), wodurch Integrationsprozesse aus anderen Anwendungen importiert und per Process Integration ausgeführt werden können. Umgekehrt ist auch der der BPEL-Export von Integrationsprozessen möglich. Komponenten Wie bereits von den Guided Procedures bekannt, wird auch im Business Process Management zwischen den Komponenten der Design Time, Configuration Time und Runtime unterschieden - dargestellt in Abbildung C.1. Design Time Für die Definition eines Integrationsprozesses zur Design Time steht mit dem Integration Builder im Integration Repository ein grafischer Editor zur Verfügung. Configuration Time Zur Konfigurations-Zeit wird im Integration Directory für den Integrationsprozess ein konkretes Routing konfiguriert. Runtime Zur Laufzeit führt die Business Process Engine, welche Bestandteil des Integration Servers ist, Integrationsprozesse aus. Dafür werden die modellierten Integrationsprozesse in ausführbare Workflows transformiert. Die Ausführung von Inte- 41

64 Kapitel 3 Workflows grationsprozessen können mittels des Monitorings der Integration Engine überwacht werden [SAP07l]. Modellierung Die grafische Modellierung von Integrationsprozessen wird durch den Integration Builder unterstützt, welcher die Funktionen aus Tabelle 3.3 abdeckt. Unabhängig von der konkreten Anwendungslandschaft können hier Design-Objekte angelegt werden, welche im Integration Repository gespeichert werden. Neben der grafischen Modellierung ist der Integration Builder auch für das Nachrichtenund Interfacemapping zuständig. Der Integration Builder unterstützt dabei neben einem komfortablen grafischen Mapping auch Java, XSLT und ABAP Mappings. Abbildung 3.9: Grafische Modellierung eines ccbpm im Integration Builder Funktionen Das BPM von NetWeaver stellt diverse Funktionen zur Transformation von Nachrichten und zur Automatisierung komplexer systemübergreifender Prozesse zur Verfü- 42

65 3.4 Vergleich der Workflowtechnologien gung - unter Berücksichtigung der semantischen Beziehungen zwischen den Nachrichten (vgl. [SAP07l]). Die wichtigsten Funktionen werden in nachfolgender Tabelle aufgezeigt. Funktion Symbol Beschreibung Receive Mit diesem Schritt wird ein Integrationsprozess gestartet und eine Nachricht wird entgegengenommen. Send Zum synchronen und asynchronen senden von Nachrichten aus dem Integrationsprozess beziehungsweise zur automatischen Bestätigung von Nachrichten (Acknowledgment). Transformation Die Transformation dient der Nachrichtenkonvertierung. Es werden 1:1, 1:n und n:1 Transformationen unterstützt. Receiver Determinatiodeschritt. Ermittelt einer Empfängerliste für den nachfolgenden Sen- Block Gruppierung von mehreren, hintereinander folgenden Schritten, um auf dieselben lokalen Daten zugreifen zu können. Loop Ähnlich einer While-Schleife, die Schleife wird solange durchlaufen bis die Abbruchbedingung eintritt. Fork Startet die parallele Verarbeitung von Zweigen. Switch Control Container Operation Wait Abhängig von der definierten Bedingung wird die Verarbeitung im jeweiligen Zweig weitergeführt. Mit einem Steuerungsschritt können Prozesse abgebrochen werden, Ausnahmen ausgelöst oder Fehler gesendet werden. Container werden verwendet wenn zur Laufzeit Werte festgelegt werden müssen. Verzögert den Prozessschritt, um eine definierte Zeitspanne oder bis zum Eintreten eines Ereignisses. Tabelle 3.3: Prozessschritte des ccbpm nach [VYS + 04], [SAP07f] 3.4 Vergleich der Workflowtechnologien Nachdem nun alle Workflowtechnologien vorgestellt wurden, folgt ein Vergleich dieser. Dazu werden die technischen Eigenschaften in Tabelle 3.4 gegenübergestellt. 43

66 Kapitel 3 Workflows Application Link Enabling MDM Workflow Collaboration Task SAP Business Workflow Guided Procedures Business Process Management Bestandteil von SAP Business Framework SAP Master Data Management SAP NetWeaver SAP ABAP Infrastruktur SAP NetWeaver SAP NetWeaver PI BPM Workflowart Allgemeiner Workflow Allgemeiner - Fallbasierter Workflow Ad-hoc-Workflow Allgemeiner - Fallbasierter Workflow Allgemeiner - Fallbasierter Workflow Allgemeiner Workflow Modellierung keine grafische Modellierung Grafische Modellierung mittels Microsoft Visio Dialoggesteuert im Portal Grafische Modellierung mittels Workflow Builder Dialoggesteuert im Portal Grafische Modellierung mittels SAP PI BPM Engine SAP Business Framework MDM Workflow Engine SAP NetWeaver Portal SAP Webflow Engine NetWeaver AS ABAP oder AS Java SAP Webflow Engine Human Interactions nein ja ja ja ja nein Zielgruppe Entwickler Business Analyst Endnutzer Business Analyst, Entwickler Endnutzer, Business Analyst Business Analyst, Entwickler Tabelle 3.4: Vergleich der Workflowtechnologien (vgl. [HH07], [Gat08]) 44

67 3.4 Vergleich der Workflowtechnologien Untersucht man die verschiedenen Workflowtechnologien auf die Abdeckung der in Kapitel 2.1 vorgestellten Referenzarchitektur stellt man fest, dass sowohl der SAP Business Workflow, Guided Procedures als auch Business Process Management diese fast vollständig implementieren, dargestellt in Tabelle 3.5. Application MDM Collaboration SAP Busi- Guided Business Link Enab- Workflow Task ness Work- Procedu- Process ling flow res Management Repository Kommunikation Transformation Prozesssteuerung Sicherheit Workflow Laufzeitmanagement Tabelle 3.5: Vergleich der Workflows anhand der vorgestellten Referenzarchitektur Anhand dieser beiden Gegenüberstellung wird leicht ersichtlich, dass sich vorallem die drei großen Workflowtechnologien - SAP Business Workflow, Guided Procedures und das Business Process Management - realtiv ähnlich sind, jedoch für verschiedene Zielgruppen gedacht sind. Welche dieser Technologien allerdings nun am besten für die Realisierung von anwendungsübergreifenden Geschäftsprozessen geeignet ist, lässt sich allein anhand dieser technischen Details nicht klären und wird im Folgenden untersucht. 45

68 Kapitel 3 Workflows 46

69 Kapitel 4 SAP NetWeaver Ex nihilo nihil fit. Aristoteles Die SAP AG bietet für die Realisierung einer unternehmensweiten serviceorientierten Architektur die NetWeaver Plattform als technische Grundlage an und unterstützt damit die ganzheitliche Implementierung betriebswirtschaftlicher Anforderungen (vgl. [NKK07, Seite 42]). SAP NetWeaver übertragt somit das Prinzip der Plattform, welches im Automobilbau seit jeher zur Erhöhung der Wiederverwendbarkeit genutzt wird, auf die Softwareentwicklung (vgl. [HK07, Seite 68]). Ziel dieser Anwendungs- und Integrationsplattform ist es, eine unternehmensweite Modellierung, Planung und Steuerung von Geschäftsprozessen anzubieten und die Integration von bestehender Software in diese Prozesse zu verwirklichen. Durch das sogenannte Shared Collaboration Knowledge soll außerdem die Wiederverwendbarkeit von Informationen und Services erhöht werden, indem diese an zentraler Stelle gespeichert und somit Entwicklungs- und Änderungsaufwand reduziert werden. 4.1 Architektur von SAP NetWeaver Der Aufbau der SAP NetWeaver Plattform kann komponentenzentrisch betrachtet werden und ist in sechs Module unterteilt (vgl. [Spa05]). Diese komponentenzentrische Betrachtung wird aufgrund ihres Aufbaus häufig auch als Kühlschrank bezeichnet, da sich Anwendungen frei aus dem Funktionsumfang der Komponenten bedienen kön- 47

70 Kapitel 4 SAP NetWeaver nen. Der SAP NetWeaver Stack ist in Abbildung 4.1 dargestellt, die einzelnen Module daraus werden im Folgenden kurz vorgestellt. Application Plattform Die Grundlage für die darauf aufsetzenden Produkte bildet der NetWeaver Application Server ABAP und der NetWeaver Application Server Java. Diese stellen Basisfunktionalitäten wie Datenaustausch, Monitoring und Benutzermanagement für andere Anwendungen zur Verfügung. Entsprechend der verwendeten Programmiersprache wird der zugehörige Application Server verwendet (vgl. [SAP07d]. Process Integration Die Komponente der Prozessintegration lässt sich in das Business Process Management (BPM) und den Integration Broker unterteilen. Der Integration Broker ist hierbei für die Konvertierung und Zustellung der verschiedenen Nachrichtenformate zuständig und übernimmt demzufolge die Aufgabe eines Services Bus. Ferner werden grundlegende Funktionen des Sicherheitsmanagements, Monitorings und Loggings bei der Kommunikation zwischen Services mit Schnittstellen zur Verfügung gestellt (vgl. [SAP07s]). Das Business Process Management unterstützt die Modellierung und Automatisierung von Geschäfts- und Integrationsprozessen über Systemgrenzen hinweg (vgl. [SAP07l]). Information Integration Der Bereich der Informationsintegration umfasst die Funktionen Master Data Management, Knowledge Management und Business Intelligence. Das Modul SAP NetWeaver Master Data Management stellt Funktionen für die zentrale Stammdatenverwaltung zur Verfügung, um Informationen konsistent und redundanzfrei zu speichern. Die Analyse von strukturierten Datenbeständen erfolgt mit Hilfe des Moduls Business Intelligence, während die Organisation von unstrukturierten Daten im Modul Knowledge Management stattfindet und vom SAP Net- Weaver Portal übernommen wird (vgl. [SAP07k]). 48

71 4.1 Architektur von SAP NetWeaver People Integration In dem Bereich der Anwenderintegration stellt der SAP NetWeaver-Stack drei verschiedene Module zur Verfügung, den Multi-Channel Access, das Portal und Funktionen zur Kollaboration. Die Integration mobiler Endgeräte, wie PDAs oder Laptops, übernimmt dabei der Multi-Channel Access. Unter dem Begriff der Kollaboration fasst SAP NetWeaver Funktionen wie , Terminkalender und Messaging zusammen (vgl. [SAP07p]). Das wichtigste Modul in diesem Teil des SAP NetWeaver Stacks ist jedoch das SAP NetWeaver Portal, welches die Implementierung eines Unternehmensportales als webbasiertes Frontend darstellt. Der Zugriff auf Daten und Funktionen kann über das Portal gesteuert werden und ist somit die zentrale Komponente im NetWeaver Stack, mit welcher der Benutzer in Berührung kommt (vgl. [BH07]. Life-Cycle-Management Das Modul Life-Cycle-Management, welches sich über den kompletten NetWeaver Stack erstreckt, stellt unterstützende Funktionen zur Verfügung um den Lebenszyklus von Anwendungen zu begleiten (vgl. [SAP07v]). Die Realisierung dieser Funktionen erfolgt dabei mit Hilfe diverser SAP Technologien, wobei der SAP Solution Manager die bedeutendste ist (vgl. [BH07, Seite 46]). Composite Application Framework Die letzte Komponente des NetWeaver Stacks stellt das Composite Application Framework (CAF) dar, welches einen Rahmen zur modellgetriebenen Anwendungsentwicklung bereitstellt. Zur Unterstützung des Entwicklers stellt das CAF eine Reihe von Entwicklungswerkzeugen zur Modellierung von Prozessen, grafischen Benutzeroberflächen und Services zur Verfügung. Das CAF besteht dabei aus zwei Teilen, dem CAF Core und dem CAF Guided Procedures. CAF Core zielt auf die Entwicklung von Anwendungen, welche sich über die vier Integrationsebenen des NetWeaver Stacks erstrecken, ab. CAF Guided Procedures beschränken sich hingegen auf die Modellierung und Ausführung von Geschäftsprozessen (vgl. [BH07, Seite 449 ff], [SAP07h]). Betrachtet man die Komponenten der ESOA Architektur (siehe Kapitel 2.3.3) und deren Umsetzung in Netweaver stellt man fest, dass das NetWeaver Portal die Funktionali- 49

72 Kapitel 4 SAP NetWeaver tät des Anwendungs-Frontends übernimmt, als Service Repository kann der SAP Web Application Server genutzt werden und die Vernetzung und den Austausch zwischen den Services übernimmt die NetWeaver Process Integration. SAP NetWeaver SAP NetWeaver People Integration Portal Collaboration People Integration SAP NetWeaver Portal SAP NetWeaver Portal Mult-Channel Access Mobile Infrastructure Composite Application Framework Information Integration Business Intelligence Knowledge Management Master Data Management Process Integration Integration Broker Business Process Management Life-Cycle-Management Composite Application Framework Information Integration SAP Business Intelligence SAP NetWeaver Portal SAP Master Data Management Process Integration SAP Exchange Infrastructure SAP Exchange Infrastructure Life-Cycle-Management Applicationplatform J2EE ABAP Applicationplatform SAP NetWeaver AS ABAP SAP NetWeaver AS Java DB and OS Abstraction SAP NetWeaver Application Server Abbildung 4.1: SAP NetWeaver Stack, Komponentenansicht (links) und dazugehörge Produktansicht (rechts) nach [BH07] 4.2 Anwendungen Im Nachfolgenden werden die aus Sicht der Prozesssteuerung und -modellierung wichtigsten Produkte aus dem SAP NetWeaver Stack erläutert Exchange Infrastructure Die Exchange Infrastructure innerhalb der SAP Process Integration, häufig auch als XI abgekürzt, ist die zentrale Komponente bei der Integration von Anwendungen und Systemen. Dabei setzt sich die XI aus den Integration Broker, welcher für die Anbindung von heterogenen Anwendungen zuständig ist, und dem Business Process Management zusammen, welcher für die Kommunikation der Komponenten verantwortlich ist. 50

73 4.2 Anwendungen Die Hauptaufgabe der Exchange Infrastructure besteht im Wesentlichen darin, Nachrichten zu transformieren und an den oder die Empfänger weiterzuleiten. Dies erscheint im ersten Moment trivial. Unter Berücksichtigung der Tatsache, dass eine Vielzahl von unterschiedlichen Protokollen zur Abbildung von Nachrichten existiert, stellt man jedoch schnell fest, dass es sich hierbei um einen komplexen Prozess handelt (vgl. [NFNH06, Seite 58]). Der Nachrichtenfluss im Integrationserver ist in Abbildung C.2 dargestellt und veranschautlich die Zusammenarbeit der Integration Engine und der Business Process Engine. Die Integration Engine empfängt die Nachricht über das XI Message Protokoll und ermittelt den zugehörigen Empfänger aus dem Integration Directory (vgl. [SAP07u]). Falls die Nachrichten in einem anderem Format zugestellt werden sollen, findet ein Nachrichtenmapping statt. Sollte es sich bei den Empfänger um einen Integrationsprozess handeln, wird die Nachricht an die Business Process Engine weitergeleitet, andernfalls wird sie an den Empfänger zugestellt (vgl. [SO05, Seite 212 ff.]). Im Hinblick auf die in Kapitel 2.1 vorgestellte Referenzarchitektur kann man feststellen, dass die XI diese vollständig abdeckt (siehe Abbildung 4.2). Die Komponenten Prozesssteuerung, Workflowmanagement, Sicherheit und Kommunikation werden vom Integration Server übernommen, die Transformation zusätzlich von der Adapter Engine. Das Laufzeitmanagement wird durch die Central Monitoring Komponente realisiert. Online Dienste Offline Dienste Laufzeitmanagement Sicherheit Workflow-Management Repository Entwicklung Monitoring Identifizierung& Authentifizierung Postkorb Dialog- Einsprung Organisations- Repositiory Prozessmodellierung Prozess-Steuerung Integration Repository Ausfallsicherheit Zugriffsschutz Business Activity Integration Monitoring Server Transaktionen & Rollback Integration Prozess- Repository Repository Transformationsmodellierung Central Monitoring Transformation Lastverteilung Fachliche Transformation Ereignisverwaltung Prozess Engine Service- Repository Adapter- NWDS Entwicklung Kommunikation Fehlerbehandlung Adapter Technische Transformation Engine Adressierung Integration Server Lieferung Protokollierung Integration Konfigurationsmanagement Directory Anwendungslandschaft Abbildung 4.2: Abdeckung der Referenzarchitektur durch die XI nach [sdm07] 51

74 Kapitel 4 SAP NetWeaver Portal Die zentrale Benutzerschnittstelle bei der Anwendungsintegration ist das SAP NetWeaver Portal. Hierüber wird eine einheitliche grafische Oberfläche angeboten, welche alle angeschlossenen Anwendungen steuert und aufruft. Das Portal kann dabei für Benutzer oder Benutzergruppen personalisiert und somit an die jeweiligen Bedürfnisse angepasst werden. Dafür werden den Benutzern Rollen zugeordnet, anhand derer die Anforderungen definiert werden. Weitere optionale Bestandteile des Portals sind Funktionen zum Knowledge Management, Collaboration und die Universal Worklist. Der Funktionsumfang des Portals erstreckt sich demzufolge über die NetWeaver-Komponenten People Integration und Information Integration (vgl. [Spa05]). Zur Unterstützung der Anwendungsintegration bietet das SAP NetWeaver Portal eine Single Sign-On Funktion an. Diese übernimmt nach erfolgreicher Anmeldung im Portal automatisch die weiteren erforderlichen Anmeldungen der angeschlossenen Anwendungen (siehe Abbildung 4.3). Single Sign-On kann dabei über SAP Logon Tickets, JAAS, SAML oder über die Weitergabe von Benutzername und Passwort realisiert werden, mehr Informationen dazu findet sich in [NKK07] und [Rae08]. Vertriebsleiter Angestellter Entwickler Authentifizierung SAP NetWeaver Portal Single Sign-On SAP ERP Collaboration Knowledge Management Abbildung 4.3: SAP NetWeaver Portal Single Sign-On nach [Rae08] Composite Application Framework Das Composite Application Framework (CAF) ist neben dem Life-Cycle-Management die zweite Querschnittsfunktion im SAP NetWeaver Stack und stellt einen Rahmen zur Anwendungsentwicklung auf Basis von serviceorientierten Architekturen bereit. Dafür bietet es eine Reihe von Design-Werkzeuge, Services und Prozesse an, um so genannte 52

75 4.2 Anwendungen Composite Applications zu entwickeln und zu steuern. Composite Application sind Zusammenstellungen von Services und dienen der Entkopplung der Prozesslogik und der darunterliegenden Anwendungen. Dadurch ist es möglich, neue Anwendungen zu entwickeln, die auf bestehenden heterogenen Anwendungen aufsetzen können. Das CAF gliedert sich in die zwei Komponenten Core Layer und Process Layer. Der Core Layer stellt Funktionen zur Entwicklung von Composite Applications zur Verfügung. Wichtige Funktionen sind hierbei vor allem der Zugriff auf bestehende SAP Dienste wie Benutzermanagement, Kollaboration und Logging. Des Weiteren sichert der Core Layer die Persistenz von Informationen. Der Core Layer basiert zur Zeit noch auf Java Session Beans, soll aber zukünftig auf EJB 3.0 aufsetzen (vgl. [Wil06]). Der zweite Bestandteil des CAF ist der Process Layer. Dieser besteht im Wesentlichen aus den bereits in Kapitel vorgestellten Guided Procedures, welche zur Kommunikation und Prozesssteuerung der Composite Applications dienen (vgl. [Wil06]). 53

76 Kapitel 4 SAP NetWeaver 54

77 Kapitel 5 Konzeption Tabula rasa. Platon Die Evaluierung der Prozesssteuerungskomponenten Business Process Engine, Guided Procedures und SAP Workflow erfolgt in mehreren Schritten. Zunächst muss hierfür ein geeigneten Prozess gefunden werden, welcher die gewünschten Kriterien hinsichtlich Nutzerinteraktion und Performance erfüllt. Als Beispielprozess dient im Folgenden die Kreditentscheidung im Bankwesen, welche in Kapitel 5.2 beschrieben wird. Zuvor werden jedoch die gestellten Anforderungen fixiert, anhand derer die Technologien bewertet werden. Die Realisierung des Beispielprozesses soll auf den Prinzipien einer serviceorientierten Architektur basieren. Dafür ist es im nächsten Schritt erforderlich, fachliche Services zu identifizieren, welche die Grundlage für die technische Realisierung bilden. Dies wird in Kapitel 5.3 vorgestellt. Abschließend wird in Kapitel 5.4 die für die Realisierung notwendige Systemlandschaft beschrieben. 5.1 Anforderungen Der Vergleich der drei konkurrierenden Workflowtechnologien Business Process Management, Guided Procedures und SAP Business Workflow stellt den Schwerpunkt der Arbeit dar. Diese drei Technologien werden anhand eines Beispielprozesses auf Stabilität, Interoperabilität und auf die Umsetzung von Human Interactions untersucht. 55

78 Kapitel 5 Konzeption Hierfür sind die funktionalen Lücken zwischen den einzelnen Systemen aufzuzeigen und gegebenenfalls zu schließen. Dadurch soll es ermöglicht werden anwendungs- und systemübergreifende Geschäftsprozesse zu modellieren und zu steuern. Allerdings muss zur Gewährleistung der Sicherheit auch die Authentifizierung berücksichtigt werden. Wünschenswert wäre außerdem eine Möglichkeit zur systematischen Erfassung und Überwachung der Prozesse. Somit existieren die folgenden Anforderungen, die im weiteren Verlauf dieser Arbeit betrachtet werden sollen: Ganzheitliche Modellierung Interoperabilität Gewährleistung von Nutzerinteraktionen Ganzheitliches Monitoring des Prozessablaufs Sicherheit garantieren 5.2 Vorstellung des Beispielprozesses Die Basis für die Untersuchung der vorgestellten Workflowtechnologien bildet der in Abbildung 5.1 dargestellte Prozess Kreditentscheidung aus dem Bereich Bankwesen. Dieser ist dabei möglichst generisch aufgebaut und gilt in dieser Form sowohl für Kredite an Privatkunden als auch an Firmenkunden. Je nach Art des Kredites, der Bonität des Kreditnehmers und weiteren Faktoren sind einige Prozessschritte optional. Die nachfolgende Beschreibung beschränkt sich jedoch auf die Standardbearbeitung eines Privatkredites. Der Prozess Kreditentscheidung durchläuft dabei im Normalfall die fünf Prozessschritte Finanzierung beraten, Kreditantrag vorbereiten, Kreditantrag entscheiden, Kredit während der Laufzeit betreuen und Kredit beenden. Im Falle einer Störung, zum Beispiel durch einen Zahlungsverzug, wird zusätzlich der Prozessschritt Notleidenden Kredit betreuen ausgeführt. 56

79 5.2 Vorstellung des Beispielprozesses Abbildung 5.1: Generischer Kreditprozess Im ersten Prozessschritt Finanzierung beraten wird dabei der Kreditwunsch des Kunden vom Berater aufgenommen. Dabei werden Verwendungszweck, wirtschaftliche Verhältnisse des Kunden sowie die Finanzierungsmodalitäten (Konditionen, Rückführung und Sicherheiten) abgefragt. Anschließend werden der Kreditantrag und die Kundendaten ins System eingegeben und plausibilisiert. Sobald alle notwendigen Daten im System vorhanden sind, kann über den eigentlichen Kreditantrag entschieden werden, wie in Abbildung 5.2 dargestellt ist. Dazu wird zunächst die Bonität des Kunden beurteilt, wobei eine Auskunft bei der Schutzgemeinschaft für allgemeine Kreditsicherung (SCHUFA) eingeholt und ein internes Scoring durchgeführt wird. Daraufhin werden die Kundenangaben zu den wirtschaftlichen Verhältnissen nachgeprüft und die Kreditsicherheit anhand eines aufwändigen Verfahrens ermittelt. Hierfür werden Beleihungswertermittlungen für Immobilien und Wertgegenstände durchgeführt. Alle Daten, die im Lauf des Kreditantrags ermittelt wur- 57

80 Kapitel 5 Konzeption den, werden anschließend in einer standardisierten Vorlage zusammengefasst, um die Kreditentscheidung zu vereinfachen. Unter günstigen Umständen (geringes Volumen, hervorragende Sicherheiten) kann die Entscheidung automatisiert erfolgen, andernfalls erfolgt die Kreditentscheidung durch einen Bearbeiter. Abhängig von der Kredithöhe kann auch eine Freigabe in mehreren Stufen notwendig sein. Abbildung 5.2: Prozessdetails Kreditentscheidung Ist der Kredit genehmigt, werden die Angaben auf Vollständigkeit geprüft und gegebenenfalls noch offene Dokumente eingefordert. Anschließend werden vom Kreditempfänger Maßnahmen zur Risikovorsorge, wie zum Beispiel eine Kreditrahmenversicherung oder eine Risikolebensversicherungen getroffen, um weitere Sicherheiten zu gewährleisten. Sind alle Dokumente vollständig und vorliegend sowie die notwendigen Maßnahmen zur Vorsorge getroffen, kann der Kredit ausgezahlt werden. In regelmäßigen Abständen werden nun Sicherheiten und Einzahlungen von dem Kreditgeber überwacht. Es kann auch zu Änderungen am Vertrag kommen, falls Sicherheiten entfallen oder sich die Zahlungsmodalitäten ändern. Ist die Laufzeit des Kredites erreicht 58

81 5.2 Vorstellung des Beispielprozesses und wurden alle Einzahlungen erfolgreich durchgeführt, wird der Kredit beendet. Dazu werden die von der Bank verwendeten Sicherheiten wieder freigegeben und die Kreditakte wird geschlossen. Der vollständige Ablauf dieses Teilprozesses ist in Abbildung 5.3 dargestellt. Abbildung 5.3: Prozessdetails Kredit betreuen 59

82 Kapitel 5 Konzeption Bei Zahlungsverzug des Kreditempfängers werden automatisch Mahnungen versendet. Kommt es auch daraufhin nicht zu einer Zahlung, ist anzunehmen, dass es sich um einen Störfall handelt. Hieraufhin wird der Prozessschritt Notleidende Kredite betreuen ausgelöst. Daraufhin wird die Situation von einem Sachbearbeiter neu geprüft (siehe Abbildung 5.4). Falls der Kunde noch zahlungsfähig ist, kann gegebenenfalls über die Konditionen neu verhandelt werden. Die Bearbeitung wird daraufhin im Prozessschritt 1.4 Kredit betreuen weiter durchgeführt. Ist der Kunde jedoch komplett zahlungsunfähig, kann die Bank den Kredit beenden und stattdessen die Sicherheiten einfordern. Abbildung 5.4: Prozessdetails Notleidende Kreditprozesse betreuen 60

83 5.3 Serviceidentifikation 5.3 Serviceidentifikation Für die weitere Bearbeitung wird die Annahme getroffen, dass die Prozessschritte Finanzierung beraten und Kreditantrag vorbereiten bereits erfolgreich ausgeführt wurden und alle für die weitere Bearbeitung notwendigen Daten vorliegen. Der darauffolgende Schritt Kreditantrag entscheiden wird nun für die Betrachtung der verschiedenen Technologien verwendet. Innerhalb dieses Schrittes ist es notwendig, sowohl externe Services zu kontaktieren als auch Human Interactions zu berücksichtigen. Der Prozessschritt Kreditantrag entscheiden eignet sich somit sehr gut für den Vergleich der Technologien hinsichtlich ihrer Interoperabilität. Im Detail können dabei die drei Services Bonitätsbewertung, Sicherheitsbewertung und Kreditentscheidung sowie die Dateneingabe identifiziert werden. Diese kapseln die Funktionalitäten der einzelnen Bearbeitungsschritte, wodurch das in Kapitel 2.3 beschriebene Konzept einer serviceorientierten Architektur umgesetzt und eine hohe Flexibilität und Austauschbarkeit erzielt wird. Die einzelnen Bearbeitungsschritte werden dabei entweder vollautomatisch oder unter Einbeziehung eines Sachbearbeiters ausgeführt. Die Auswahl der Bearbeitungsvariante erfolgt anhand verschiedener Parameter. Falls die automatische Prüfung nicht eindeutig ist oder in definierten Grenzbereichen liegt, wird ebenso ein Sachbearbeiter hinzugezogen. Der daraus resultierende generische Ablaufplan des Workflows ist in Abbildung 5.5 dargestellt. Die Realisierung der Nutzerinteraktion in den Schritten Sicherheitsbewertung und Kreditentscheidung erfolgt mit Hilfe von leichtgewichtigen Workflows in Guided Procedures, welche in das SAP Portal integriert werden können. Dies hat den Vorteil, dass Benutzer nicht mit verschiedenen Anwendungen arbeiten müssen. Jegliche Interaktion zwischen Mensch und Computer erfolgt über das Portal. Die Orchestrierung der Services ist abhängig von der verwendeten Technologie und wird in Kapitel 6 am Beispiel des SAP Business Workflow und des SAP Business Process Management beschrieben. Da die Funktionalität der Bearbeitungsschritte aus dem eigentlichem Workflow ausgelagert wird, können diese in der konkreten Orchestrierung wiederverwendet werden. Hierfür ist es jedoch erforderlich, dass die zu untersuchenden Technologien auch mit den Services kommunizieren können, was in den Kapiteln 6.2 und 6.3 untersucht wird. 61

84 Kapitel 5 Konzeption Abbildung 5.5: Ablaufplan Kreditentscheidung 62

85 5.4 Systemlandschaft 5.4 Systemlandschaft Die Realisierung des Beispielprozesses basiert auf der in Abbildung 5.6 dargestellte Systemlandschaft. Diese besteht im Wesentlichen aus den unterschiedlichen Systemen, welche die Technologien zur Verfügung stellen. Die Implementierung des SAP Business Workflows erfolgt dabei auf einem SAP ECC 6.0 System. Für die Umsetzung des ccbpms wird ein NetWeaver 2004s Server mit der Process Integration 7.0 verwendet. Die leichtgewichtigen Guided Procedures für die Realisierung der Human Interactions laufen auf einem CE 7.1 SP1 Server. Die Funktionalitäten werden, wie bereits erwähnt, in Services gekapselt und können somit an beliebiger Stelle im Netz bereitgestellt werden. In der dargestellten Systemlandschaft wird angenommen, dass diese auf einem separaten Server laufen. Die Realisierung dieser Services, der anwendungsspezifischen Callable Objects und der grafischen Oberflächen zur Dateneingabe erfolgt mit Hilfe des SAP NetWeaver Developer Studio, welches hierfür bereits diverse Bibliotheken zur Verfügung stellt [BMH06]. Benutzer SAP NetWeaver Developer Studio CE 7.1 SP1 SAP ECC 6.0 CE 7.1 SP1 Server WebAS 7.0 SAP Business Workflow Guided Procedures NetWeaver 2004s Server Process Integration 7.0 Business Process Engine SAP Web AS Services Abbildung 5.6: Benötigte Systemlandschaft für die Realisierung des Beispielprozesses 63

86 Kapitel 5 Konzeption 64

87 Kapitel 6 Implementierung Per aspera ad astra. Seneca Nachdem im vorangegangenen Kapitel der Prozess für die Evaluierung spezifiziert und die vier fachlichen Services identifiziert wurden, müssen diese nun umgesetzt und orchestriert werden. In Kapitel 6.1 wird dabei zunächst auf die Entwurfsentscheidungen während der Implementierung eingegangen und die detaillierte Umsetzung erläutert. Daraufhin wird in den Kapiteln 6.2 und 6.3 aufgezeigt, wie diese Services orchestriert werden können. Dabei wird zunächst auf die Einzelheiten bei der Implementierung mit Hilfe des SAP Business Workflows eingegangen und anschließend die Details der Realisierung des Integrationsprozesses im ccbpm der Process Integration betrachtet. Danach wird in Kapitel 6.4 untersucht, wie einzelne Bausteine einer solchen Implementierung in den verschiedenen Technologien wiederverwendet oder hierarchisch genutzt werden können. Abschließend werden Möglichkeiten zur Überwachung des Prozessablaufs im SAP Business Workflow und in der Process Integration analysiert. 65

88 Kapitel 6 Implementierung 6.1 Serviceimplementierung Aus dem Prozess Kreditantrag wurde, wie bereits in Kapitel 5.3 erläutert, der Schritt Kreditentscheidung für die prototypische Realisierung ausgewählt. Die notwendigen Funktionen dieses Schrittes können in vier Services gekapselt werden, im Folgenden wird auf die Besonderheiten der Realisierung dieser eingegangen. Dateneingabe Die Dateneingabe ist im eigentlichen Sinne kein Bestandteil des Prozessschrittes Kreditentscheidung, da dies bereits in den zuvorgehenden Prozessschritten Finanzierung beraten und Kreditantrag vorbereiten vom Sachbearbeiter erledigt wird. Für die prototypische Realisierung ist die Dateneingabe jedoch Bestandteil des betrachteten Schrittes und wird als Auslöser des Workflows interpretiert. In dem erstellten Prototyp werden die Daten über eine in das Portal integrierte WebDynpro-Komponente eingegeben. Neben den eigentlichen Kundendaten, wie Name, Vorname, Adresse und den Kreditdaten wird hier auch die verwendete Business Process Runtime Engine festgelegt (siehe Abbildung 6.1). Die Implementierung dieser WebDynpro-Komponente erfolgt mit Hilfe des NetWeaver Developer Studio und wird im Anhang D.1 ausführlich beschrieben. Abbildung 6.1: WebDynpro Komponente der Dateneingabe 66

89 6.1 Serviceimplementierung Außerdem wird ein generischer Webservice entwickelt, der als Vermittler zwischen der eigentlichen Dateneingabe und der Business Process Runtime Engine fungiert. Das Interface und die Funktionsweise dieses Webservices werden in Listing 6.1 dargestellt. Die dadurch entstandene zusätzliche Abstraktionsebene schafft den Vorteil, dass der Nutzer nicht auf eine Anwendung für die Dateneingabe festgelegt ist, da die eigentliche Funktionalität zum Starten der Workflow- Engine ausgelagert wird. Es ist somit denkbar, dass neben der implementierten Dateneingabe per WebDynpro-Komponente auch eine Stand-Alone Applikation verwendet wird. Diese Abstraktion spiegelt eine konkrete Umsetzung einer serviceorientierten Architektur wider. Die Auslagerung der fachlichen Funktionalität in einen Service schafft eine hohe technologische Unabhängigkeit und erzielt dadurch eine größere Flexibilität. Von Anpassungen oder Änderungen der Geschäftsprozessen bleibt der Service im Wesentlichen unberührt. 1 public class StartBusinessProcessBean implements StartBusinessProcessLocal { 2 3 public void startworkflow( 4 String kundenid, 5 String kundenvorname, 6 String kundenname, 7 String kundenadresse, 8 String kredithoehe, 9 String kreditrate, 10 String kreditzins, 11 String engine){ if(engine.equals("xi")) 14 startxiworkflow(kundenid, kundenvorname, kundenname, kundenadresse, kredithoehe, kreditrate, kreditzins); 15 else 16 startsapworkflow(kundenid, kundenvorname, kundenname, kundenadresse, kredithoehe, kreditrate, kreditzins); 17 } 18 } Listing 6.1: Pseudocode des StartBusinessProcess Webservice Sicherheitsbewertung Der Prozessschritt Sicherheiten bewerten erfordert die Anwenderintegration in den Prozess. Es ist demzufolge erforderlich, eine Möglichkeit zur Visualisierung der übertragenen Daten und zur Eingabe der Sicherheiten zur Verfügung zu stellen. Dies wird, wie auch zuvor bei der initialen Dateneingabe, über eine WebDynpro- Komponenten realisiert, welche in eine Guided Procedure integriert ist. In der 67

90 Kapitel 6 Implementierung entwickelten WebDynpro-Komponente werden zunächst die zuvor eingegeben Kunden- und Kreditdaten visualisiert und die vorhanden Sicherheiten abgefragt. Für die ausgewählten Sicherheiten werden anschließend Details aufgenommen und gegebenenfalls Anhänge, wie Belege, Nachweise oder Urkunden, angefügt. Ein Beispiel für die dafür erstellte grafische Oberfläche wird in Abbildung 6.2 veranschaulicht. Abbildung 6.2: WebDynpro Komponente zur Visualisierung von Nutzerdaten (links) und zur Eingabe der entsprechenden Sicherheiten (rechts) Da allerdings die entsprechende Guided Procedure nicht direkt aus der Prozesssteuerungskomponente angesprochen werden kann, wird auch hier eine zusätzliche Abstraktionsebene in Form eines Webservices eingeführt. Dieser Webservice stellt Funktionen zum Starten der Guided Procedure und zur Kommunikation mit der Prozesssteuerungskomponente zur Verfügung. Das nachfolgende Listing 6.2 zeigt in verkürzter Form die Funktionsweise dieses Webservices. Hierfür wird zunächst die ProcessTemplateId der zu startenden Guided Procedure festgelegt, wodurch eine eindeutige Zuordnung erfolgen kann (Zeile 3). Daraufhin werden die zum Starten der Guided Procedure erforderlichen Kontexte erzeugt und die Eingabeparameter mit den übergebenen Werten gefüllt (Zeile 19-32). Abschließend kann die Guided Procedure mit Hilfe der Methode startprocess des RuntimeManagers gestartet werden. 68

91 6.1 Serviceimplementierung 1 public class CheckSecurities_GPWSBean implements CheckSecurities_GPWSLocal { 2 3 private final String processid = "C3F70711C7FA11DCA5AF001558C3EA5A"; 4 5 private static final String INITIATOR_ID = "Administrator"; 6 private static final String UD_NAME = "CheckSecurities"; 7 private static final String UD_DESCRIPTION = "Sicherheitscheck Aufruf vom WebService"; 8 9 public void startprocess( 10 String kundenid, 11 String nachname, 12 String vorname, 13 String adresse, 14 String khoehe, 15 String krate, 16 String kzins, 17 String initiator) throws Exception{ IUser user = UMFactory.getUserFactory().getUserByLogonID( INITIATOR_ID); 20 IGPUserContext usercontext = GPContextFactory.getContextManager(). createusercontext(user); 21 IGPProcess process = GPProcessFactory.getDesigntimeManager(). getactivetemplate(processid, usercontext); 22 IGPRuntimeManager rtm = GPProcessFactory.getRuntimeManager(); 23 IGPProcessRoleInstanceList roles = rtm.createprocessroleinstancelist (); IGPStructure params = GPStructureFactory.getStructure(process. getinputparameters()); 26 params.setattributevalue(kundenid, kundenid); 27 params.setattributevalue(nachname, nachname); 28 params.setattributevalue(vorname, vorname); 29 params.setattributevalue(adresse, adresse); 30 params.setattributevalue(khoehe, khoehe); 31 params.setattributevalue(krate, krate); 32 params.setattributevalue(kzins, kzins); IGPProcessInstance prinstance = rtm.startprocess( 35 process, 36 UD_NAME, 37 UD_DESCRIPTION, 38 user, 39 roles, 40 params, 41 user); 42 } 43 } Listing 6.2: Auszug aus dem CheckSecurities Webservice zum Starten der Guided Procedure CheckSecurities Die konkrete Implementierung des Webservices ist jedoch abhängig von der gewählten Business Process Runtime Engine. Auch die Guided Procedure muss hierfür geringfügig angepasst werden, da die Kommunikation zurück zur Business Process Runtime Engine auf unterschiedlichen Wegen erfolgt. Auf diese Besonderheiten wird in Kapitel 6.2 und 6.3 eingegangen. 69

92 Kapitel 6 Implementierung Bonitätsprüfung Im Gegensatz zum Prozessschritt Sicherheiten bewerten, erfolgt innerhalb der Bonitätsprüfung keinerlei Nutzerinteraktion. Der daraus resultierende Service bedarf demzufolge keiner WebDynpro-Komponente zur Visualisierung oder Dateneingabe. Die Funktionalität dieses Webservice wurde im vorliegenden Fall nur prototypisch implementiert, da der Fokus auf der Realisierung der Integration von Anwendern in die Geschäftsprozesse lag. In der Realität müsste hier ein Aufruf der Schutzgemeinschaft für allgemeine Kreditsicherung (SCHUFA) erfolgen, um die Bonität des Kunden zu überprüfen. Das Ergebnis dieser Anfrage ist im Allgemeinen eine Bewertung der Bonität in der Form von Schulnoten, wobei 1 die bestmögliche Bonität und 6 die schlechteste Bonität widerspiegelt. Der folgende Pseudocode soll die Funktionsweise und die Schnittstellen des Services verdeutlichen. 1 public class CheckRatingBean implements CheckRatingLocal { 2 3 public String getpersonscoring( 4 String kundenid, 5 String nachname, 6 String vorname, 7 String adresse, 8 String khoehe, 9 String krate, 10 String kzins){ personscoringresult = callschufa(kundenid, nachname, vorname, adresse); return personscoringresult; 15 } 16 } Listing 6.3: Pseudocode des CheckRating Webservices zur Bewertung der Bonität Kreditentscheidung Die eigentliche Entscheidung, ob der Kunde einen Kredit zur Verfügung gestellt bekommt, wird im Prozessschritt Kreditentscheidung fällen getroffen. Diese Entscheidung kann unter günstigen Bedingungen (Kunde hat sehr gute Bonitätsund Sicherheitsbewertung, Kredit liegt unter einem bestimmten Grenzwert) vollautomatisch getroffen werden. Im Normalfall bedarf jedoch auch dieser Schritt einer Nutzerinteraktion. 70

93 6.1 Serviceimplementierung Deswegen wird auch hierfür, analog zu den Services Sicherheitsbewertung und Dateneingabe, eine WebDynpro-Komponente entworfen, welche in eine Guided Procedure integriert wird. Die Komponente veranschaulicht dem Sachbearbeiter zunächst die Kundendaten sowie dessen Bewertungen und gibt anschließend eine Empfehlung für die Kreditvergabe, wie aus Abbildung 6.3 ersichtlich. Diese Empfehlung basiert auf einem Algorithmus, welcher sowohl die Kredithöhe als auch die Bewertung der Sicherheiten und der Bonität überprüft. Der Sachbearbeiter kann der automatischen Prüfung zustimmen oder diese manuell ändern. Abbildung 6.3: WebDynpro-Komponente zur Visualisierung aller bisherigen Daten (links) und zur manuellen Änderung der Kreditentscheidung (rechts) Der Aufruf der Guided Procedure erfolgt analog zu den Implementierungen Sicherheitsbewertung und Dateneingabe. Listing 6.4 zeigt in verkürzter Form die Schnittstellen des Webservices. 1 public class Result_GPWSBean implements Result_GPWSLocal { 2 3 private final String processid = "E1889EF1C82311DCB C3EA5A"; 4 5 public void startprocess( 6 String kundenid, 7 String nachname, 8 String vorname, 9 String adresse, 71

94 Kapitel 6 Implementierung 10 String khoehe, 11 String krate, 12 String kzins, 13 String bonitaet, 14 String sicherheiten, 15 String initiator) throws Exception{ IGPProcessInstance prinstance = rtm.startprocess( 18 process, 19 UD_NAME, 20 UD_DESCRIPTION, 21 user, 22 roles, 23 params, 24 user); 25 } 26 } Listing 6.4: Pseudocode des Result Webservices zur Kreditentscheidung 6.2 Prozesssteuerung mit dem SAP Business Workflow Die zuvor beschriebenen Services werden nun mit Hilfe des SAP Business Workflows orchestriert. Für diese Integration existieren im SAP ECC System im Wesentlichen drei verschiedene Möglichkeiten: über den Prozessschritt Web-Aktivität, über den Webservice Handler oder über einen ABAP Proxy. Deren Eignung für die Integration von Webservices wird im Folgenden untersucht. Web-Aktivität Der Prozessschritt Web-Aktivität bietet die Möglichkeit, ein XML Dokument von einem Workflow an ein anderes System zu senden (vgl. [SAP07x]). Die Übertragung kann dabei entweder mit Hilfe von Wf-XML, SOAP oder in reinem XML erfolgen. Jedoch unterstützt SAP bisher nur SOAP in der Version 1.1, demzufolge wird kein SOAP Binding unterstützt, da dies erst mit SOAP 1.2 eingeführt wurde (vgl. [GH05]). Das Binding ist jedoch zwingend erforderlich, um das konkrete Protokoll sowie das Datenformat für die Arbeitsschritte und Nachrichten festzulegen. Des Weiteren werden derzeit auch keine komplexen Datentypen unterstützt. Das fehlende SOAP Binding sowie die mangelnde Unterstützung von komplexen Datentypen, machen es unmöglich einen der zuvor beschriebenen Services aufzurufen. Somit scheidet diese Alternative aus. 72

95 6.2 Prozesssteuerung mit dem SAP Business Workflow Wf-XML ist aufgrund der fehlenden Unterstützung auf Seiten von Guided Procedures ebenso keine Alternative. Der Prozessschritt Web-Aktivität bietet somit keine Möglichkeit der Integration von Guided Procedures in den SAP Business Workflow, sondern dient in erster Linie dem Austausch von Nachrichten mit anderen SAP R/3 Systemen oder Workflowmanagementsystemen. ABAP Proxy ABAP Proxys stellen eine weitere Möglichkeit dar, Webservices in den SAP Business Workflow zu integrieren. Ein solcher Proxy kann auf Basis eines WSDL Dokuments automatisch generiert werden (vgl. [SAP08f]). Dafür muss zunächst im Object Navigator ein Proxy-Objekt angelegt werden, welches anschließend mit den entsprechenden Parametern konfiguriert werden kann. Da dieser Proxy allerdings nicht direkt als Aktivität in den Workflow integriert werden kann, muss hierfür entweder ein bereits bestehendes Business Objekt um eine entsprechende Methode zum Starten des Proxys erweitert oder ein komplett neues Business Objekt implementiert werden. Dies geschieht direkt im SAP ECC- System und wird somit in ABAP realisiert. Eine beispielhafte Implementierung ist in Listing 6.5 dargestellt. Die implementierte Methode kann nun als Aktivitätsschritt in den Workflow eingefügt werden. 1 DATA: 2 *Reference variables for proxy and exception class 3 lo_clientproxy TYPE REF TO [generierte Proxy-Klasse], 4 lo_sys_exception TYPE REF TO cx_ai_system_fault, 5 6 *Structures to set and get message content 7 ls_request TYPE [Output-Message-Typ], 8 ls_response TYPE [Input-Message-Typ] TRY. 11 *create proxy client 12 CREATE OBJECT lo_clientproxy 13 EXPORTING LOGICAL_PORT_NAME = LOGICAL_PORT_NAME *do synchronous client proxy call 16 CALL METHOD lo_clientproxy execute_synchronous 17 EXPORTING output = ls_request 18 IMPORTING input = ls_response CATCH cx_ai_system_fault INTO lo_sys_exception. 21 *Error handling 22 ENDTRY. Listing 6.5: Pseudocode des ABAP Proxys nach [SAP08a], [Jun04] 73

96 Kapitel 6 Implementierung Der Nachteil dieser Lösung besteht allerdings darin, dass der Aufruf des Webservices asynchron erfolgt. Das hat wiederum zur Folge, dass die Aktivität nach dem Aufruf des Proxys beendet wird und nicht auf den Rückruf des Webservices wartet. Hierfür muss ein Warteschritt in den SAP Business Workflow eingefügt werden, der solange wartet, bis ein bestimmtes Ereignis im ECC-System ausgelöst wird. Analog der zuvor angelegten Methode wird dafür ein spezifisches Event im Business Object registriert. Dieses Event kann anschließend per Webservice oder RFC ausgelöst werden. Für die Fortsetzung der korrekten Workflowinstanz ist es weiterhin notwendig, eine Korrelations-ID zu übertragen, welche die Workflowinstanz eindeutig identifiziert. Die komplette Kommunikation zwischen SAP Business Workflow und Webservice per ABAP-Proxy, wie in Abbildung 6.4 ersichtlich, ist somit relativ kompliziert und mit aufwändiger, individueller Anpassung im ECC-System verbunden. Aktivität: Aufruf Business Object startproxy ABAP Proxy callwebservice Webservice startguidedprocedure callback Aktivität: Warten Business Object eventcallback Eventauslösung per RFC oder Funktionsbaustein Abbildung 6.4: Webserviceaufruf per ABAP Proxy Webflow Service Handler Aufgrund der Nachteile der ABAP Lösung wurde sich dafür entschieden, eine weitere Lösung zu suchen. Diese wurde mit dem Webflow Service Handler, häufig auch nur als Webservice Handler bezeichnet, gefunden. Der Webservice Handler ist Teil des Internet Communication Framework und stellt Funktionen zur Kommunikation verschiedener Systeme über das Internet zur Verfügung. Ein solcher Service Handler kann durch den Import eines WSDL Dokumentes au- 74

97 6.2 Prozesssteuerung mit dem SAP Business Workflow tomatisch generiert oder manuell im System registriert werden (vgl. [SAP08e]). Wie bereits im vorangegangenem Abschnitt erwähnt, werden derzeit allerdings weder komplexe Datentypen noch SOAP 1.2 unterstützt. Da die implementierten Services jedoch komplexe Datentypen und SOAP 1.2 voraussetzen, kann der Service Handler demzufolge nicht automatisch aus der WSDL generiert werden. Die Services müssen also manuell im System registriert werden. Dies geschieht über die Transaktion WF_EXTSRV (Externe Services für Webflow pflegen) und wird im Anhang D.5 ausführlich beschrieben. Der Webservice Handler ermöglicht das Senden von HTTP-Requests aus dem SAP Business Workflow. Allerdings kann der entsprechende Webservice darüber nicht direkt gestartet werden. Aus diesem Grund muss ein Gateway implementiert werden, welches den Request aus dem Workflow entgegennimmt, die Anfrage transformiert und den Webservice aufruft. Diese funktionale Lücke zwischen Workflow und Webservice wird durch ein Java Servlet geschlossen, welches in Auszügen in Listing 6.6 dargestellt ist. Das Servlet instanziiert dazu im ersten Schritt einen Java Proxy, welcher zur Kommunikation mit dem Guided Procedures Webservice dient. Anschließend werden die Inputparameter aus dem HTTP-Request gelesen und verarbeitet. Der Proxy ruft daraufhin die Methode startprocess auf, welche den Guided Procedure Webservice startet und übergibt dieser Methode die notwendigen Parameter. 1 public class Servlet extends javax.servlet.http.httpservlet implements javax.servlet.servlet { 2 3 WebServiceBeanService service; 4 5 protected void doget(httpservletrequest request, HttpServletResponse response) 6 throws ServletException, IOException { 7 8 if (service!=null){ 9 WebServiceBeanService pt = service.getgp_webservicebeanport(); for (Entry entry : (Set<Entry>) request.getparametermap().entryset()) 12 processparameter(entry); pt.startprocess(inputparameter); 15 } 16 } 17 } Listing 6.6: Pseudocode des Java Servlets 75

98 Kapitel 6 Implementierung Zur Realisierung der asynchronen Kommunikation von der Guided Procedure zurück zum SAP Business Workflow, stellt der Webflow Service Handler die Möglichkeit des Callback Handlers zur Verfügung. Dadurch wird der SAP Business Workflow so lange pausiert, bis ein entsprechender Callback erfolgt. Der Webflow Service Handler übergibt dazu einen sogenannten Callbackparameter, welcher neben der URL des Callback Handlers auch noch weitere Parameter zur eindeutigen Zuordnung der Prozessinstanz enthält. Die Implementierung des Guided Procedure Webservice muss somit, im Vergleich zu der bereits auf Seite 69 beschriebenen Implementierung, geringfügig angepasst werden (siehe Listing 6.7). Es muss demzufolge neben den eigentlichen Eingabeparametern der Guided Procedure auch der Callbackparameter übergeben werden (Zeile 17-19). Der Rest der Implementierung erfolgt analog dem bereits bekannten Vorgehen. 1 public class GPWebServiceBean implements GPWebServiceLocal { 2 3 private final String processid = "CF9A DCB33A001558C3EA5A"; 4 private static final String INPUTPARAMETER = "Inputparameter"; 5 private static final String CALLBACKURL = "CallbackURL"; 6 7 public String startprocess( 8 String input, 9 String callbackurl) throws Exception{ IUser user = UMFactory.getUserFactory().getUserByLogonID(INITIATOR_ID); 12 IGPUserContext usercontext = GPContextFactory.getContextManager(). createusercontext(user); 13 IGPProcess process = GPProcessFactory.getDesigntimeManager().getActiveTemplate( processid, usercontext); 14 IGPRuntimeManager rtm = GPProcessFactory.getRuntimeManager(); 15 IGPProcessRoleInstanceList roles = rtm.createprocessroleinstancelist(); IGPStructure params = GPStructureFactory.getStructure(process.getInputParameters ()); 18 params.setattributevalue(inputparameter, input); 19 params.setattributevalue(callbackurl, callbackurl); IGPProcessInstance prinstance = rtm.startprocess( 22 process, 23 UD_NAME, 24 UD_DESCRIPTION, 25 user, 26 roles, 27 params, 28 user); 29 } 30 } Listing 6.7: Pseudocode des Guided Procedures Webservice 76

99 6.2 Prozesssteuerung mit dem SAP Business Workflow Die Guided Procedure nimmt diese Inputparameter entgegen und visualisiert sie für den Bearbeiter. Nachdem der Bearbeiter alle Sicherheiten eingegeben hat, erfolgt deren Bewertung anhand von Schulnoten, wie bereits in Kapitel 6.1 beschrieben. Der Rückweg von der Guided Procedures zum SAP Business Workflow erfolgt, im Gegensatz zum Aufruf, auf direktem Weg. Dafür wird im Hintergrund, für den Bearbeiter unsichtbar, ein Callable Object ausgeführt welches die notwendigen Parameter für den Rückruf verarbeitet. Anschließend wird ein Callable Object zum Aufruf der Callback-URL genutzt und damit der Callback Handler des SAP Business Workflows angesprochen. In Abbildung 6.5 wird die Realisierung einer solchen Guided Procedure am Beispiel der Sicherheitsbewertung aufgezeigt. Abbildung 6.5: Guided Procedure zur Bewertung der Sicherheiten Der komplette Ablauf der Kommunikation zwischen dem SAP Business Workflow und der Guided Procedure zur Realisierung einer Human Interaction besteht somit aus vier Teilen und ist in Abbildung 6.6 dargestellt. 77

100 Kapitel 6 Implementierung SAP R/3 SAP Business Workflow Workitem ruft Webservice Handler auf Webservice Handler Workitem wird beendet Launch Handler führt ServletRequest durch Servlet HttpServletRequest Proxy wird aufgerufen Webservice Proxy Übergabe der Parameter und Callback URL Guided Procedures Webservice Callback Handler wird mittels Callback URL aufgerufen startprocess GPProcessFactory instanziiert Guided Procedure Guided Procedures CO: User Interaction CO: URL Mapping CO: Callback Abbildung 6.6: Bestandteile der Kommunikation zwischen SAP Business Workflow und Guided Procedures Dadurch sind alle funktionalen Lücken geschlossen und der Geschäftsprozess kann modelliert werden. Die prototypische Realisierung mit Hilfe des SAP Business Workflows ist in Abbildung 6.7 dargestellt. Der Workflow wird dabei in Schritt 1 durch die Dateneingabe gestartet. Anschließend werden die Services zur Sicherheitsbewertung und Bonitätsprüfung aufgerufen. Sobald die Bewertungen erfolgreich abgeschlossen wurden, erhält der Benutzer eine Benachrichtigung, dass die Kreditentscheidung aus- 78

101 6.2 Prozesssteuerung mit dem SAP Business Workflow stehend ist. Daraufhin wird in Schritt 5 die eigentliche Entscheidung getroffen und der Workflow anschließend beendet. 1) Workflow wird durch Eingabe der Daten gestartet 2) Guided Procedure zur Sicherheitsbewertung aufrufen 3) Webservice zur Bonitätsprüfung aufrufen 4) Benachrichtigung an den Nutzer versenden, Ergebnis ausstehend 5) Guided Procedure zur Kreditentscheidung aufrufen 6) Benachrichtigung über die Kreditentscheidung an den Nutzer versenden 7) Workflow beendet Abbildung 6.7: Geschäftsprozess Kreditentscheidung im SAP Business Workflow 79

102 Kapitel 6 Implementierung 6.3 Prozesssteuerung mit der Process Integration Nachdem im vorangegangenen Kapitel 6.2 die Orchestrierung der Services mit Hilfe des SAP Business Workflows erläutert wurde, wird nun gezeigt, wie dies in der Process Integration möglich ist. Da NetWeaver von SAP als Integrationsplattform für heterogene Systeme entwickelt wurde, ist es bereits von Haus aus für die Kommunikation mit anderen Systemen ausgelegt. Hierfür existieren zwei verschiedene Konzepte: Zum einen wird die direkte Kommunikation über einen Proxy unterstützt, zum anderen stehen diverse Adapter zur Verfügung (siehe Abbildung 6.8). Integration Server Business Process Engine Integration Engine Adapter Engine XI Protocol RFC RosettaNet XI Protocol Local Integration Engine Proxy Runtime SAP WebAS > 6.20 SAP System File DB JMS 3 rd Party Apps Apps of Business Partner Partner Connectity Kit Apps of small Business Partners Abbildung 6.8: Architektur SAP Integration Server - Adapter Engine vs. Proxy Proxy Die Kommunikation über Proxys wird hauptsächlich zur Integration bestehender SAP Systeme genutzt, da mindestens ein SAP Web Application Server 6.20 vorausgesetzt wird. Wie in Abbildung 6.8 ersichtlich, stellt der Proxy eine direkte Verbindung zu dem integrierenden System her. Je nach Programmiersprache der Anwendung werden entweder ABAP Proxys oder Java Proxys zur Verfügung gestellt. Da die Kommunikation ohne Umweg über die Adapter Engine läuft, ist sie ressourcen- und zeitsparender als die Verwendung von Adaptern. In dem Szenario Kreditentscheidung soll allerdings mit Webservices kommuniziert werden, wodurch die Kommunikation nicht über Proxys realisiert werden kann. 80

103 6.3 Prozesssteuerung mit der Process Integration Adapter Im Gegensatz zu der Integration über Proxys können mit Hilfe der Adapter Engine beliebige Systeme angesprochen werden. Hierfür werden von SAP bereits eine Reihe von vorgefertigten Adaptern mitgeliefert. Eine detaillierte Übersicht aller zur Verfügung stehenden Adapter findet sich unter [SAP08c]. Mit Hilfe dieser Adapter werden die XML-basierten Nachrichten der Integration Engine in die spezifischen Protokolle und Formate der jeweiligen Fremdsysteme konvertiert. Des Weiteren können mit Hilfe das Adapter Frameworks auch eigene Adapter entwickelt werden, wodurch die Integrationsmöglichkeiten nahezu unbegrenzt sind. Für die Implementierung des Prozesses Kreditentscheidung wird jedoch auf den bereits vordefinierten SOAP Adapter zurückgegriffen, mit welchem der Aufruf beliebiger Webservices möglich ist. Im Gegensatz zu der SOAP Implementierung des SAP ECC Systems unterstützt die Process Integration auch SOAP in der Version Design Für den Aufruf der in Kapitel 6.1 beschriebenen Services werden während des Entwurfs je ein synchroner Sende- und ein asynchroner Empfangsschritt in den Integrationsprozess eingefügt. Der synchrone Sendeschritt ist für den Aufruf des Guided Procedures Webservices verantwortlich, der Empfangsschritt wartet auf den Rückruf dieser Guided Procedure. Der Aufruf der Guided Procedures erfolgt analog zu dem Vorgehen aus Kapitel 6.1, wobei allerdings die Parameter entsprechend angepasst werden müssen. Eine Schritt-für-Schritt Anleitung zur Implementierung findet sich in Anhang D.6. Damit die Rückgabeparameter des jeweiligen Services auch der dazugehörige Workflowinstanz zugeordnet werden, wird beim Starten des Integrationsprozesses eine Korrelations-ID auf Basis des aktuellen Zeitstempels erzeugt. Diese Korrelations-ID dient als eindeutiger Identifikator des Prozesses und wird über den kompletten Prozess durchgereicht. Der Nachteil dieser Variante ist jedoch, dass es zu einer Vermischung der fachlichen und der technischen Parameter kommt. Zur Vermeidung dieser Vermischung kann man diese Korrelations-ID auch implizit aus den fachlichen Parametern ermitteln, zum Beispiel mit einer entsprechenden Hashfunktion. Hierauf wurde jedoch bei der prototypischen Implementierung aus Gründen der Komplexität verzichtet. 81

104 Kapitel 6 Implementierung Die Services der Sicherheitsüberprüfung und der Bonitätsprüfung liefern, wie bereits in Kapitel 6.1 beschrieben, das Ergebnis in Form von Schulnoten an den Prozess zurück. Da der Service Kreditentscheidung jedoch sowohl die Bewertungen als auch die eigentlichen Kundendaten als Eingabeparameter benötigt, ist ein entsprechendes Message- Mapping erforderlich (dargestellt in Abbildung 6.9). Dieses Mapping nimmt alle zuvor verarbeiteten Nachrichten des Integationsprozesses entgegen und formt diese entsprechend den definierten Abbildungsregeln zu einer neuen Nachricht. Abbildung 6.9: Message-Mapping im Integrationsprozess Der Entwurf des Geschäftsprozesses ist damit abgeschlossen. Das Ergebnis ist in Abbildung 6.10 dargestellt. Abbildung 6.10: Integrationsprozess Kreditentscheidung 82

105 6.3 Prozesssteuerung mit der Process Integration Konfiguration Die strikte Trennung zwischen Design und Konfiguration bei der Erstellung von Integrationsprozessen ermöglicht von Haus aus eine sehr hohe Flexibilität. Im Entwurf werden nur die verwendeten Nachrichten und Formate spezifiziert und erst während der Konfiguration wird die konkrete Adresse des Services definiert. In der Konfiguration ist es demzufolge erforderlich, entsprechend der zuvor definierten Interfaces die konkreten Datenflüsse festzulegen. Hierfür werden im Integration Directory für jede Kommunikation je ein Kommunikationskanal, eine Empfänger- sowie eine Interfaceermittlung festgelegt. Dadurch wird konkret spezifiziert, wie und an welchen Empfänger entgegenkommende Nachrichten von der Integration Engine weitergeleitet werden sollen. Da diese Einstellungen allerdings sehr komplex sind, wird dies ausführlich am Beispiel des Kreditprozesses im Anhang D.6 erklärt. Für die Realisierung des Rückrufes stellt das Integration Directory eine Assistenten zur Verfügung, der unter Angabe des benötigten Services und des Kommunikationskanals eine Beschreibung des SOAP-Adapters in Form einer WSDL-Datei generiert (siehe [SAP08b]). Mit Hilfe dieser WSDL kann anschließend im NetWeaver Developer Studio ein Java Proxy erstellt werden, welcher in den Webservice integriert wird. Da die Integration Engine jedoch vorherige Autorisierung erfordert, müssen entweder Nutzerdaten und Passwort übergeben oder die in Kapitel bereits erläuterten Single Sign-On Techniken genutzt werden. Eine Implementierung dieses Callback-Proxys ist in Listing 6.8 dargestellt. 1 public void callbackxi(string sicherheitsbewertung, String correlationid){ 2 3 if (service!=null){ 4 CACheckSecuritiesWSCallbackAA pt = service.getca_checksecuritiesws_callback_aaport(); 5 6 CallbackXIType cxit = new CallbackXIType(); 7 cxit.setcorrelationid(correlationid); 8 cxit.setsicherheitsbewertung(sicherheitsbewertung); 9 10 javax.xml.ws.bindingprovider bindingprovider = (javax.xml.ws.bindingprovider) pt; 11 Map<String, Object> requestcontext = bindingprovider.getrequestcontext(); 12 requestcontext.put("javax.xml.ws.security.auth.username", user); 13 requestcontext.put("javax.xml.ws.security.auth.password", pass); pt.cachecksecuritieswscallbackaa(cxit); 16 } 17 else { 18 /*Fehlerbehandlung*/ 19 } 20 } Listing 6.8: Pseudocode für den Callback vom Webservice zum Integrationsprozess 83

106 Kapitel 6 Implementierung 6.4 Enterprise Composite Services Aus Sicht einer serviceorientierten Architektur können Workflows auch als Composite Services betrachtet werden. Composite Services sind, ähnlich den in Kapitel vorgestellten Composite Applications, im Grunde nichts anderes als eine Kollektion von Business Services (vgl. [Gim07]). Diese komponentenorientierte Ausrichtung von Workflows soll die Komplexität dieser bei der Erstellung reduzieren. Somit soll es ermöglicht werden, verschiedene Workflows miteinander zu kombinieren und ganzheitliche Workflows zu modellieren. Komplexe Workflows werden so in wiederverwendbare und weniger komplexe Teile zerlegt. Im Nachfolgenden wird aufgezeigt, wie solche Composite Services mit dem SAP Business Workflow und dem SAP Business Process Management erstellt werden können Composite Services im SAP Business Workflows Innerhalb des SAP Business Workflows können solche Composite Services durch das Einfügen von Subworkflows oder von Subworkflowschritten realisiert werden. Dafür wird in dem Composite Service ein Prozessschritt vom Typ Aktivität verwendet. In dieser Aktivität wird anstelle einer Standardaufgabe ein Verweis auf den Subworkflow hinterlegt, wie in Abbildung 6.11 dargestellt. Neben dieser statischen Variante eines Subworkflow existiert auch noch die Möglichkeit, dynamisch zur Laufzeit zu entscheiden, welcher Subworkflow aufgerufen werden soll (vgl. [MB00, Seite 352 ff.]). Abbildung 6.11: Konfiguration der Aktivität als Sub-Workflow Während der Laufzeit wird anstelle dieser Aktivität der entsprechende Subworkflow eingesetzt (siehe Abbildung 6.12). Um zwischen dem Hauptworkflow und dem Subworkflow Daten auszutauschen, kann ein entsprechender Datenfluss definiert werden. 84

107 6.4 Enterprise Composite Services Hierfür müssen im Subworkflow jedoch die notwendigen Import- und Exportparameter definiert werden (vgl. [RDS06, Seite 245 ff]). Abbildung 6.12: Composite Service mit Hilfe von SAP Business Workflow Composite Services im SAP Business Process Management Im Gegensatz zum SAP Business Workflow gibt es in der hier verwendeten Version 7.0 der Process Integration keine Möglichkeit, Composite Services zu realisieren. Jedoch können bereits bestehende Integrationsprozesse in einen neuen Integrationsprozess eingefügt werden, allerdings wird dieser dann komplett importiert. Es wird sozusagen ein eigenständiges Replikat des Integrationsprozesses erstellt. Dies hat zur Folge, dass Änderungen am Original nicht automatisch an die Replikate weitergereicht werden, was unter Umständen zu Fehlern bei der Bearbeitung führt. Die Realisierung von Composite Services in der Process Integration 7.0 ist somit nur über einen Umweg möglich. Hierfür kann ein Webservice geschrieben werden, welcher einen anderen Integrationsprozess aufruft und das Ergebnis dieses Integrationsprozesses zurück gibt. Dieses Konzept ist ähnlich dem bereits zuvor beschriebenen Aufruf der Guided Procedure Webservices. Der Nachteil dieser Lösung besteht jedoch darin, dass 85

108 Kapitel 6 Implementierung sich die Subworkflows nur getrennt überwachen lassen, da der Hauptintegrationsprozess nur die Schnittstelle zu diesen kennt, nicht aber den Subworkflow an sich. Eine andere Möglichkeit zur Realisierung von Composite Services stellen die in der Process Integration 7.1 neu eingeführten Step Groups dar. Diese sollen häufig verwendete Kombinationen von Schritten zu wiederverwendbaren Templates zusammenfassen (vgl. [SAP08d]). Anders als die Implementierung der Subworkflows im SAP Business Workflow stellen aber auch diese Step Groups keine Referenz auf einen bereits bestehenden Workflow dar. Vielmehr sind sie mit einer abstrakten Klasse aus der objektorientierten Programmierung vergleichbar. Änderungen an der Step Group werden demzufolge nicht an bereits verwendete Step Groups weitergereicht. Step Groups werden im Integration Repository definiert und können anschließend in Integrationsprozesse eingefügt und angepasst werden (siehe Abbildung 6.13). Abbildung 6.13: Verwendung von Step Groups [SAP08d]. Importieren der Step Group (oben), Parametrisierung (unten) 86

109 6.5 Business Process Monitoring 6.5 Business Process Monitoring Da es während des Ablaufs automatisierter Geschäftsprozesse immer wieder zu unvorhersehbaren Ereignissen und dadurch unter Umständen zu Fehlern während der Bearbeitung kommen kann, muss die Überwachung der Abläufe möglich sein. In verteilten Anwendungen ist dies mehr denn je erforderlich, um festzustellen, an welcher Position der Fehler auftritt. Im Nachfolgenden werden die Möglichkeiten eines solchen Monitorings für die jeweiligen Technologien aufgezeigt Monitoring von Geschäftsprozessen im SAP Business Workflow Das SAP ECC-System bietet zum Überwachen von Geschäftsprozessen das sog. Workflow-Protokoll an. Dieses kann entweder über den Business Workplace des jeweiligen Nutzers oder direkt über die Transaktion SWDP aufgerufen werden. Im Workflow- Protokoll werden zu jedem Workitem, das heißt zu jeder Repräsentation einer Workflow- Instanz, alle Informationen zum Geschäftsprozess an zentraler Stelle zusammengefasst (vgl. [RDS06, Seite 176 ff.]). Hierfür werden neben einer hierarchischen Ansicht aller bisher abgearbeiteten Schritte auch die zugehörigen Bearbeiter und Workflow-Objekte dargestellt. Darüber hinaus kann das Workitem auch grafisch abgebildet werden, wodurch ein schneller Überblick über den Workflowstatus gegeben wird (siehe Abbildung 6.14). Abbildung 6.14: Workflow-Protokoll zur Überwachung von SAP Business Workflows 87

110 Kapitel 6 Implementierung Monitoring von Geschäftsprozessen in der Process Integration Um Integrationsprozesse der Process Integration zu überwachen, bietet SAP mit der SAP GUI und der Runtime-Workbench zwei verschiedene Möglichkeiten an. In der SAP GUI können die verarbeiteten XML Nachrichten mit Hilfe der Transaktion SXMB_MONI überwacht werden, worüber zu der jeweiligen Workflowinstanz auch das grafische Workflow-Protokoll aufgerufen werden kann. Das Monitoring über die SAP GUI geschieht somit analog zu dem Monitoring des SAP Business Workflows. Dadurch wird auch ersichtlich, dass die eigentliche Runtime Engine sowohl beim SAP Business Workflow als auch beim ccbpm der Process Integration die SAP Webflow Engine ist. Das zentrale Monitoringwerkzeug der Process Integration ist jedoch die Runtime- Workbench, welche im Gegensatz zur SAP GUI als Webapplikation realisiert ist. Die Runtime-Workbench stellt detaillierte Überwachungswerkzeuge zur Verfügung. Die wichtigsten Komponenten sind dabei das Komponenten-Monitoring für die Statusüberwachung der Runtime-Engines, das Message-Monitoring zur Nachverfolgung des konkreten Nachrichtenflusses im Integration Server und das End-to-End-Monitoring. Weitere Details zu den jeweiligen Monitoring-Komponenten finden sich unter [SO05, Seite 189 ff.] und [SAP08g]. 88

111 Kapitel 7 Fazit Finis coronat opus. Publius Ovidius Naso Im Mittelpunkt dieser Arbeit steht die Analyse der Workflowtechnologien innerhalb von SAP NetWeaver. Darüber hinaus wurde untersucht, wie diese im Sinne einer serviceorientierten Architektur genutzt werden können, um Geschäftsprozesse zu modellieren und zu steuern. Im ersten Schritt wurden dafür alle zur Verfügung stehenden Workflowtechnologien im SAP NetWeaver Umfeld aufgezeigt und gegenübergestellt. In der weiteren detaillierten Betrachtung lag der Fokus auf den Technologien SAP Business Workflow, Guided Procedures und cross-component Business Process Management. Anschließend wurde ein Beispielprozess spezifiziert, welcher als Vergleichsbasis diente und soweit verfeinert wurde, dass fachliche Services als Grundlage für die nachfolgende Implementierung identifiziert werden konnten. Im weiteren Verlauf der Arbeit erfolgte die Orchestrierung der Services zu einem komplexen, systemübergreifenden Workflow mit Hilfe der zur Verfügung stehenden Technologien. Abschließend erfolgt nun eine Bewertung diese Technologien hinsichtlich ihrer Eignung für anwendungsübergreifender Geschäftsprozesse. Daraufhin werden die erreichten Ergebnisse sowie mögliche Verbesserungen aufgezeigt. Den Abschluss dieser Arbeit bildet ein Ausblick auf die Zukunft von SOA und zu erwartenden Neuentwicklungen im Bereich der Workflowtechnolgien. 89

112 Kapitel 7 Fazit 7.1 Bewertung Stellt man die verschiedenen Technologien zur Modellierung und Steuerung von Geschäftsprozessen gegenüber und fragt sich Welche dieser Technologien ist für die Realisierung von anwendungsübergreifenden Szenarien am besten geeignet?, wird man feststellen, dass es auf diese Frage leider keine eindeutige Antwort gibt. Die konkrete Realisierung ist immer abhängig von den vorhandenen Rahmenbedingungen. So ist der SAP Business Workflow sehr gut dafür geeignet, Geschäftsprozesse innerhalb von SAP spezifischen Anwendungen zu modellieren und zu steuern. Auch die Einbeziehung von Anwendern in die Prozesse funktioniert hier sehr gut, solange dies im SAP System stattfindet. Allerdings ist er aufgrund der mangelnden technischen Unterstützung nur unzureichend für die Integration von Webservices in den Prozessablauf geeignet. Die in Kapitel 6.2 aufgezeigte Implementierung erfüllt zwar die gestellten Anforderungen, jedoch ist die Realisierung mit sehr viel Aufwand verbunden und nicht wirklich praktikabel. Hierfür wäre es wünschenswert, dass SAP die Integration von Webservices in den SAP Business Workflow weiterentwickelt und der Aufruf eines Webservices somit direkt erfolgen könnte. Im Gegensatz dazu wird die Integration von Webservices im cross-component Business Process Management der Process Integration direkt unterstützt. Ebenso sind die Möglichkeiten der Integration von Fremdsystemen durch die verwendete Adaptertechnologie nahezu unbegrenzt. Ein Nachteil des ccbpm im Vergleich zum SAP Business Workflow ist jedoch die relativ komplizierte Modellierung und Konfiguration. Die strickte Trennung zwischen Entwurf und Konfiguration ist allerdings durchaus von SAP gewollt, da hierdurch sehr schnell zwischen konkreten Implementierungen gewechselt werden kann und der eigentliche Prozess von den Änderungen weitgehend unverändert bleibt. Die Integration von Anwendern in die Geschäftsprozesse unterstützt das ccbpm allerdings nicht direkt, diese müssen wie in der prototypischen Implementierung gezeigt ausgelagert werden. Nichtsdestotrotz ist das ccbpm für die Realisierung von anwendungs- und systemübergreifenden Geschäftsprozessen, die nicht auf reinen SAP Lösungen basieren, weitaus besser geeignet als der SAP Business Process. 90

113 7.1 Bewertung Die gewählte Umsetzung der Nutzerinteraktion per Guided Procedures erwies sich als gute und einfache Lösung, da hiermit relativ schnell einfache Workflows erstellt werden können. Durch die Einbindung von WebDynpro Komponenten sind der Oberflächengestaltung außerdem fast keine Grenzen gesetzt. Ferner ist auch die hohe Wiederverwendbarkeit von Objekten sehr positiv zu bewerten. Jedoch sind auch die Guided Procedures nicht ohne Einschränkungen zu empfehlen. Da keine grafische Modellierung existiert, gelangt man damit schnell an die Grenzen des Machbaren. Die Übersichtlichkeit der Workflows nimmt mit der Anzahl an Schritten und Parametern rasch ab. Änderungen an den Prozessen sind im Nachhinein nur mit großen Anstrengungen zu realisieren, da die Benutzerzuordnung sowie das Parametermapping bei jeder Änderung neu definiert werden müssen. Eine Lösung für die umständliche Modellierung bietet das Werkzeug ARIS for SAP NetWeaver von IDS Scheer. Damit ist es möglich, Geschäftsprozesse in Form von Ereignisgesteuerten Prozessketten (EPK) zu modellieren und diese anschließend als ccbpm zu exportieren. Damit wird der eigentliche Entwurf der Geschäftsprozesse ausgelagert und vereinfacht. Jedoch wird dadurch nur die äußere Struktur des Geschäftsprozesses beschrieben, auch hierfür ist individuelle Konfiguration und Anpassung notwendig. Dieser Ansatz wurde allerdings in der hier vorliegenden Arbeit nicht gesondert betrachtet, da hierzu bereits Erfahrungen innerhalb von sd&m existieren und erfolgreich demonstriert wurde, wie mit Hilfe dieses Werkzeuges die Erstellung von Geschäftsprozessen vereinfacht werden kann. Es ist somit unschwer erkennbar, dass derzeit innerhalb von SAP NetWeaver keine optimale Lösung für die Realisierung der gestellten Anforderungen existiert. Mit der prototypischen Implementierung wurden jedoch Lösungsmöglichkeiten aufgezeigt mit denen anwendungs- und systemübergreifende Geschäftsprozesse umgesetzt werden können. Des Weiteren lässt sich festhalten, dass sich durch die Umsetzung des SOA- Paradigmas Anwendungen entwickeln lassen, die sich besonders gut an Geschäftsprozessen ausrichten können und eine hohe Flexibilität aufweisen. SOA schließt demzufolge die viel diskutierte Lücke zwischen IT und Business. 91

114 Kapitel 7 Fazit 7.2 Verbesserungen Die vorgestellten Lösungsmöglichkeiten sind jedoch rein prototypischer Natur und nicht für den Einsatz in Produktivsystemen gedacht, sondern sollen lediglich zeigen, ob eine Realisierung möglich ist und wie diese aussehen könnte. Für den Produktiveinsatz sollte beachtet werden, dass zum einen die Abstraktionsebenen, also die Servlets und die Webservices, dafür möglichst generisch umgesetzt werden um den Änderungsund Anpassungsaufwand zu reduzieren. Zum anderen muss der Aspekt der Sicherheit dafür weiter betrachtet werden. In der aufgezeigten Implementierung wird eine direkte Übergabe von Benutzernamen und Passwort verwendet, besser wäre jedoch die Verwendung von Single Sign-On Mechanismen. 7.3 Ausblick Das Gebiet der serviceorientierten Architekturen ist ein relativ junges Feld in der Softwareentwicklung und befindet sich demzufolge noch sehr stark in Bewegung. Diese macht natürlich auch vor den Prozesssteuerungskomponenten nicht Halt. So hat SAP erst vor kurzem auf der TechEd 2007 bekannt gegeben, dass sie mit der Entwicklung einer neuen Business Process Engine beschäftigt sind. Diese Entwicklung läuft unter dem Codenamen Galaxy und verspricht eine Revolution der Workflowtechnologien im SAP NetWeaver Umfeld. Galaxy wird nach derzeitigen Informationen vollständig auf der Business Process Modeling Notation (BPMN) basieren und in der Entwicklungsumgebung Eclipse modelliert werden (vgl. [Gat08]). Des Weiteren wird es eine komplette Business Rule Engine enthalten, wodurch sich das Verhalten der Geschäftsprozesse sehr gut steuern lassen soll. Außerdem wird es von Haus aus Möglichkeiten zur Integration von Anwendern und anderen Systemen bieten (vgl. [Nie08]). Dies bedeutet über kurz oder lang die Ablösung von Guided Procedures und ccbpm durch Galaxy. Bis Galaxy jedoch erhältlich ist, wird es noch eine Weile dauern. Das Ramp-Up ist für Ende 2008 angekündigt, was bedeutet das es wohl frühestens Mitte 2009 in entsprechenden Anwendungen verfügbar sein wird. Bis dahin müssen sich die Anwender also noch mit den bisherigen Technologien begnügen. 92

115

116

117 Anhang A SOA Bestanteile Eine Serviceorientierte Architektur lässt sich in die 4 Bestandteile Service, Anwendungsfrontend, Service Repository und Service Bus unterteilen. Der Service wiederum besteht aus dem Servicevertrag, der Schnittstellenbeschreibung und der eigentlichen Implementierung. Eine detaillierte Beschreibung dieser Komponenten wird in Kapitel 2.3 vorgenommen. SOA Service Anwendungs- Frontend Service Repository Service Bus Vertrag Implementierung Schnittstelle Geschäftslogik Daten Abbildung A.1: Bestandteile einer serviceorientierten Architektur nach [KBS07] Ein Service besteht neben der eigentlichen Implementierung, außerdem aus den Komponenten Servicevertrag und einer Menge definierter Schnittstellen. Service Schnittstelle A - Operation 1 - Operation 2 Schnittstelle B - Operation 1 - Operation 2 Implementierung Geschäfts logik Daten Abbildung A.2: Aufbau eines Services nach [KBS07] 95

118 Anhang A Anhang SOA 96

119 Anhang B Workflows Workflowreferenzmodell Die Workflow Management Coalition entwickelte 1995 zur besseren Beschreibung und Vergleichbarkeit von Workflowmanagementsystemen ein Referenzmodell. Dadurch werden neben der grundlegenden Struktur auch die zur Verfügung stehenden Schnittstellen beschrieben. Das Referenzmodell definiert ein Workflowmanagementsystemen durch die fünf Interfaces: Process Definition Tools, Workflow Client Applications, Invoked Applications Administration and Monitoring Tools und Other Workflow Enactment Services. Detailierte Informationen zu den Interfaces und dem Referenzmodell finden sich unter [All01]. Process Definition Tools Interface 1 Workflow API and Interchange Formats Administration and Monitoring Tools Interface 5 Workflow Enactment Services Workflow Workflow Workflow Engines Engines Engines Interface 4 Other Workflow Enactment Services Workflow Workflow Workflow Engines Engines Engines Interface 2 Interface 3 Workflow Client Applications Invoked Applications Abbildung B.1: Workflowreferenzmodell nach [Hol95] 97

120 Anhang B Anhang Workflows Integrationsprozesse Die Grafik B.2 zeigt eine schematische Darstellung eines Integrationsprozesse in SAP NetWeaver. Der Integrationsprozesse verbindet in dem gezeigten Beispiel ein SAP R/3 System mit einem anderen Nicht-SAP System. Abbildung B.2: Schematische Darstellung eines Integrationsprozesses Gegenüberstellung der Workflowtechnologien Nachfolgende Abbildung zeigt die Abdeckung der BPM Aktivitäten durch die in SAP zur Verfügung stehenden Produkte auf. Abbildung B.3: Gegenüberstellung von Workflowtechnologien in SAP anhand des Einsatzgebietes nach [Wil06] 98

121 Modellierung in Guided Procedure Die Modellierung, dargestellt in Abbildung B.4, von Guided Procedures erfolgt dialoggestützt im SAP Portal. Der Benutzter wird anhand dieser Dialoge durch die Konfiguration der Guided Procedure geführt, es ist demzufolge keine Modellierung im eigentlichem Sinne. Abbildung B.4: Dialoggesteuerte Modellierung einer Guided Procedure nach [SAP06a] 99

122 Anhang B Anhang Workflows 100

123 Anhang C NetWeaver Process Integration Abbildung C.1: Architektur Process Integration Abbildung C.2: Prozess der Nachrichtenzustellung innerhalb des Integration Servers 101

124 Anhang C Anhang NetWeaver 102

125 Anhang D Implementierung D.1 WebDynpro Komponente für Human Interaction erstellen Benutzeroberflächen für Guided Procedures können als WebDynpro Komponenten realisiert werden. Dazu muss im NetWeaver Developer Studio eine WebDynpro Development Component angelegt werden. Mit Hilfe des grafischen Editors, wird anschließend die Benutzeroberfläche gestaltet und die Interaktionen zwischen den einzelnen Sichten konfiguriert. Damit die WebDynpro Komponente jedoch in der Guided Procedures genutzt werden kann muss das Interface IGPWebDynproCO implementiert werden. Ebenso müssen Development Component Dependences für die Komponenten com.sap.security.api.sda, caf/eu/gp/api und caf/eu/gp/api/wd erstellt werden. Abbildung D.1: Implemented Interface der WebDynpro Komponenten einstellen 103

126 Anhang D Anhang Implementierung Im Component Controller werden daraufhin zwei zusätzliche Methoden, getdescription() und execute(), erstellt. Die getdescription() Methode definiert die Import- und Exportparameter für das Callable Object. 1 public com.sap.caf.eu.gp.co.api.igptechnicaldescription getdescription( java.util.locale locale ) { 2 //@@begin getdescription() 3 try { 4 this.textaccessor = wdcomponentapi.gettextaccessor(); 5 6 GPWebDynproResourceAccessor resourceaccessor = new GPWebDynproResourceAccessor( textaccessor); 7 IGPTechnicalDescription technicaldescription = GPCallableObjectFactory. createtechnicaldescription("co_name", "CO_DESCRIPTION",resourceAccessor, locale); 8 9 // Pre-existing input structure 10 IGPStructureInfo input = technicaldescription.getinputstructureinfo(); 11 IGPAttributeInfo kundeid = input.addattribute("kundenid", IGPAttributeInfo. BASE_STRING); 12 kundeid.setmultiplicity(igpattributeinfo.mulitiplicity_0_1); //Pre-existing structure for output parameters 15 IGPStructureInfo output = technicaldescription.getoutputstructureinfo(); 16 IGPAttributeInfo kreditvergabe = output.addattribute("kreditvergabe", IGPAttributeInfo.BASE_STRING); 17 kreditvergabe.setmultiplicity(igpattributeinfo.mulitiplicity_1_1); 18 return technicaldescription; 19 } 20 catch (GPInvocationException e) { } 23 //@@end 24 } Listing D.1: WebDynpro Komponente - Auszug 1 aus dem ComponentController Neben der getdescription() Methode, steht im Component Controller auch noch die Methode execute() zur Verfügung. Diese Methode wird beim Start des Callable Objects aufgerufen und dient der Implementierung der Logik hinter der Benutzeroberfläche. Außerdem findet hier auch die Übergabe der zuvor deklarierten Variablen statt. 1 public void execute( com.sap.caf.eu.gp.co.api.igpexecutioncontext executioncontext ) { 2 //@@begin execute() 3 String kundeid; 4 5 try { 6 this.executioncontext = executioncontext; 7 8 //Process the input parameters 9 IGPStructure input = executioncontext.getinputstructure(); 10 kundeid = (String) input.getattributeasstring("kundenid"); IKundeElement kunde = wdthis.wdgetcontext(). createandaddkundeelement(); 13 kunde.setid(kundeid); 14 } 15 catch (GPInvocationException e) { 104

127 D.1 WebDynpro Komponente für Human Interaction erstellen } 18 //@@end 19 } Listing D.2: WebDynpro Komponente - Auszug 2 aus dem ComponentController Damit bei Beendigung des Callable Objects die Ergebnisse der Verarbeitung zurückgegeben werden und das Callable Object geschlossen wird, ist zusätzlich die Methode complete() im Componente Controller zu implementieren. Diese Methode wird durch Klick auf den Beenden-Button in der WebDynpro Komponente aufgerufen. 1 public void complete(){ 2 //@@begin complete() 3 //Output 4 boolean kreditvergabe = wdthis.wdgetcontext().currentbewertungelement().getresult(); 5 6 try { 7 IGPStructure output = executioncontext.getoutputstructure(); 8 output.setattributevalue("kreditvergabe", kreditvergabe); 9 10 //complete Callable Object 11 executioncontext.processingcomplete(); 12 } 13 catch (GPInvocationException e) { } 16 //@@end 17 } Listing D.3: WebDynpro Komponente - Auszug 3 aus dem ComponentController 105

128 Anhang D Anhang Implementierung D.2 WebDynpro Komponente als Callable Object in Guided Procedure einbinden Die zuvor angelegte und auf dem Server ausgelieferte WebDynpro Komponente kann nun in die Guided Procedure integriert werden. Dazu wird in der Guided Procedure Designtime ein Callable Object vom Typ WebDynpro-Komponente (GP-Schnittstelle) angelegt. Anschließend wird die zuvor entwickelte Komponente aus der Liste ausgewählt. Die Im- und Exportparameter, welcher in der getdescription() Methode deklariert wurden, werden automatisch erkannt und eingebunden. Abbildung D.2: Integration der WebDynpro Komponente in die Guided Procedure 106

129 D.3 Guided Procedures Webservice D.3 Guided Procedures Webservice Das Starten der Guided Procedure wird durch einen Webservice realisiert. Dieser kann mit Hilfe des NetWeaver Developer Studios entwickelt werden. Dazu wird eine Development Component vom Typ EJB Module, sowie eine Development Component vom Typ Enterprise Application angelegt. In der Enterprise Application wird die EJB als Referenzprojekt angegeben. Anschließend werden die Development Component Dependences sowohl für das EJB als auch für die Enterprise Application gesetzt. Hierfür müssen die folgenden Komponenten referenziert werden: com.sap.security.api.sda, caf/eu/gp/api und com.sap.exception. Abbildung D.3: Guided Procedures Webservice. Anlegen der EJB DC (links) und Festlegen der Dependences (rechts) Daraufhin kann in der EJB Development Component eine EJB 3.0 Session Bean angelegt werden, welche die Basis für den zu entwickelnden Webservice darstellt. In dieser Session Bean wird eine Methode startprocess() implementiert, welche den Aufruf der Guided Procedure übernimmt. Damit die richtige Guided Procedure gestartet wird, ist es wichtig das die Process-Template-ID der Guided Procedure bekannt ist. Des Wei- 107

130 Anhang D Anhang Implementierung teren müssen die Bezeichnung der Parameter exakt mit den technischen Namen der Gudied Procedure Parameter übereinstimmen, da es sonst zu Fehlern in der Verarbeitung kommt! 1 private final String processid = "C3F70711C7FA11DCA5AF001558C3EA5A"; 2 3 private static final String KUNDENID = "KundenID"; 4 private static final String CALLBACKURL = "CallbackURL"; 5 6 private static String INITIATOR_ID = "Administrator"; 7 8 public String startprocess( 9 String kundenid, 10 String initiator, 11 String callbackurl 12 ) throws Exception{ //Überprüfen ob Nutzer wirklich vorhanden, ansonsten Standardnutzer 15 try{ 16 UMFactory.getUserFactory().getUserByLogonID(initiator); 17 INITIATOR_ID = initiator; 18 } 19 catch (Exception e) { 20 INITIATOR_ID = "Administrator"; 21 } IUser user = UMFactory.getUserFactory().getUserByLogonID(INITIATOR_ID); 24 IGPUserContext usercontext = GPContextFactory.getContextManager().createUserContext(user) ; 25 IGPProcess process = GPProcessFactory.getDesigntimeManager().getActiveTemplate(processId, usercontext); IGPRuntimeManager rtm = GPProcessFactory.getRuntimeManager(); 28 IGPProcessRoleInstanceList roles = rtm.createprocessroleinstancelist(); IGPStructure params = GPStructureFactory.getStructure(process.getInputParameters()); 31 params.setattributevalue(kundenid, kundenid); 32 params.setattributevalue(callbackurl, callbackurl); IGPProcessInstance prinstance = rtm.startprocess( 35 process, 36 UD_NAME, 37 UD_DESCRIPTION, 38 user, 39 roles, 40 params, 41 user); return prinstance.getid(); 44 } Listing D.4: Guided Procedures Webservice - Auszug Ist die EJB Session Bean fertig implementiert, kann daraus automatisch ein Webservice generiert werden. Dadurch werden Webservice Annotations erstellt und die Webservice Beschreibung generiert. Anschließend kann der Webservice auf den Application Server ausgeliefert werden. 108

131 D.4 Servlet erstellen D.4 Servlet erstellen Damit der Guided Procedures Webservice im SAP ECC System auch genutzt werden kann, muss zusätzlich ein Servlet entwicklet werden. Dieses Servlet fungiert als ein Adapter zwischen dem SAP ECC System und dem Webservice und vermittelt die Kommunikation zwischen diesen. Das Servlet wird, wie auch die anderen Komponenten, mit Hilfe des NetWeaver Developer Studios entwickelt. Dazu wird eine Development Component vom Typ Web Module, sowie eine Development Component vom Typ Enterprise Application, die das eigentliche Web Module kapselt, angelegt. In dem Web Module wird ein Servlet vom Typ Web 2.5 erzeugt und die Methode doget() generiert. Anschließend wird die WSDL des zuvor erstellten Webservices in das Projekt importiert und daraus ein Java Proxy generiert. Abbildung D.4: Generierung eines Java Proxys Daraufhin kann das eigentlich Servlet implementiert werden. Dazu wird die doget() Methode, welche den HTTPRequest entgegennimmt, vervollständigt. Hierfür werden die Inputparameter verarbeitet und gespeichert. Daraufhin wird der zuvor erzeugten Proxy des Webservices aufgerufen und der startprocess() Methode die Inputparameter übergeben. 109

132 Anhang D Anhang Implementierung 1 public ResultServlet() { 2 super(); 3 try { 4 service = new ResultGPWSBeanService(); 5 } 6 catch (MalformedURLException e) { 7 e.printstacktrace(); 8 } 9 } protected void doget(httpservletrequest request, HttpServletResponse response) 12 throws ServletException, IOException { if (service!=null){ 15 ResultGPWSBean pt = service.getresult_gpwsbeanport(); for (Entry entry : (Set<Entry>) request.getparametermap().entryset()) { 18 processparameter(entry); 19 } try { 22 String result = pt.startprocess(kundenid, 23 initiator, 24 callbackurl); 25 } 26 catch (StartProcessFault e) { 27 e.printstacktrace(); 28 } 29 } 30 } Listing D.5: Servlet - Auszug 110

133 D.5 Aufruf des Webservices aus dem SAP Business Workflow D.5 Aufruf des Webservices aus dem SAP Business Workflow Externe Services müssen mittels der Transaktion WF_EXSTRV manuell im System registriert werden, siehe Abbildung D.5. Dazu wird ein neuer Service angelegt (Abbildung D.6) und die notwendigen Werte für Host, Port und Pfad angegeben. Abbildung D.5: Neuen Service im SAP System registrieren Abbildung D.6: Neuen Service anlegen Daraufhin werden zu diesem Service die notwendigen Import- und Exportparameter definiert, damit diese im SAP Business Workflow verwendet werden können. Sind alle Einstellungen vorgenommen, kann man sich aus dem erstellten Service eine Aufgabe generieren lassen, siehe Abbildung D.8. Abbildung D.7: Serviceparameter festlegen 111

134 Anhang D Anhang Implementierung Abbildung D.8: Aufgabe generieren Diese generierte Aufgabe kann nun als Aktivität im Workflow Builder in den SAP Business Workflow verwendet werden. Abschließend wird noch der Datenfluss festgelegt, siehe Abbildung D.9, und der externe Service kann verwendet werden. Abbildung D.9: Aufgabe im Workflow Builder einfügen (links) und Datenfluss festlegen (rechts) 112

135 D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine Bevor ein Integrationsprozess erstellt werden kann, muss im System Landscape Directory (SLD) ein Produkt und eine dazugehörige Softwarekomponente angelegt werden (siehe Abbildung D.10). Abbildung D.10: SLD - Anlegen eines Produktes (links) und der dazugehörigen Softwarekomponente (rechts) Anschließend muss das eben angelegte Produkt, sowie die dazugehörige Softwarekomponente, einem Technischen System und einem Business System zugeordnet werden (siehe Abbildung D.11). Abbildung D.11: SLD - Zuordnung Produkt zu einem Technischen System 113

136 Anhang D Anhang Implementierung Nun kann diese Softwarekomponente im Integration Builder - Designtime (auch als Integration Repository bezeichnet) importiert werden (siehe Abbildung D.12). Abbildung D.12: Design - Softwarekomponente aus SLD importieren Dafür muss zunächst ein Namespace angelegt werden (siehe Abbildung D.13). Abbildung D.13: Design - Namespace für Softwarekomponente anlegen Anschließend kann ein Integrationsprozess erstellt werden (siehe Abbildung D.14). Abbildung D.14: Design - Integrationsprozess erstellen 114

137 D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine Daraufhin kann die WSDL Beschreibung des zu verwendenden Webservices importiert werden, wie in Abbildung D.15 dargestellt. Dadurch werden die Message-Typen sowie die Datentypen beschrieben und müssen nicht von Hand angelegt werden. Abbildung D.15: Design - WSDL Beschreibung des Webservices importieren Anschließend wird ein abstaktes synchrones Message-Interface für die Kommunikation mit dem Webservice angelegt (siehe Abbildung D.16). Zusätzlich zu diesem muss für den Request, Response und den Callback je ein abstrakt asynchrones Message- Interface für die interne Kommunikation angelegt werden. Abbildung D.16: Design - Message-Interface anlegen 115

138 Anhang D Anhang Implementierung Danach muss für jedes abstrakt asynchrones Message-Interface ein entsprechender Container angelegt werden (siehe Abbildung D.17). Abbildung D.17: Design - Container für die Message-Interfaces anlegen Diese Container werden für die Request- bzw. Response Message im synchronen Sendeschritt benötigt, welcher nun im Integrationsprozess eingefügt werden kann (siehe Abbildung D.18). Der Aufruf des Webservices erfolgt Synchron. Als synchrones Interface wird das zuvor definierte abstakt synchrone Message-Interface ausgewählt, die Request bzw. Response-Message sind die eben erstellen Container. Abbildung D.18: Design - Senden-Schritt in den Integrationsprozess einfügen Um sicherzustellen, dass der Rückruf des Webservices auch an die richtige Workflowinstanz geleitet wird, muss eine entsprechende Korrelation erstellt werden. Dies geschieht im Korrelationseditor, wo das Korrelationsattribut und die daran beteiligten Nachrichten festgelegt werden (siehe Abbildung D.19). 116

139 D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine Abbildung D.19: Design - Korrelation erstellen Die eben erstellte Korrelation kann nun im Sende-Schritt aktiviert werden (siehe Abbildung D.20). Abbildung D.20: Design - Korrelation im Sendeschritt aktivieren Anschließend wird ein Empfangen-Schritt im Integrationsprozess platziert, welcher den Rückruf des Webservices entgegennimmt. Als verwendete Korrelation wird die entsprechende Korrelations-ID ausgewählt (siehe Abbildung D.21). 117

140 Anhang D Anhang Implementierung Abbildung D.21: Design - Empfangen-Schritt in Integrationsprozess einfügen Damit der Integrationsprozess auch gestartet werden kann, wird ein weiterer Empfangen- Schritt am Anfang des Integrationsprozesses eingefügt. Dieser wird als auslösendes Ereignis definiert und nimmt entsprechende Nachrichten entgegen (siehe Abbildung D.22). Abbildung D.22: Design - Empfangen-Schritt zum Starten des Integrationsprozesses 118

141 D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine Das Design des Integrationsprozesses ist hiermit komplett. Jetzt muss dieser entsprechend konfiguriert werden. Dazu wird der Integration Builder - Configuration (auch als Integration Directory bezeichnet) gestartet und ein neues Konfigurationsszenario angelegt. Anschließend werden die zuvor im SLD zugeordneten Business-Systeme importiert und der Integrationsprozess aus dem Integration Repository übernommen (siehe Abbildung D.23). Abbildung D.23: Konfiguration - Import des Integrationsprozesse aus dem Integration Repository Infolgedessen werden die beteiligten Empfänger- und Senderinterfaces automatisch aus dem Integrationsprozess importiert (siehe Abbildung D.24). Abbildung D.24: Konfiguration - Empfänger- und Senderinterfaces 119

142 Anhang D Anhang Implementierung Anschließend muss ein Kommunikationskanal für den Aufruf des Webservices zum starten der Guided Procedure erstellt werden. Hierfür wird der bereits vorhandene SOAP Adapter genutzt (siehe Abbildung D.25). Abbildung D.25: Konfiguration - Kommunikationskanal erstellen Danach wird eine neue Empfängerermittlung für diese Kommunikation angelegt (siehe Abbildung D.26). Als Senderservice wird der Integrationsprozess ausgewählt, das Senderinterface muss dem zuvor erstelltem abstrakt synchronen Message-Interface entsprechen. Abbildung D.26: Konfiguration - Empfängerermittlung anlegen 120

143 D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine Für diese Empfängerermittlung wird nun eine neue Interfaceermittlung sowie eine Empfängervereinbarung angelegt (siehe Abbildung D.27 und D.28). Abbildung D.27: Konfiguration - Interfaceermittlung Abbildung D.28: Konfiguration - Empfängervereinbarung 121

144 Anhang D Anhang Implementierung Die Konfiguration für den Aufruf des Webservice zum Starten der Guided Procedure ist dadurch abgeschlossen. Nun wird analog dazu, die Konfiguration für den Rückruf angelegt. Hierfür wird ebenso ein Kommunikationskanal vom Typ SOAP Adapter erstellt. Allerdings ist die Richtung des Kommunikationskanals nun Sender (siehe Abbildung D.29) Abbildung D.29: Konfiguration - Kommunikationskanal Callback Im Gegensatz zu der Konfiguration zum Aufruf des Webservice, muss nun jedoch zuerst eine Senderermittlung durchgeführt werden (siehe Abbildung D.30). Abbildung D.30: Konfiguration - Senderermittlung Callback 122

145 D.6 Aufruf des Webservices aus einem Integrationsprozess der Process Engine Anschließend erfolgt auch hier die Empfänger- sowie die Interfaceermittlung (siehe Abbildung D.31 sowie D.32). Abbildung D.31: Konfiguration - Empfängerermittlung Callback Abbildung D.32: Konfiguration - Interfaceermittlung Callback Damit der Integrationsprozess auch gestartet werden kann, muss außerdem noch ein Kommunikationskanal, eine Empfängerermittlung und eine Interfaceermittlung für die auslösende Nachricht angelegt werden. Das Vorgehen ist hierbei jedoch analog zu dem Aufruf des Webservice. 123

146 Anhang D Anhang Implementierung Die Konfiguration ist hiermit abgeschlossen und der Integrationsprozess kann verwendet werden. Zuvor ist es jedoch sinnvoll den Integrationsprozess mit Hilfe eines einfachen HTTP-Clients zu testen (siehe Abbildung D.33) um zu überprüfen ob alle Einstellungen fehlerfrei sind. Abbildung D.33: Integrationsprozess mit Hilfe des HTTP Clients testen 124