Analyse. Migrationsassistent BPMN 2.0 nach BPI. Hochschule Luzern Technik & Architektur. Master of Science in Engineering Master-Thesis

Transkript

1 Hochschule Luzern Technik & Architektur Migrationsassistent Master of Science in Engineering Master-Thesis Simon von Däniken Zihlmattweg 42 / Luzern simon.vondaeniken@gmail.com Matrikel-Nummer Horw,

2 Inhalt Abbildungsverzeichnis... IV Tabellenverzeichnis... VI Abkürzungsverzeichnis... VII 1 Einleitung Diagrammtypen Pool und Lanes Pool Lanes Sequenzflüsse Nachrichtenfluss Aktivitäten Tasks Unterprozesse Aufrufaktivität Daten Ereignisse Gateways Exklusiver Gateway Inklusiver Gateway Paralleler Gateway Komplexer Gateway Ereignisbasierter Gateway Prozesspfade ohne Gateways Kompensation Artefakte Zusammenfassung Pool und Lanes Flüsse Task-Markierungen Task-Typen Unterprozesse Aufrufaktivität Daten Startereignisse Startereignisse für Ereignis-Unterprozesse Endereignisse Zwischenereignisse im normalen Fluss Angeheftete Zwischenereignisse Gateways II

3 3.14 Artefakte Kosten/Nutzen-Matrizen Literatur- und Quellverzeichnis Anhang A Häufigkeit der BPMN Symbole B BPMN 2.0 Unterstützung in jbpm III

4 Abbildungsverzeichnis Abbildung 1: Beispiel einer Kommunikation zweier Pools, dargestellt mittels Nachrichtenflüssen... 3 Abbildung 2: Beispiel eines Mehrfachteilnehmers... 3 Abbildung 3: Mögliche Ausprägungen eines Sequenzflusses... 5 Abbildung 4: Modellierung von Sequenzflüssen in der BPMN (links) und im BPI... 5 Abbildung 5: Mögliche Ausprägungen eines Nachrichtenflusses... 6 Abbildung 6: Mögliche Markierungen eines Tasks gemäss der BPMN Abbildung 7: Transformation einer Schleife von BPMN 2.0 (oben) nach BPI (unten)... 7 Abbildung 8: Umsetzung einer parallelen Mehrfachinstanz im BPI... 8 Abbildung 9: Mögliche Task-Typen gemäss BPMN Abbildung 10: Mögliche Markierungen eines Unterprozesses gemäss BPMN Abbildung 11: Verzicht auf einen eingebetteten Unterprozess Abbildung 12: Zugeklappter Ereignis-Unterprozess welcher durch eine Nachricht gestartet wird Abbildung 13: Umwandlung eines Ereignis-Unterprozesses (links) zu einem angehefteten Ereignis.. 12 Abbildung 14: Umwandlung eines an einen Unterprozess angehefteten Ereignis Abbildung 15: Auswirkung einer parallelen Ausführung auf angeheftete Ereignisse Abbildung 16: Darstellung einer zugeklappten Transaktion in BPMN Abbildung 17: Aufruf eines unbestimmten Tasks, User Tasks und Unterprozesses (v.l.n.r.) Abbildung 18: Mögliche Datenobjekte in BPMN Abbildung 19: Schreibender Zugriff auf Sharepoint in der BPMN (links) und in BPI Abbildung 20: Beispiel unterschiedlicher Ereignisse in BPMN Abbildung 21: Beispiel eines Zeitnehmers in BPI Abbildung 22: Aufteilung eines Nachrichten-Endereignisses in zwei Ereignisse Abbildung 23: Umsetzung eines Bedingungs-Zwischenereignisses in BPI Abbildung 24: Exklusiver Gateway Abbildung 25: Transformation eines exklusiven Gateways (oben) nach BPI (unten) Abbildung 26: Inklusiver Gateway Abbildung 27: Abbildung eines inklusiven Gateways mittels exklusiven und parallelen Gateways Abbildung 28: Paralleler Gateway Abbildung 29: Beispiel eines nicht funktionsfähigen BPI Prozesses Abbildung 30: Auftrennung einer Kombination von Zusammenführung und Verzweigung Abbildung 31: Komplexer Gateway in Kombination mit einer parallelen Verzweigung Abbildung 32: Beispiel eines ereignisbasierten Gateways Abbildung 33: Beispiel eines Prozessstartes mit einem ereignisbasierten exklusiven Gateway Abbildung 34: Beispiel eines Prozessstartes mit einem ereignisbasierten parallelen Gateway Abbildung 35: Exklusiver Gateway (links) und dessen alternative Darstellung ohne Raute Abbildung 36: Umsetzung des exklusiven Gateways ohne Raute im BPI Abbildung 37: Inklusiver Gateway (links) und dessen alternative Darstellung ohne Raute Abbildung 38: Umsetzung des Inklusiven Gateways ohne Raute in BPI Abbildung 39: Paralleler Gateway (links) und dessen alternative Darstellung ohne Raute Abbildung 40: Umsetzung des parallelen Gateways ohne Raute in BPI Abbildung 41: Beispiel einer Kompensation mittels eines Tasks (links) oder Unterprozesses Abbildung 42: Beispiel einer Kompensation mittels eines Ereignis-Unterprozesses Abbildung 43: Eine Aktivität rückgängig machen mit (links) und ohne Kompensation Abbildung 44: Möglicher Einsatz von Assoziationen, Text Annotationen und Gruppen IV

5 Abbildung 45: Kosten/Nutzen-Matrix für Start- und Endereignisse Abbildung 46: Kosten/Nutzen-Matrix für Zwischenereignisse Abbildung 47: Kosten/Nutzen-Matrix für angeheftete Zwischenereignisse Abbildung 48: Kosten/Nutzen-Matrix für Aktivitäten Abbildung 49: Kosten/Nutzen-Matrix für Pools, Lanes, Gateways, Flüsse, Daten und Artefakte Abbildung 50: Häufigkeit der BPMN 2.0 Symbole V

6 Tabellenverzeichnis Tabelle 1: Transformation der BPMN 2.0 Task-Typen nach BPI Tabelle 2: Übersicht aller BPMN 2.0 Ereignisse Tabelle 3: Transformation von Pool und Lanes Tabelle 4: Transformation von Flüssen Tabelle 5: Transformation von Task-Markierungen Tabelle 6: Transformation von Task-Typen Tabelle 7: Transformation von Unterprozessen Tabelle 8: Transformation der Aufrufaktivität Tabelle 9: Transformation von Daten Tabelle 10: Transformation von Startereignissen Tabelle 11: Transformation von Startereignissen für Ereignis-Unterprozesse Tabelle 12: Transformation von Endereignissen Tabelle 13: Transformation von Zwischenereignissen im normalen Fluss Tabelle 14: Transformation von angehefteten Zwischenereignissen Tabelle 15: Transformation von Gateways Tabelle 16: Transformation von Artefakten VI

7 Abkürzungsverzeichnis BPI Business Process Integrator BPM Business Process Management BPMN Business Process Model and Notation OMG Object Management Group VII

8 Einleitung 1 Einleitung Die Bison Schweiz AG hat sich mit dem Business Process Integrator (BPI) zum Ziel gesetzt, eine eigene BPM-Lösung zu entwickeln, welche insbesondere die Einfachheit in der Modellierung von Business- Prozessen in den Vordergrund stellt. Als Grundlage kommt die Open Source Prozess-Engine jbpm in der dritten Version zum Einsatz. Um die Prozessmodellierung zu vereinfachen, wurde ein eigenes Prozessmodell entwickelt, welches bewusst auf die wesentlichen Funktionalitäten reduziert wurde. Im Rahmen der Master-Thesis Migrationsassistent soll aufgezeigt werden, wie gut sich fachliche Business Prozess in der BPMN 2.0 Notation ins BPI Prozessmodell transformieren lassen und wo die Grenzen des Machbaren liegen. Bevor ein Prototyp eines Migrationsassistenten implementiert werden sollte, wurden in einer ersten Phase die Unterschiede zwischen der BPMN und dem BPI Modell analysiert. Ziel dieser war es, eine Grundlage in Form einer Kosten/Nutzen- zu schaffen, sodass einerseits für die Umsetzung des Prototypen eine Priorisierung der BPMN Elemente vorgenommen werden kann und andererseits Lücken im BPI zur Integration von BPMN Prozessen ersichtlich werden. Dieses Dokument beinhaltet die Resultate der und ist im Kontext der Master-Thesis zu betrachten. Obwohl zu jedem behandelten BPMN Element eine einführende Kurzbeschreibung gegeben wird, sind grundlegende Kenntnisse bezüglich BPMN 2.0 von Nutzen. Das Dokument ist ausserdem als Arbeitsdokument zu verstehen und richtet sich insbesondere an Personen, welche sich in der Vergangenheit bereits mit dem BPI auseinandergesetzt haben. Des Weiteren ist zu erwähnen, dass dieses Dokument lediglich die fokussiert und keine Aussagen macht bezüglich den letztendlich innerhalb der praktischen Arbeit umgesetzten Funktionalitäten. Hierzu ist die Projektdokumentation 1 oder die (interne) technische Dokumentation 2 beizuziehen. Die Kurzbeschreibungen der BPMN Elemente sind jeweils mit einem grauen Hintergrund versehen. Sofern nichts anderes angegeben ist, handelt es sich jeweils um eine freie Übersetzung aus der englischsprachigen BPMN 2.0 Spezifikation [1] der Object Management Group (OMG). 1 Migrationsassistent 2 Migrationsassistent Technische Dokumentation 1

9 2 2.1 Diagrammtypen Die BPMN 2.0 kennt unterschiedliche Diagrammtypen. Im Zentrum dieser steht das BPMNtypische Prozessdiagramm, welches den eigentlichen Prozessablauf fokussiert. Des Weiteren kennt die BPMN die Kollaboration. Eine Kollaboration (engl. Collaboration) ist das aufeinander abgestimmte Zusammenspiel von zwei oder mehr Prozessen, die keiner zentralen Steuerung unterliegen und mittels Nachrichtenaustausch kommunizieren. [2 S. 49] Die Abbildung 1 zeigt ein einfaches Beispiel einer Kollaboration. Wie sich in Kapitel zeigen wird, kann dieser Diagrammtyp unterstützt werden, indem der Migrationsassistent die Selektion des zu transformierenden Prozesses zulässt. Das Choreographie- und das Konversationsdiagramm wurden mit der zweiten Version der BPMN eingeführt. Diese beiden Diagramme fokussieren die Kommunikation und den Nachrichtenfluss von zwei oder mehreren Teilnehmern. Der Prozessfluss wird dabei ausser Acht gelassen. Diese beiden Diagrammtypen sind für die irrelevant. 2.2 Pool und Lanes Pool Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 9.2 [1 S. 112]. Ein Pool stellt die grafische Repräsentation eines Teilnehmers (engl. Participant) dar. Beim Teilnehmer kann es sich um eine Entität (beispielsweise eine Firma) oder auch um eine Rolle (beispielsweise ein Verkäufer) handeln. Ein Pool fungiert als Container für Aktivitäten und Sequenzflüsse. Die Interaktionen zwischen zwei Pools werden mittels Nachrichtenflüssen (engl. Message Flows, siehe Kapitel 2.4) dargestellt. Abbildung 1 zeigt hierzu ein einfaches Beispiel. 2

10 Financial Institution Credit Card Authorization Supplier Sales Distribution Authorize Payment Process Order Pack Goods Ship Goods Abbildung 1: Beispiel einer Kommunikation zweier Pools, dargestellt mittels Nachrichtenflüssen Quelle: Abbildung 9.4 der BPMN 2.0 Spezifikation, Kapitel 9.2 [1 S. 113] Ein Pool kann entweder horizontal oder vertikal ausgerichtet sein. Ein Pool, dessen Details nicht bekannt sind (Blackbox), kann leer gelassen werden. In diesem Fall werden die Nachrichtenflüsse mit dem Pool-Rahmen verbunden. Der Pool des eigenen (Haupt-) Prozesses kann auch weggelassen werden. Nachrichtenflüsse betreffen immer zwei verschiedene Pools, d.h. es können nicht zwei Flussobjekte desselben Pools mit einem Nachrichtenfluss verbunden werden. Andererseits sind Sequenzflüsse nur innerhalb desselben Pools gültig und können nicht zwei Flussobjekte zweier Pools miteinander verbinden. Ein Pool kann mittels Lanes (siehe Kapitel 2.2.2) weiter unterteilt werden. Ein Pool kann auch eine Vielzahl von Teilnehmer darstellen (zum Beispiel mehrere Lieferanten). In diesem Fall wird, wie in Abbildung 2 zu erkennen, der Pool als Mehrfachteilnehmer (engl. Multiple Participant) markiert. Manufacturer Request for Quote Quote Supplier Abbildung 2: Beispiel eines Mehrfachteilnehmers Quelle: Abbildung 9.9 der BPMN 2.0 Spezifikation, Kapitel [1 S. 117] 3

11 Der BPI unterstützt keine Modellierung mehrerer Pools, was durchaus Sinn ergibt. Gemäss [3 S. 95] steht ein Pool für eine den Lanes übergeordnete Instanz, die die Steuerung des Prozesses übernimmt, also die tatsächliche Zuordnung der Aufgabe vornimmt. Im Falle automatisierter Prozesse übernimmt die Prozess-Engine die Rolle dieser Instanz. Während auf fachlicher Ebene eine Pool-übergreifende Modellierung mehrerer Prozesse (und deren Kommunikation) durchaus berechtigt ist, kümmert sich auf technischer Ebene die Prozess-Engine lediglich um die Ausführung eines Prozesses eines Pools. Weitere Pools (beispielsweise Kunde, Lieferant etc.) müssen durch die Prozess-Engine nicht abgedeckt werden. Bevor ein BPMN Diagramm migriert wird, ist somit zu entscheiden, welcher Pool in den BPI portiert werden soll. Diese Entscheidung muss sinnvollerweise durch den Benutzer getroffen werden Lanes Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 10.7 [1 S. 305]. Lanes ermöglichen eine Partitionierung des Prozesses und werden gebraucht, um Aktivitäten innerhalb eines Pools zu organisieren und zu kategorisieren. Die exakte Bedeutung einer Lane ist jedoch nicht durch die BPMN spezifiziert und wird dem Prozessdesigner überlassen. Oftmals werden Lanes verwendet, um geschäftsinterne Rollen zu beschreiben. Lanes können sowohl vertikal als auch horizontal ausgerichtet sein. Ausserdem ist es möglich, Lanes beliebig zu verschachteln. Lanes werden im BPI Swimlanes genannt. Sie bestimmen, welcher Mitarbeiter oder welche Organisationseinheit eine Benutzeraufgabe zu erledigen hat. Die Zuordnung einer Swimlane ist für einen Task und einen BisonWorkflowTask sowie für den Start zwingend. (Die Swimlane des Starts wird zur Laufzeit nicht benötigt und stellt ein Überbleibsel aus der Vergangenheit dar.) Alle anderen Bausteine müssen keiner Swimlane zugeordnet werden, kommen aber meistens dennoch in der Prozessgrafik auf eine Swimlane zu liegen sie ist jedoch irrelevant. Die Migration der BPMN Lanes ist bei genauer Betrachtung mit einigen Aufwänden verbunden. Erstens unterstützt der BPI lediglich eine vertikale Anordnung. Prozessdiagramme, dessen Lanes horizontal ausgerichtet sind, müssen somit an der zweiten Winkelhalbierenden gespiegelt werden. Zweitens sind die Koordinaten von Swimlane-abhängigen Aktivitäten (d.h. Tasks, BisonWorkflowTasks und Start) stets relativ zur oberen linken Ecke der Swimlane (und nicht zu derjenigen des gesamten Diagrammes). Aktivitäten dieses Typs müssen somit an den neuen Bezugspunkt angepasst werden. Dies wird zusätzlich durch den Umstand erschwert, dass die Breiten der Swimlanes dynamisch vom BPI Designer berechnet aber nicht im Modell abgelegt werden. Für die Berechnung der Bezugspunkte ist eine Nachbildung der Logik des Designers notwendig. Drittens können Swimlanes nicht verschachtelt werden. Als einfache Lösung bietet sich an, Verschachtelungen aufzubrechen und die Lane-Hierarchie auf neu zu vergebende Swimlane- Bezeichnungen abzubilden. Zu guter Letzt wird im BPI mindestens eine Swimlane vorausgesetzt. Falls keine Lane gegeben ist, muss folglich eine Standard-Swimlane angelegt werden. 4

12 2.3 Sequenzflüsse Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 97]. Sequenzflüsse (engl. Sequence Flow) legen die Ausführungsreihenfolge der Flusselemente fest. Sie können optional mit einer Bedingung belegt werden (engl. Conditional Sequence Flow) oder im Falle von Gateways als Standard-Sequenzfluss (engl. Default Sequence Flow) definiert werden. Sequence Flow Conditional Sequence Flow Default Sequence Flow Abbildung 3: Mögliche Ausprägungen eines Sequenzflusses Ein Sequenzfluss kann auf den ersten Blick mit wenig Aufwand in eine BPI Transition überführt werden. Bei genauerer Betrachtung ist festzustellen, dass Sequenzflüsse mit Eckpunkten in der BPMN und im BPI unterschiedlich modelliert werden und bei der Migration eine Umstrukturierung verlangen. Abbildung 4 versucht den Unterschied zu verdeutlichen. Eine Verbindung zwischen zwei Aktivitäten A und B besteht in der BPMN immer aus einem Sequenzfluss, welcher optional mehrere Eckpunkte enthalten kann. Im BPI wird ein Eckpunkt mittels einer leeren Aktivität modelliert. Zwischen zwei Aktivitäten A und B und den Eckpunkten wird jeweils ein eigener Sequenzfluss eingefügt. Der BPI Designer täuscht dem Benutzer einen durchgehenden Sequenzfluss lediglich vor. A B A B Abbildung 4: Modellierung von Sequenzflüssen in der BPMN (links) und im BPI Bedingte und Standard-Sequenzflüsse werden im Kontext von Gateways in Kapitel abgehandelt. 2.4 Nachrichtenfluss Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 93] und Kapitel 9.3 [1 S. 120]. Nachrichtenflüsse (engl. Message Flow) zeigen Nachrichten zwischen Teilnehmern (engl. Participants) auf. Ein Nachrichtenfluss verbindet immer zwei unterschiedliche Pools. Entweder werden sie mit dem Poolrahmen oder mit einem Flussobjekt innerhalb des Pools verbunden. Optional kann ein Nachrichtenfluss mit einer Nachricht (engl. Message) versehen werden, wobei farblich zwischen der initialisierenden Nachricht und allen Folgenachrichten unterschieden wird. 5

13 Message Flow Message Flow with attached Message Message Flow with non-initating Message Abbildung 5: Mögliche Ausprägungen eines Nachrichtenflusses In Kapitel wurde aufgezeigt, weshalb stets nur ein Pool in den BPI transformiert werden kann. Da ein Nachrichtenfluss einen zweiten Pool voraussetzt, verliert er durch die Transformation einen seiner Bezugspunkte. Eine korrekte Modellierung des Nachrichtenversands respektive -Empfangs liegt in der Verantwortung der daran beteiligten Aktivität (beispielsweise Sende-Task, siehe Kapitel 2.5.1). Die Transformation eines Nachrichtenflusses erübrigt sich. 2.5 Aktivitäten Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 10.2 [1 S. 151]. Eine Aktivität (engl. Activity) ist eine Arbeit, welche innerhalb eines Prozesses aus- oder durchgeführt wird. Eine Aktivität kann mehrere ein- und ausgehende Sequenzflüsse haben. Ist kein eingehender Sequenzfluss definiert, wird die Aktivität bei der Erzeugung der Prozessinstanz ebenfalls instanziiert. Ist kein ausgehender Sequenzfluss definiert, wird ein eintreffendes Token aufgelöst und allenfalls der Prozess beendet, sofern keine aktiven Tokens mehr vorhanden sind. Im Falle von mehreren eingehenden Sequenzflüssen, wird mit jedem eintreffenden Token eine neue Instanz erzeugt (siehe auch Kapitel 2.8.6). Im Falle von mehreren ausgehenden Sequenzflüssen, wird für jeden Sequenzfluss ein eigenes, paralleles Token erzeugt (siehe auch Kapitel 2.8.6). Jede Aktivität kann die Quelle oder das Ziel eines Nachrichtenflusses sein. Von der Aktivität existieren drei Ausprägungen, welche in den folgenden Kapiteln behandelt werden: Task, Unterprozess und Aufrufaktivität Tasks Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 156]. Ein Task ist eine Aktivität innerhalb eines Prozessflusses. Er kommt dann zum Einsatz, wenn die damit verbundene Arbeit nicht mehr aufgebrochen und feiner beschrieben werden kann. 6

14 Markierungen Ein Task kann mit unterschiedlichen Markierungen (engl. Marker) versehen werden. Hierzu gehören die Schleife (engl. Loop), eine parallele und sequenzielle Mehrfachinstanz (engl. Multi-Instance oder Multiple Instance) und die Kompensation (engl. Compensation, siehe Kapitel 2.9). Loop Multi-Instance Parallel Multi-Instance Sequential Compensation Abbildung 6: Mögliche Markierungen eines Tasks gemäss der BPMN 2.0 Die Kompensation lässt sich optional mit den ersten drei Markierungen kombinieren. Der BPI unterstützt obige Markierungen nicht. Allerdings lassen sich die Schleife und die beiden Mehrfachinstanzen mit Hilfe von zusätzlichen Transitions, Decisions sowie Forks und Joins ausdrücken. Abbildung 7 zeigt, wie eine Schleife im BPI mit Hilfe einer rückführenden Decision dargestellt werden kann. Sämtliche Eigenschaften einer Schleife (d.h. die Attribute testbefore, loopmaximum und loopcondition, siehe BPMN 2.0 Spezifikation, Kapitel [1 S. 189]) können nach diesem Prinzip abgebildet werden. Für die Implementierung von loopmaximum ist eine zusätzliche Variable notwendig, welche mit jedem Durchlauf dekrementiert wird. Looping Task Abbildung 7: Transformation einer Schleife von BPMN 2.0 (oben) nach BPI (unten) Alternativ zu einer Rückführung könnte der Task auch dupliziert und sequentiell hintereinander geschaltet werden. Da hierzu jedoch die Anzahl Wiederholungen bereits zur Design-Zeit bekannt sein muss, ist dieser Ansatz nicht zu empfehlen. Die beiden Mehrfachinstanz-Markierungen können grundsätzlich analog transformiert werden. Der wesentliche konzeptionelle Unterschied zur Schleife ist jedoch die Datenbasis. Eine Mehrfachaktivität kann verwendet werden, wenn man es mit einer Menge von zu bearbeitenden Objekten zu tun hat, und eine bestimmte Aktivität für jedes Element dieser Menge ausgeführt werden kann [2 S. 95]. Da der BPI keine Sequenzen oder Arrays von Daten unterstützt, entsteht bei der Umsetzung von Mehrfachinstanzen ein konzeptionelles Problem und die Notwendigkeit einer zusätzlichen Datenstruktur. 7

15 Sieht man von der Datenbasis ab, stellt sich die Frage, wie Mehrfachinstanzen dennoch im BPI umgesetzt werden könnten. Die sequentielle Mehrfachinstanz lässt sich analog zur Schleife in Abbildung 7 implementieren. Die Umsetzung einer parallelen Mehrfachinstanz mit einer dynamischen Anzahl Instanzen ist wesentlich aufwändiger und wird in Abbildung 8 dargestellt. Abbildung 8: Umsetzung einer parallelen Mehrfachinstanz im BPI In diesem Beispiel wird die Anzahl Instanzen des Parallel Tasks in der Aktivität Set Counters gesetzt. Für jede Instanz wird der Fork und anschliessend der Join jeweils einmal durchlaufen. Obschon die Umsetzung der parallelen Mehrfachinstanz innerhalb eines Migrationsassistenten durchaus machbar wäre, muss offensichtlich aus Gründen der Lesbarkeit davon abgeraten werden. Die Kompensation wird in Kapitel 2.9 behandelt. Task-Typen Die BPMN kennt die in Abbildung 9 und im Folgenden beschriebenen Task-Typen. Abstract Service Send Receive User Manual Business Rule Script Abbildung 9: Mögliche Task-Typen gemäss BPMN 2.0 8

16 Ein unbestimmter Task (engl. Abstract Task, in BPMN 1.2 noch None Task genannt) ist ein allgemeiner, nicht weiter spezifizierter Task. Der BPI unterstützt zurzeit keine nicht weiter spezifizierte Aktivität. Um im Allgemeinen BPMN Flussobjekte, welche im BPI nur schlecht abbildbar sind, in einer Form transformieren zu können, sollte die Einführung eines sogenannten AbstractTasks 1 in Betracht gezogen werden. Ein Service-Task (engl. Service Task) benutzt jegliche Arten von Diensten. Hierzu gehören auch Web- Services und automatisierte Applikationen. Falls es sich um einen Aufruf eines Web-Services handelt (implementation Attribut = ##WebService, siehe BPMN 2.0 Spezifikation, Kapitel [1 S. 159]), kann der Task mit einem BPI WebServiceCall umgesetzt werden. Falls es sich um einen anderen Service handeln sollte, bietet der BPI kein entsprechendes Pendant an. Ein Sende-Task (engl. Send-Task) sendet eine Nachricht an einen externen Empfänger. Sobald die Nachricht versendet ist, gilt der Task als abgeschlossen. Optional kann mit einem Nachrichtenfluss (siehe Kapitel 2.4) der Sende-Task mit dem Empfänger verbunden werden. Der BPI beschränkt sich mit der SendMail Aktivität auf das Versenden von s. Die BPMN erlaubt hingegen insbesondere auch den Aufruf eines Web-Services (implementation Attribut = ##WebService, siehe BPMN 2.0 Spezifikation, Kapitel [1 S. 161]), welcher den eigentlichen Versand der Nachricht tätigt. Ein Sende-Task liesse sich somit entweder auf fachlicher Ebene als SendMail oder aber auch auf technischer Ebene als WebServiceCall umsetzen. Ein Empfangs-Task (engl. Receive Task) wartet auf das Eintreffen einer Nachricht von einem externen Sender. Sobald die Nachricht eingetroffen ist, gilt der Task als abgeschlossen. Optional kann mit einem Nachrichtenfluss (siehe Kapitel 2.4) der Empfangs-Task mit dem Sender verbunden werden. Der Empfangs-Task kann auch verwendet werden, um einen Prozess zu starten (in diesem Fall wird das Briefsymbol innerhalb eines zusätzlichen Kreises dargestellt). Der BPI bietet die Möglichkeit, eine Benutzeraufgabe in BPI Task genannt derart zu konfigurieren, dass diese nur über einen Web-Service beendet werden kann, womit das Verhalten eines Empfangs- Tasks erreicht werden kann. Für die Abbildung eines Empfangs-Tasks zum Starten eines neuen Prozesses, kann die BPI Startaktivität entsprechend konfiguriert werden, sodass der Prozess per Web-Service (alternativ auch per Weblink (URL) oder ) ausgeführt werden kann. Eine Benutzeraufgabe (engl. User Task) ist eine Aufgabe, welche durch einen Menschen mit Hilfe einer Software Applikation ausgeführt wird. Siehe auch BPMN 2.0 Spezifikation Kapitel [1 S. 165]. Das Pendant zur BPMN Benutzeraufgabe ist der BPI Task. Ein manueller Task (engl. Manual Task) ist eine Aufgabe, welche zwar ebenfalls durch einen Menschen ausgeführt wird, allerdings ohne die Unterstützung einer Software Applikation (z.b. ein Telefonanruf). Siehe auch BPMN 2.0 Spezifikation Kapitel [1 S. 165]. 1 Obschon gemäss ursprünglicher Vereinbarung keine Erweiterungen am BPI vorgenommen werden sollten, hat sich für den umgesetzten Prototypen die Entwicklung eines AbstractTasks gelohnt. Während der Aufwand sehr gering war, ist der daraus entstandene Nutzen sehr gross. 9

17 Der BPI kennt kein Pendant zum manuellen Task und beschränkt sich stattdessen darauf, sämtliche Aufgaben, welche durch einen Benutzer ausgeführt werden, mittels einer Aufgabenverwaltung zu unterstützen. Ein manueller Task sollte wohl ebenfalls als BPI Task abgebildet werden. Ein Geschäftsregel-Task (engl. Business Rule Task) führt eine Berechnung einer Business Rule Engine aus. Zum aktuellen Zeitpunkt ist innerhalb vom BPI noch keine Business Rule Engine im Einsatz. Ein Skript-Task (engl. Script Task) führt innerhalb der Prozess-Engine ein Skript aus. Ein wichtiges Konzept vom BPI ist deren einfache Prozessgestaltung, welche auf Skripte verzichtet. Die Migration eines Skript-Tasks gestaltet sich daher als schwierig. Die folgende Tabelle 1 fasst die Transformation der unterschiedlichen BPMN Task-Typen nach BPI nochmals zusammen. BPMN 2.0 Unbestimmter Task Service-Task Sende-Task Empfangs-Task Benutzeraufgabe Manueller Task Geschäftsregel-Task Skript-Task Tabelle 1: Transformation der BPMN 2.0 Task-Typen nach BPI BPI AbstractTasks WebServiceCall (falls es sich um einen Web Service handelt) oder AbstractTask SendMail (fachliche Ebene) oder WebServiceCall (technische Ebene) Task mit externer Beendigung durch einen Web-Service oder Start mit Web-Service Ausführung Task Task oder AbstractTask AbstractTask AbstractTask Unterprozesse Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 173]. Eingebetteter Unterprozess Ein Eingebetteter Unterprozess (engl. Embedded Sub-Process, kurz Sub-Process) ist eine Aktivität, welche wiederum aus Aktivitäten, Gateways und Ereignissen besteht. Der Unterprozess kann entweder zu- (engl. collapsed) oder aufgeklappt (engl. expanded) dargestellt werden. Ein Unterprozess kann mit den in Abbildung 10 dargestellten Markierungen (engl. Marker) versehen werden. Loop Multi-Instance Multi-Instance Parallel Sequential Compensation Ad-Hoc Compensation & Ad-Hoc Abbildung 10: Mögliche Markierungen eines Unterprozesses gemäss BPMN

18 Obschon der BPI keine Unterprozesse unterstützt, bieten sich dennoch Möglichkeiten, einen Unterprozess zu migrieren. In erster Linie sollte zwischen zu- und aufgeklappten Unterprozessen unterschieden werden. Nach [3 S. 130] können auf fachlicher Ebene Aufgaben mittels zugeklappter Unterprozesse modelliert werden, wenn sich dahinter höchstwahrscheinlich komplexe Abläufe verbergen. Derartige Unterprozesse werden sinnvollerweise mit Hilfe eines AbstractTasks aus Kapitel in den BPI überführt. Für aufgeklappte Unterprozesse ergeben sich zwei Möglichkeiten. Erstens könnten Unterprozesse im BPI eingeführt werden, was jedoch auch entsprechende Erweiterungen sowohl im Prozessdesigner als auch in der Laufzeitumgebung mit sich bringt. An dieser Stelle ist zu erwähnen, dass Unterprozesse gemäss User-Guide [4] von jbpm 5.3 unterstützt werden (siehe Anhang B) und somit auch ein Update von jbpm in Erwägung gezogen werden kann. Als zweiter Lösungsansatz kann auf den Unterprozess verzichtet werden und stattdessen der Inhalt des Unterprozesses direkt in den äusseren Prozess kopiert werden. Start- und Endereignisse werden dabei verworfen. Falls der Unterprozess mehrere Endereignisse enthält, müssen die dazugehörigen Sequenzflüsse wie in Abbildung 11 dargestellt über einen geeigneten Gateways (siehe Kapitel 2.8) zusammengeführt werden. Die grosse Herausforderung hierbei ist, programmatisch den richtigen Gateway-Typ (beispielsweise exklusiv oder parallel) zu bestimmen. Allenfalls ist hierzu eine manuelle Nacharbeit notwendig. B B A D A D C C Abbildung 11: Verzicht auf einen eingebetteten Unterprozess Gemäss [1 S. 430] muss ein eingebetteter Unterprozess in der BPMN exakt ein Startereignis oder Aktivitäten ohne eingehende Sequenzflüsse enthalten. In Letzterem Fall werden diese Aktivitäten instanziiert, sobald ein Token den Unterprozess erreicht. Für die Umsetzung im BPI müssen diese Aktivitäten mit Hilfe eines parallelen Gateways mit dem äusseren Prozess in Verbindung gebracht werden. Der Verzicht auf Unterprozesse hat folgende Konsequenzen: Der Prozess verliert ein strukturelles Mittel und kann dadurch unübersichtlicher werden. An den Unterprozess angeheftete Ereignisse verlieren ihren Aufhänger. Wiederverwendbarer Unterprozess Der Wiederverwendbare Unterprozess (engl. Reusable Sub-Process) stammt aus der BPMN 1.2 und wird in der Version 2.0 durch die Aufrufaktivität (engl. Call Activity, siehe Kapitel 2.5.3) ersetzt. 11

19 Ereignis-Unterprozess Ein Ereignis-Unterprozess (engl. Event Sub-Process) ist ein Unterprozess, welcher jeweils beim Eintreffen eines festgelegten Ereignisses ausgeführt wird, vorausgesetzt, dass sein übergeordneter (Unter-) Prozess aktiv ist. Der Ereignis-Unterprozess ist nicht Bestandteil des Prozessflusses seines übergeordneten (Unter-) Prozesses und besitzt weder ein- noch ausgehende Sequenzflüsse. Abbildung 12: Zugeklappter Ereignis-Unterprozess welcher durch eine Nachricht gestartet wird. Der BPI unterstützt grundsätzlich keine Unterprozesse. Daher stellt sich die Frage, ob ein Ereignis- Unterprozess auch ohne das Konzept eines Unterprozesses dargestellt werden kann. Abbildung 13 zeigt, wie sich ein Ereignis-Unterprozess mittels angehefteter Ereignisse (siehe Kapitel 2.7) ausdrücken lässt. Für das folgende Gedankenexperiment wird angenommen, dass das angeheftete Nachrichtenereignis vom BPI unterstützt wird. A B A B React on message React on message Abbildung 13: Umwandlung eines Ereignis-Unterprozesses (links) zu einem angehefteten Ereignis Da das Nachrichtenereignis die Ausführung des Unterprozesses nicht unterbricht (gestrichelt), kann auf der rechten Seite der Prozessfluss nach dem Eintreffen der Nachricht in ein Endereignis geführt werden. Andernfalls ist der Prozessfluss mit einem geeigneten Gateway in den regulären Fluss zurückzuführen. Bei genauer Betrachtungsweise stellt sich heraus, dass das Laufzeitverhalten nicht exakt dasselbe ist. Man stelle sich vor, dem äusseren Unterprozess folge im Prozessfluss eine Aktivität X. In der linken Darstellung ist sichergestellt, dass bei der Ausführung der Aktivität X sowohl der äussere Unterprozess als auch der darin enthaltene Ereignis-Unterprozess zwischenzeitlich beendet wurden. In der rechten Variante ist es denkbar, dass die Aktivität React on message bei der Ausführung von X noch aktiv ist. 12

20 In [3 S. 94] werden zudem weitere Unterschiede erläutert, sofern es sich beim Unterprozess um einen wiederverwendbaren Unterprozess handelt: Wenn der Teilprozess in einem anderen Verantwortungsbereich liegt als der Top-Level- Prozess, kümmern sich zwei unterschiedliche Rollen um die Durchführung des Teilprozesses bzw. die Behandlung der Ereignisse. [ ] Weil der Teilprozess wiederverwendbar ist, kann und muss jeder Top-Level-Prozess gesondert festlegen, wie er auf diese beiden Ereignisse reagiert. Wenn die Behandlung hingegen innerhalb des Teilprozesses stattfindet, wird sie ebenfalls wiederverwendet mit den damit verbundenen Vor- und Nachteilen. Wiederverwendbare Teilprozesse können nicht direkt auf die Daten des Top-Level- Prozesses (bzw. allgemein ihres Oberprozesses) zugreifen; es ist ein Mapping erforderlich. Das wäre mit einem Ereignis-Teilprozess nicht notwendig. Sofern von den obigen Differenzen abgesehen werden kann, darf als Folgerung festgehalten werden, dass eine Unterstützung von angehefteten Ereignissen (siehe Kapitel 2.7) auch zur Transformation von Ereignis-Unterprozessen beitragen kann. In einem weiteren Schritt stellt sich die Frage, ob sich auch der Unterprozess auflösen lässt. In Abbildung 14 wird das angeheftete Ereignis in mehrere Ereignisse aufgebrochen. Diese Ereignisse werden anschliessend mittels eines exklusiven Gateways (siehe Kapitel 2.8.1) zusammengeführt. A B A B Message M Message M Message M React on message React on message Abbildung 14: Umwandlung eines an einen Unterprozess angehefteten Ereignis Das ursprüngliche Problem der Transformation eines Ereignis-Unterprozesses lässt sich für das obige Beispiel auf die Transformation von angehefteten Ereignissen reduzieren. Diese Vorgehensweise ist jedoch nicht für alle Ereignistypen gültig. Ist beispielsweise mit einem Zeitereignis modelliert, dass der Unterprozess innert einer Woche erledigt sein muss (ansonsten wird eine Reaktion hervorgerufen), lässt sich das Ereignis nicht auf einzelne Tasks aufbrechen. Die Bedeutung wäre eine andere, da nun jeder einzelne Task innert einer Woche erledigt sein muss. Weiter ist klar festzuhalten, dass die Komplexität des Prozesses durch die obige Umwandlung stark zunehmen kann. Im Falle mehrerer Ereignis-Unterprozesse oder bei einer Vielzahl von Aktivitäten kann eine derartige Problemreduktion zur vollständigen Unlesbarkeit des Prozesses führen. Die Komplexität nimmt auch rasant zu, wenn innerhalb des Unterprozesses mittels Gateways eine parallele Ausführung modelliert ist. Abbildung 15 zeigt beispielhaft die Auswirkung einer parallelen Ausführung. 13

21 Message M Message M A1 A2 B1 B2 Message M Message M React on message Abbildung 15: Auswirkung einer parallelen Ausführung auf angeheftete Ereignisse Abbildung 15 zeigt, dass die Unterstützung von Ereignis-Unterprozessen als sehr schwierig und aufwändig einzustufen ist. Es wird auch deutlich, welche Vereinfachungen Unterprozesse und angeheftete Ereignisse in der Prozessmodellierung mit sich bringen. Transaktion Eine Transaktion (engl. Transaction) wird ebenfalls als Unterprozess dargestellt und ermöglicht ein Rollback von ausgeführten Aktivitäten im Fehlerfall. Abbildung 16: Darstellung einer zugeklappten Transaktion in BPMN 2.0 Der BPI unterstützt keine Transaktionen. Auf das Transaktionsverhalten muss im BPI somit verzichtet werden. Die darin enthaltenen Flussobjekte lassen sich analog zum herkömmlichen Unterprozess migrieren. Ad-hoc-Unterprozess Ein Ad-hoc-Unterprozess (engl. Ad-Hoc Sub-Process) beinhaltet Aktivitäten, deren Ausführungsreihenfolge erst während der Prozessausführung bekannt wird und daher nicht mit Sequenzflüssen verbunden werden können. Der Ad-hoc-Unterprozess wird mittels einer Markierung als solcher deklariert (siehe Abbildung 10). Der BPI unterstützt keine Unterprozesse und beruht konzeptionell auf modellierbaren Prozessen mit klar festgelegten Sequenzflüssen. Ein ähnliches Verhalten kann aber erreicht werden, indem anstelle des Ad-hoc-Unterprozesses ein Fork und ein Join eingefügt werden. Anschliessend wird der Fork mit den Aktivitäten ohne eingehende und der Join mit den Aktivitäten ohne ausgehende Sequenzflüsse verbunden. 14

22 2.5.3 Aufrufaktivität Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 183]. Eine Aufrufaktivität (engl. Call Activity) ist eine Aktivität, welche einen globalen Prozess oder globalen Task ausführt. Die Aufrufaktivität erhält jeweils das Aussehen des aufgerufenen Prozesses resp. Tasks, wobei der Rahmen dick dargestellt wird. Abbildung 17: Aufruf eines unbestimmten Tasks, User Tasks und Unterprozesses (v.l.n.r.) Eine Aufrufaktivität, welche einen Task aufruft, lässt sich gut nach BPI transferieren, indem der globale Task kopiert und an Stelle der Aufrufaktivität in den Prozess eingefügt wird. Eine Aufrufaktivität, welche einen Prozess aufruft, kann prinzipiell auf gleiche Weise transferiert werden. Die Herausforderungen sind denjenigen eines eingebetteten Unterprozesses ähnlich. Es sind die folgenden Unterschiede zu beachten: Die Aktivitäten des globalen Prozesses können eigenen Lanes zugeordnet sein, welche in den Prozess, welcher die Aufrufaktivität beinhaltet, integriert werden müssen. Allenfalls führt dies dazu, dass der globale Prozess nach der Einbettung aufgrund der Lane-Zuordnungen in seiner Darstellung zerrissen wird. Soll ein globaler Prozess anstelle einer Aufrufaktivität in den aufrufenden Prozess kopiert werden, wird dadurch mehr Platz beansprucht als es die Aufrufaktivität zuvor getan hat. Sinnvollerweise müssen anliegende Elemente entsprechend verschoben werden. Ein globaler Prozess kann gemäss [1 S. 431] nebst einem unbestimmten Startereignis noch weitere Startereignisse mit einem anderen Typ enthalten. Beim Aufruf aus einer Aufrufaktivität haben zusätzliche Startereignisse jedoch keine Relevanz. Die Transformation einer Aufrufaktivität, welche einen globalen Prozess referenziert, sollte aufgrund des Aufwandes und der zu erwartenden Komplexität in Frage gestellt werden. Die Aufrufaktivität wird gemäss User-Guide [4] von jbpm 5.3 unterstützt (siehe Anhang B). 15

23 2.6 Daten Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 10.3 [1 S. 203]. Die BPMN bietet die Möglichkeit, die Daten zu modellieren, welche durch den Prozess erstellt, bearbeitet und benötigt werden. Data Object Data Object Collection Data Input Data Output Data Store Abbildung 18: Mögliche Datenobjekte in BPMN 2.0 Datenobjekte (engl. Data Objects) bilden das wichtigste Konstrukt, um Daten innerhalb eines Prozesses zu modellieren. Es kann sich hierbei um jegliche Form von Daten handeln, beispielweise um ein Dokument oder eine komplexe Datenstruktur. Mehrere Datenobjekte werden mit drei vertikalen Linien als Collection markiert. Unterprozesse können ihren Dateninput (engl. Data Input) und -output (engl. Data Output) festlegen. Der Aufrufer eines Unterprozesses muss sich entsprechend an die festgelegten Datenobjekte halten. Der Lebenszyklus eines Datenobjektes ist an denjenigen des Prozesses (oder Unterprozesses) gebunden. Um auch nach dem Prozessende auf ein Datenobjekt zugreifen zu können, muss dieses in einen Datenspeicher (engl. Data Store) gestellt werden. Der BPI bietet keine Möglichkeit zur Visualisierung von Datenobjekten. Allenfalls liesse sich für jedes Datenobjekt eine Prozessvariable mit demselben Namen erzeugen. Durch die fehlende Unterstützung von Unterprozessen erübrigt sich die Migration von Dateninput und -output. Der BPI stellt keinen eigenen Datenspeicher zur Verfügung und folgt der Philosophie, dass Daten in externen Systemen gehalten werden. Der Datenspeicher wird auch nicht als solcher modelliert. Stattdessen steht der lesende oder schreibende Zugriff als Aktivität zur Verfügung. Abbildung 19 zeigt den schreibenden Zugriff am Beispiel des Microsoft Sharepoints. Create Document Sharepoint Abbildung 19: Schreibender Zugriff auf Sharepoint in der BPMN (links) und in BPI Die Schwierigkeit bei der Transformation liegt darin, die richtige Technologie (beispielsweise Sharepoint) programmatisch zu erkennen und für den BPI zu konkretisieren. Ausserdem ist die Anzahl der im BPI unterstützten Technologien eingeschränkt. 16

24 2.7 Ereignisse Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 10.4 [1 S. 233]. Ein Ereignis (engl. Event) ist etwas, das passiert und den Prozess beeinflusst. Es wird zwischen Start-, End- und Zwischenereignis (engl. Start-, End- und Intermediate-Event) unterschieden. Ereignisse können ausserdem in zwei Gruppen unterteilt werden: eintretende (engl. catching Events) und durch den Prozess ausgelöste (engl. throwing Events) Ereignisse. Während Startereignisse immer eintretende und Endereignisse immer ausgelöste Ereignisse sind, kann es sich bei einem Zwischenereignis sowohl um ein eintretendes als auch ausgelöstes Ereignis handeln. Als Beispiel hierzu kann das Nachrichtenereignis (engl. Message Event) genannt werden. Es existiert als eintretendes Ereignis für das Eintreffen einer Nachricht und als ausgelöstes Ereignis für das Versenden einer Nachricht. Abbildung 20 zeigt als Beispiel einen Prozess mit unterschiedlichen Ereignissen. Die Begrifflichkeiten werden im Folgenden weiter erklärt. Start Event Intermediate Event: Throwing Intermediate Event: Catching End Event Intermediate Event: Boundary (interrupting) End-Event Abbildung 20: Beispiel unterschiedlicher Ereignisse in BPMN 2.0 Startereignis Das Startereignis startet eine neue Prozessinstanz und hat demzufolge keine eingehenden Sequenzflüsse. Das Startereignis ist optional. In diesem Fall sollten alle Flussobjekte, welche keine eingehenden Sequenzflüsse haben, beim Prozessstart initiiert werden. Das Startereignis ist zwingend, sobald ein Endereignis innerhalb des Prozesses vorhanden ist. Das Startereignis kommt sowohl im Top-Level Prozess als auch in Unterprozessen zum Einsatz. Im Falle eines Ereignis-Unterprozesses kann festgelegt werden, ob beim Eintreffen des Startereignisses der übergeordnete Prozess unterbrochen (engl. to interrupt) werden soll oder nicht. 17

25 Endereignis Das Endereignis beendet einen Prozess (sofern keine weiteren Tokens mehr aktiv sind) und hat demzufolge keine ausgehenden Sequenzflüsse. Ein Endereignis ist optional, jedoch zwingend, sobald mindestens ein Startereignis innerhalb des Prozesses vorhanden ist. Mehrere Endereignisse innerhalb eines Prozesses sind ebenfalls erlaubt. Zwischenereignis Ein Zwischenereignis kann auf zwei Arten zum Einsatz kommen: 1. Innerhalb des Prozessflusses: In diesem Fall kann es sich um ein eintretendes oder ausgelöstes Ereignis handeln. 2. Angeheftet an eine Aktivität (engl. Boundary): In diesem Fall kann es sich nur um ein eintretendes Ereignis handeln. Es kann jedoch festgelegt werden, ob beim Eintreffen des Ereignisses die Aktivität unterbrochen werden soll oder nicht. 18

26 Übersicht Die Tabelle 2 zeigt eine Übersicht aller Ereignisse sowie deren Einsatzmöglichkeiten. Die Erläuterung erfolgt anschliessend. Unbestimmtes Ereignis Zeitereignis Fehlerereignis Link-Ereignis Signalereignis Nachrichtenereignis Eskalationsereignis Abbruchsereignis Kompensationsereignis Bedingungsereignis Terminierungsereignis Mehrfachereignis Paralleles Mehrfachereignis Ereignistyp Startereignis Zwischenereignis Endereignis Top-Level Ereignis-Unterprozess Ein- Angeheftet Aus- Nicht- tretend Nicht- gelöst Unterbr. Unterbr. Unterbr. Unterbr. Tabelle 2: Übersicht aller BPMN 2.0 Ereignisse Basierend auf der Tabelle der BPMN 2.0 Spezifikation, Kapitel [1 S. 261] Kurzbeschreibung Legt im Falle eines Startes keinen Trigger und im Falle eines Endes kein Resultat fest. Als Zwischenereignis dient es zur Modellierung, dass etwas geschieht. Sendet oder empfängt eine Nachricht von einem Teilnehmer (siehe Kapitel 2.2.1). Dieser kann optional via Nachrichtenfluss mit dem Ereignis verbunden werden. Legt ein bestimmtes Datum oder Zeitintervalle fest. Innerhalb eines Prozessflusses dient es als Zeitverzögerung. Reagiert auf Fehler innerhalb eines Unterprozesses oder einer Aktivität, resp. führt zu einem fehlerhaften Abbruch eines (Unter-) Prozesses. Reagiert auf eine Eskalation innerhalb eines Unterprozesses resp. löst eine Eskalation aus. Kommt innerhalb einer Transaktion (siehe Kapitel 2.5.2) zum Einsatz und reagiert auf deren Abbruch oder ruft einen Abbruch hervor. Dient dazu, ausgeführte Aktivitäten rückgängig zu machen. Kompensationen können durch einen Transaktionsabbruch oder durch ein ausgelöstes Kompensationsereignis hervorgerufen werden. Siehe Kapitel 2.9. Überprüft eine Bedingung in Form eines Ausdruckes. Verlinkt Sequenzflüsse, sodass beispielsweise Sequenzflusslinien oder Wiederholungen eingespart werden können. Ermöglicht einen Broadcast eines Signales (ohne spezifischen Sender & Empfänger) über Prozesse hinweg sowie die Reaktion auf ein eintreffendes Signal. Beendet eine Prozessinstanz sofort, unabhängig davon, ob noch weitere Tokens aktiv sind. Definiert mehrere Bedingungen, wobei nur eine davon erfüllt sein muss, respektive führt zu mehreren Konsequenzen beim Prozessende. Definiert mehrere Bedingungen, wobei alle davon erfüllt sein müssen. Legende Migration % möglich Migration % möglich mit geeigneter Umformung Migration 50-90% möglich, allenfalls mit geeigneter Umformung oder minimen Erweiterungen von BPI Migration möglich mittels kleinerer bis mittlerer Erweiterung von BPI. Migration nicht möglich oder nur mit sehr grossem Aufwand 19

27 Anmerkungen: Im Falle eines Unterprozesses kommt als Startereignis lediglich das unbestimmte Ereignis in Frage; ausser, es handelt sich um einen Ereignis-Unterprozess. Thomas Allweyer erklärt den Unterschied zwischen Eskalationsereignis (engl. Escalation) und Fehlerereignisse (engl. Error) wie folgt: Während Fehlerereignisse vor allem bei technischen Problemen verwendet werden, markieren Eskalationsereignisse eher fachliche Probleme. [ ] Im Gegensatz zu Fehlern, bei denen die betreffende Aktivität immer abgebrochen wird, gibt es bei Eskalationen beides: Die Abbrechende und die nicht-unterbrechende Variante. [2 S. 115] Der BPI unterstützt weder Ereignis-Unterprozesse (siehe Kapitel 2.5.2) noch die Möglichkeit, ein Ereignis an eine Aktivität anzuheften. Hierzu wären grössere Erweiterungen zur Design- und Laufzeit notwendig. Dementsprechend sind die betroffenen Spalten in Tabelle 2 mit wenigen Ausnahmen rot eingefärbt. Einzig bei einer Benutzeraufgabe im BPI Task genannt kann mittels eines Zeitnehmers festgelegt werden, dass nach Ablauf einer bestimmten Zeit ein bestimmter Ausgang gewählt werden soll. Ein einfaches Beispiel hierzu ist in Abbildung 21 zu sehen. Das unterbrechende, angeheftete Zeitereignis kann somit im BPI als Zeitnehmer abgebildet werden, allerdings nur im Falle einer Benutzeraufgabe (d.h. Manual- oder User-Task, siehe Kapitel 2.5.1). Abbildung 21: Beispiel eines Zeitnehmers in BPI Weitere Ereignisse, wie beispielsweise zur Handhabung eines Fehlers, könnten prinzipiell ähnlich implementiert werden. Als Nachteil ist jedoch zu nennen, dass die Erweiterbarkeit bezüglich neuer Ereignisse und die Flexibilität im Prozessdesign darunter leiden. Ausserdem ist das Fehlerhandling, abgesehen von der Benennung des Sequenzflusses, nicht in der Prozessgrafik ersichtlich. Das unbestimmte Start- und Endereignis lässt sich ohne weiteres nach BPI transformieren. Das unbestimmte Zwischenereignis existiert hingegen nicht. Es liesse sich allerdings durch einen AbstractTask (siehe Kapitel 2.5.1) ersetzen, sofern dieser implementiert würde. Der BPI Start kann so konfiguriert werden, dass der Prozess durch einen Web-Service Aufruf, ein E- Mail oder durch den Aufruf einer URL gestartet werden kann. Hiermit lässt sich das Nachrichten- Startereignis ebenfalls transformieren. Das eintreffende Nachrichtenereignis kann wie der Empfangs-Task (siehe Kapitel 2.5.1) mit Hilfe eines BPI Tasks modelliert werden, welcher nur über einen Web-Service beendet werden kann. Das ausgelöste Nachrichtenereignis, d.h. der Versand einer Nachricht, kann wie der Sende-Task (siehe Kapitel 2.5.1) auf ein SendMail oder einen WebServiceCall abgebildet werden. Das Nachrichten- Endereignis kann, wie in Abbildung 22 dargestellt, in zwei Ereignisse aufgeteilt werden, welche in BPI jeweils ihr Pendant finden. 20

28 Abbildung 22: Aufteilung eines Nachrichten-Endereignisses in zwei Ereignisse Der BPI bietet keine Unterstützung für einen zeitgesteuerten Start. Da ein Startereignis mit der eigentlichen Instanziierung des Prozesses verknüpft ist, kann das Zeit-Startereignis nur schwer ummodelliert werden im Gegensatz zum Nachrichten-Endereignis. Alternativ könnte ein zeitgesteuerter Start jedoch an ein externes Scheduling Tool delegiert werden, welches den Prozess über einen Web-Service startet. Derselbe Lösungsansatz kommt auch für das Bedingungs-, Mehrfachund paralleles Mehrfach-Startereignis in Frage. Das eintretende Zeitereignis, welches innerhalb eines laufenden Prozesses als Zeitverzögerung fungiert, kann auf den BPI Timer abgebildet werden. Dieser ist jedoch in der Funktionalität beschränkt und unterstützt nur die Verzögerung gemäss einer konfigurierten Zeitdauer (z.b. 1 Stunde). Die Angabe eines festen Zeitpunktes (z.b. 12:00 Uhr) ist nicht möglich. Eine Zeitdauer wird in der BPMN gemäss [1 S. 274] im ISO-8601 Format festgelegt und muss für den BPI in die Anzahl Sekunden umgerechnet werden. Allerdings ist dabei zu beachten, dass Inkonsistenzen entstehen können. Beispielweise entspricht 1 Tag (P1D) im Falle einer Zeitumstellung nicht Sekunden! Die Fehler-, Eskalations- und Abbruchsereignisse setzen die Möglichkeit eines Unterprozesses voraus und können daher im BPI nicht sinnvoll umgesetzt werden. Das Kompensationsereignis wird in Kapitel 2.9 abgehandelt. Das Bedingungs-Zwischenereignis kann wie in Abbildung 23 durch eine wiederkehrende Überprüfung durch eine BPI Decision erreicht werden. Eine zeitliche Verzögerung zwischen jeder Prüfung verringert die Rechnerauslastung. Abbildung 23: Umsetzung eines Bedingungs-Zwischenereignisses in BPI Das Mehrfach- und das parallele Mehrfach-Zwischenereignis lassen sich nach demselben Prinzip realisieren. Ein Link-Ereignis lässt sich umsetzen, indem das End- und das Zwischenereignis mit einem Sequenzfluss verbunden werden. Allerdings muss davon ausgegangen werden, dass dadurch die Lesbarkeit und die Übersicht des Prozessdiagrammes negativ beeinflusst werden. Die Umsetzung der unterschiedlichen Signalereignisse erweist sich als schwieriger. Als möglicher Workaround könnte der Broadcast über einen Dienst abgewickelt werden. Dagegen spricht jedoch, dass dem Signal-Sender der (oder die) Empfänger nicht bekannt sein sollte. Alternativ könnte ein derartiges Broadcast-System mit verhältnismässig kleinem Aufwand im BPI umgesetzt werden. 21

29 Das Terminierungs-Endereignis existiert im BPI nicht, wird jedoch gemäss User-Guide [4] von jbpm 5.3 unterstützt (siehe Anhang B). Das auslösende Mehrfach-Zwischenereignis kann in einzelne Ereignisse aufgeteilt (vorausgesetzt, diese werden unterstützt) und parallel (mittels Fork und Join) ausgeführt werden. Das Mehrfach-Endereignis steht für mehrere Konsequenzen beim Prozessende. Es könnte grundsätzlich durch einen Fork mit einzelnen Endereignissen dargestellt werden. Da der BPI jedoch nur das unbestimmte Endereignis unterstützt, ergibt sich eine Aufteilung in einzelne Ereignisse. 2.8 Gateways Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 10.5 [1 S. 287]. Gateways dienen zur Kontrolle des Sequenzflusses eines Prozesses und ermöglichen Entscheidungen und parallele Verarbeitung sowie deren Zusammenführung. Ein einzelner Gateway kann zugleich mehrere ein- als auch mehrere ausgehende Sequenzflüsse beinhalten. Eine derartige Kombination von Zusammenführung und Verzweigung wird jedoch sowohl in [2 S. 26] als auch in [3 S. 30] wegen der verringerten Lesbarkeit nicht empfohlen Exklusiver Gateway Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 290]. Der exklusive Gateway (engl. Exclusive Gateway) dient zur Modellierung von alternativen Pfaden, wobei zur Laufzeit exakt ein ausgehender Pfad gewählt wird. Der Gateway wird sowohl zur Entscheidung (engl. Exclusive Decision (data-based) [1 S. 435]) als auch zur Zusammenführung (engl. Exclusive Merge [1 S. 435]) genutzt. Das Symbol des exklusiven Gateways ist eine Raute. Wie in Abbildung 24 dargestellt kann dieses optional mit einem X versehen werden. Die Spezifikation [1 S. 290] empfiehlt, innerhalb eines Prozessdiagramms stets dieselbe Darstellung zu nutzen. Condition 1 Condition 2 Exclusive Decision (data-based) Default Exclusive Merge Abbildung 24: Exklusiver Gateway 22

30 Für den Fall, dass keine der Ausgangsbedingungen zutrifft, kann optional ein Standard-Sequenzfluss mittels eines Schrägstriches festgelegt werden. Trifft keine Ausgangsbedingung zu und ist kein Standard-Sequenzfluss festgelegt, führt dies zu einem Laufzeitfehler [1 S. 435]. Der BPI bietet mit der Decision ein Pendant zum exklusiven Gateway. Es sind allerdings kleine Unterschiede zu beachten. Zur Decision existiert kein zusammenführendes Element. Stattdessen können zu jeder Aktivität mehrere Sequenzflüsse führen, womit dasselbe Verhalten erreicht wird (Die BPMN unterstützt diese Darstellung ebenfalls, siehe Kapitel 2.8.6). Wie in Abbildung 25 dargestellt, müssen bei der Transformation folglich exklusive Zusammenführungen entfernt und die Sequenzflüsse auf die darauffolgende Box umgehängt werden. Condition 1 Task A Task C Condition 2 Task B Abbildung 25: Transformation eines exklusiven Gateways (oben) nach BPI (unten) Als zweiter Unterschied ist zu erwähnen, dass die Decision vom BPI einen Standardausgang (ohne Bedingung) erzwingt. Falls der Exklusive Gateway keinen Standard-Sequenzfluss definiert, kann diesem Umstand bei der Transformation begegnet werden, indem dem letzten Ausgang die Bedingung entfernt und der Ausgang stattdessen als Standardausgang festgelegt wird. Allerdings gilt es zu beachten, dass das Verhalten nun leicht vom ursprünglichen abweicht. Falls keine der ursprünglichen Bedingungen zutreffen sollte, würde nun kein Laufzeitfehler mehr erzeugt, wie es von der BPMN vorgesehen ist. 23

31 2.8.2 Inklusiver Gateway Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 292]. Im Gegensatz zum exklusiven Gateway schliessen sich beim inklusiven Gateway (engl. Inclusive Gateway) die Ausgangsbedingungen nicht gegenseitig aus, womit entweder ein, mehrere oder alle Sequenzflüsse gewählt werden können. Für jede zutreffende Ausgangsbedingung wird ein eigenes Token erzeugt und die dazugehörigen Pfade parallel zueinander ausgeführt. Der Gateway wird sowohl zur Entscheidung (engl. Inclusive Decision [1 S. 435]) als auch zur Zusammenführung (engl. Inclusive Merge [1 S. 435]) genutzt. Condition 1 Condition 2 Inclusive Decision Inclusive Merge Default Abbildung 26: Inklusiver Gateway Für den Fall, dass keine der Ausgangsbedingungen zutrifft, kann optional ein Standard-Sequenzfluss mittels eines Schrägstriches festgelegt werden. Trifft keine Ausgangsbedingung zu und ist kein Standard-Sequenzfluss festgelegt, führt dies zu einem Laufzeitfehler [1 S. 436]. Beim zusammenführenden Gateway wird gemäss [2 S. 32] auf so viele Tokens gewartet, wie dort aufgrund der vorangehenden Sequenzlogik noch ankommen können. Diese Synchronisation kann nach [3 S. 36] sowohl organisatorisch wie auch innerhalb einer Prozess-Engine zu einer grossen Herausforderung werden. Beispielsweise könnte ein parallel ausgeführtes Token auf ein Prozessende treffen und die Zusammenführung somit nie erreichen. Derartige Situationen müssen vom Gateway erkannt werden. Der BPI unterstützt keinen inklusiven Gateway. Das Beispiel aus Abbildung 26 lässt sich grundsätzlich aber auch mit Hilfe von exklusiven und parallelen Gateways ausdrücken, wie es Abbildung 27 zeigt. 24

32 Condition 1 Condition 2 Not Condition 1 and not Condition 2 Abbildung 27: Abbildung eines inklusiven Gateways mittels exklusiven und parallelen Gateways Eine derartige Rückführung bringt jedoch zahlreiche Nachteile mit sich. Erstens nimmt die Komplexität deutlich zu und die Lesbarkeit des Prozessdiagramms nimmt massgebend ab. Zweitens muss der ursprüngliche Standard-Sequenzfluss mittels Wiederholung aller Bedingungen explizit ausformuliert werden, womit eine Redundanz entsteht. Drittens stösst diese Vorgehensweise an ihre Grenze, wenn sich innerhalb eines Pfades ein Endereignis befinden würde, sodass das Token die parallele Zusammenführung nie erreichen würde. Für die saubere Unterstützung inklusiver Gateways sollte daher ein Update von jbpm in Betracht gezogen werden, denn gemäss User Guide von jbpm [4], Kapitel 6.6 wird der inklusive Gateway von der aktuellen jbpm Version unterstützt (siehe auch Kapitel 3) Paralleler Gateway Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 293]. Mit einem parallelen Gateway (engl. Parallel Gateway) kann ein Sequenzfluss in mehrere Pfade aufgeteilt werden, welche parallel zueinander durchlaufen werden. Fork Join Abbildung 28: Paralleler Gateway Der Gateway dient sowohl als Verzweigung (engl. Fork nach [1 S. 434]) wie auch als Zusammenführung (engl. Join nach [1 S. 434]). Bei Letzterem wird bei jedem Eingang auf ein eintreffendes Token (derselben Prozessinstanz) gewartet, bevor diese miteinander verschmolzen werden und der Prozessfluss fortgesetzt wird. 25

33 Mit den beiden Bausteinen Fork und Join unterstützt der BPI auf den ersten Blick den parallelen Gateway vollumfänglich. Bei genauerer Betrachtung kann jedoch eine leichte Abweichung im Laufzeitverhalten festgestellt werden. Abbildung 29 zeigt einen BPI Prozess, bestehend aus einem Fork, dessen drei Pfade mittels zweier unterschiedlicher Joins zusammengeführt werden. Abbildung 29: Beispiel eines nicht funktionsfähigen BPI Prozesses Zur Laufzeit werden zunächst wie erwartet die drei Benutzeraufgaben A, B und C, sowie nach Abschluss der letzten beiden die Aufgabe BC erzeugt. Selbst wenn nun die Aufgaben A und BC abgeschlossen werden, wird die Aufgabe ABC nicht erzeugt. Der Prozess bleibt stattdessen beim Join A/BC stehen. Ein Hinweis auf die Ursache ist im User Guide von jbpm 3 in Kapitel 9 [5] zu finden: The default fork behaviour is to create a child token for each transition that leaves the fork, creating a parent-child relation between the token that arrives in the fork. [ ] The default join assumes that all tokens that arrive in the join are children of the same parent. Zur Lösung des Problems muss im oberen Beispiel somit ein zweiter Fork für die Aufgaben B und C eingefügt werden, sodass jeder Fork mit einem Join korrespondiert. Im Idealfall würde eine derartige Konstellation durch die Transformation korrigiert und notwendige Joins automatisch eingefügt werden. Dies könnte sich allerdings als schwierig erweisen (eine hierzu geeignete Strategie ist noch offen). Im Mindesten sollte jedoch eine kritische Konstellation durch die Transformation erkannt und eine Meldung ausgegeben werden, denn das Fehlverhalten kann ansonsten erst zur Laufzeit festgestellt werden. Ausserdem ist der Fehler sehr schwierig zu identifizieren und erfordert fundierende Kenntnis bezüglich der Prozess-Engine. Der User Guide der aktuellen jbpm Version [4] deutet in Kapitel nicht auf ein derartiges Problem hin, womit ein Update von jbpm das Problem womöglich beheben würde (eine entsprechende Evaluierung wurde nicht durchgeführt). Als zweiter Unterschied ist zu nennen, dass im Gegensatz zur BPMN eine Kombination von Zusammenführung und Verzweigung im BPI nicht erlaubt ist. Obschon sowohl in [2 S. 26] als auch in [3 S. 30] die Kombination nicht empfohlen wird, muss grundsätzlich damit gerechnet und der Gateway allenfalls, wie in Abbildung 30 dargestellt, aufgetrennt werden. Abbildung 30: Auftrennung einer Kombination von Zusammenführung und Verzweigung 26

34 2.8.4 Komplexer Gateway Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 295]. Der komplexe Gateway (engl. Complex Gateway) wird genutzt, um komplexe Synchronisationsverhalten zu modellieren. Häufig genanntes Beispiel ( [1 S. 295], [2 S. 36] und [3 S. 39]) für eine Zusammenführung (engl. Complex Merge [1 S. 437]) ist die M out of N Situation, beispielsweise sobald drei von fünf Tokens eingetroffen sind. Als Spezialfall gilt die 1 out of M Situation, welche auch als Discriminator Pattern [6 S. 9] oder Structured Discriminator Pattern [7] bezeichnet wird. Die Verzweigung (engl. Complex Condition [1 S. 437]) verhält sich gleich wie die inklusive Verzweigung. Continue if two tasks have been finished Complex Merge Abbildung 31: Komplexer Gateway in Kombination mit einer parallelen Verzweigung Der komplexe Gateway kommt gemäss [2 S. 37] und [3 S. 39] nur selten zum Einsatz. Der BPI unterstützt keinen komplexen Gateway. Allenfalls wäre es denkbar, eine M out of N Funktion innerhalb des BPI Joins zu implementieren Ereignisbasierter Gateway Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 297]. Beim ereignisbasierten Gateway (engl. Event-Based Gateway) wird der zu wählende Pfad aufgrund eines nach dem Eintreffen des Tokens eintretenden Ereignisses gewählt. Wie in Abbildung 32 zu erkennen, wird der Gateway mit einem anschliessenden Zwischenereignis (siehe Kapitel 2.7) verbunden. Hierbei kann es sich um ein Nachrichten-, Signal-, Zeit-, Bedingungs- oder Mehrfachereignis handeln. Alternativ kann anstelle des Nachrichtenereignisses auch ein Empfangs- Task (siehe Kapitel 2.5.1) verwendet werden. 27

35 Mesage 1 Message 2 Exclusive Decision (event-based) 1 Day Abbildung 32: Beispiel eines ereignisbasierten Gateways Die Zusammenführung erfolgt gemäss [2 S. 84] über einen exklusiven Gateway. Ereignisbasierte Gateways werden vom BPI nicht unterstützt und es ist keine Möglichkeit bekannt, wie eine Analogie erreicht werden kann. Ereignisbasierte Gateways werden jedoch gemäss User-Guide [4] von jbpm 5.3 unterstützt (siehe Anhang B). Der ereignisbasierte Gateway kann auch verwendet werden, um den Prozessstart zu modellieren. Beim ereignisbasierten exklusiven Gateway (siehe Abbildung 33) ist eines der Ereignisse notwendig, um den Prozess zu starten. Every Month Abbildung 33: Beispiel eines Prozessstartes mit einem ereignisbasierten exklusiven Gateway Nach [2 S. 85] kann in Abbildung 33 der Gateway auch weggelassen werden. Der resultierende Prozess weist weiterhin dasselbe Verhalten auf. Die BPI Startaktivität bietet die Möglichkeit, auf unterschiedliche Ereignisse Triggers genannt zu reagieren und eine Prozessinstanz zu starten. Hierzu gehören: manueller Start durch den Benutzer, Empfang einer Nachricht, Erstellung einer Datei und Aufruf eines Web-Service. Es ist möglich, mehrere Triggers für einen Prozess zu aktivieren, womit das Verhalten einem ereignisbasierten exklusiven Gateway zum Starten eines Prozesses entspricht. Die Anzahl möglicher Ereignistypen ist jedoch stark eingeschränkt. 28

36 Im Gegensatz zum exklusiven sind beim ereignisbasierten parallelen Gateway (siehe Abbildung 34) alle Ereignisse notwendig um einen neuen Prozess zu starten. Every Month Abbildung 34: Beispiel eines Prozessstartes mit einem ereignisbasierten parallelen Gateway Ereignisbasierte parallele Gateways zum Starten eines Prozesses können nicht im BPI abgebildet werden Prozesspfade ohne Gateways Die BPMN 2.0 Spezifikation legt in Kapitel 10.2 [1 S. 153] fest, dass eine Aktivität sowohl mehrere einals auch mehrere ausgehende Sequenzflüsse haben kann. Das Verhalten entspricht einer exklusiven Zusammenführung respektive einer parallelen Verzweigung. (In [2 S. 44] wird explizit erwähnt, dass das Verhalten für mehrere Ein- und dasjenige für mehrere Ausgänge somit nicht symmetrisch ist.) In Kapitel [1 S. 97] erläutert die Spezifikation den bedingten Sequenzfluss (engl. Conditional Sequence Flow). Mit diesen Mitteln lassen sich Prozesspfade teilweise auch ohne Raute modellieren. Ein exklusiver Gateway kann, wie in Abbildung 35 dargestellt, vollständig ohne Raute dargestellt werden. B B A C E A C E D D Abbildung 35: Exklusiver Gateway (links) und dessen alternative Darstellung ohne Raute Für die Migration nach BPI muss die Verzweigung explizit eingefügt werden, sodass das Resultat demjenigen des exklusiven Gateways mit Raute aus Kapitel entspricht. Abbildung 36 zeigt die Umsetzung von Abbildung 35 im BPI. Abbildung 36: Umsetzung des exklusiven Gateways ohne Raute im BPI 29

37 Gemäss [2 S. 45] ist die Darstellung eines Gateways ohne Raute nicht nur platzsparender, sondern hat noch eine zusätzliche Bedeutung: Je nach zu modellierendem Sachverhalt kann die direkte Verzweigung aus einer Aktivität heraus auch als natürlichere Darstellung angesehen werden. Handelt es sich [ ] um eine Entscheidungsaktivität, so ist es naheliegend, die als Ergebnis der Entscheidung einzuschlagenden Sequenzflüsse direkt aus der Aktivität herausgehen zu lassen. Diese Aussage widerspiegelt sich durchaus auch im BPI. Nebst der Entscheidung und dem Fork kann auch der Task mehrere Ausgänge enthalten. Sie bewirken, dass zum Abschliessen des Tasks unterschiedliche Optionen in Form von UI Buttons (beispielsweise Annehmen und Ablehnen ) zur Verfügung gestellt werden. Es wäre somit denkbar, eine verzweigende Benutzeraufgabe (wie es in Abbildung 35 der Fall sein könnte) in einen BPI Task mit mehreren Ausgängen zu überführen. Es ist jedoch programmatisch schwierig zu erkennen, ob diese Vorgehensweise für einen konkreten Fall die richtige ist. Die inklusive Verzweigung (siehe Abbildung 37) kann wie die exklusive durch bedingte Sequenzflüsse ersetzt werden. Der Unterschied besteht lediglich darin, dass bei der exklusiven Verzweigung die Bedingungen so formuliert sind, dass immer nur genau eine zutrifft. Die inklusive Zusammenführung kann, wie in Abbildung 37 dargestellt, nicht ohne Raute modelliert werden. B B A C E A C E D D Abbildung 37: Inklusiver Gateway (links) und dessen alternative Darstellung ohne Raute Die grosse Herausforderung besteht darin, die ex- und die inklusive Verzweigung programmatisch voneinander unterscheiden zu können. Es ergeben sich drei mögliche Ansätze: 1. Es wird analysiert, ob sich die Bedingungen gegenseitig ausschliessen. Abgesehen von banalen Fällen wird dies jedoch sehr schwierig bis unmöglich sein. 2. Es wird die Zusammenführung untersucht. Auch dies führt nur in einfacheren Konstellationen (wie in Abbildung 37) zu einem eindeutigen Ergebnis. 3. Es wird davon ausgegangen, dass inklusive Gateways auf fachlicher Ebene nur selten zum Einsatz kommen (siehe auch Anhang A) und es sich um einen exklusiven Gateway handelt. Falls diesbezüglich Gewissheit besteht und ein inklusiver Gateway im BPI umgesetzt werden soll, muss gezwungenermassen mit Einbussen bezüglich der Übersicht des Prozessdiagramms gerechnet werden. Die Abbildung 38 zeigt die Umsetzung des in Abbildung 37 gezeigten Beispiels. 30

38 Abbildung 38: Umsetzung des Inklusiven Gateways ohne Raute in BPI Es ist zu bemerken, dass der inklusive Gateway nur dann im BPI umgesetzt werden kann, wenn sich zwischen der Verzweigung und der Zusammenführung kein Ende befindet, welches verhindert, dass ein Token den Join erreicht. Gemäss [2 S. 40] ist es auch denkbar, dass gewöhnliche und bedingte Ausgänge miteinander kombiniert werden. Es scheint offensichtlich, dass die Umsetzung einer derartigen Ausgangslage nach BPI massiv an Komplexität zunehmen würde. Es wird davon ausgegangen, dass diese Situation in der Praxis auf fachlicher Ebene unbedeutend und selten anzutreffen ist. Abbildung 39 zeigt die Darstellung eines parallelen Gateways ohne Raute. B B A C E A C E D D Abbildung 39: Paralleler Gateway (links) und dessen alternative Darstellung ohne Raute Die Umsetzung des parallelen Gateways ohne Raute kann mit einem geringeren Aufwand durchgeführt werden, wie Abbildung 40 zeigt. Abbildung 40: Umsetzung des parallelen Gateways ohne Raute in BPI Zusammenfassend darf vermerkt werden, dass Prozesspfade ohne Gateways schwieriger einzuordnen und zu transformieren sind. Situationsbedingt kann der korrekte zu verwendende Gateway-Typ nicht mit vollständiger Gewissheit bestimmt werden. 31

39 2.9 Kompensation Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel 10.6 [1 S. 302]. Mit dem Konzept der Kompensation (engl. Compensation) können bereits ausgeführte Aktivitäten rückgängig gemacht werden. Die eigentliche Kompensation wird durch einen Kompensations- Handler (engl. Compensation Handler) ausgeführt, welcher auf zwei unterschiedliche Varianten festgelegt werden kann. Erstens kann es sich beim Kompensations-Handler um eine Kompensationsaktivität (engl. Compensation Activity) handeln, welche über ein Kompensationsereignis an die rückgängig zu machende Aktivität angeheftet wird. Als Kompensationsaktivität kommen wie in Abbildung 41 dargestellt ein Task oder ein Unterprozess in Frage, wobei diese mit einer Kompensationsmarkierung (siehe Kapitel und 2.5.2) versehen werden. Book Hotel Book Journey Cancel Hotel Cancel Journey Abbildung 41: Beispiel einer Kompensation mittels eines Tasks (links) oder Unterprozesses Quelle (links): Abbildung der BPMN 2.0 Spezifikation, Kapitel [1 S. 303] Die Kompensation wird ausgeführt, wenn sich die Aktivität innerhalb einer Transaktion (siehe Kapitel 2.5.2) befindet und diese abgebrochen wird oder ein auslösendes Kompensationsereignis (siehe Kapitel 2.7) in Form eines Zwischen- oder Endereignisses auftritt. Als Kompensations-Handler kann zweitens auch ein Kompensations-Ereignis-Unterprozess (engl. Compensation Event Sub-Process) zum Einsatz kommen, welcher wiederum Kompensationsaktivitäten aufrufen kann. Abbildung 41 zeigt hierzu ein einfaches Beispiel. 32

40 Book Flight Cancel Flight Book Hotel Cancel Hotel Handle Compensation Booking Flight Hotel Update Customer Record Abbildung 42: Beispiel einer Kompensation mittels eines Ereignis-Unterprozesses Quelle: Abbildung der BPMN 2.0 Spezifikation, Kapitel [1 S. 304] Der Kompensations-Ereignis-Unterprozess kann und dies ist in dem Sinne eine Ausnahme ausserhalb des gesamten Unterprozesses über ein ausgelöstes Kompensationsereignis aufgerufen werden. Vorteil dieses Ansatzes ist, dass die Kompensationsreihenfolge festgelegt werden kann und zusätzliche Aktivitäten ausgeführt werden können. Eine Kompensation lässt sich auf den ersten Blick gut nach BPI transformieren, wenn sie explizit durch ein Kompensationsereignis ausgelöst wird. Abbildung 43 zeigt, wie in diesem Fall das Kompensationsereignis durch die Kompensationsaktivität ersetzt werden kann. Book Hotel Book Hotel Cancel Hotel Cancel Hotel Abbildung 43: Eine Aktivität rückgängig machen mit (links) und ohne Kompensation 33

41 Es gilt jedoch zu beachten, dass das Kompensationsereignis mehrere Kompensationsaktivitäten auslösen könnte und diese dann in umgekehrter Reihenfolge ausgeführt werden müssen. Dies kann aufgrund von Verzweigungen im Prozessfluss zu einer schwierigen Angelegenheit werden. Die anderen Anwendungsfälle der Kompensation lassen sich ebenfalls nur schwer nach BPI transformieren. Hierzu fehlt die Möglichkeit, auf Fehler- oder Abbruchsereignis reagieren zu können (Vgl. angeheftetes Abbruchs- und Fehlerereignis, siehe Kapitel 2.7). Dies ist jedoch eine wichtige Voraussetzung, um auf ein Fehlverhalten reagieren und bereits ausgeführte Aktivität rückgängig machen zu können. Kompensationen stehen ausserdem in engem Zusammenhang mit einer Transaktion. Diese werden im BPI ebenfalls nicht unterstützt. Es stellt sich jedoch die Frage, ob Transaktionen tatsächlich eine Notwendigkeit darstellen, um bereits ausgeführte Aktivitäten rückgängig machen zu können. Für die folgenden Überlegungen soll daher angenommen werden, der BPI würde um die Möglichkeit der angehefteten Ereignisse erweitert werden, sodass auf ein Fehlerereignis reagiert werden kann. Prinzipiell lässt sich hiermit ohne Einsatz einer Transaktion ein Prozessfluss für den Fehlerfall modellieren, welcher sämtliche zuvor ausgeführten Aktivitäten rückgängig macht. Schwierig wird es dann, wenn Verzweigungen modelliert sind und im Fehlerfall festgestellt werden muss, welche Aktivitäten überhaupt ausgeführt wurden und welche nicht. Dies kann unter Umständen zu einer komplizierten Fallunterscheidung führen, womit die Behandlung eines Fehlers aufwändiger wird als der gewöhnliche Prozessablauf selbst. Die Fallunterscheidung muss zwar unabhängig von der eingesetzten Prozess-Engine ohnehin gemacht werden, jedoch kann sie durch die Unterstützung von Transaktionen von der Prozess-Engine übernommen werden und erhält somit keinen Einzug in das Prozessdiagramm. Es darf zusammenfassend festgehalten werden, dass die automatisierte Migration der Kompensation nach BPI nur in den einfachsten Fällen möglich und sinnvoll ist Artefakte Die im Folgenden auf grauem Hintergrund dargestellten Beschreibungen basieren auf der BPMN 2.0 Spezifikation, Kapitel [1 S. 66]. Die BPMN erlaubt es, mit Hilfe von Artefakten (engl. Artifacts), zusätzliche Information über den Prozess darzustellen. Der Sequenz- oder Nachrichtenfluss wird dabei nicht beeinflusst. Zu diesen Artefakten gehören Assoziationen (engl. Associations), Gruppierungen (engl. Groups) und Textanmerkungen (engl. Text Annotations), welche in Abbildung 44 veranschaulicht werden. A Group of Tasks Text Annotation are used for additional information Abbildung 44: Möglicher Einsatz von Assoziationen, Text Annotationen und Gruppen 34

42 Assoziationen werden eingesetzt, um Text Annotationen mit Flussobjekten zu verbinden. Sie können sowohl ungerichtet als auch gerichtet (uni- oder bidirektional) dargestellt werden. Des Weiteren kommen sie bei Kompensationen (siehe Kapitel 2.9) zum Einsatz. Gruppen dienen zur visuellen Gruppierung von Diagrammelementen. Im Gegensatz zu Unterprozessen (siehe Kapitel 2.5.2) haben sie keine Auswirkungen auf die Laufzeit. BPI unterstützt keine der obigen Artefakten. Einerseits kann festgehalten werden, dass Artefakte keine Auswirkungen auf die Prozessausführung haben und somit grundsätzlich weggelassen werden können. Andererseits tragen insbesondere Annotationen massgebend zum Verständnis eines Prozesses bei. Im Rahmen eines Migrationsassistenten könnten Annotationen ausserdem genutzt werden, um Hinweise bezüglich der durchgeführten Transformation geben zu können beispielsweise Warnungen zu einzelnen Elementen, Hinweise bezüglich Unvollständigkeit oder Dinge, die noch zu erledigen sind. Eine Implementierung innerhalb von BPI ist daher durchaus in Betracht zu ziehen. Alternativ könnten Text Annotationen auf die dazugehörigen Flussobjekte abgebildet und beispielsweise als Task-Beschreibung hinterlegt werden. Der Text ist zwar nicht mehr im Diagramm ersichtlich, aber kann wenigstens über die Objekteigenschaften betrachtet werden. Diese Notlösung ist jedoch objektspezifisch und nicht für alle Aktivitäten in BPI umsetzbar. 35

43 Zusammenfassung 3 Zusammenfassung Die Erkenntnisse der obigen Kapitel werden in den folgenden Tabellen zusammengefasst. Zusätzlich wird die Machbarkeit einer Transformation der einzelnen BPMN Symbole abgeschätzt. Die Häufigkeit beschreibt, wie oft gemäss [3 S. 185] (siehe auch Anhang A) die einzelnen BPMN Symbole in der Praxis für fachliche Geschäftsprozesse eingesetzt werden. Für zusätzliche Kontextinformation ist die Projektdokumentation 1 beizuziehen. Die Bedeutung von Machbarkeit und Häufigkeit ist wie folgt definiert: Machbarkeit Migration % möglich Migration % möglich mit geeigneter Umformung Migration 50-90% möglich, allenfalls mit geeigneter Umformung oder minimen Erweiterungen von BPI Migration möglich mittels kleinerer bis mittlerer Erweiterung von BPI. Migration nicht möglich oder nur mit sehr grossem Aufwand Häufigkeit Immer Häufig Immer wieder mal Selten Fast nie 3.1 Pool und Lanes Pool Machbarkeit Häufigkeit Bemerkung Wahl des zu portierenden Pools (manuelle Eingabe durch Benutzer) Lane Spiegelung von horizontalen Lanes notwendig; Neuausrichtung von Swimlane-abhängigen Aktivitäten Tabelle 3: Transformation von Pool und Lanes 3.2 Flüsse Machbarkeit Häufigkeit Bemerkung Umwandlung in Darstellung mit Gateway; allerdings nicht in allen Situationen möglich/sinnvoll Allenfalls Umwandlung in Darstellung mit Gateway Tabelle 4: Transformation von Flüssen 1 Migrationsassistent, Kapitel 3 36

44 Zusammenfassung 3.3 Task-Markierungen Loop Machbarkeit Häufigkeit Bemerkung Modellierung mittels rückführendem Sequenzfluss Multi-Instance Parallel Modellierung mittels zwei rückführenden Sequenzflüssen; sehr kompliziert; fehlende Arrays als Datenstruktur Multi-Instance Sequential Modellierung mittels rückführendem Sequenzfluss; fehlende Arrays als Datenstruktur Compensation Fehlende Unterstützung von Transaktionen und angehefteten Ereignissen Tabelle 5: Transformation von Task-Markierungen 3.4 Task-Typen Abstract Machbarkeit Häufigkeit Bemerkung Empfehlung: Einführung eines neuen AbstractTasks Service WebServiceCall falls Web Service, ansonsten AbstractTask Send SendMail (fachlich) oder WebServiceCall (technisch) Receive Transformation mittels BPI Task möglich falls Web Service Aufruf; Starten des Prozesses per Web Service, URL oder E- Mail. User Umsetzung mittels BPI Task oder AbstractTask Manual Business Rule Keine Business Rule Engine vorhanden; Umsetzung mittels AbstractTask Script BPI soll konzeptionell ohne Skripte auskommen können; Umsetzung mittels AbstractTask Tabelle 6: Transformation von Task-Typen 37

45 Zusammenfassung 3.5 Unterprozesse Sub-Process Machbarkeit Häufigkeit Bemerkung Umsetzung mittels AbstractTask falls zugeklappt, ansonsten Verzicht auf Unterprozess (und somit auf angeheftete Ereignisse) Modellierung mittels rückführendem Sequenzfluss Loop Sub-Process vorausgesetzt Multi-Instance Parallel Modellierung mittels zwei rückführenden Sequenzflüssen; sehr kompliziert; fehlende Arrays als Datenstruktur Multi-Instance Sequential Annahme: Analog zu Task-Markierung Modellierung mittels rückführendem Sequenzfluss; fehlende Arrays als Datenstruktur Compensation Fehlende Unterstützung von Transaktionen und angehefteten Ereignissen Ad-Hoc Parallele Ausführung der Aktivitäten mittels Fork und Join Event Sub- Process Transaction Transaktionsverhalten wird nicht Unterstützt; Umsetzung als herkömmlicher Unterprozess Tabelle 7: Transformation von Unterprozessen 3.6 Aufrufaktivität Call Activity Machbarkeit Häufigkeit Bemerkung Einbettung des globalen Tasks. Umsetzung für globale Prozesse hingegen sehr aufwändig. Tabelle 8: Transformation der Aufrufaktivität 3.7 Daten Machbarkeit Häufigkeit Bemerkung Data Object Fehlende Arrays als Datenstruktur Data Object Collection Anmerkung: nach eigener Einschätzung Fehlende Unterstützung von Unterprozessen Data Input 38

46 Zusammenfassung Fehlende Unterstützung von Unterprozessen Data Output Data Store Tabelle 9: Transformation von Daten 3.8 Startereignisse Machbarkeit Häufigkeit Bemerkung Start Aktivität mit oder Web Service Ausführung Delegation an externes Tool Delegation an externes Tool Implementierung eines Broadcast-Systems in BPI Delegation an externes Tool Delegation an externes Tool Tabelle 10: Transformation von Startereignissen 3.9 Startereignisse für Ereignis-Unterprozesse Machbarkeit Häufigkeit Bemerkung Fehlende Unterstützung von (Ereignis-) Unterprozessen Siehe Ereignis- Unterprozess Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen 39

47 Zusammenfassung Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Fehlende Unterstützung von (Ereignis-) Unterprozessen Tabelle 11: Transformation von Startereignissen für Ereignis-Unterprozesse 3.10 Endereignisse Machbarkeit Häufigkeit Bemerkung Transformation nach SendMail Aktivität und Ende Fehlende Unterstützung von Unterprozessen Fehlende Unterstützung von Unterprozessen Fehlende Unterstützung von Unterprozessen Fehlende Unterstützung von Transaktionen und angehefteten Ereignissen Implementierung eines Broadcast-Systems in BPI Tabelle 12: Transformation von Endereignissen 40

48 Zusammenfassung 3.11 Zwischenereignisse im normalen Fluss Machbarkeit Häufigkeit Bemerkung Umsetzung mittels AbstractTask Transformation mittels BPI Task möglich falls Web Service Aufruf SendMail (fachlich) oder WebServiceCall (technisch) Konfiguration einer Zeitdauer möglich (aber nicht eines Zeitpunktes) Fehlende Unterstützung von Transaktionen und angehefteten Ereignissen Umsetzung mittels Entscheidungsaktivität und Timer Verbindung mittels Sequenzfluss Verbindung mittels Sequenzfluss Implementierung eines Broadcast-Systems in BPI Implementierung eines Broadcast-Systems in BPI Umsetzung mittels Fork / Join Umsetzung mittels Entscheidungsaktivität und Timer Umsetzung mittels Entscheidungsaktivität und Timer Tabelle 13: Transformation von Zwischenereignissen im normalen Fluss 41

49 Zusammenfassung 3.12 Angeheftete Zwischenereignisse Machbarkeit Häufigkeit Bemerkung Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Umsetzung mittels Zeitnehmer im Falle eines BPI Tasks möglich Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Implementierung eines konfigurierbaren Fehlerausgangs möglich Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Annahme: gleich wie unterbrechend. Fehlende Unterstützung angehefteter Zwischenereignisse Fehlende Unterstützung angehefteter Zwischenereignisse Tabelle 14: Transformation von angehefteten Zwischenereignissen 42

50 3.13 Gateways Zusammenfassung Machbarkeit Häufigkeit Bemerkung Zusammenführung bei der darauffolgenden Aktivität Exclusive jbpm 5.3 Update Inclusive Auftrennung von kombinierten Join/Forks; Erkennung falsch strukturierter Joins Parallel M out of N Funktion denkbar als Erweiterung des Forks Complex jbpm 5.3 Update Event Bedingt umsetzbar mittels Triggers (Manuell, Empfang, Dateierstellung und Webservice) Event Start Exclusive Event Start Parallel Tabelle 15: Transformation von Gateways 3.14 Artefakte Machbarkeit Häufigkeit Bemerkung Text Annotation Überführung des Textes zur dazugehörigen Aktivität (beispielsweise als Beschreibung); Implementierung in BPI denkbar, sodass Hinweise zur durchgeführten Transformation gegeben werden können Ist grundsätzlich verzichtbar; Implementierung in BPI Group denkbar, sodass Hinweise zur durchgeführten Transformation gegeben werden können Tabelle 16: Transformation von Artefakten 43

51 Kosten/Nutzen-Matrizen 4 Kosten/Nutzen-Matrizen Anhand der Einschätzung bezüglich Machbarkeit und Häufigkeit aus dem vorherigen Kapitel lassen sich die folgenden fünf Kosten/Nutzen-Matrizen ableiten. Start- & Endereignisse Nutzen Event Sub-Process Kosten Abbildung 45: Kosten/Nutzen-Matrix für Start- und Endereignisse 44

52 Kosten/Nutzen-Matrizen Zwischenereignisse Nutzen Kosten Abbildung 46: Kosten/Nutzen-Matrix für Zwischenereignisse Angeheftete Zwischenereignisse Nutzen Kosten Abbildung 47: Kosten/Nutzen-Matrix für angeheftete Zwischenereignisse 45

53 Kosten/Nutzen-Matrizen Aktivitäten Abstract Sub-Process Send Ad-Hoc Service Business Rule Receive User Call Activity Loop Loop Nutzen Manual Multi-Instance Parallel Multi-Instance Parallel Script Event Sub- Process Multi-Instance Sequential Multi-Instance Sequential Compensation Compensation Transaction Kosten Abbildung 48: Kosten/Nutzen-Matrix für Aktivitäten Pools & Lanes, Gateways, Flüsse, Daten und Artefakte Nutzen Pool Lane Text Annotation Group Kosten Abbildung 49: Kosten/Nutzen-Matrix für Pools, Lanes, Gateways, Flüsse, Daten und Artefakte 46

54 Literatur- und Quellverzeichnis 5 Literatur- und Quellverzeichnis [1]. Object Management Group (OMG). Business Process Model and Notation (BPMN). 3. Januar [2]. Allweyer, Thomas. BPMN Business Process Model and Notation. Norderstedt : Books on Demand, [3]. Freund, Jakob, Rücker, Bernd und Henninger, Thomas. Praxishandbuch BPMN. München : Carl Hanser Verlag, [4]. JBoss Community. JBoss.org. jbpm User Guide. [Online] 21. Mai [Zitat vom: 9. Oktober 2012.] [5].. JBoss.org. JBoss jbpm - Workflow in Java. [Online] 15. September [Zitat vom: 9. Oktober 2012.] [6]. White, Stephen A. Process Modeling Notations and Workflow Patterns. [Online] März [Zitat vom: 15. Januar 2013.] [7]. Workflow Patterns. Pattern 9 (Structured Discriminator). [Online] [Zitat vom: 15. Januar 2013.] [8]. JBoss Community. JBoss.org. jbpm. [Online] [Zitat vom: 22. November 2012.] 47

55 Anhang Anhang A Häufigkeit der BPMN Symbole Abbildung 50: Häufigkeit der BPMN 2.0 Symbole Quelle: Praxishandbuch BPMN [3 S. 185] (WWW: 48