BPMN 2.0 Crashkurs
Business Process Model and Notation entwickelt von der Object Management Group, einem Konsortium von vielen Firmen (u.a. HP, IBM, Microsoft, Oracle, SAP) >60 verschiedene Produkte implementieren BPMN in der Praxis aktuell: Version 1.2, Implementationen eher nach 1.0 als Draft: Version 2.0
Business Process Model and Notation Graphische Diagrammdarstellung Kontrollfluß durch Erstellen, Löschen und Bewegen von Token Im Standard: kein explizites Tokenmodell, Versuch mit ungefärbten Token auszukommen dazu ein einfaches Datenmodell ( XML Fragmente)
Flussobjekte der BPMN Activities: verrichten die eigentliche Arbeit z.b. Ausführung eines Skripts, Manipulation einer Datenbank, Veranlassung einer Handlung in der echten Welt Gates: modifizieren den Kontrollfluß im Workflow z.b. Aufspaltung eines Token in mehrere oder Vereinigung mehrerer Token zu einem Events: verzögern den Kontrollfluß bis ein Ereignis auftritt bzw. lösen ein Ereignis aus z.b. das Versenden/Empfangen einer Nachricht oder einen Timeout
Kontrollfluss Kontrollfluß wird angezeigt durch durchgezogene gerichtete Kanten Viele Flussobjekte können mehrere eingehende und/oder ausgehende Kanten haben Zyklen sind ohne Einschränkungen erlaubt (problematisch!)
Task Activity Wartet bis mindestens ein Token auf der eingehenden Kante liegt Konsumiert genau ein Token von der eingehenden Kante Führt dem Task zugeordnete Aktion aus (Skript, Datenbankupdate, Interaktion mit der echten Welt... ) Produziert genau ein ausgehendes Token
Parallel Gate (als Split) Wartet bis mindestens ein Token auf der eingehenden Kante liegt Konsumiert genau ein Token von der eingehenden Kante Produziert gleichzeitig genau ein Token pro ausgehender Kante
Parallel Gate (als Join) Wartet bis auf jeder eingehenden Kante mindestens ein Token liegt Konsumiert gleichzeitig genau ein Token pro eingehender Kante Produziert genau ein Token pro ausgehender Kante
Exclusive Gate (als Split) Warte bis mindestens ein Token auf der eingehenden Kante liegt Konsumiere genau ein Token von der eingehenden Kante Produziere genau ein Token auf genau einer ausgehenden Kante Wahl der ausgehenden Kante im schlimmsten Fall nichtdeterministisch und für jedes triggernde Token unterschiedlich (mehr später)
Exclusive Gate (als Join) warte bis mindestens ein Token auf irgendeiner eingehenden Kante liegt konsumiere genau ein Token von genau einer eingehenden Kante produziere genau ein Token auf der ausgehenden Kante
Inclusive Gate (als Split) Wie ein Exclusive Gate, darf aber auf mehreren Kanten gleichzeitig Token produzieren. Wahl darf nichtdeterministisch sein Höchstens ein Token pro Kante Je nach Version: mindestens eine Kante muß ein Token erhalten / es darf auch kein ausgehendes Token produziert werden. Empfehlung: immer mindestens ein Token produzieren
Inclusive Gate (als Join) Wartet solange auf Token, wie jede Kante die noch keines hat noch eines erhalten könnte Gibt es dann mindestens eine Kante mit Token, so wird von jeder Kante mit Token genau eines konsumiert. In diesem Fall wird danach genau ein Token auf der ausgehenden Kante produziert Problematisches Konzept, insbesondere in zyklischen Netzen (später mehr)
Nichtlokale Semantik von Inclusive Joins
Nichtlokale Semantik von Inclusive Joins
Nichtlokale Semantik von Inclusive Joins
Nichtlokale Semantik von Inclusive Joins
Nichtlokale Semantik von Inclusive Joins
Nichtlokale Semantik von Inclusive Joins
Zyklen - Repeat
Zyklen - While
Zyklen - Unsauber Q: Wie sollte die Inclusive Join Semantik angepasst werden? A: (informell) Warte nicht auf Token, die auch auf einer schon belegten Kante des Joins laden können, oder erst durch eben diesen Join wandern müssten
Subprozesse als Activities
Subprozesse als Activities
Events Fänger: warten auf Eintreffen des Ereignisses, und aktivieren dann t Start Events: None, Message, Timer, Escalation, Error, Compensation, Signal, Multi, Parallel. Instanziieren einen Prozess bei Aktivierung. Catching Intermediate Events: Message, Timer, Escalation, Error, Cancel, Compensation, Signal, Multi, Parallel. Leiten genau ein Token bei Aktivierung weiter. Werfer: lösen Ereignisse aus wenn sie aktiviert werden Throwing Intermediate Events: Message, Escalation, Compensation, Signal, Multi. Werden durch eingehendes Token aktiviert. End Events: None, Message, Escalation, Error, Cancel, Compensation, Signal, Multi, Terminate. Werden durch eingehendes Token aktiviert.
Events - Beispiel
Event-gesteuerte Splits Wie ein Exclusive Split, dessen Entscheidungskriterien erst nach Eintreffen eines Ereignisses ausgewertet werden können Event Split und nachfolgende Events bilden eine Einheit (normale Semantik außer Kraft gesetzt) Split wählt denjenigen Ausgang, dessen Event zuerst eintritt (Annahme: BPMN Interpreter gewährleistet totale Ordnung zwischen Events)
Boundary Events Catching Intermediate Events, die auf Ereignisse der zugeordneten Activity reagieren Zeitüberschreitung, normalerweise nicht terminierend Exception-Handling, normalerweise terminierend Compensation, von außen ausgelöst
Exceptions - Beispiel
Compensation - Beispiel
Kollaboration Trennung autonomer Akteure in Pools, die evtl. weiter in Swimlanes geteilt sind Nachrichtenaustausch als gestrichelte Pfeile, aber niemals innerhalb eines Pools es dürfen Pools, Activities und Message Events verbunden werden