Business Process Management und Workflow
Werbung
Business Process Management und Workflow-Technologie Juni 2005 Der vorliegende Text darf für Zwecke der Vorlesung Business Process Management und Workflow-Technologie des Autors vervielfältigt werden. Eine weitere Nutzung bedarf der schriftlichen Einverständnis des Autors. © Copyright International Business Machines Corporation 2001,2005. Alle Rechte vorbehalten. Inhaltsverzeichnis Abbildungsverzeichnis . . . . . . . . v Vorwort . . . . . . . . . . . . . . vii Literaturverzeichnis . . . . . . . . . ix Kapitel 1. Einführung . . . . . . . . . 1 Die Systemarchitektur . . . . . . . . . Von der Modellierung zur Ausführung eines Prozesses . . . . . . . . . . . . . Wer macht was . . . . . . . . . . Schritte zur Erstellung eines lauffähigen Workflows . . . . . . . . . . . . Die Bearbeitung einer Process Instance . . Grundlegende Elemente eines Workflow-Modells Die wichtigsten Komponenten eines Workflow-Systems . . . . . . . . . . Aufgaben . . . . . . . . . . . . . . . 2 . . . 3 . 3 . . . . 3 . 3 . 3 . . . 4 . 4 Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems . . . . . . . . . . 5 Activities . . . . . . . . . . . . . . . 5 Container . . . . . . . . . . . . . . . 6 Navigation . . . . . . . . . . . . . . . 7 An Organizational Model integrated into a Workflow System . . . . . . . . . . . . . . . . 8 Die Zuweisung von Activities an Personen . . . . 9 Separate Staff-Datenbank . . . . . . . . . . 10 Systemstruktur eines Workflow-Systems . . . . . 10 XML als Invocation-Interface . . . . . . . . 11 Audit Trail . . . . . . . . . . . . . . . 11 Suche nach einem Vorgang . . . . . . . . . 12 Überwachung von Business-Zielen . . . . . . 12 Error Log . . . . . . . . . . . . . . . 13 Tracing . . . . . . . . . . . . . . . . 13 IT-orientierte Statistik, Monitoring . . . . . . . 14 Aufgaben . . . . . . . . . . . . . . . 14 Kapitel 3. Allgemeine Aspekte eines Workflow-Systems . . . . . . . . . . 17 Drei Dimensionen . . . . . . . . . . . . Kategorien von Workflow . . . . . . . . . Kriterien eines Geschäftsprozesses . . . . . . . Ändern von Geschäftsprozessen . . . . . . . Abgrenzung von Business Process Reengineering zur Geschäftsprozessoptimierung . . . . . . Ansätze für eine Geschäftsprozessoptimierung. . Beispiel der Optimierung des Geschäftsprozesses Scheckeinreichung . . . . . . . . . . . . Phasen der Geschäftsprozessoptimierung . . . Aufgaben . . . . . . . . . . . . . . . © Copyright IBM Corp. 2001,2005 17 17 18 19 19 20 20 22 23 Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden. . . . . . . . . . . . . . . 25 Relationales Datenbanksystem . . . . . . . Tabellen als Strukturierungsmittel von Daten . Trennung des Anwendungsprogramms von den Zugriffspfaden zur Datenbank . . . . . . Transaktionen . . . . . . . . . . . Verteilte Transaktionen . . . . . . . . . Two Phase Commit . . . . . . . . . . Messages und Queues . . . . . . . . . Message Queueing als Alternative zu einer verteilten Transaktion . . . . . . . . . Architektur eines Servers . . . . . . . . . Ablauf einer Servertransaktion . . . . . . . Verkettete Transaktionen . . . . . . . . . Kennzeichen einer verketteten Transaktion . . Prozessnavigation als verkettete Transaktion . Businesstransaktionen . . . . . . . . . . Compensation Spheres . . . . . . . . Atomic Spheres . . . . . . . . . . . Ersatzlösung für verteilte Transaktionen . . . Web-basierte Architekturen . . . . . . . . Safe Applications . . . . . . . . . . . Aufgaben . . . . . . . . . . . . . . . 25 . 25 . . . . . 25 25 27 27 28 . . . . . . . . . . . . . 30 31 34 34 34 35 36 36 38 38 39 40 40 Kapitel 5. Von 1-tier zu n-tier Systemen 43 Klassische Großrechnersysteme . Client-Server Systeme . . . . Clients als Integrationsplattform Middleware . . . . . . . Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 45 46 47 48 Kapitel 6. Komponenten eines Workflow-Systems . . . . . . . . . . 49 Kernel . . . . . . . . . . . . . . . ID Handling . . . . . . . . . . . . C++ spezifische Kernelmethoden . . . . . Messagelayer . . . . . . . . . . . . . Das Interface zur Datenbank . . . . . . . Verwendete Funktionen des Datenbanksystems Database Access Layer . . . . . . . . . TOM (Tiny Object Manager) . . . . . . . Staff Resolution . . . . . . . . . . . Server Framework . . . . . . . . . . . FDL Parser, Verifier . . . . . . . . . . . Regression Test . . . . . . . . . . . . . . . . . . . . . . . 49 50 51 51 52 52 53 54 54 57 57 58 Kapitel 7. Prozesse eines Workflow-Systems . . . . . . . . . . 59 Administration Server . . . Administration Client . . . Navigation, Execution Server Program Execution Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 59 60 60 iii Scheduling Server . . Cleanup Server . . . Workflow Client API . Web Client . . . . Staff Administration API LDAP Bridge . . . . Buildtime . . . . . Workload Management Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 61 61 62 62 62 63 63 63 Kapitel 8. Middleware: Standards und Produkte . . . . . . . . . . . . . . 65 RPC (Remote Procedure Call) . . . TP-Monitore (Transaction Processing) . Object Broker . . . . . . . . . Message Queueing . . . . . . . iv . . . . . . . . . . . . . . . . . . . . 65 65 66 66 Business Process Management und Workflow-Technologie Message Broker . . . . . . . . . . . Web Services . . . . . . . . . . . . Probleme bei der B2B Integration . . . . Verwendete Protokolle bei Web Services . . BPEL (BPEL4WS: Business Process Execution Language for Web Services) . . . . . . J2EE . . . . . . . . . . . . . . . .Net . . . . . . . . . . . . . . . Workflow . . . . . . . . . . . . . Vertikale Standards . . . . . . . . . . Aufgaben . . . . . . . . . . . . . . . . . . . . . 66 67 67 67 . . . . . . . . . . . . 69 69 69 70 70 70 Kapitel 9. Übungsaufgaben . . . . . . 71 Index . . . . . . . . . . . . . . . 73 Abbildungsverzeichnis 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Diagramm des Prozesses in einem graphischem Modellierungstool: . . . . . . . . . . 1 Die Interfaces der Workflow-Engine: . . . . 2 Die Modellierungsebenen von Geschäftsprozessen . . . . . . . . . . 3 Three-Tier Architektur . . . . . . . . . 4 Das Datenmodell eines Workflow-Systems 6 Navigation . . . . . . . . . . . . . 7 The entity-relationship diagram for staff data 8 Kontext einer Staff Resolution . . . . . . . 9 API-Struktur . . . . . . . . . . . . 10 Die Dimensionen von Workflow . . . . . 17 Eine Klassifikation von Workflow . . . . . 18 Orginaler Prozess Scheckeinreichung . . . . 21 Verbesserter Prozess Scheckeinreichung 21 Eine erfolgreiche Transaktion . . . . . . . 26 Eine Transaktion, bei der ein Fehler zum Abbruch der Transaktion führt . . . . . . 26 Die Beteiligten einer verteilten Transaktion 27 Die Statusübergänge beim Transaction Coordinator . . . . . . . . . . . . 27 Die Statusübergänge beim Resource Manager 28 Verteilte Transaktion, an der ein Datenbanksystem und ein Messagingsystem teilnimmt. . . . . . . . . . . . . . 29 Asynchrone verteilte Transaktionen mit Messaging . . . . . . . . . . . . . 30 Synchrone verteilte Transaktion . . . . . . 31 Pro Client ein Prozeß . . . . . . . . . 31 Pro Clientrequest ein Prozeß . . . . . . . 32 Ein Prozess bearbeitet alle Clientrequests 33 © Copyright IBM Corp. 2001,2005 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Ablauf einer Servertransaktion . . . . . . Zur Illustration der Navigation . . . . . . Transaktionsgrenzen bei der Navigation durch einen einfachen Prozess . . . . . . . . Reisebuchung mit Konsistenzbedingung als Workflow . . . . . . . . . . . . . Kompensation explizit modelliert . . . . . Kompensation implizit durch Compensation Sphere . . . . . . . . . . . . . . Aufruf eines Programms ohne Transaktionssicherheit . . . . . . . . . Sicherer Aufruf einer Program Activity Two-Tier Client-Server Konfiguration . . . . 4 Tier Client-Server Konfiguration . . . . . Die Komponenten einer Anwendung . . . . Die Struktur eines 1-tier Systems . . . . . Die Struktur eines 2-tier Systems (Client-Server) . . . . . . . . . . . Clients als Integrationsplattform . . . . . Middleware als Integrationsplattform . . . . Thin clients und Application Server . . . . Die Code-Ebenen beim Datenbankzugriff Der Tiny Object Manager . . . . . . . . Aufrufhierarchie Staff Resolution . . . . . Vereinfachtes Statusübergangsdiagramm von Activities . . . . . . . . . . . . . Die Architektur des Client APIs . . . . . . Die Architektur des Staff Administration APIs Architektur der LDAP Bridge . . . . . . Struktur einer SOAP Message . . . . . . 34 35 36 36 37 37 38 38 39 40 43 44 45 46 47 48 52 54 55 60 61 62 63 68 v vi Business Process Management und Workflow-Technologie Vorwort Dieser Text ist Teil des Skripts zur Vorlesung Workflow, Business Process Management von Dr. Andreas Wickenhäuser in Jena. Das Skript gibt nicht den vollständigen Stoff der Vorlesung wieder. Ein Mitschrieb ist während der Vorlesung fär den erfolgreichen Abschluß der Prüfung notwendig. Dr. Andreas Wickenhäuser Geboren 1961 in Stuttgart, verheiratet, zwei Kinder. 1981-1988 Diplomstudium Mathematik und Informatik an der FernUniversität Hagen. 1986-1987 Mitarbeit in einer Softwarefirma für Apothekensysteme. 1988-1990 Promotion in Mathematik an der FernUniversität Hagen. 1989- Mitarbeit bei der IBM 1994- Mitarbeit bei der Entwicklung von Workflow-Software 1997- Dozententätigkeit Telefon: 07031 164108 (Geschäft), 0711 734367 (privat) Internet: [email protected] © Copyright IBM Corp. 2001,2005 vii viii Business Process Management und Workflow-Technologie Literaturverzeichnis Neben dem Vorlesungsskript empfehle ich die Verwendung eines Buches wie Production Workflow.Die meisten hier aufgeführten Bücher gehen in ihrem Gebiet weit über den Umfang der Vorlesung hinaus und sind als weiterführende Literatur gedacht. Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju: Web Services Springer Verlag 2004, 350 Seiten. Beschreibt Konzepte und Architektur sowohl von Web Services als frühere Beispiele von Middleware. Ohne auf die technischen Details der einzelnen Produkte einzugehen wird hier die Entwicklung der Software hin zu den Web Servies beschrieben. William Crawford, Jonathan Kaplan: J2EE Design Patterns O’Reilly 2002, 350 Seiten. Andreas Gadatsch: Management von Geschäftsprozessen Vieweg 2001, 239 Seiten. Betrachtet Geschäftsprozesse und Workflow von der Anwenderseite aus. Der Schwerpunkt des Buches liegt in der Analyse und Beschreibung von Geschäftspozessen. Ulrike Hammerschall: Verteilte Systeme und Anwendungen Pearson Studium 2005, 208 Seiten. Ist im ersten Teil eine systematische Einführung in das Thema. Im zweiten Teil werden aktuelle Produkte und Standards vorgestellt wobei hier weniger technische Details im Vordergrund stehen sondern versucht wird, die Architektur dieser Produkte vorzustellen. Vorgestellt werden neben anderen: Web Services, J2EE, .Net. Internet-Applicationserver hier nicht beschrieben sind, gibt dieses Buch viele Einblicke sowohl von der Anwendungsseite als bei den technischen Details in dieses Thema. MQSeries Workflow Benutzerdokumentation Empfehlenswert im Rahmen der Vorlesung ist zuerst Concepts and Architecture. IBM Redbooks Weitere Literatur zu WebSphere und MQSeries Workflow und anderen Produkten der IBM. Frei erhältliche Bücher im pdf-Format. Meistens wird beschrieben, wie mit den konkreten Produkten ein Anwendungsproblem gelöst werden kann. Die zugrunde liegende Architektur wird weniger beschrieben. Siehe unter www.redbooks.ibm.com. Robert Orfali, Dan Harkey, Jeri Edwards: Client/Server Survival Guide www.wiley.com/compbooks/ 1999, 760 Seiten. Unterhaltsame und informative Einführung in verteilte Anwendungen, Themen sind: Datenbanken, verteilte Transaktionen, verteilte Objekte. Gibt auch eine Übersicht über das aktuelle Marktgeschehen in diesen Bereichen. Andrew S. Tanenbaum, Maarten van Steen: Distributed Systems Prentice Hall 2002, 800 Seiten. Gut lesbare Einführung in dieses Gebiet, der Schwerpunkt liegt eher auf den grundliegenden Prinzipien statt auf aktuell vorhandenen Produkten. Frank Leymann, Dieter Roller: Production Workflow, Concepts and Techniques Prentice-Hall 2000, 479 Seiten. Betrachtet vor allem die technische Seite eines Workflow-Systems. Jim Gray, Andreas Reuter: Transaction Processing: Concepts and Techniques Morgan Kaufmann 1993, 1070 Seiten. Standardwerk über Transaktionen und Transaktionsmanager. Obwohl das Buch älter ist und moderne © Copyright IBM Corp. 2001,2005 ix x Business Process Management und Workflow-Technologie Kapitel 1. Einführung Zur Einführung dient der folgende Prozess: Ein Onlineversandhaus hat folgenden Bestellprozess: Abbildung 1. Diagramm des Prozesses in einem graphischem Modellierungstool: Prozessstart Der Kunde erstellt mit einer Web-Applikation die Bestellung. Wenn er sie abgeschlossen hat, wird sie als XML-String dem neu gestarteten Prozess übergeben. Reservierung Die Bestellung wird in einer Datenbank gespeichert, die bestellte Ware wird reserviert, die Bestellung erhält eine Nummer. Zahlungsweise Die Bonität des Kunden wird abhängig von der Zahlungsweise geprüft. Der Zahlungsvorgang kann eingeleitet werden. Versand Der Versand bearbeitet die Bestellung, die Ware wird abgeschickt. © Copyright IBM Corp. 2001,2005 1 Warten Der Prozess wird für einige Tage angehalten, bis ein Geldeingang zu erwarten ist. Bestätigung schicken Eine E-Mail wird an den Kunden geschickt. Geldeingang prüfen Je nach Zahlungsweise wird der Geldeingang geprüft. Inkasso Falls die Rechnung nicht vollständig beglichen ist, wird eine Mahnung geschickt. Die Systemarchitektur Web Frontend Internet Web Frontend Intranet Buchhaltung Workflow Engine Bestell, Artikel DB Mail Versand Abbildung 2. Die Interfaces der Workflow-Engine: Dieses Beispiel erläutert die folgenden Schlagworte: Workflow Die Bearbeitung eines Geschäftsvorfalls (Process Instance) nach vorgegebenen Regeln. Dieser Begriff wird oft verwendet, wenn die einzelnen Schritte (Activities) von Personen ausgeführt werden. Enterprise Application Integration (EAI) Die Integration von Anwendungen, damit Geschäftsprozesse effizient bearbeitet werden können. Business Process Management (BPM) Ähnliche Bedeutung wie Workflow. Meint aber auch die Überwachung und Steuerung von Geschäftsprozessen. 2 Business Process Management und Workflow-Technologie Von der Modellierung zur Ausführung eines Prozesses Wer macht was Business Modeling Management, Consultant Workflow Modeling WF Specialist Function Programming Programmer Abbildung 3. Die Modellierungsebenen von Geschäftsprozessen Schritte zur Erstellung eines lauffähigen Workflows 1. Definition der Prozessmodelle und anderer Daten mit einem Modellierungstool. 2. Codierung oder Integration der von den Activities ausgeführten Programme. 3. Definition der Personen und ihrer Relationen im System. Ein ausführbares Prozessmodell wird Process Template genannt. Die Bearbeitung einer Process Instance 1. Ein Prozess wird gestartet, es wird also eine neue Process Instance erzeugt. 2. Eine zuständige Person kann eine Activity starten, diese kann dann nicht mehr von einer anderen Person gestartet werden. 3. Nach Abschluß der Activity wird nach den Regeln des Prozess Templates weiternavigiert. 4. Der Prozess ist beendet, wenn keine Activity mehr gestartet werden kann. Grundlegende Elemente eines Workflow-Modells Process Template Definiert, wie ein Vorgang (Process Instance) zu bearbeiten ist. Das Process Template kann als Graph dargestellt werden. Die Knoten sind Activities und die Kanten definieren den Kontroll- und Datenfluß. Process Instance Beschreibt den aktuellen Zustand eines Vorgangs. Activity Ist eine Ausführungseinheit eines Prozesses. Activities können weitere Activities enthalten ähnlich wie bei Blöcken in Programmiersprachen. Program Eine elementare Activity kann die Ausführung durch ein Program sein. Control Connector Definiert zeitliche Abhängigkeiten zwischen den Activities. Kapitel 1. Einführung 3 Data Connector Damit können Daten zwischen den einzelnen Activities ausgetauscht werden. Work Item Ein Work Item repräsentiert eine startbereite Activity für eine zuständige Person. Worklist In der Worklist (auch Todo-List) sind die Work Items einer Person zusammengefaßt. Work Items können z.B. gestartet werden. Die wichtigsten Komponenten eines Workflow-Systems MQSeries Workflow Client Tier one Buildtime components MQSeries Workflow Server (hot pool) Message queues Database client Database Server Tier two Runtime database FDL Import/Export Buildtime database Tier three Abbildung 4. Three-Tier Architektur Aufgaben 1. Die folgenden Daten werden bei Process Instances oder Process Templates benötigt. Überlegen Sie, welche dieser Daten Bestandteil der Template-Datenstrukturen sind und welche Bestandteil der Instance-Datenstrukturen sind. Bei unklaren Fällen versuchen Sie diese zu präzisieren und dann zuzuordnen: a. Die Zeiten, zu denen einzelne Activities ausgeführt wurden. b. Informationen über die zeitliche Abhängigkeit der Ausführung von Activities. c. Typ und Werte der Daten, die zwischen den Activities ausgetauscht werden. d. Name eines Prozesses. 4 Business Process Management und Workflow-Technologie Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems Activities Hier werden die einzelnen Schritte eines Prozesses ausgeführt. Activities können sein: Program Activities Hier wird ein Programm aufgerufen. Late Binding möglich. Block Activities Block Activities sind vergleichbar mit Funktionsaufrufen bei einer Programmiersprache. In einem Block kann ein Netzwerk von weiteren Activities definiert sein, die durchlaufen werden müssen, damit der Block abgearbeitet ist. Process Activities Hier wird eine neue Prozessinstanz gestartet. Zu welchem Prozesstemplate diese Instanz gehört, kann auch dynamisch bestimmt werden. Bei einem Programm würde dies einem Funktionsaufruf in einer DLL (Dynamic Link Library) entsprechen. Activities haben im wesentlichen folgende Eigenschaften: Startbedingung Die Activity kann gestartet werden, wenn mindestens ein eingehender Kontrollkonnektor wahr ist oder wenn alle Kontrollkonnektoren war sind. Hat eine Activity keine eingehenden Kontrollkonnektoren, so wird diese Prüfung übersprungen. Starttyp Dieser kann manuell oder automatisch sein. Manuelle Activities sind typischerweise Programme, die mit einer Person interagieren. Automatische Activities sind Programme, die ohne Benutzerinteraktion laufen, oder auch Blocks oder Subprocesses, die bei Gültigkeit der Startbedingung sofort gestartet werden können. Invocation 1. Wie und wo wird das Programm aufgerufen und ausgeführt ? Das Spektrum reicht von einem lokalen Funktionsaufruf auf dem Workflow-Server bis zum Aufruf eines Web-Services über das Internet. 2. Gibt es Benutzerinteraktion in der Activity ? Wenn ja wird das Programm lokal auf der Maschine des Benutzers ausgeführt oder z.B. auf einem Applicationserver. Wenn nicht (z.B. Backend-Anwendung) gibt es mehr Freiheiten. 3. Werden bei der Invocation Standards unterstützt oder gibt es propriätäre Elemente ? Staff Resolution Hier kann bestimmt werden, bei wem diese Activity als Item in der Workliste erscheint, wer diese Activity also starten kann. Exitbedingung Die Exitbedingung entspricht der Abbruchbedingung einer Do-While Schleife in einer Programmiersprache. © Copyright IBM Corp. 2001,2005 5 Expiration Wenn eine Activity zu lange nicht abgeschlossen wird, kann einfach weiternavigiert werden. Damit können zeitliche Abhängigkeiten modelliert werden. Notification Wenn eine Activity zu lange nicht abgeschlossen wird, kann eine andere Person benachrichtigt werden. Diese erhält dann ein sogenanntes Notification Item in die Workliste gestellt. Container Bei der Bearbeitung einer Prozessinstanz fallen im Allgemeinen Daten an, die Process Process Input Container Activity Activity Input Container Activity Process Output Container Output Container Abbildung 5. Das Datenmodell eines Workflow-Systems gespeichert werden müssen. Abhängig von diesen Daten sind dann später Entscheidungen zu treffen oder die Daten beeinflussen die Ausführung von späteren Activities. Am Beginn jedes Prozesses und jeder Activity steht ein Inputcontainer. Entsprechend steht am Ende ein Outputcontainer. Activities können aus ihren Inputcontainern lesen und in die Outputcontainer schreiben. Datenkonnektoren können definiert werden, die dafür sorgen, daß die Daten wie gewünscht durch den Prozess geroutet werden. Die Container sollten im Wesentlichen Referenzen enthalten. Werden beispielsweise in einer Versicherung eingehende Briefe gescannt und dann mit Workflow bearbeteitet, so sollten diese Briefe dann in einem Imagingsystem gespeichert sein. Die Container werden dann einige Schlüsseldaten wie Kundenname und Kundennummer enthalten sowie Referenzen auf die entsprechenden Dokumente in dem Imagingsystem. Die Programm Activitäten können dann diese Referenzen auflösen und dem Sachbearbeiter die zur Bearbeitung des Vorgangs notwendigen Dokumente vorlegen. Designalternativen für das Datenmodell eines Workflow-Systems Datentypen Die verwendbaren Datentypen können fest vorgegeben sein oder über Schnittstellen frei definierbar sein. Lokalität Innerhalb eines Prozesses können die Container jeweils lokale Input- oder 6 Business Process Management und Workflow-Technologie Outputcontainer sein. Oder ein globaler Container existiert, auf den alle Activities lesend und schreibend zugreifen können. Persistenz Speziell bei lokalen Containern können diese persistent sein, sodaß zur Auswertung von Bedingungen und bei der Staffresolution darauf zugegriffen werden kann, ohne daür spezielle Mappings definieren zu müssen. Sichtbarkeit Container enthalten oft Daten wie Kundennummern, Auftragsnummern, Termine. Queries über die Prozessinstanzen mit Filter- oder Ordnungskriterien für diese Daten sind oft sinnvoll. Auch die Speicherung dieser Daten mit Auditevents (siehe „Audit Trail” auf Seite 11) zu dieser Prozessinstanz kann sinnvoll sein. Navigation Die Reihenfolge der Bearbeitung der Activities wird durch Kontrollkonnektoren A Transition Condition: Zusatzprüfung=1 C B Exit Condition: rc=1 OR D E Abbildung 6. Navigation bestimmt. Die wesentlichen Regeln der Navigation sind: 1. Die Kontrollkonnektoren bilden einen gerichteten azyklischen Graphen. 2. Schleifen (genauer Do-While Schleifen) sind möglich durch die Definition einer Exit-Condition der Activity. Ist beim Abschluß der Activity die Exit-Condition nicht erfüllt, wird die Activity erneut gestartet. 3. Activities ohne eingehenden Kontrollkonnektoren können gleich gestartet werden. 4. Ist eine Activity beendet und die Exitbedingung erfüllt, werden alle Kontrollkonnektoren, die von dieser Activity ausgehen, bearbeitet. Dabei wird die Transition Condition des Kontrollkonnektors ausgewertet. Ist sie False, werden alle daraus folgenden Kontrollkonnektoren, die sicher nicht mehr gestartet werden können, mit False gekennzeichnet (Dead Path Elimination).Ist die Transition Condition gleich True, so wird die Zielaktivität des Kontrollkonnektors in einem nächsten Schritt überprüft. 5. Ändert sich bei einer Activity der Status eines eingehenden Kontrollkonnektors, wird überprüft, ob alle eingehenden Kontrollkonnektoren true oder false sind. Ist dies der Fall, so wird die Start Condition ausgewertet. Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems 7 6. Bei der Start Condition kann die Bedingugn angeben, unter der die Activity gestartet werden kann. Dies kann z.B. sein: Alle eingehenden Kontrollkonnektoren sind wahr oder mindestens einer. 7. Entlang der Kontrollkonnektoren, die auf True gesetzt wurden, werden jetzt die vorhandenen Datenkonnektoren ausgewertet und die Containerinhalte entsprechend kopiert. 8. Eine Prozessinstanz ist dann beendet, wenn alle Activities beendet wurden oder endgültig nicht bearbeitet wurden. An Organizational Model integrated into a Workflow System All relationships described in the diagram above can be used with staff resolution. reports 0,1 0..n Organization manager 0..n 1 0,1 0..n member 0,1 Person 0..n has 1 substitute 0..n member 0..n 0..m 0,1 0..n coordinator Role Level Abbildung 7. The entity-relationship diagram for staff data The primary entities in the staff model are person, organization, role and level. The following relations are defined between these entities: reports to Organizations can have at most one parent organization. This relation is used to build up the organizational hierarchy. is manager of Each organization must have one manager. A person can manage more than one organization. member of organization A person can be member of at most one organization. The organization a manager belongs to is independent of the organization the manager manages. A manager (as every person in this model) needs not be member of an organization. is substitute of For a person, at most one substitute can be defined. A person can be substitute of several people. is member of a role A person can have several roles, mutiple people can have a role. A role can be used to define a group of people able to do a specific task. Also, roles could be used to model matrix organizations: One dimension of the matrix organization could be modeled with the organizational hierachy, the other could be modeled with roles. is coordinator of a role For a role, at most one coordinator can be specified. 8 Business Process Management und Workflow-Technologie If for example a role specifies the ability to do a specific task, the coordinator of a role could be notified in case of problems when performing this task. has level Each person can have a level. If no level is specified for a person, then level 0 is assumed. With staff resolution, not only a level can be specified as criteria, but also intervals can be specified. Die Zuweisung von Activities an Personen Wenn eine Activity von einer Person ausgeführt werden soll, ist zu definieren, welche Personen diese Activity ausführen können (potential owner). Organization Process Instance Process Template Staff Resolution, Notification Worklists Abbildung 8. Kontext einer Staff Resolution Diese Zuweisung soll folgende Eigenschaften haben: 1. Zur Laufzeit. 2. Abhängig von Daten des Prozesses. 3. Abhängig von Eigenschaften der Personen. 4. Bei Abwesenheit einer Person sollte deren Vertreter diese Activity ausführen. 5. Abhängig von anderen Activities (Vier-Augen Prinzip oder Activity B soll vom Manager des Starters der Activity A ausgeführt werden). Üblicherweise werden diese Anforderungen erfüllt, indem Daten zu den Mitarbeitern separat von den Prozessen gespeichert werden. Für die beiden Fälle oben ist zu jedem Mitarbeiter ein Vertreter (Substitute) zu definieren und die Abteilungsstruktur muß im System gespeichert sein. Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems 9 Wesentliche Aspekte dieser Lösung sind: Trennung zwischen Prozesslogik und Organisation (Deutsch: Ablauforganisation versus Aufbauorganisation) Die Prozessmodelle sind weitgehend unabängig von organisatorischen Änderungen. Late Binding Ändert sich die Organisationsstruktur, so hat dies Auswirkungen auf alle Prozessinstanzen, die gerade ausgeführt werden: wurde in einem Prozess eine Activity gerade beendet und wird zur nächsten Activity navigiert, so wird zu diesem Zeitpunkt die Organisationsstruktur analysiert, um die Personen zu ermitteln, die die nächste Activity ausführen sollen. Separate Staff-Datenbank Vor allem große Organisationen versuchen, Informationen über Mitarbeiter möglichst zentral zu halten, z.B. mit einem LDAP-Directory (Leight-weight directory access protocol). Zwei mögliche Lösungen kommen in so einem Fall in Frage: 1. Staff Exit für den Online-Zugriff zur Authentication, Authorization, Staff Resolution. 2. Staff Bridge für eine Replication (z.B. nachts) in die Staff-Datenbank des Workflow-Systems. Systemstruktur eines Workflow-Systems Die in „Die wichtigsten Komponenten eines Workflow-Systems” auf Seite 4 besprochene Systemstruktur soll hier genauer beschrieben werden anhand einer Grafik aus Concepts and Architecture: Abbildung 9. API-Struktur Workflow-Systeme können nicht nach einfacher Installation betrieben werden. Neben der Anpassung oder Neuschreibung von Programmen, die in den Activities 10 Business Process Management und Workflow-Technologie aufgerufen werden, wird oft auch das User-Interface des Workflow-Clients speziell für die Anwendung geschrieben. Workflow kann quasi in die Anwendung eingebaut werden. Dies stellt eine wesentliche Erleichterung für die Benutzer des Produkts dar, die besser bei der Erfüllung ihrer Aufgaben geleitet werden können. Ein anderer Aspekt ist der Wunsch, Workflow auf einer ganzen Reihe von Plattformen und Umgebungen einsetzen zu können. Speziell bei automatischen Activities gibt es hier eine große Bandbreite. All dies sind Gründe, warum die APIs die eigentlichen Interfaces des Produkts sind. Außer dem Admin Client können alle anderen Clients ersetzt werden. Spezielle Funktionen lassen sich nur über das API ausführen. So haben die Clients eher den Character von Beispielprogrammen. XML als Invocation-Interface XML (eXtensible Markup Language) ist ein Standard, um strukturierte Daten in einem Textstring zu speichern und zu übertragen. Das Format (das XML-Schema) ist ist innerhalb der Grundsyntax frei definierbar. Es existieren Tools wie z.B. XML Parser, mit denen ein XML-Dokument relativ einfach mit einem Programm verarbeitet oder konvertiert werden kann. Im XML-Format können Requests direkt an den Execution-Server geschickt werden. Als Illustration soll folgende XML-Message dienen: <?xml version="1.0" standalone="yes"?> <WfMessage> <WfMessageHeader> <ResponseRequired>Yes</ResponseRequired> <UserContext>This data is sent back in the response</UserContext> </WfMessageHeader> <ProcessTemplateExecute> <ProcTemplName>OnlineCreditRequest</ProcTemplName> <ProcInstName>Credit_Request#658321</ProcInstName> <KeepName>true</KeepName> <ProcInstInputData> <_ACTIVITY_INFO> <Priority>1</Priority> </_ACTIVITY_INFO> <PersonInfo> <FirstName>Andreas</FirstName> <LastName>Wickenhaeuser</LastName> </PersonInfo> </ProcInstInputData> </ProcessTemplateExecute> </WfMessage> Mit dieser Beispielmessage kann ein Prozess gestartet werden. Eine andere Möglichkeit, XML hier einzusetzen ist, eine Activity durch XML zu starten. Audit Trail Sobald mit Workflow-Prozessen Dinge bearbeitet werden, die einen gewissen Wert haben oder die mit einem gewissen Risiko verbunden sind, wird es wichtig, daß dauerhaft gespeichert wird, wer wann was gemacht hat. Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems 11 Wenn zum Beispiel Wertpapieraufträge in Millionenhöhe bearbeitet werden, oder in einem Krankenhaus Patientendaten verwaltet werden, ist es sinnvoll beim Einsatz von Workflow-Systemen darauf zu achten, daß wichtige Aktionen protokolliert werden. Einige Daten, die bei einem Audit Event gespeichert werden: Timestamp Der Zeitpunkt, zu dem dieses Ereignis eingetreten ist. Event Numerisch codierter Typ des Ereignisses,, z.B.: v Process startet v Process terminated v Activity started Process Name Name der Prozessinstanz, in der dieses Ereignis eingetreten ist. User ID Person, die die Aktion ausgeführt hat. Anwendungsdaten In beschränktem Umfang können ausgewählte Anwendungsdaten wie z:B. Kundennummer oder Rechnungsnummer dem Event mitgegeben werden. Audit Events können in die Datenbank geschrieben werden oder als XML Messages verschickt werden, die dann von einer anderen Stelle aus gespeichrt und ausgewertet werden können. Suche nach einem Vorgang Ein typische Kundenanfrage in einer prozessorientierten Verwaltung lautet: Ich habe einen Versicherungsschaden gemeldet, wie ist der Stand der Bearbeitung ? Es ist also der Status einer Prozessinstanz zu ermitteln. Folgende Schritte interessieren hier: 1. Wir nehmen an, der Versicherungsschaden wird mit einer neuen Prozessinstanz bearbeitet. Der Name der Instanz kann z.B. die Kundennummer des Versicherungsnehmers enthalten. 2. Ruft der Kunde an, kann dann nach der Prozessinstanz gesucht werden. 3. Mit dem Prozessmonitor kann der Status der Instanz ermittelt werden. Überwachung von Business-Zielen Prozessinstanzen eines Prozesses haben Kennzahlen wie: 1. Kosten 2. Dauer 3. Qualität (z.B. Wahrscheinlichkeit von Fehlersituationen) Diese können in folgendem Zusammenhang zu Prozessen stehen: 1. Vorgaben bei der Entwicklung einer Workflow-Anwendung. 2. Überprüfung auf Konsistenz durch Simulation. 3. Verifizierung im produktiven Einsatz. 4. Veränderung des Prozesses zur besseren Zielerreichung. 12 Business Process Management und Workflow-Technologie Error Log Treten Fehler beim Betrieb auf, sollten diese einer zuständigen Person gemeldet werden. Bei Fehlern, die nicht direkt mit der Eingabe von Daten zusammenhängen, ist es oft nicht sinnvoll, dem Endanwender eine detaillierte Beschreibung des Fehlers zu geben. In solchen Fällen ist ein Administrator der eigentliche Adressat, der z.B. ein Error Log File analysieren kann, in dem die Fehler in chronologischer Reihenfolge verzeichnet sind. Tracing Da beim Kunden oft die Konfiguration komplex sein kann, sind Fehler, die beim Kunden auftreten, im Labor nicht einfach nachzuvollziehen. Das Produkt hat hier die Möglichkeit, wichtige Programmaktionen zu protokollieren. Es gibt Analogien zum Audit Trail, der Unterschied liegt aber, daß hier die Interessenten der protokollierten Informationen die Programmierer sind und oben es Personen sind, die an den Business-Prozessen interessiert sind, Entsprechend unterschiedlich sind die Daten, die protokolliert werden. Beispiel eines Traces: 2000-12-13, 16:31:51.78, fmcixbas.cxx( 781), ( 3,Fl,MC), fmcibie( 348- 346), FmcXLateBackend::GetBool(bool&,const FmcfAttributeDataReader&), <exit 2000-12-13, 16:31:51.78, fmcixbas.cxx( 808), ( 3,Fl,MC), fmcibie( 348- 346), FmcXLateBackend::GetTargetName (FmcString&,const FmcfEntity&,const FmcfLinkType&), >entry 2000-12-13, 16:31:51.78, fmcixbas.cxx( 819), ( 3,Gn,MC), fmcibie( 348- 346), FmcXLateBackend::GetTargetName (FmcString&,const FmcfEntity&,const FmcfLinkType&), Name is Staffless 2000-12-13, 16:31:51.78, fmcixbas.cxx( 808), ( 3,Fl,MC), fmcibie( 348- 346), FmcXLateBackend::GetTargetName (FmcString&,const FmcfEntity&,const FmcfLinkType&), <exit Da die Traceentries sehr lang sind, wurden sie auf mehrere Zeilen aufgeteilt und jeweils mit einer Leerzeile getrennt. Folgende Daten werden mit einem Traceentry hier geschrieben: 1. Timestamp 2. Sourcefile mit Zeilennummer, dessen Code gerade ausgeführt wird. 3. Tracelevel, hier 3, möglich ist 0–9. Tracing kann so eingestellt werden, daß z.B. nur Entries mit den Werten 0–2 geschrieben werden. 4. Kategorie des Traceentries. Hier wird Gn (General) und Fl (Flow) verwendet. Weitere mögliche Werte sind Er (Error) und Pf (Performance)... 5. Komponte des Sourcecodes. MC steht hier für Modeling Client. Weitere mögliche Werte sind KR (Kernel), EX (Execution Server) ... 6. Name des ausgeführten Programms mit Prozess-Id, Thread-Id. 7. Aktuelle Methode. 8. Frei definierbare Daten. 9. Optional >entry, wenn in eine Methode gesprungen wurde, <exit, wenn eine Methode verlassen wird. Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems 13 Der korrespondierende Sourcecode sieht wie folgt aus: void FmcXLateBackend::GetTargetName(FmcString& targetName, FmcfEntity const& source, FmcfLinkType const& linkType) { traceFlw(3, ModC, ""); FMC_REQUIRE(source.Alive()); FMC_REQUIRE(linkType.IsValid()); FmcfLink link = source.FirstLinkOfType(linkType); } if (link.IsValid()) { targetName = link.Target().Name(); traceDbg(3, Gen, ModC, "Name is " << targetName); } else { targetName.SetNull(); traceDbg(3, Gen, ModC, "No name defined"); } IT-orientierte Statistik, Monitoring Systemadministratoren haben dafür zu sorgen, daß möglichst reibungslos mit dem System gearbeitet werden kann. Überwacht werden muß beispielsweise: 1. Funktionsfähigkeit von allen Komponenten. 2. Anwortzeiten des Systems. 3. Verwaltung des Plattenplatzes (Datenbanksystem). Aufgaben 1. Sie haben verschiedenen Aspekte eines Workflow-Systems kennengelernt. Überlegen Sie sich, welche Personengruppen mit dem System zu tun haben und welche Qualifikationen diese Personen haben müssen. Denken Sie dabei an Aufgaben wie Planung der Prozesstemplates, Umsetzung, Installation, Betrieb, Kontrolle der Prozesse, Fehlerbehandlung. 2. Diese Aufgabe hat den Vergleich von System/Error Log, Audit Trail und Trace zum Thema. Nehmen Sie an, Sie betreuen einen Kunden eines Workflow-Produkts. Der Kunde beschwert sich bei Ihnen, daß der Trace so schwierig auszuwerten sei. Können Sie dem Kunden einen Tip geben ? 3. Wie kann die mehrfache Ausführung einer Gruppe von Aktivitäten modelliert werden ? Kann ein Kontrollkonnektor von der letzten Aktivität dieser Gruppe zu der ersten Aktivität gezogen werden ? 4. In einem Prozess, der die Laufzeit von einigen Wochen haben kann, muß eine Folge von Activities ausgeführt werden. Diese Activities werden in der Regel schnell durchlaufen. Wie ist diese Folge von Activities zu modellieren, wenn Änderungen in diesem Bereich auch für Prozesse gelten sollen, die schon gestartet worden sind ? 5. Bei der Navigation haben Sie den Begriff der Dead Path Elimination kennengelernt. Überlegen Sie sich, welche Konsequenzen es auf die Navigation haben würde, wenn keine Dead Path Elimination ausgeführt würde. a. Zeichnen Sie ein Beispiel von Aktivitäten und Kontrollkonnektoren, wo dies zu einem Problem führen kann. 14 Business Process Management und Workflow-Technologie b. Erläutern Sie dieses Problem, indem Sie Schritt für Schritt durch diese Aktivitäten und Kontrollkonnektoren durchnavigieren. c. Wie müßte die Semantik beim Start einer Activity geändert werden, damit es nicht zu unerwünschten Stops bei der Navigation kommen würde ? 6. Wird z.B. Rollen-basierte Staff Resolution für eine Activity ausgeführt, kann aus einer Gruppe von mehreren Personen einer diese Activity starten. Nennen Sie zwei Gründe warum es sinnvoll sein kann, wenn Program Activities, die auszuführen sind, von mehr als einer Person gestartet werden können. 7. Ausgangspunkt ist ein Ausschnitt eines Prozeßmodells, in dem es von der Aktivität A einen Control- und einen Datenconnector zur folgenden Aktivität B gibt. Diese Aktivität, die von Sachbearbeitern ausgeführt wird, soll stichprobenweise überprüft werden: In zufällig ausgewählten 10% der Instanzen soll nach dem Abschluß von A statt nach B zur Aktivität U gerouted werden. Ist U abgeschlossen, soll nach B weiternavigiert werden. Für die durchschnittlich 90% anderen Instanzen soll wie bisher nach B geroutet werden, ohne daß U durchlaufen wird. a. Beschreiben Sie, wie die zufällige Auswahl ausgeführt wird. Dies soll natürlich automatisch erfolgen. b. Wie ist das Prozessdiagramm zu ändern, sodaß die Auswahl stattfindet, U eventuell durchlaufen wird und dann in beiden Fällen zu B weiternavigiert wird. Skizzieren Sie das Diagramm. c. Beschreiben Sie anhand des Diagramms, wie es in den beiden relevanten Fällen durchlaufen wird. 8. Entscheiden Sie, ob die folgenden Aussagen wahr oder falsch sind, indem Sie diese mit der Abb. 7 auf Seite 8 überprüfen. Begründen Sie Ihre Aussagen: a. Eine Person kann Mitglied von mehreren Organisation sein. b. Eine Person kann Manager von mehreren Organisationen sein. c. Der Vertreter einer Person muß mindestens die Rollen der vertretenden Person haben. d. Eine Person kann Koordinator von mehreren Rollen sein. 9. In einem Unternehmen gebe es neben der üblichen hierarchischen Organisation eine Projektorganisation mit folgenden Eigenschaften: a. Jedes Projekt hat einen Projektverantwortlichen. b. Mitarbeiter können Mitglieder von mehreren Projekten sein. c. Mitarbeiter von verschiedenen Abteilungen können einem Projekt angehören. Überlegen Sie sich, wie dies mit dem in Abb. 7 auf Seite 8 definierten Organisationsmodell abgebildet werden kann. Hinweis: Sie sollten untersuchen, ob Sie die Projekte durch Organization oder durch Role abbilden können. Beachten Sie die Bedingungen, die bei den Relationen zwischen den Entities gelten müssen. Wie müsste die Staff Resolution einer Activity definiert werden, damit genau die Mitglieder eines Projekts diese Activity ausführen können ? 10. Wäre es nicht einfacher, statt den verschiedenen Input- und Outputcontainern mit den Mappingregeln, einen Container für den Prozeß zu definieren ? Mit diesem Container würden dann alle Activities des Prozesses arbeiten, also daraus lesen und schreiben. Die Definition von Mappingregeln wäre dann nicht mehr nötig. Kapitel 2. Wichtige Eigenschaften eines Workflow-Systems 15 a. Vergleichen Sie diese Alternative mit dem oben vorgestellten Konzept. Denken Sie z.B. an Probleme beim gleichzeitigen Zugriff auf den Container, bei Activities, die von mehreren anderen Activities abhängen. b. Was hat diese Lösung für Konsequenzen für Programme und Prozesse, die von verschiedenen Prozessen aus aufgerufen werden sollen ? 16 Business Process Management und Workflow-Technologie Kapitel 3. Allgemeine Aspekte eines Workflow-Systems Drei Dimensionen Abbildung 10. Die Dimensionen von Workflow Prozesslogik Die Prozesstemplates. Organisation Die Beziehungen zwischen den Mitarbeitern. IT-Struktur Die Hard- und Softwaresysteme, die verwendet werden. Das Workflow-System muß zum Beispiel mit der existierenden IT-Struktur zusammenarbeiten können: v Hardwareplattformen, Betriebssysteme. v Netzwerkprotokolle, Datenbanksysteme, Application Server. v Anwendungsprogramme, Transaktionssysteme. Workflow kann unter diesen drei Aspekten betrachtet werden. Obwohl sie miteinander zusammenhängen, sollten sie soweit wie möglich unabhängig voneinander definiert werden könen. Kategorien von Workflow © Copyright IBM Corp. 2001,2005 17 Geschäftswert Collaborative Entwicklungsprojekte Ad Hoc Unstrukturierte Kommunikation Production Freigabe von Krediten Administrative Einkaufsanforderungen Wiederholungsrate Abbildung 11. Eine Klassifikation von Workflow Wiederholungsrate steht hier für die Anzahl, wie oft ein Prozess genau in dieser Form ausgeführt wird. Ein Prozess, der zwar häufig ausgeführt wird, dann jeweils aber in anderer Form, hat daher eine eher niedrige Wiederholungsrate. Geschäftswert steht hier für den Wert einer Prozessinstanz. Von ihm hängt zum Beispiel das Risiko des Unternehmens ab, wenn dieser Prozess fehlerhaft ausgeführt wird. Workflow-Software ist eher bei Szenarien auf der rechten Seite zud finden. Auf der linken Seite wird Software mit weniger ausgeprägte Workflow-Eigenschaften eingesetzt. Kriterien eines Geschäftsprozesses Ein Geschäftsprozess ist die Bearbeitung eines Vorgangs oder das Erstellen eines Produkts in einem Unternehmen. Aspekte von Geschäftsprozessen: Geschäftsprozesse als Kernkompetenz eines Unternehmens Beispiele: Produktion eines Autos, Bearbeitung eines Schadenfalls bei einer Versicherung. Ebene Als Geschäftsprozess kann die Entwicklung eines neuen Flugzeugtyps betrachtet werden oder das Erstellen eines neuen Firmenausweises. Grad der Automatisierung Viele Geschäftsprozesse zeichnen sich durch einen geringen Automatisierungsgrad aus: z.B. die Ernennung eines Mitarbeiters zum Manager. Im Vergleich dazu dürfte die Bearbeitung der Online-Bestellung eines Buches weitgehend automatisiert sein. 18 Business Process Management und Workflow-Technologie Organisatorische Aspekte überwiegen Wenn Prozesse analysiert und verbessert werden, stehen meist organisatorische Fragen im Vordergrund: Wie schaut der Prozess aus, wer macht was, wer kontroliert wen, wer kann welche Daten ermitteln etc. Technische Fragen wie verwendete Programme, IT-Infrastruktur sind eher zweitrangig. Bevor die Frage nach der Änderung von Geschäftsprozessen gestellt wird, sind Kriterien zu definieren, nach denen Geschäftsprozesse beurteilt werden: Angemessenheit Ist der Prozess sinnvoll und der Aufgabenstellung angepaßt ? Effizienz Die Relation zwischen Kosten und Nutzen des Prozesses. Fehlerwahrscheinlichkeit Hohe Fehlerwahrscheinlichkeiten können negative Auswirkungen auf alle anderen Kriterien hier haben. Antwortzeiten Die Schnelligkeit bei der Bearbeitung von Aufträgen. Transparenz Geschäftsprozesse sind oft nicht ausreichend dokumentiert. Oft ist nur den ausführenden Mitarbeitern klar, wie sie funktionieren. Was ist der Status einer Prozessinstanz ? Welche Prozessschritte benötigen wieviel Resourcen ? Anpassungskosten Geschäftsprozesse ändern sich. Sind die Anpassungskosten bei Änderungen akzeptabel ? Erfüllung von Erwartungshaltungen, Kunden- und Mitarbeiterzufriedenheit Der Prozess sollte auf vorhandene Erwartungshaltungen von Kunden und Mitarbeitern eingehen (z.B. Servicezeiten, Entscheidungsspielräume von Sachbearbeitern, Gruppenarbeit statt Arbeit am Fließband). Ändern von Geschäftsprozessen Abgrenzung von Business Process Reengineering zur Geschäftsprozessoptimierung Business Process Reengineering 1. Radikale Änderung eines Geschäftsprozesses. 2. Personen von außen werden benötigt, mit deren Fachwissen Änderungen geplant und durchgesetzt werden können, die auch gegen die Interessen der beteiligten Personen gerichtet sein können. 3. Höheres Risiko, aber auch die Erwartung eines größeren Gewinns nach dem Abschluß des Projekts 4. Beispiel: Aufteilung eines Unternehmens in voneinander unabhängige Einheiten (Profit Center). Verschmelzung von Unternehmen mit anschließender Konsolidierung. 5. Weiteres Beispiel: Bei der Softwareentwicklung wurde früher oft ein Release von einer Abteilung entwickelt und es dann mit der Auslieferung beim Kunden einer anderen Abteilung übergeben, die für Kapitel 3. Allgemeine Aspekte eines Workflow-Systems 19 die Maintenance verantwortlich war. Heutzutage ist es eher üblich, daß Entwicklung und Maintenance einer Komponente von den gleichen Personen betrieben wird. Geschäftsprozessoptimierung 1. Inkrementelle Verbesserung eines Prozesses. 2. Der Prozess wird in Zusammenarbeit und unter Nutzung des Fachwissens der beteiligten Mitarbeiter verbessert. Ansätze für eine Geschäftsprozessoptimierung Eliminierung unnötiger Arbeit. Unnötige Arbeit festzustellen kann bei komplexen Prozessen schwer sein. Oft ist eine Risikoabschätzung notwendig, um zu ermitteln, ob alle relevanten Kriterien des Prozesses nach dem Vereinfachen noch erfüllt sind. Andere Organisation der Arbeit. Beispiel: Statt Produktion und Qualitätskontrolle als separate Abteilungen zu haben, wird die Qualitätskontrolle in die Produktion integriert. Vorteile: Kürzerer Feedback zur Produktion bei Qualitätsproblemen, klare Verantwortlichkeiten für die Qualität (besonders wenn die Produktionsschritte entsprechend protokolliert wird), Kosteneinsparungen. Risiken: Verminderte Produktqualität. Vermeidung von Brüchen im Informationsfluß. Beispiel: Manuelle Eingabe von Daten von einem System in ein anderes System. Als Begründung von solchen Schritten dient oft, daß mit der Eingabe auch eine manuelle Prüfung der Daten stattfindet. Bessere Unterstützung durch Programme. Dies kann durch Automatisierung geschehen oder der Vereinheitlicheung des User Interfaces geschehen. Einsatz von Standardlösungen. Statt selbstentwickelten Programmen werden branchenspezifische Prozesse oder Anwendungen verwendet. Worklists statt Queries. Wenn der Prozess datenbankorientiert ist, muß der Mitarbeiter oft anstehende Arbeit dadurch ermitteln, indem er verschiedene Queries absetzt, die als Resultate die Vorgänge liefert, die zu bearbeiten sind. Im Gegensatz dazu stellt eine Worklist dies an einer Stelle zusammen. Die Worklist kann sachgerecht sortiert sein, z.B. nach Priorität. Optimierung des Prozessflusses Zum Beispiel durch parallele Verarbeitung Beispiel der Optimierung des Geschäftsprozesses Scheckeinreichung Ein Unternehmen erhalte pro Tag etwa 10 Schecks, mit denen Kunden ihre Rechnungen bezahlen. 20 Business Process Management und Workflow-Technologie Buchhaltung Eintrag in Liste der Schecks Zuordnung erfolgt Zuordnung Kopie offene erstellen Posten Finanzabteilung Scheckeinreichung keine Zuordnung Kundenanruf Nacharbeit Abbildung 12. Orginaler Prozess Scheckeinreichung 1. Die Schecks werden im Unternehmen an die Buchhaltung geschickt, die auch für das Ausstellen von Rechnungen verantwortlich ist. 2. Die Schecks werden in eine Liste manuell eingetragen. 3. Mit einem Dialogprogramm wird versucht, den Scheck einem Offenen Posten des Kunden zuzuordnen. 4. In etwa 5% der Fälle ist eine eindeutige Zuordnung nicht sofort möglich (z.B. ein Scheck zum Begleichen von mehreren Rechnungen), der Kunde wird angerufen. 5. Der Scheck wird kopiert. 6. Der Orginalscheck geht an die Finanzabteilung, die den Scheck einreicht. 7. Die Kopie des Schecks bleibt in der Buchhaltung und wird abgelegt. Finanzabteilung Erfassung, Abgleich offene Posten Scheckeinreichung keine Zuordnung Buchhaltung Kundenanruf Nacharbeit Abbildung 13. Verbesserter Prozess Scheckeinreichung 1. Voraussetzungen: Kapitel 3. Allgemeine Aspekte eines Workflow-Systems 21 2. 3. 4. 5. a. Verwendung eines Datenbanksystems oder Imaging-Systems zur Speicherung der Scheckdaten. b. Die Finanzabteilung hat Zugriff auf die Offenen Posten der Buchhaltung. Die Schecks gehen an die Finanzabteilung. Nach der Erfassung mit einem Programm werden die Schecks eingereicht. Zusammen mit der Erfassung geschieht die Zuordnung zu den Offenen Posten. Die Scheckdaten werden vom System entsprechend ausgewertet.. Phasen der Geschäftsprozessoptimierung Die Akteure bei der Geschäftsprozessoptimierung Oft finden diese Projekte im Spannungsfeld zwischen den Fachabteilungen, die für die Prozesse verantwortlich sind und der IT-Abteilung (Information Technology), die für die Infrastruktur zuständig ist, statt. Wer sind auf der Managementseite Initiatoren und Unterstützer bei dem Projekt ? Wenn ein Geschäftsprozess zwei Abteilungen umfaßt und nur das Management der einen Abteilung die Optimierung unterstützt, kann dies zu Problemen führen. Ist-Analyse des Prozesses v Zusammenstellung von Dokumenten, die den Prozess beschreiben. v Interviews v Ermittlung von Prozesskenngrößen wie Durchlaufzeiten, Fehlerhäufigkeiten, Kundenzufriedenheit. v Bestimmung der Kosten eines Prozesses, z.B. der Kosten einer durchschnittlichen Prozessinstanz bei einer durchschnittlichen Anzahl von Prozessinstanzen pro Zeiteinheit. Definition Soll-Zustand v Was soll verbessert werden ? v Möglichst quantifizierbare Ziele definieren. v Abschätzung und Planung der Kosten des neuen Prozesses. Im einfachsten Fall setzen sich diese zusammen aus Umstellungskosten und den Kosten pro Prozessinstanz, die dann vergleichbar sein sollten zu den ermittleten Kosten des aktuellen Prozesses. Entwicklung der Lösung Änderungen können umfassen: v Prozessänderungen v Organisationsänderungen v Neue Stellenbeschreibungen v Einführung von neuer Software, Hardware. Pilotphase Der neue Prozess wird simuliert und getestet. Er wird im kleinen Rahmen eingeführt. Wie bei der Entwicklung bei Software allgemein üblich, sollte der Kontakt zu den Anwendern möglichst früh hergestellt werden mit Hilfe von Prototypen oder mit einem Piloten, um Fehlentwicklungen im Projekt möglichst frühzeitig korrigieren zu können. Roll-Out Der neue Prozess geht in Produktion. 22 Business Process Management und Workflow-Technologie Nachlese Die Kennzahlen des neuen Prozesses werden ermittelt und mit dem alten Prozess verglichen. Korrekturen des neuen Prozesses werden ausgeführt. Aufgaben 1. Im Diagramm Abb. 1 auf Seite 1 soll folgende Erweiterung eingebaut werden: Fall bei einer Bestellung einer der bestellten Artikel nicht auf Lager ist, soll er nachbestellt werden. Die Nachbestellung umfasse zwei Activities: a. Erstellung einer Nachbestellung b. Empfang und Bearbeitung der Nachbestellung Diese beiden Activities sollen parallel zur Activity Zahlungsweise ausgeführt werden. a. Skizzieren Sie den geänderten Prozessgraphen. b. Beschreiben Sie, wie der Start der Nachbestellung ausgeführt werden kann. Wie könnten hier Containervariablen verwendet werden ? c. Die Activity Versand ist Synchronisationspunkt der beiden Kontrollflüsse. Ist die Startbdingung dieser Activity AND oder OR ? Spielen Sie die beiden Alternativen (mit oder ohne Nachbestellung) durch. d. Nach einigen Tests des Prozesses habe sich ergeben, daß die Nachbestellung komplexer ist als ursprünglich angenommen. Überlegen Sie sich, wie eine stärkere Entkoppelung von dem Kundenbestellprozeß erreicht werden könnte. 2. Überlegen Sie sich Kriterien, nach denen sie Instanzen des ProzessesAbb. 1 auf Seite 1 beurteilen können a. Unter Business-Aspekten b. Unter IT-Aspekten 3. Wir betrachten die letzte Activity Inkasso im Diagramm Abb. 1 auf Seite 1 genauer. Diese Activity sei durch einen starken Anteil von manuellen Arbeiten geprägt (hoher Ad-Hoc-Anteil), die auch unterbrochen werden können. Gleichzeitig soll der Status persistent gespeichert sein, z.B. folgende Daten: a. 1. Mahnung erfolgte am: b. 2. Mahnung erfolgte am: c. Vollstreckungstitel beantragt am: d. Zahlung erfolgte am: e. Zahlung kann nicht eingetrieben werden. Überlegen Sie sich, wie dies sinnvoll modeliert werden kann 4. In der Beschreibung eines Projekts zur Optimierung eines Geschäftsprozess finden Sie folgende Sätze: In der Pilotphase zeigte sich, daß die Kosten einer Prozessinstanz im Durchschnitt 20% geringer sind als im aktuellen Prozess. Wenn der neue Prozess in Produktion geht, wird die Einführung des neuen Prozesses somit zu erheblichen Einsparungen führen. a. Beschreiben Sie in einem Satz, was in dem Projekt wohl schon gemacht wurde. b. Sind diese beiden Sätze plausibel ? Begründen Sie Ihre Antwort. 5. Gegeben sei folgender Vorschlag (die Verfügbarkeit entsprechender Systeme zum Betrieb wird vorausgesetzt und ist nicht Bestandteil des Vorschlags, Aufwände sind geschätzt und in einem Anhang des Vorschlags dokumentiert): Kapitel 3. Allgemeine Aspekte eines Workflow-Systems 23 Ein aktueller Prozess umfaßt 5 Schritte, die in 3 verschiedenen Fachabteilungen auszuführen sind. Für 4 Schritte gibt es jeweils ein Anwendungsprogramm zur Bearbeitung, 1 Schritt ist manuell auszuführen. Der Prozess soll auf die neueste Workflow-Technologie umgestellt werden. Projektplan: Evaluierung, Entscheidung, welche Produkte verwendet werden, Dauer 4 Wochen Anhand einer schon vorbereiteten Liste sollen verschiedene Produkte beurteilt werden und die passende Kombination an Software ausgewählt werden. Umstellung der Activities, Dauer 4 Wochen Aufträge werden vergeben zur Umstellung der 5 Prozessschritte zu Anwendungen, die sich in einen Workflow integrieren lassen können. Modellierung des Prozesses, Dauer 1 Woche Der Prozess wird im Workflow-System modelliert und zusammen mit den neuen Anwendungen integriert. Lasttest, Dauer 2 Wochen Die erwartete Last wird auf dem Testsystem simuliert zum Nachweis der Funktionsfähigkeit der Lösung. Umstellungsphase, Dauer 1 Woche Die Daten der Benutzer des Systems (etwa 200) werden übernommen, die Benutzer werden in das neue System eingewiesen, Neue Prozessinstanzen werden mit dem neuen Workflow-System bearbeitet. a. Welche Informationen fehlen, um beurteilen zu können, ob das Projekt sinnvoll ist ? b. Beurteilen Sie den Projektplan. 24 Business Process Management und Workflow-Technologie Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden Relationales Datenbanksystem Wenn Daten zu speichern sind, die eine gewisse feste Struktur haben, so eignet sich hierfür besonders ein Datenbanksystem. Die Personalabteilung eines Unternehmens zum Beispiel muß Daten von Mitarbeitern speichern. Zu jedem Mitarbeiter gibt es einen Datensatz, in dem Angaben wie Name, Personalnummer, Adresse, Gehalt gespeichert sind. Tabellen als Strukturierungsmittel von Daten Wenn wir diese Personaldaten in einer relationalen Datenbank (der heute übliche Typ von Datenbanken) speichern wollen, so müßten wir im einfachsten Fall eine Tabelle (Table) definieren. Die Spalten (Column) der Tabelle entsprechen den einzelnen Datenfeldern wie Name, Personalnummer..., jede Zeile (Row oder Record) entspricht dem Datensatz eines Mitarbeiters. Zugegriffen wird auf diese Daten mit SQL (Structured Query Language) einer speziellen Sprache. Trennung des Anwendungsprogramms von den Zugriffspfaden zur Datenbank Wesentliches Merkmal eines Datenbanksystemes ist, daß die Anwendungsprogramme, die auf die Daten zugreifen, nicht zu eng mit den Daten gekoppelt sind. Wird in unserem Beispiel in der Personaltabelle eine neue Spalte hinzugefügt (zum Beispiel E-Mail Adresse), so sollen alle Anwendungsprogramme ohne Änderungen weiterarbeiten können. (Ein Anwendungsprogramm, daß auf die E-Mail Adressinformationen zugreifen möchte, muß natürlich entsprechend angepaßt sein.) Transaktionen Datenbanksysteme werden von mehreren Anwendern gleichzeitig benutzt. Natürlich soll nicht nur gleichzeitig gelesen werden können, sondern auch gleichzeitig geschrieben werden können. Damit hier nicht Einer die Daten eines Anderen überschreibt, gibt es Mechanismen, die steuern, wer welche Aktionen ausführen kann, und wie im Konfliktfall vorgegangen wird. Das wichtigste Konzept in diesem Zusammenhang sind Transaktionen. Werden Daten in der Datenbank geändert, geschieht dies immer innerhalb von Transaktionen Beispiel: Überweisung von 100 € von Konto A auf Konto B der gleichen Bank. Begin Transaction; KontoA = KontoA - 100; KontoB = KontoB + 100; Commit Transaction; © Copyright IBM Corp. 2001,2005 25 Begin Transaction Datenbankstatus Commit Transaction Updates Abbildung 14. Eine erfolgreiche Transaktion Die Änderungen werden alle nicht vollzogen. Fehler können sein: Begin Transaction Datenbankstatus Rollback Transaction Updates Abbildung 15. Eine Transaktion, bei der ein Fehler zum Abbruch der Transaktion führt v Ein Befehl der Transaktion kann nicht ausgeführt werden (z.B. Konto existiert nicht). v Fehler bei der Ausführung (z.B. Rechnerabsturz). Transaktionen haben ACID-Eigenschaften: Atomicity Entweder alle Aktionen oder keine Aktion der Transaktion werden ausgeführt (Commit Transaction oder Rollback Transaction). Consistency Die Datenbank geht von einem konsistenten Zustand in einen anderen konsistenten Zustand über. Kein Programm sieht inkonsistente Daten. Isolation Nur Ergebnisse von abgeschlossenen Transaktionen sind für andere Programme sichtbar. Durability Die Ergebnisse von abgeschlossenen Transaktionen gehen nicht verloren (auch bei Stromausfall, Programmabsturz ...). Ein Synonym dazu ist Persistenz: Die Daten sind persistent (nichtflüchtig) gespeichert. Im Hauptspeicher sind Daten in der Regel transient gespeichert, da sie bei einem Stromausfall verloren gehen. 26 Business Process Management und Workflow-Technologie Verteilte Transaktionen Two Phase Commit Wenn wir bei dem Beispiel einer Geldüberweisung annehmen, daß die beiden Konten bei verschiedenen Banken sind und die Überweisung Transaktionseigenschaften haben soll (eine Geldtransaktion) besteht das Problem, daß zwei Datenbanksysteme entweder beide die Transaktion committen oder beide aborten. Vor allem das Commit kann dann keine einfache Aktion wie das Setzen eines Flags in einem Update-Record sein. Als Lösung des Problems wurde hier das Konzept der verteilten Transaktion eingeführt. Application Resource Manager 1 Transaction Coordinator Resource Manager 2 Abbildung 16. Die Beteiligten einer verteilten Transaktion Abbildung 17. Die Statusübergänge beim Transaction Coordinator Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 27 Init in: vote request out: vote commit in: vote request out: abort Ready in: global abort Abort in: global commit Commit Abbildung 18. Die Statusübergänge beim Resource Manager Anmerkungen zu verteilten Transaktionen 1. Die interessanteste Frage bei verteilten Transaktionen ist, wie ein Commit zustandekommt unter Einhaltung der ACID-Eigenschaften. 2. Das Verhalten im Fehlerfall (z.B. unterbrochene Kommunikation) ist hier nicht dargestellt. 3. Oft ist der Transaction Coordinator gleichzeitig ein Resource Manager. 4. Verteilte Transaktionen können hierarchisch organisiert sein, indem ein Resource Manager gleichzeitig als Transaction Coordinator weitere Resource Manager kontrolliert. 5. Verteilte Transaktionen werden nach meinem Kenntnisstand vor allem bei einer engen Koppelung der beteiligten Programme innerhalb einer Organisation eingesetzt. Bei einer Kommunikation zwischen gleichberectigten Organisationen wird diese Aufgabe oft durch spezielle Protokolle übernommen, wo z.B. auch ein neutraler dritter Beteiligter eine Notar-ähnliche Rolle haben kann (z.B. SWIFT-Netzwerk zur weltweiten Kommunikation zwischen Banken. SWIFT: Society for Worldwide Interbank Financial Telecommunication). Messages und Queues Bei einer verteilten Anwendung muß dafür gesorgt werden, daß die Kommunikation zwischen den Komponenten im praktischen Einsatz verläßlich arbeitet. Dies kann durch persistente Messages geschehen, welches in den Grundzügen hier vorgestellt werden soll. Messages Ähnlich wie bei einer E-Mail wird hier eine Kommunikation asynchron ausgeführt. Das heißt, der Empfänger muß beim Abschicken der Message nicht unbedingt erreichbar sein. Das Messaging-System sorgt daür, daß der Empfänger die Message dann bekommt, wenn er erreichbar ist. persistent, non-persistent Messages Bei persistent im Gegensatz zu non-persistentMessages sorgt das System darür, daß unter allen Umständen die Messages zum Ziel kommen. Dies soll auch dann der Fall sein, wenn Sender und Empfänger zu beliebigen Zeitpunkten ausfallen. Queues Messages werden in Queues gespeichert, entweder beim Sender, wenn der Empfänger gerade nicht erreichbar ist, oder dann beim Empfänger. Eine 28 Business Process Management und Workflow-Technologie Queue kann man sich als eine Datenbanktabelle vorstellen, in die transaktionsorientiert Messages geschrieben und gelesen werden. Queue Manager Queue Manager verwalten die Queues und sorgen dafür, daß die Messages zuverlässig die Empfänger erreichen. Two Phase Commit, Verteilte Transaktionen Datenbanktransaktionen können mit dem Messaging-System so abgestimmt werden, daß auf der Senderseite zum Beispiel eine Message genau dann abgeschickt wird, wenn die beteiligte Datenbanktransaktion erfolgreich abgeschlossen wird (Commit). Es handelt sich hier um verteilte Transaktionen, die mit einem Two Phase Commit-Protokoll synchronisiert werden. Genauso kann der Empfänger auch so arbeiten, daß er eine Message aus einer Queue nur dann löscht (sie also verarbeitet), wenn andere Transaktionen erfolgreich sind. Überweisung von 100 € vom Konto A bei Bank X auf Konto B bei Bank Y: Begin Transaction; KontoA = KontoA - 100; Sende Message to Y: KontoB + 100; Commit Transaction; Was passiert beim Abbruch nach Senden der Message nach Commit ? v Änderung des Kontos A wird zurückgesetzt. v Message ist aber schon abgeschickt. Lösung sind verteilte Transaktionen. Datenbankstatus Begin Updates Transaction Commit Transaction MessagesStatus Abbildung 19. Verteilte Transaktion, an der ein Datenbanksystem und ein Messagingsystem teilnimmt. v Zu sendende Message wird lokal auf Platte gespeichert (persistente Message). v Bei Rollback wird Kontobewegung und Speicherung der Message rückgängig gemacht. v Nach Commit wird die Message sicher verschickt. v Außerdem gehen alle Requests und Replies über die Messaging-Komponente: Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 29 Begin Transaction; Empfange Überweisungsauftrag vom Client; Änderung des Saldos von KontoA; Sende Message an Bank Y: Änderung des Saldos von KontoB; Sende ok an Client; Commit Transaction; Trigger Queue Manager können Anwendungen starten, wenn Messages in bestimmte Queues geschickt werden. Cluster Queue Manager auf verschiedenen Systemen können zu Clustern zusammengefaßt werden. Messages können dann an den Cluster geschickt werden. Die Queue Manager sorgen dann dafür, daß diese Messages auf die einzelnen Systeme verteilt werden. Damit kann eine Anwendung auf mehrere Systeme aufgeteilt werden. Diese Aufteilung ist für Clients transparent, da diese den lediglich den Cluster adressieren müssen ohne sich darum zu sorgen, welches System gerade läuft und nicht zu stark ausgelastet ist. JMS (Java Message Services) Dieses Interface ist Bestandteil von Java 2EE und kann verwendet werden, um von Java aus mit Messages arbeiten zu können. Für weitere Informationen siehe http://java.sun.com/products/jms/tutorial/index.html. Message Queueing als Alternative zu einer verteilten Transaktion Als Zusammenfassung sollen die beiden Vorschläge gegenübergestellt werden. 1. Empfänger Sender Trn 1 Trn 3 Trn 2 Abbildung 20. Asynchrone verteilte Transaktionen mit Messaging 2. 30 Business Process Management und Workflow-Technologie Empfänger Sender Trn 1 Abbildung 21. Synchrone verteilte Transaktion Vergleich der beiden Lösungen: Tabelle 1. Asynchroner Fall: Synchroner Fall: Drei Transaktionen Eine Transaktion Wenn Fehler bei der 2. oder 3. Transaktion auftreten, muß darauf außerhalb der ersten Transaktion reagiert werden. Die erste Transaktion muß komponsiert werden Tritt ein Fehler bei der Übertragung auf oder beim Verarbeiten bei der Bank 2, kann die ganze Transaktion mit einem Rollback zurückgenommen werden. Kürzer laufende Transaktionen Länger laufende Transaktion Robustere Lösung Lösung kann aus administrativen oder technischen Gründen nicht möglich sein. Architektur eines Servers Serversysteme, die eine große Anzahl von Clients unterstützen, könnten wie folgt strukturiert sein: 1. Limitierungen: Server Logon Requests/ Replies Logoff ein Client Zeit Abbildung 22. Pro Client ein Prozeß Speicher Würde jeder dieser Prozesse 10MB Speicher für Daten benötigen, müßte Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 31 das Betriebssysten bei 1000 Clients mindestens10GB an Daten (im Hauptspeicher und im Paging Space auf einer Festplatte) verwalten. Anzahl Prozesse Bei 1000 Clients müßte das Betriebssystem 1000 Prozess verwalten. Anzahl Kontrollstrukturen Kontrollstrukturen für offene Files, Datenbankverbindungen, Netzwerkverbindungen müßten verwaltet werden. Prozessschwitch Mit jedem Request muß ein Prozessor auf den laufenden Prozeß wechseln. 2. Server Request/ Reply Zeit Abbildung 23. Pro Clientrequest ein Prozeß Die Kommunikation zwischen Client und Server ist oft ein Request/Response Protokoll. Für jeden Request wird ein Prozess gestartet, der nach der Erzeugung der Response wieder beendet wird. a. Oft müssen zu jeder Client-Verbindung Daten gespeichert werden (Welcher Benutzer arbeitet am Client, was waren frühere Bearbeitungsschritte...). Diese Daten werden oft Kontext einer Verbindung genannt (Session Context). Der Session Context muß in diesem Fall gespeichert werden und nach dem Start des Prozesses vor dem Bearbeiten des Requests geladen werden. Identifiziert wird der Session Kontext oft durch eine Referenz, die der Client mit seinen Requests immer mitschicken muß. Diese wird Correl(ation) ID genannt. b. Das Starten und Beenden eines Prozesses ist ein aufwändiger Schritt. Selbst wenn statt eines Prozesses nur ein Thread innerhalb eines existierenden Prozesses gestartet würde, wäre dies oft aufwändiger als die eigentliche Bearbeitung des Requests. 3. 32 Business Process Management und Workflow-Technologie Server Client 1 Request/ Reply Client 2 Request/ Reply Client x Request/ Reply Zeit Abbildung 24. Ein Prozess bearbeitet alle Clientrequests Diese Alternative hat im Vergleich zur letzten Alternative den Vorteil, daß im laufenden Betrieb kein Prozess oder Thread gestartet und gestoppt werden muß. Nachteil dieser Lösung ist die schlechte Ausnutzung der Systemresourcen, wenn beispielsweise Daten von der Festplatte geladen werden. Der Prozess und somit alle Clientrequests warten jetzt. 4. Hotpool von Prozessen zum Bearbeiten der Clientrequests Hier läuft eine Anzahl von Prozessen gleichzeitig, die eingehenden Clientrequests werden auf diese Prozesse verteilt. Das System (besonders wenn es mehrere Prozessoren hat) wird hier besser ausgelastet. Ein separater Prozess (Admin Server genannt) überwacht in regelmäßigen Abständen die Anzahl der Prozesse und startet gegebenenfalls Prozesse nach. Bis auf die erste Alternative sind die Serverprozesse stateless, d.h. sie speichern zwischen den Transaktionen keine Session-Information. Dinge wie 1. UserId, die logged on ist, 2. Client-Netzwerkadresse, 3. Augenblicklicher Stand, wenn z.B. größere Worklisten zu übertragen sind, müssen entweder im Client-Request mitgeschickt werden oder in der Datenbank gespeichert werden. Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 33 Ablauf einer Servertransaktion Schreiben der Reply-Message Lesen der Request-Message Begin Transaction Kontext setzen Commit Transaction Lesen und Schreiben in die Datenbank Abbildung 25. Ablauf einer Servertransaktion Bei dieser verteilten Transaktion sind das Messageging-System und das Datenbank-System die Teilnehmer der Transaktion. Falls die Transaktion abbricht, wird also weder eine Message von der Input-Queue entfernt, noch DB-Updates getätigt noch die Message auf die Output-Queue gestellt. Folgende Probleme sind hier zu beachten: Poisoned Message Gibt es einen Request, der den Server zum Absturz bringt, bricht die Transaktion ab. Als Konsequenz bleibt dieser Request in der Input-Queue. Eine andere Instanz des Servers wird diesen Request wieder bearbeiten und stürzt wieder ab... Um dies zu beenden, kann es bei eine Begrenzung geben, die dafür sorgt, daß diese Schleife zum Beispiel nur drei Mal durchlaufen wird. Danach wird dieser Request in eine spezielle Queue zur manuellen Bearbeitung gestellt. Vorsicht: Die Transaktion kann auch aus anderen Gründen abbrechen, zum Beispiel ein Deadlock. Reproduzierberer Fehler Wird im Laufe der Transaktion festgestellt, daß ein Fehler vorliegt, reproduzierbar ist und eigentlich kein Commit erlaubt, so ist ein Rollback auch nicht die beste Lösung, da die Request-Message eigentlich verarbeitet werden soll, und vielleicht eine Reply-Message erzeugt werden soll. Verkettete Transaktionen Das Szenario Abb. 20 auf Seite 30 kann als Beispiel einer verketteten Transaktion (Chained Transaction) gesehen werden. Kennzeichen einer verketteten Transaktion Die Elemente Die einzelnen Transaktionen einer verketteten Transaktion können als klassische Transaktionen verstanden werden mit der Einschränkung, daß die Konsistenz schwächer sein kann. 34 Business Process Management und Workflow-Technologie Die Verbindung der Elemente Das System muß eine sichere Ausführung der Teiltransaktionen garantieren. Welche Konsequenzen hätte es, wenn dies nicht garantiert wäre ? Atomicity, Isolation, Consistency einer verketteten Transaktion Für die verkettete Transaktion als ganzes gilt nicht mehr: Atomicity, Isolation. Wenn keine verkettete Transaktion offen ist, ist das System wieder in einem konsistenten Zustand. Ausnahmebehandling, Kompensation Ausnahmebedingungen können dazu führen, daß frühere, bereits committete Transaktionen der Kette kompensiert werden müssen. Prozessnavigation als verkettete Transaktion Wir nehmen an, in einer Prozessinstanz wird eine Activity beendet und die Exit Condition ist wahr. Nachdem der Status der Activity selbst in der Datenbank geändert wurde, müssen alle ausgehenden Kontroll- und Datenkonnektoren verfolgt werden und der Status weiterer Objekte geändert werden. Falls die Bedingungen für Dead Path Elimination zutreffen, kann dieser Prozess rekursiv fortgesetzt werden. All diese Updates müßten in einer klassischen Transaktion ausgeführt werden mit einem hohen Risiko an Deadlocks. A C B D Abbildung 26. Zur Illustration der Navigation Alternativ dazu werden in einer ersten Transaktionen nur folgende Aktionen ausgeführt: 1. Statusupdate der Ausgangsaktivität. 2. Data Mapping entsprechend den ausgehenden Datenkonnektoren. 3. Für jeden ausgehenden Kontrollkonnektor schickt die Navigationsinstanz an sich selbst eine Message, damit der Status der Zielaktivität bearbeitet werden kann. Die verkettete Transaktion ist beendet, wenn die transitive Hülle der von der ersten Transaktion initiierten Transaktionen ausgeführt wurde. Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 35 Process Activity Transaktion 1 Transaktion 2 Transaktion 3 Transaktion 4 Abbildung 27. Transaktionsgrenzen bei der Navigation durch einen einfachen Prozess Businesstransaktionen Motivation, all-or-nothing Semantik für eine Gruppe von Activities in einem Prozess. Start Flug Hotel ok AND ok nicht ok ok nicht ok OR nicht ok Abbildung 28. Reisebuchung mit Konsistenzbedingung als Workflow Compensation Spheres In dem oben eingeführten Prozessmodell sind Flug und Hotel zwei Activities, die unabhängig voneinander ausgeführt werden. Wird die Activity nicht ok erreicht, kann es notwendig sein, eine dieser Activities zurückzusetzen. Dies kann explizit mit Hilfe von Compensation Activities modelliert werden: 36 Business Process Management und Workflow-Technologie Start Flug Hotel ok nicht ok ok AND ok nicht ok OR nicht ok Flug nicht ok Hotel nicht ok Flug’ Hotel’ Abbildung 29. Kompensation explizit modelliert Start Flug nicht ok Hotel Flug’ Hotel’ ok oder Kompensation Abbildung 30. Kompensation implizit durch Compensation Sphere Umfang der Compensation Sphere Die Compensation Sphere kann einen Teil oder den ganzen Prozess umfassen. Modellierung Jeder Activity kann eine Compensation Activity zugeordnet werden oder Mode Durch die Anwendung getriggert kann die Prozessinstanz vom normalen Mode in den Compensation Mode wechseln. Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 37 Compensation Processing Die Compensation Activities werden in umgekehrter Reihenfolge der ursprünglichen Navigation asugeführt. Vergleich von Compensation Spheres mit ACID-Transaktionen 1. Lang laufende Transaktionen 2. Konsistenz wird durch Kompensation erreicht 3. Die Transaktion ist Foreward Recoverable 4. Isolation und Atomicity sind nicht erfüllt. Atomic Spheres Wenn ein Prozess nur aus automatischen Activities besteht, könnte der Prozess auch in einer Transaktion (Atomic Sphere) ausgeführt werden. Im Einzelnen: Die Activities des Prozesses haben keine eigenen Transaktionsgrenzen Die Activities könnten an einer verteilten Transaktion partizipieren. Subprozesse übernehmen die Transaktion Wie Program Activities dürfen auch Process Activities keine eigenen Transaktion definieren. Ersatzlösung für verteilte Transaktionen Wir nehmen an, ein Service stehe lediglich als Program Activity zur Verfügung. Wie erreichen wir die Eigenschaftetn Atomicity und Durability ? Status der Activity Ready Running Finished Zeit Start Ende Programm läuft Abbildung 31. Aufruf eines Programms ohne Transaktionssicherheit Wenn die Nachricht der Beendigung der Activity nicht beim Workflow-System ankommt, soll dann die Activity noch einmal gestartet werden (at least once-Semantik) oder gleich weiternavigiert werden (at most once-Semantik) ? Block Activity Abbildung 32. Sicherer Aufruf einer Program Activity 38 Business Process Management und Workflow-Technologie Kennzeichen der Lösung: Activity Expiration Ein Timeout ist definiert, der die maximale Laufzeit der Activity begrenzt. Block Exit Condition Wenn die Activity expired ist, wird der Block erneut gestartet. Erst wenn die Activity erfolgreiche beendet wurde, wird weiternavigiert. Activity ist idempotent Wenn die Activity Daten verändert, kann z.B. mit Sequenznummern erreicht werden, daß die Activity für einen Prozess nicht mehrfach ausgeführt wird. Web-basierte Architekturen Einfache Client-Server Architekturen werden als Two-Tier bezeichnet (Tier 1: Client, Tier 2: Server), wenn der Server aus einer Maschine besteht. Verbindungen zu anderen Servern Serveranwendung DB System Clients Abbildung 33. Two-Tier Client-Server Konfiguration Es ist sinnvoll, die Serverfunktionen auf meherere Maschinen zu verteilen. Dies ergibt eine 4–tier Konfiguration: 1. Web-Browser alsClient 2. Ein Applicationserver für die Darstellungssicht (Server-side Execution). 3. Die Workflow-Engine und weitere Programme (Backend-Application). 4. Der Datenbankserver. Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 39 Datenbankserver Workflow-Engine Applicationserver Verbindungen zu anderen Servern Clients Abbildung 34. 4 Tier Client-Server Konfiguration Wesentliche Eigenschaften dieser Lösung: 1. Kein Installationsaufwand bei den Clients 2. Ausfallsicherheit und Skalierbarkeit im Tier 2 und 3 durch ″Blech″. D.h. mehrere Maschinen teilen sich die gleichen Aufgaben. 3. Nur das Datenbanksystem muß ausfallsicher sein. Safe Applications Safe Applications bietet eine exactly once Semantik beim Starten einer Anwendung vom Workflow-Server aus. beschreibt eine Technik, mit der eine Anwendung von einem Workflow—Server gestartet wird nach einem der folgenden Muster: 1. Die Anwendung läuft innerhalb der Servertransaktion. 2. Die Anwendung wird über Message Queuing eingebunden. Aufgaben 1. Der Audit Trail kann in die Datenbank geschrieben werden, der Trace dagegen in ein einfaches ASCII-File. Überlegen Sie sich, welchen Vorteil es hat, wenn der Audit Trail in die Datenbank geschrieben wird gegenüber dem Schreiben in ein File. Unter anderem können Sie folgende Aspekte betrachten: a. Transaktionen b. Sind Audit-Trail Daten strukturiert oder haben Sie eher ein freies Format ? 40 Business Process Management und Workflow-Technologie 2. 3. 4. 5. 6. c. Arten eines möglichen Zugriffs auf die Audit-Trail Daten, wie z.B. 1. Alle Aktionen einer Person in den letzten zwei Wochen. 2. Welche Aktionen wurden bei einer bestimmten Prozessinstanz ausgeführt ? 3. Wie lange hat im Durchschnitt die Ausführung einer bestimmten Activity gedauert ? In dem Kapitel über asynchrone verteilte Transaktionen wurde das Beispiel von drei Transaktionen gegeben, zwei lokalen, die jeweils das Datenbanksystem und das Messaging-System umfassen und einer, in der die Übertragung der Message abgewickelt wird (Abb. 20 auf Seite 30). Kann es sein, daß das Commit der zweiten Transaktion vor dem Commit der ersten Transaktion stattfindet ? Begründen Sie Ihre Antwort. Wir haben verschiedene Möglichkeiten kennengelernt, wie die Architektur eines Serverprogramms aussehen kann, um den Anforderungen gerecht zu werden. Nennen Sie drei Anforderungen an ein Serverprogramm, die hier relevant sind. Die Koppelung einer Servertransaktion mit einem Messaging-System haben wir als Beispiel einer verteilten Transaktion kennengelernt. Betrachen Sie den Rollback dieser Transaktion genauer beim Beispiel einer Poisoned Message. Gelten die ACID-Eigenschaften für diese verteilte Transaktion im Detail ? Ein Batchprogramm führe nacheinander eine Reihe von Transaktionen aus. Überlegen Sie sich, unter welchen Voraussetzungen man hier von verketteten Transaktionen sprechen kann. Nehmen Sie an, aus einer Atomic Sphere heraus wird eine Activity aufgerufen, die in einer separaten Transaktion ausgeführt wird, die mit Abschluß der Activity ein Commit macht. a. Schildern Sie ein Szenario, bei dem dies zu Problemen führen kann. b. Wie könnte dieses Problem umgangen werden ? Kapitel 4. Services und Techniken, die von einem Workflow-System verwendet werden 41 42 Business Process Management und Workflow-Technologie Kapitel 5. Von 1-tier zu n-tier Systemen client presentation layer application logic layer resource managment layer Abbildung 35. Die Komponenten einer Anwendung © Copyright IBM Corp. 2001,2005 43 Klassische Großrechnersysteme Haben sich aus den Batch-Systemen in den 60er und 70er Jahren zu client presentation layer application logic layer resource managment layer 1-tier information system Abbildung 36. Die Struktur eines 1-tier Systems Online-Systemen hin entwickelt. Kennzeichen Dumb Terminals Im allgemeinen Zeichenbasierte Terminals, wenig attraktiv für Benutzer. Zwar haben die Terminals etwas Programmlogik (in nichtflüchtigem Speicher), dieser ist aber nicht anwendungsspezifisch. Daher keine Software-Lifecycle-Kosten bei den Clients (Entwicklung, Installation, Maintenance von Software). Integrierte Programmlogik Alle Ebenen befinden sich auf einer Maschine, die Programme sind eng integriert, proprietäre Schnittstellen Hohe Effizienz und Stabilität Diese Systeme sind ausgereift und wegen den früheren beschränkten Resourcen sehr effizient programmiert. Änderungen schwierig bis unmöglich Monolithische Anwendungsprogramme haben oft eine hohe Komplexität. Außerdem gibt es oft Skillprobleme bei den verwendeten Tools und beim Anwendungsprogramm selbst. 44 Business Process Management und Workflow-Technologie Client-Server Systeme client presentation layer application logic layer resource managment layer server Abbildung 37. Die Struktur eines 2-tier Systems (Client-Server) Getrieben durch die Möglichkeiten der PCs: lokal ausgeführte Programme und ein attraktives User Interface entstanden Client-Server Systeme. Kennzeichen sind: v RPC, Client-Server Programmierung, der Client enthält den Code der Darstellungsschicht. Man spricht heute von einem Fat Client. v Um 1990 sehr populär als Leitbild einer Programmentwicklung, heute wird dies differenzierter betrachtet. v Startpunkt, bei der Serverentwicklung APIs statt Panels zu entwickeln. Probleme wurden unterschätzt: Skalierbarkeit Serverseitig wurden oft keine adäquaten Platformen gewählt. Skalierbarkeit wurde erreicht durch eine große Anzahl von Maschinen. Folge war ein hoher Maintenance-Aufwand und schwierige bis unmögliche Bereitstellung von zentralen Services. Software-Lifecycle-Kosten beim Client Software-Updates auf dem Client sind möglichst zu vermeiden oder setzen eine entsprechende Infrastruktur voraus. Neue Software-Releases des Servers sollten Backlevel Clients unterstützen. Tendenz zu Insellösungen Zusammen mit PCs und den 2–tier Systemen fand eine Abwertung der traditionellen IT-Strukturen in den Betrieben statt. IT-Entscheidungen wurden eher dezentral von den Fachabteilungen gefällt. Der Integrationsund Kompatibilitätsaspekt wurde zuerst vernachlässigt. Betrieb eines Fileservers:o 1. 1987 wurde ein Fileserver von einer Abteilung aufgebaut und betrieben (15 Mitarbeiter). Kapitel 5. Von 1-tier zu n-tier Systemen 45 2. 1993 wurde diese Aufgabe von der Hauptabteilung übernommen (100 Mitarbeiter). 3. Verfahrensanweisungen regeln immer genauer, wie der Fileserver zu betreiben ist: Benutzerverwaltung, Backup, Virenschutz. 4. 2001 übernimmt eine Serviceabteilung den Betrieb des Fileservers. 5. Eine zentrale LDAP-Directory ist möglich zur Benutzerverwaltung. Clients als Integrationsplattform client presentation layer application and integration logic layer application logic layer application logic layer resource managment layer server 1 resource managment layer server 2 Abbildung 38. Clients als Integrationsplattform Mögliche Fehlentwicklung: Integration auf der Clientseite von verschiedenen Servern. 46 Business Process Management und Workflow-Technologie Middleware client presentation layer application and integration logic layer middleware resource managment layer Abbildung 39. Middleware als Integrationsplattform Ausbau des Application-Logic-Layers zu einem Middleware-Layer als Integrationspunkt. Probleme sind fehlende Standards und die Beschränkung auf die Integration innerhalb einer Organisation. Insbesondere dürfen keine Firewalls zwischen den Komponenten existieren. Kapitel 5. Von 1-tier zu n-tier Systemen 47 Application Server client Web browser application server presentation layer application and integration logic layer middleware resource managment layer Abbildung 40. Thin clients und Application Server Ziel ist es, die Software-Lifecycle-Kosten beim Client und damit für das Gesamtsystem zu minimieren. Die Application Server entwickeln sich hin zu einer Integrationplattform. 48 Business Process Management und Workflow-Technologie Kapitel 6. Komponenten eines Workflow-Systems Das System kann nach zwei Kriterien analysiert werden: Komponenten Komponenten setzen sich aus Klassen in C++ oder Java mit iheren Methoden zusammen. In C++ ist eine Komponente üblicherweise ein Satz von Shared Libraries oder DLLs. Einige Komponenten werden in diesem Kapitel vorgestellt. Prozesse Im laufenden Betrieb besteht ein Workflow-System aus einer Reihe von Prozessen. Unter Prozeß wird hier ausgeführter Maschinencode verstanden, nicht Workflow-Prozeß. Beispiele sind: Execution Server oder FDL Import/Export. Während der Laufzeit eines Prozesses wird Code von verschiedenen Komponenten ausgeführt. Einige Prozesse des Workflow-Systems werden im nächsten Kapitel vorgestellt.. Kriterien für die Strukturierung des Codes: Vermeidung von Redundanz 1. über die verschiedenen Komponenten (Beispiel Syntax Checker) 2. über Plattformgrenzen (Die Server sind in C++ geschrieben: möglichst hoher Anteil an common code über die Plattformen.) 3. im Verarbeitungsfluß der Daten (Beispiel Messages, Datenbankinterface, Skripte zur Erstellung der Datenbank) Da immer mehr Teile in Java geschrieben sind, läßt sich nicht vermeiden, daß einige Komponenten in beiden Sprachen geschrieben wurden (Beispiel: Tracing). Isolierung von Interfaces durch Wrapper 1. um mit vertretbarem Aufwand andere Interfaces zu unterstützen 2. um allgemeine Interfaces zu spezialisieren für die Bedürfnisse des Produkts 3. zur Bereitstellung von Conveniance-Methoden Kernel Stellt Basisklassen zur Verfügung.Die Implementierung dieser Klassen kann durchaus plattform-spezifisch sein.Die Methoden und Variablen dieser Klassen, die public sind, sollten plattform-unabhängig sein. Eine Auswahl: Syntax Checker Testet Eingabewerte z.B. von UserIds, Paßwörtern, Namen auf Länge und gültige Zeichen. Assertion Handling Codiert wird nach dem Fail-Fast-Paradigma: Implizite Annahmen über Daten, die Input für Methoden sind, werden explizit durch Pre-Conditions geprüft. Konsistenzregeln am Ende einer Methode werden explizt durch Post-Conditions geprüft. Was passiert, wenn eine dieser Bedingungen verletzt ist: © Copyright IBM Corp. 2001,2005 49 1. 2. 3. 4. Abbruch des Programms Ausgabe der Sourcecodestelle des Fehlers Schreiben eines Traceeintrags Ausgabe des Callstacks Beispiel im Code: int Wert = 0; FMC_ASSERT( Wert != 0 ); Beispiel im Trace: THROW_INT, FmcAssertionException, Condition=*** Assertion failed in c:\V350\srd\fmctkstr.cxx(1724): Wert != 0 Tracing Wurde schon in einem früheren Kapitel vorgestellt. Profilezugriff Konfigurationsparameter des Systems werden je nach Plattform unterschiedlich gespeichert (Registry bei Windows, Files bei Unix, Data Sets bei zOS). Die Profileklasse verbirgt diese Details. Eine Liste der Konfigurationsvariablen ist definiert. Messages für Benutzer Alle Texte für Benutzer werden separat vom ausführbaren Code gehalten und werden in verschiedene Sprachen übersetzt. Es gibt Klassen, die dafür sorgen, daß die durch eine Zahl identifizierte Message formatiert (Parameterersetzung) und ausgegeben wird. Fehlermeldungen mit Erklärungen erscheinen auch in einem Buch (Messages and Codes). ID Handling Objekte, die bearbeitet werden, benötigen einen eindeutigen Namen. Es gibt hier zwei Ansätze: Namensvergabe durch den Benutzer Zum Beispiel die UserId einer Person wird vom Benutzer bei der Definition dieser Person vergeben. Namensvergabe durch das System Das System ermittelt einen eindeutigen Namen, hier OID (Object Identifier genannt). Vorteil: Kann eine kleine Schlüssellänge haben und dadurch schnellere Suche nach einem Objekt in der Datenbank. Wenn Objekte zusätzlich vom Benutzer vergebene eindeutige Namen haben, gibt es zwei Alternativen 1. Fremdschlüssel enthalten nur die OID. Dann ist bei Queries oft ein Join nötig. Beispiel: select Person.Name from Organization, Person where Organization.Name = ? and Person.OrgOID = Organization.OID 2. Fremdschlüssel enthalten OID und Name. Dies ergibt einfachere Queries wie select Name from Person where OrgName = ? Diese Lösung benötigt mehr Spalten und mehr Indexes. OID Handling OIDs sind binär und 16 Byte lang. Jedes Programm, welches persistente Objekte anlegt, reserviert zuerst einen Bereich von OIDs, die es verwenden kann. Die höchste vergebene OID ist persistent gespeichert 50 Business Process Management und Workflow-Technologie ID-Klassen Die IDs dienen zur Identifizierung von Objekten sowohl im Code als auch in der Datenbank. Dort sind die IDs Primary und Secondary Keys. Beispiel: ATID Activity Template ID, eine OID. BTID Block Template ID, eine OID. Zur Identifizierung von Blöck- und Prozesstemplates. BIID Block Instance ID, besteht aus einer OID und der BTID des entsprechenden Templates. AIID Activity Instance ID, besteht aus der laufenden Nummer in der Block Instance, der BIID und der ATID. Enthält auch Methoden zum Lesen und Schreiben bei Datenbankzugriffen und zur Serialisierung in Messages. C++ spezifische Kernelmethoden Diese Methoden hängen eng mit der Programmiersprache C++ zusammen. String-Klasse Enthält neben den Standard-String-Operationen auch Methoden zum Lesen und Schreiben bei Datenbankzugriffen, Methoden zum Verschlüsseln von Paßwörtern. Kann DBCS (Double Byte Character Sequence) verarbeiten. Codepage Conversion Einheitliche Benennung von gleichen oder fast gleichen Codepages über die verschiedenen Plattformen. Ermittlung der System-Codepage. Stringkonvertierung in zwei Schritten über Unicode. Strings sind im Programm in der Systemcodepage gespeichert. Eine Alternative wäre die Speicherung in Unicode (UTF-8 oder UTF-16, wie dies bei Java üblich ist). Streaming Klasse zur Serialisierung und Deserialisierung von Datenstrukturen in Messages und Datenbank. Werden diese Funktionen nicht selbst implementiert, (Beispiel Java) könnte sich daraus eine ungewünschte Releaseabhängigkeit ergeben (wenn die Serialisierung inkompatibel geändert würde). Verwaltung von Shared Libraries Methoden zum dynamischen Laden und Entladen von ausführbarem Code. Messagelayer Interface zum Message Queueing System: Fehlerbehandlung. Messages haben einen Messagetyp, der für die Aktion der Message steht, z.B. Start Activity. Für jeden Messagetyp ist folgendes definiert: 1. Quelle und Ziel der Message 2. Request/Reply Messages sind paarweise definiert. 3. Liste der Datenfelder der Message Für jedes Datenfeld einer Message sind folgende Attribute definiert: 1. Name 2. Typ 3. Maximale Länge Kapitel 6. Komponenten eines Workflow-Systems 51 4. Mögliche Anzahl; 0, 1, mehrfach Ein Codegenerator erzeugt C++ und Java Klassen mit den Interfaces zu Messages. Der generierte Code enthält die Methoden zur Serialisierung und Deserialisierung der Messages. Das Interface zur Datenbank Navigation Engine Staff Resolution TOM DBA Database Abbildung 41. Die Code-Ebenen beim Datenbankzugriff Verwendete Funktionen des Datenbanksystems Trigger, Constraints ... werden nicht verwendet. Die Integrität der Datenbank zu erhalten ist Aufgabe des Workflow-Systems. Es dürfen keine Updates in der Datenbank gemacht werden unter Umgehung des Workflow-Systems. Views ... sind definiert als Schnittstelle für Kunden: Selektiver Zugriff auf die Daten z.B. auf Audittrail-Tabelle: CREATE VIEW FMC.ACTSTART AS( SELECT CREATED, ASSOCIATED_OBJECT AS ACTID FROM FMC.AUDIT_TRAIL A1 WHERE EVENT IN (21007,21022) AND ACTIVITY_TYPE = 21100) Der Grund zur Verwendung der Views ist eine Abkoppelung des Interfaces für Kunden vom intern verwendeten Datenbankschema. Authorisierung Datenbanken haben ein Authorisierungskonzept. Verschiedene Personen können unterschiedliche Rechte haben beim Zugriff auf die Datenbank. Das Workflowsystem hat ein eigenes Authorisierungskonzept. Die Datenbankzugriffe für alle Workflow-Benutzer erfolgen immer mit dem gleichen Datenbankbenutzer. 52 Business Process Management und Workflow-Technologie Die Rechte dieses Datenbankbenutzers werden von manchen Kunden auf ein Minimum eingeschränkt, es muß also dokumentiert sein, was dieser minimale Satz an Berechtigungen ist. Datenbankschema erweiterbar Das mit dem Workflow-System bei der Installation angelegte Datenbankschema ist fest mit der folgenden Ausnahme: Der Global Datacontainer von Prozessen: Abhängig von der Struktur des Global Datacontainers wird eine Tabelle beim Import des Processtemplates angelegt. Tablespaces der Datenbank Bei der physischen Organisation der Daten unterstützen wir die Kunden, damit sie über geeignete Schnittstellen bei der Konfiguration die Datenbank an ihre Bedürfnisse bezüglich Speicherplatz und Performance anpassen können. Migration bei Releasewechsel Von einem Workflow-Release zum nächsten können Schemaerweiterungen vorgenommen werden. Falls in diesem Zusammenhang Änderungen der Kundendaten notwendig ist, wird ein Programm zur Datenbankmigration mit dem neuen Release ausgeliefert. Database Access Layer Generierter C++ Code Dieser Layer besteht im Wesentlichen aus generiertem Code. Beispieldefinition einer Query: METHOD seluni2 UNIQUE SELECT * FROM FMC.PROCESS_INST WHERE NAME = ? AND STATE <> 128 ; Static SQL Es wird hier statisches SQL verwendet, d.h. alle Queries und Update SQL-Statements sind zum Compilezeitpunkt definiert. Einfache Zugriffsstruktur Typisch für die SQL-Calls des DBA ist das Lesen und Schreiben aus einer Tabelle. Isolation vom Datenbanksystem Der generierte Code liest dann die Felder alle in eine entsprechende Datenstruktur ein. Durch diesen Layer werden Unterschiede zwischen verschiedenen DB2–Versionen und Oracle vom restlichen Code abgeschirmt: z.B. Unterschiede bei der SQL-Syntax oder verschiedene Datentypen, die verwendet werden können. Da für Oracle und DB2 das Interface von DBA zu TOM gleich ist, reicht es aus, nur den DBA an die Datenbank anzupassen und die Shared Libraries für beide Datenbanktypen auszuliefern. Der restliche ausführbare Code ist gleich. Denormalisierung beim Lesen Kapitel 6. Komponenten eines Workflow-Systems 53 Beim Lesen von Instanzdaten werden zusätzlich auch die Templatedaten gelesen und auch in der Datenstruktur der Instanz gespeichert (Denormalisierung der Daten beim Lesen). Templatedaten dürfen grundsätzlich nicht geändert werden. TOM (Tiny Object Manager) Eingenschaften des TOM Lesen von A Ändern von A Schreiben von A TOM Datenbank Abbildung 42. Der Tiny Object Manager 1. Hält Objekte in seinem Cache innerhalb einer Transaktion. 2. Objekte werden im Cache nach ihrem Schlüssel verwaltet. 3. Updates vom Anwendungsprogramm finden direkt auf den Objekten des TOM statt. 4. Das Zurückschreiben von Records in die Datenbank geschieht nur explizit 5. Einfache Updates von mehreren Records werden direkt ausgeführt, z.B. UPDATE work_item SET state = ’inactive’ WHERE process_inst = ? AND owner != ? Dazu sollte der Cache geleert werden, damit keine veralteten Daten im Cache stehen (Cache Coherency). 6. Werden mehrere Objekte mit einer Query gelesen, wird dem Anwendungsprogramm eine Liste dieser Objekte zurückgegeben. Wenn das Anwendungsprogramm nur eine beschränkte Anzahl an Objekten bearbeiten will, sollte vom TOM nur diese Anzahl geholt werden. Staff Resolution Wie im ganzen Code wurde auch hier versucht, mit statischem SQL zu arbeiten. Da die Menge der möglichen Staff-Resolution Queries nicht begrenzt ist, wurde folgende Lösung gewählt: 54 Business Process Management und Workflow-Technologie Navigation engine Regression test Code generation Resolve BldDynQry PerformQry ExecDynQry ExecStatQry Abbildung 43. Aufrufhierarchie Staff Resolution Die Staff Resolution liefert im Wesentlichen eine Liste von Personen, die ein Workitem zu einer bestimmten Activity erhalten sollen. Dies kann im Prinzip durch eine Query erreicht werden. Beispiel 1: Gesucht sind alle anwesenden Mitglieder einer Abteilung. Ist keiner anwesend, sollen alle Mitglieder der Abteilung ermittelt werden. DECLARE PQERY1111 CURSOR FOR WITH FMC.BASIC(NAME, ABSENT) AS ( SELECT P.NAME, P.ABSENT FROM FMC.PERSON P WHERE P.ORGANIZATION = :org ), FMC.ABS_INDICATOR(EMPTY) AS ( VALUES ( CASE WHEN (SELECT 1 FROM (VALUES(1)) AS Q WHERE EXISTS (SELECT * FROM FMC.BASIC WHERE ABSENT = 0)) IS NOT NULL THEN 0 ELSE 1 END ) ) SELECT P.NAME, 0 FROM FMC.BASIC P, FMC.ABS_INDICATOR I WHERE I.EMPTY = P.ABSENT FOR READ ONLY; Erläuterungen 1. Es werden hier Common Table Expressions verwendet. 2. FMC.BASIC ermittelt alle Personen der Abteilung. Kapitel 6. Komponenten eines Workflow-Systems 55 3. Mit FMC.ABS_INDICATOR wird ermittelt, ob es anwesende Personen gibt. In diesem Fall hat er den Wert 0, sonst 1. 4. Abhängig von diesem Indikator sucht dann die Query entweder die anwesenden Personen oder die abwesenden Personen dieser Abteilung. Die gleiche Aufgabe wird jetzt mit einer allgemeineren Query gelöst: DECLARE PQERY5073 CURSOR FOR SELECT P.NAME, P.ABSENT FROM FMC.PERSON P WHERE P.ORGANIZATION = :org FOR READ ONLY; Hier liefert die Query alle Mitglieder der Abteilung. Danach muß noch im C++ Code durch die Liste durchgegangen werden um entweder alle abwesenden oder alle anwesenden Personen zu löschen. Beispiel 2: Wie oben werden die Mitglieder einer Abteilung gesucht. Ist eine Person abwesend, soll ihr Vertreter ausgewählt werden, wenn sie anwesend ist. DECLARE PQERY1110 CURSOR FOR WITH FMC.BASIC(OID) AS ( SELECT P.OID FROM FMC.PERSON P WHERE P.ORGANIZATION = :org ), FMC.NORMAL(NAME, ASSIGNMENT_TYPE) AS ( SELECT P.NAME, 0 FROM FMC.PERSON P WHERE P.ABSENT = 0 AND P.OID IN (SELECT OID FROM FMC.BASIC) ), FMC.SUBSTITUTE(NAME, ASSIGNMENT_TYPE) AS ( SELECT DISTINCT P.NAME, 1 FROM FMC.PERSON P, FMC.PERSON P2 WHERE P2.ABSENT = 1 AND P2.SUBSTITUTE_OID IS NOT NULL AND P.OID = P2.SUBSTITUTE_OID AND P.ABSENT = 0 AND P2.OID IN (SELECT OID FROM FMC.BASIC) ) SELECT * FROM FMC.NORMAL UNION ALL SELECT * FROM FMC.SUBSTITUTE WHERE NAME NOT IN (SELECT NAME FROM FMC.NORMAL) FOR READ ONLY; Mit etwas C++ Code wird diese Aufgabe mit der folgenden Query erledigt: DECLARE PQERY5074 CURSOR FOR SELECT P.NAME, P.ABSENT, P.SUBSTITUTE, FMCS.ABSENT FROM FMC.PERSON P LEFT OUTER JOIN FMC.PERSON FMCS ON P.SUBSTITUTE_OID = FMCS.OID WHERE P.ORGANIZATION = :org FOR READ ONLY; Die Ergebnisliste wird wie folgt bestimmt:: 1. Von jedem gelesenen Record wird die Person ausgewählt, wenn sie anwesend ist. Ist sie abwesend und ist ihr Vertreter anwesend, wird der Vertreter ausgewählt. 2. Die so erhaltene Liste wird sortiert. 56 Business Process Management und Workflow-Technologie 3. Mehrfache Records der gleichen Person werden aus der Liste gelöscht. Server Framework Das Serverframework kann als Betriebssystem eines Servers bezeichnet werden. Aufgaben: 1. Initialisierung und Beenden des Servers. 2. Fangen und korrektes Verarbeiten von Exceptions, die vom Server geworfen wurden. 3. Weiterleiten der Message in eine Hold Queue, wenn sie nicht verarbeitet werden kann. 4. Die Main-Message-Loop: Transaktionsbeginn, Lesen einer Message, Bearbeiten und Abschluß der Transaktion. 5. Spezielle Anpassungen an das Betriebssystem bei z/OS. FDL Parser, Verifier Ausschnitt aus einer FDL-Definition eines Prozesses: PROCESS ’CreditRequest’ ( ’PersonInfo’, ’Default Data Structure’ ) DESCRIPTION ’Credit request’ PROMPT_AT_PROCESS_START NO AUTONOMY WINDOW ZOOM_FACTOR 100 WINDOW PAPERSIZE WIDTH 2970 HEIGHT 2100 WINDOW SHOW ALL CONNECTORS WINDOW SHOW TRANSITION_CONDITIONS SOURCE 1 XPOS -918 YPOS 433 PROGRAM_ACTIVITY ’AssessRisk’ ( ’CreditInfo’, ’CreditInfo’ ) DESCRIPTION ’Credit request for %CredReq.FirstName% %CredReq.LastName%’ START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -232 YPOS 177 NAME_POSITION XPOS -232 YPOS 102 DONE_BY STARTER_OF_ACTIVITY ’CollectCreditInformation’ PROGRAM ’NAssessCreditRisk’ END ’AssessRisk’ ... CONTROL FROM ’AssessRisk’ TO ’AcceptCredit’ WHEN ’CreditAmount<100000 AND RiskFactor="L"’ XPOS 188 YPOS 146 ... DATA FROM SOURCE 1 TO ’CollectCreditInformation’ MAP ’_STRUCT’ TO ’_STRUCT’ ... END ’CreditRequest’ Die FDL Parser bestehen aus zwei Teilen: Parser-Frontend Das Parser-Frontend für C++ ist mit einem YACC- (yet another compiler compiler) ähnlichen Tool geschrieben, für Java wurde JavaCC verwendet. Das Frontend baut einen Parsertree im Speicher auf. Syntaktische und semantische Fehler sollten möglichst bei diesem Schritt erkannt werden. Parser-Backend Der Parsetree wird vom Backend bearbeitet. Kapitel 6. Komponenten eines Workflow-Systems 57 Beispielsweise haben Runtime-Import und Buildtime-Import ein gemeinsames Frontend, aber verschiedene Backends. Regression Test Schon bei der Entwicklung von größeren Komponenten sind Tests zu schreiben, die sicherstellen, daß Szenarien korrekt bearbeitet werden. Kennzeichen: Produktstabilität Die Hauptaufgabe von Regressiontests ist, zu gewährleisten, daß neu eingebaute Funktionen oder Korrekturen nicht unerwünschte Nebeneffekte haben. Der Regression Test läuft automatisch ab. Validierung Die Ergebnisse werden entweder mit einem früheren, als korrekt identifiziertem Ergebnis verglichen oder auf auch eine andere Weise bestimmt und dann verglichen. Fehlerursachen Falls Differenzen auftreten, ist die Analyse oft sehr aufwändig. Mögliche Ursachen sind: Setupproblem beim Testcase, korrekt geänderter Code, liefert etwas andere Ergebnisse, neu eingebauter Fehler im Code. Aufsetzpunkt Speziell am Anfang eines Entwicklungsprojektes ist es sinnvoll, über spezielle Interfaces eine Komponente zu testen. Zum Beispiel kann dann ein Workflow-Server ohne das Message-Queueing-Interface getestet werden. Später sollten dann eher die offiziellen Schnittstellen beim Test verwendet werden, um praxisnähere Bedingungen zu haben. 58 Business Process Management und Workflow-Technologie Kapitel 7. Prozesse eines Workflow-Systems Außer dem Client API, welches multi-threaded betrieben werden kann, sind die Prozesse hier single-threaded. Folgende Kriterien wurden bei der Aufteilung der Funktionen verwendet: Trennung der Verarbeitung der Client-Requests von anderen Aufgaben Die Hauptlast eines Workflow-Systems sind Client-Requests. Durch diese Trennung läßt sich das System besser kontrollieren. Andere Transaktionen, die lange laufen, behindern dadurch nicht kurze Transaktionen, die vom gleichen Server zu bearbeiten wären. Sonderaufgaben müssen oft zentral für die ganze Installation ausgeführt werden. Für diese Aufgaben speziell geschriebene Programme können dies besser kontrollieren. Fehlertoleranz Fehler sollten zwar gemeldet werden, das System sollte aber nach Möglichkeit robust sein. Verschiedene Workflow-Installationen sinnvoll unterstützen Speziell bei größeren Kunden gibt es Systeme zum Modellieren, Testen und für die Produktion. Administration Server Watchdog Überwacht und steuert die anderen Server des Systems, gibt Auskunft über den Zustand des Systems. Session Handling Da eine Kommunikation mit dem Administration Server nur in einer gültigen Session möglich ist, und der Administration Server auch allein laufen sollte, wird das Session Handling für das gesamte Workflow-System vom Administration Server ausgeführt. Logging Es gibt verschiedene Ziele für Log-Messages: Administration Client, Datenbanktabellen, Files. Die Log-Messages werden an den Administration Server geschickt, der sie dann weiterverteilt. Hold-Quere Handling Messages, deren Backout-Count überschritten wurden, werden in die Hold-Queue geschickt. Der Administration Server ermöglicht die Verwaltung dieser Messages (Löschen, Wiederausführung, Lesen der Messages). Administration Client Stellt das Userinterface des Administration Servers dar: 1. Auskunft, welche Server gerade laufen. 2. Manuelles Starten und Stoppen von Serverinstanzen. 3. Ist Konsole des Systems, es werden Ereignisse des Systems wie z.B. Fehlersituationenen angezeigt. © Copyright IBM Corp. 2001,2005 59 Navigation, Execution Server Bearbeitet die Client Requests (Außer Logon/Logoff und Administration Tasks). Ist Quelle und Ziel der Messages von verketteten Transaktionen. Abbildung 44. Vereinfachtes Statusübergangsdiagramm von Activities Falls Memory Leaks auftreten, kann der Server nach einer festgelegten Anzahl von Transaktionen stoppen. Der Administration Server startet in diesem Fall eine neue Serverinstanz. Anlegen und Löschen von Process Instances kann auf Zeiten verlegt werden, bei denen das System weniger belastet ist. Program Execution Server Startet die Programmaktivitäten für das Workflow-System. Mögliche Invokationmechanismen: CICS, IMS Transaktionen Aufruf als Safe Application, das heißt als verkettete Transaktion. Ausführbares Programm Keine Transaktionssicherheit Java Programm, Shared Library Keine Transaktionssicherheit. Wichtige Optionen: 1. Fenced Mode: in separatem Prozess für eine größere Robustheit. 2. Keep Loaded: die Library wird im Speicher für eine bestimmte Zeit gehalten, damit nicht mit jedem Programmaufruf die Library erneut geladen werden muß. 60 Business Process Management und Workflow-Technologie Scheduling Server Es gibt zeitgesteuerte Ereignisse wie Notification (Mitteilung, wenn eine Activity zu lange in Bearbeitung ist) oder Expiration (Weiternavigation nach einer bestimmten Zeit). Diese Ereignisse werden in einer Tabelle gesammelt. Der Scheduling Server ermittelt regelmäßig die Ereignisse, die in der Vergangenheit liegen. Für jedes Ereignis wird eine Message an den Execution Server geschickt, der dann die notwendigen Aktionen ausführt. Cleanup Server Das Löschen von Prozessen läuft in drei Schritten ab: 1. Der Cleanup Server ermittelt die Prozesse, die gelöscht werden sollen. Dem Execution Server wird eine Liste dieser Prozesse geschickt. Das Löschen eines Prozesses kann auch explizit über ein API angestoßen werden. 2. Der Execution Server identifiziert alle Records, die gelöscht werden sollen und markiert sie als Deleted. 3. Der Cleanup Server löscht alle Records, die im Status Deleted sind. Workflow Client API Die eigentliche Benutzerschnittstelle. Existiert in zwei Formen: Abbildung 45. Die Architektur des Client APIs Java API Ist komplett in Java geschrieben. C-API Ist in C++ geschrieben, Das C-API ist auch Basis folgender APIs: C++, Cobol, COM/DCOM/ActiveX. Das Java API basierte in früheren Releases auch auf dem C-API (über JNI, Java Native Interface). Kapitel 7. Prozesse eines Workflow-Systems 61 Das Client API stellt folgende Funktionen zur Verfügung: Prozessnavigation Starten von Prozessen und Programmen Prozessadministration Status des Prozesses, Verändern des Prozessstatuses. Listen Basis zur Anzeige von Worklisten. Container API Zum Zugriff auf Containerfelder von einem Programm aus (wenn Invocation nicht über XML geht). Web Client Siehe auch Kapitel über Web-basierte Anwendungen oben. Der Web Client setzt auf das Java API auf. Die Darstellungssicht ist über JSP (Java Server Pages) programmiert. Session Handling geschieht über Cookies im Browser und die Services des Application Servers. Staff Administration API Um Personen, Organisationen und Rollen mit einer Kundenanwendung verwalten zu können, gibt es das Staff Administration API. Es gab drei Alternativen beim Entwurf dieses APIs: 1. Erweiterung des Client APIs um entsprechende Klassen und Methoden. 2. Staff Administration API basiert auf Datenbank-Client. 3. Kein API, sondern Freigabe der SQL-Schnittstelle. Die zweite Alternative wurde gewählt. Abbildung 46. Die Architektur des Staff Administration APIs LDAP Bridge Zum Abgleich mit einer externen Directory wird die LDAP Bridge verwendet. 62 Business Process Management und Workflow-Technologie Abbildung 47. Architektur der LDAP Bridge Buildtime Modellierungskomponente Workload Management Plattformen für geschäftskritische Anwendungen bieten ein Workload Management an. Hier werden Ziele für Durchsatz, Antwortzeiten und Prioritäten definiert. Workload Management steuert das System dann so, daß diese Ziele möglichst erreicht werden. Bei dem Workflow-System wurde dies auf z/OS umgesetzt. Aufgaben des Administration Servers werden hier von Workload Management übernommen. Aufgaben 1. Der Schedulingserver hat einen Konfigurationsparameter: die Zeit, die zwischen zwei Queries zum Ermitteln der aktuellen Ereignisse liegt. a. Welche Kriterien sind relevant bei der Frage, wie lang dieses Intervall sein sollte ? b. Welche andere Lösungen wären möglich, um diesen Konflikt zu entschärfen ? 2. Für diese Aufgabe betrachten wir im Detail, was im Execution Server abläuft, wenn ein Workitem im Zustand Ready selektiert wird und dadurch die assoziierte Activity gestartet wird. Wir nehmen an, diese Transaktion läuft wie folgt ab: Der Client-Request enthält neben der Aktion Start Workitem die Id des Workitems. Der Reihe nach werden folgende Records gelesen, um ihre Stati zu ändern: Als erstes wird der Workitem-Record gelesen um daraus auch die Activity zu ermittlen. Diese wird dann in einem zweiten Schritt gelesen. Zuletzt werden dann die restlichen Kapitel 7. Prozesse eines Workflow-Systems 63 Workitems dieser Activity gelesen. Das eigene Workitem und die Activity werden in den Status Running und alle anderen Workitems in den Zustand Disabled gesetzt. a. Überlegen Sie sich, welches Problem auftreten kann, wenn quasi gleichzeitig zwei verschiedene Workitems einer Activity gestartet werden. b. Überlegen Sie sich eine Lösung des Problems.. Hinweis: Datenbankrecords können auch ohne Setzen eines Locks (uncommitted read) gelesen werden. 64 Business Process Management und Workflow-Technologie Kapitel 8. Middleware: Standards und Produkte Dieses Kapitel beschreibt Ansätze, verteilte Anwendungen zu integrieren. Das Spektrum der erhältlichen Produkte ist diffus. Große Komplexität, keine oder verschiedene Standards, Überschneidungen beim Funktionsumfang sind üblich. RPC (Remote Procedure Call) RPC ist eine einfache Interaktion zwischen zwei Systemen. Kennzeichen: v Synchroner Aufruf. v Überwindung von Plattformgrenzen. v Darstellung des RPCs als lokaler Funktionsaufruf für den Anwendungsprogrammierer. v Verwendung einer IDL (Interface Definition Language). v Anzahl der RPCs zwischen den Partnern sollte in einer Session minmiert werden. v Referenzen auf Objekte im RPC müssen für beide Partner sinnvoll sein. v Authorisierung, Sicherheit Erweiterungen Dynamic Binding Erweitert die Möglichkeiten, wie ein Client den Service des Servers findet. Möglichkeiten sind hier: 1. Static Binding, also zum Compile-Zeitpunkt. 2. Binding by Reference, also durch einen Konfigurationsparameter. 3. Binding by Lookup, also durch Suchen in einer Service Registry. 4. Service Composition, bei der die Syntax und Semantik der Services erst aus der Service Registry ermittelt werden. TRPC (Transaktionaler RPC) Damit kann ein RPC an einer vereilten Transaktion mit 2 Phase Commit teilnehmen. Asynchroner RPC, persistente Messages Beim asynchronen RPC blockiert der Client nicht bei dem Aufruf bis zum Empfang der Antwort. Wird die feste Bindung zwischen Request und Reply aufgegeben, handelt es sich um ein Message-orientiertes Kommunikationssystem. TP-Monitore (Transaction Processing) Umfang eines TP-Monitors RPC IDL Compiler, Runtime Environment für RPC. TRPC Die Programmiersprache unterstützt Transaktionen. Ein Transaktionsmanager mit den Funktionen Logging, Recovery, Schnittstellen für Kundenerweiterugen (z.B. Audit Trail mit kundenspezifischen Daten). © Copyright IBM Corp. 2001,2005 65 System Administration Installation, Überwachen, Starten, Stoppen von Services, Workload Management. Interfaces zu Resource Managern Andere Komponenten wie z.B. Datenbanken sind integriert in den TP-Monitor. Transaktionssicherheit kann durch verteilte Transaktionen gewährleistet sein. Object Broker Als Beispiel sei hier CORBA (Common Object Request Broker Architecture) vorgestellt. Weiterer Vertreter ist COM+ (Component Object Model) von Microsoft. CORBA wurde Anfang der 1990–Jahre von der OMG (Object Managment Group) spezifiziert. Es gab viele CORBA-Implementierungen und Anwendungen, die darauf basierten. Mit Java, Application Server und Web Services hat CORBA viel an Aufmerksamkeit eingebüßt. Kennzeichen von CORBA RPC für Objekte Wendet das objektorientierte Paradigma auf RPC an: Vererbung und Polymorphie. Ein weiteres objektorientiertes Paradigma, Information Hiding, das heißt Zugriff auf Daten nur über definierte Interfaces ergibt sich schon aus den Umständen eines RPCs. Dynamic Service Invocation Wenn ein Service in CORBA zur Verfügung steht, kann sein Interface in CORBA beschrieben sein, sodaß Clients, dies dynamisch ermitteln können. Die Beschreibung umfaßt die Syntax der Services, aber nicht die Semantik (Bedeutung) und auch nicht zeitliche oder inhaltliche Abhängigkeiten zwischen den Services. Außer für administrative Zwecke (Service Directory) hat dies keine weite Verbreitung gefunden. Objekt Monitore als Weiterentwicklung von TP-Monitoren. Message Queueing Losere Koppelung von Anwendungen als bei RPC Message Queueing Produkte sind nicht so breit angelegt wie TP Monitore (keine IDL). Das Leitbild ist hier, aus verschiedenen Komponenten eine Lösung zu bauen. Message Broker Erweiterug von Message Queuing als Integrationsplattform, Kennzeichen 66 Business Process Management und Workflow-Technologie Message Transformation Tools werden bereitgestellt, zu transformieren, beispielsweise XML Messages in dem Umfang, wie es XSLT (XML Stylesheet Language Transformation) bietet. Adapter Sind Interfaces zu Produkten wie Datenbanken, E-Mail-Systemen, Application Servern, damit eine Integration mit diesen Produkten möglichst einfach wird. Publish Subscribe Ist ein Kommunikationsmodell zwischen einem Server und vielen Clients: Der Server liefert Daten, z.B. Aktienkurse und die Clients können sich für Kategorien registrieren z.B. die Kurse von bestimmten Firmen, die sie dann zugeschickt bekommen. Web Services Nach dem W3C (World Wide Web Consortium) ist ein Web Service a software application identified by a URL, whose interfaces and bindings are capable of being defined, described and discovered as XML artifacts. A Web Service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols. Probleme bei der B2B Integration Mit klassischer Middleware könnten auch Unternehmen miteinander verbunden werden. Dem spricht entgegen: Zentralisierte Administration Software, die unternehmsweite Services zur Verfügung stellt, sollte aus Kosten- und Effizienzgründen möglichst zentral administriert werden. Dies ist unpassend, wenn unabhängige Unternehmen miteinander kommunizieren. Information Hiding Soll beispielsweise ein Workflow zwischen Unternehmen definiert werden, so wird unterschieden zwischen der Interaktion zwischen den Firmen und dem internen Workflow innerhalb des Unternehmens. Ersteres muß zwischen den Unternehmen definiert sein, letzteres darf und soll nicht publik sein. Firewalls schränken mögliche Protokolle ein Bei B2B müssen Firewalls überwunden werden. Typischerweise werden hier HTTP (Hyper Text Transfer Protocol) und SMTP (Simple Mail Transfer Protocol) verwendet. Standardisierung Es besteht die Erwartung, daß B2B in einem ähnlichen Stadium ist wie das Internet vor der Einführung des WWW mit den Standards HTTP und HTML. Verwendete Protokolle bei Web Services SOAP (ursprünglich: Simple Object Access Protocol) SOAP ist ein durch das W3C definierter Standard. SOAP ist das Basisprotokoll der bei Web Serivices verwendeten Messages. SOAP spezifiziert folgendes: Kapitel 8. Middleware: Standards und Produkte 67 Message Format Beschreibt, wie Daten in XML-Messages einzupacken ist: Ein SOAP Header SOAP Envelope SOAP Header Header Block SOAP Body Body Block Abbildung 48. Struktur einer SOAP Message ist optinonal, während ein SOAP Body vorhanden sein muß. Attribute der Message können im SOAP Header gespeidhert werden (z.B. Informationen zu einem TRPC). RPC Konventionen Beschreibt, wie SOAP Messages für RPCs zu verwenden sind. Regeln zur Verarbeitgung von SOAP Messages Beschreibt, welche XML Elemente einer SOAP Message zu lesen sind und was der Empfänger zu tun hat, wenn er die SOAP Message nicht verarbeiten kann. SOAP Bindings Beschreibt, wie SOAP Messages über HTTP und SMTP zu verschicken sind. Üblicherweise wird HTTP eher bei einer RPC-ähnlichen Interaktion verwendet, während SMTP ein asynchrones Protokoll ist. WSDL (Web Service Definition Language) WSDL ist ein durch das W3C definierter Standard. Ist quasi die IDL bei Web Services. Beschreibt folgende Aspekte eines Web Services: InterfaceBindings Beschreibt, welche Attribute in der Message verwendet werden können, und wie sie codiert sind. Definiert auch das verwendete Protokoll wie HTTP oder SMTP. Ports Damit wird ein InterfaceBinding einer Netzwerkadresse zugeordnet. Services Ist eine logische Gruppierung von Ports. Stellt beispielsweise eine Anwendung mehrere Ports zur Verfügung, können diese zu einem Service zusammengefaßt werden. 68 Business Process Management und Workflow-Technologie Bei vorhandene Services, die über einen Adapter als Web Service zur Verfügung gestellt werden, sollte WSDL aus den existierenden Beschreibungen des Interfaces generiert werden. Eine vorhandene WSDL sollte verwendet werden können, um Server- oder Clientstub zu generieren. UDDI (Universial Description Discovery and Integration) UDDI ist ein von OASIS definierter Standard. UDDI definiert Registries, die vorhandene Web Services katalogisieren. Die UDDI stellt Daten zur Verfügung, die zum Designzeitpunkt oder zur Laufzeit einer Anwendung gelesen werden können, um Web Services zu finden und um Daten über diese Web Services zu ermitteln. BPEL (BPEL4WS: Business Process Execution Language for Web Services) BPEL hat verschiedene Aspekte: Service Composition Ein Business Prozeß, der zwischen Partnern abläuft, beinhaltet oft den Austausch von mehreren Messages, die nach bestimmten Regeln zu erfolgen hat. Prozeßbeschreibung BPEL kann wie die FDL verwendet werden, um ein Process Template zu definieren. J2EE J2EE ist eine Middleware-Platform von Sun. Die Weiterentwicklung von J2EE wird durch den JCP (Java Community Process) gesteuert,, in dem Java-Interessenten eingebunden sind. Basierend auf Java RMI (dem CORBA-Protokoll IIOP) stellt J2EE entfernte Methodenaufrufe zur Verfügung. Services werden in folgenden Containern zur Verfügung gestellt: EJB-Container Die Anwendungslogik läuft als Enterprise JavaBeans im Applicationserver. Servlet-Container Vor allem die Darstellungsschickt läuft als Servlet im Webserver. Application-Client-Container Java Clients können in diesem Container laufen. Applet-Container Dieser Code kann als Plugin in einem HTML-Browser laufen. .Net .Net ist eine von Microsoft entwickelte und kontrollierte Middleware-Plattform. Basis von .Net ist CLR, die Common Language Runtime. Die von CLR unterstützen Sprachen werden in MSIL (Microsoft Intermediate Language) umgewandelt, der vor der Ausführung in Maschinencode übersetzt werden kann (vergleichbar dem Byte-Code bei Java). Kapitel 8. Middleware: Standards und Produkte 69 .Net stellt vier teilweise inkompatible Kommunikationstechnologien zur Verfügung: ASP.Net Active Server Pages für Webanwendungen. Steht auch als Webservice zur Verfügung. .Net Remoting TCP-basierende entfernte Methodenaufrufe, die Kommunikationsinfrastruktur von .Net. DCOM Distributed Component Object Model, entfernte Methodenaufrufe, nicht auf CLR basierend. MS Message Queue Queuing-System für Enterprise Server. Workflow Begann mit Office Automation, Workflow als Bestandteil von Imaging Systemen. Bei solchen Systemen wird die eingehende Post einer Verwaltung eingescannt und dann papierlos weiterverarbeitet. Vertikale Standards Typisch für die Umsetzung einer Kommunikations- oder Datenverarbeitungsaufgabe ist die Verwendung von Ebenen (XML, HTTP, TCP, IP, Ethernet, Darstellungsschicht, Message Queuing, Datenbanken). Ein anderer Ansatz wird bei den folgenden Standards gewählt: UN/EDIFACT United Nations Directories for Electronic Data Interchange for Administration, Commerce and Transport. Wird beispielsweise zwischen Autoherstellern und Zulieferern eingesetzt. SWIFT Die Society for Worldwide Interbank Financial Telecommunication betreibt ein Netz zum Austausch von Finanznachrichten zwischen Banken mit der von Banken geforderten Sicherheit und Verläßlichkeit. Ähnliche Standards sind RosettaNet, xCBL (XML Common Business Library) von CommerceOne, ebXML (Electronic Business Using eXtensible Markup Language). Hier werden Messagetypen (Syntax und Semantik) für konkrete Anwendungsfälle definiert (z.B. Bestellung) im B2B (Business to Business) Fall. Weiter werden Protokollstacks und z.B. die zeitliche Abfolge von einem Messageaustausch definiert. Aufgaben 1. Vergleichen Sie ein Workflow-System mit einem TP-Monitor. Betrachten Sie folgende Aspekte: a. Dem Kunden zur Verfügung stehende Funktionsumfang b. Welche dieser Funktionen sind Bestandteil des Workflow-Systems oder des TP-Monitors, welche Funktionen werden von anderen Produkten bereitgestellt ? 70 Business Process Management und Workflow-Technologie Kapitel 9. Übungsaufgaben 1. Aufgabe In einem Workflow Prozess gebe es unter anderem zwei Activities A, B, die nacheinander auszuführen sind. Dieses Paar von Activities ist mehrfach zu durchlaufen bis eine Abbruchbedingung erfüllt ist. a. Skizzieren Sie, mit welchen Konstrukten dies zu modellieren ist. b. Wie wird die Abbruchbedingung spezifiziert ? 2. Aufgabe 3. 4. 5. 6. 7. Erläutern Sie, warum man im Zusammenhang mit Message Queuing von einer asynchronen Kommunikation spricht. Aufgabe Im Folgenden gehen wir von einer Einprozessorenmaschine aus. Ein Mikroprozessor mit der Taktgeschwindigkeit von 1 GHz führe im Durchschnitt einen Maschinenbefehl pro Takt aus. Werden Daten von der Festplatte gelesen, so benötige dies 10 ms bis die Daten im Hauptspeicher stehen. a. Wieviele Maschinenbefehle kann dieser Prozessor ausführen, bis angeforderte Daten von der Festplatte in den Hauptspeicher geladen sind ? b. Verwenden Sie diese Ergebnis, um zu begründen, warum es sinnvoll sein kann, ein Serverprogramm mehrfach zu starten, sodaß davon mehrere Prozesse quasiparallel laufen. Aufgabe Erläutern Sie, warum bei den ACID-Eigenschaften die Consistency-Eigenschaft als Voraussetzung die Isolation-Eigenschaft hat. Sehen Sie weitere Abhängigkeiten zwischen den ACID-Eigenschaften ? Aufgabe Warum ist es sinnvoll, für Process Instances und Process Templates zwei Datenbanktabellen in der Runtime-Datenbank eines Workflow-Systems vorzusehen und nicht die Daten gemeinsam in einer Tabelle zu speichern ? Aufgabe Workflow-Systeme unterstützen die Trennung von Anwendungslogik und Prozesslogik. a. Erläutern Sie diesen Satz. b. Was ist der Nutzen einer Trennung von Anwendungslogik und Prozesslogik ? c. Was könnten Nachteile des Einsatzes von Workflow-Systemem sein ? Aufgabe Warum sind in einem typischen Workflow-System die Mitarbeiter, die mit diesem System arbeiten und ihre Beziehungen zueinander in dem Workflow-System definiert ? © Copyright IBM Corp. 2001,2005 71 72 Business Process Management und Workflow-Technologie Index A I ACID siehe Atomicity, Consistency, Isolation, Durability Activity 3, 5 Atomicity 26 Atomicity, Consistency, Isolation, Durability 26 Audit Trail 11 Isolation Program 3 Activity 5 26 Q L Level einer Person Message Role 8 28 S Block Activity 5 N Navigation C Cluster von Queue Managern Consistency 26 Container 6 Control Connector 3 30 D Data Connector 4 Datenbanksystem 25 Dead Path Elimination Durability 26 8 R M B Queue 28 7 © Copyright IBM Corp. 2001,2005 Start Condition Substitute 9 7 T O Organization 7 8 P persistent 26 Person 8 Process Activity 5 Instance 3 Monitor 12 Template 3 Three-Tier Architektur Tracing 13 Transaction 25 transient 26 4 W Work Item 4 Worklist 4 73
