Ein Prozess mit einem ereignisbasierten Gateway (Klicken zum Vergrößern)
Möchte man in einem BPMN-Prozess auf unterschiedliche Ereignisse reagieren, so erweist sich der ereignisbasierte Gateway als nützlich. An einer Verzweigung mit einem gewöhnlichen exklusiven Gateway wird ein Sequenzfluss auf Grundlage von Daten gewählt. Er heißt daher auch datenbasierter Gateway. Zum Beispiel kann ein Beschaffungsanstrag an einen Manager zur Genehmigung geleitet werden, wenn die Bestellsumme über einem bestimmten Limit liegt. Bei einem ereignisbasierten Gateway erfolgt die Auswahl des ausgehenden Sequenzflusses hingegen auf Grundlage eines eingetretenen Ereignisses. In jedem ausgehenden Sequenzfluss muss auf den Gateway ein empfangendes Ereignis (oder ein Empfangs-Task) folgen. Wenn der Gateway aktiviert wird, wird auf das Eintreten der folgenden Ereignisse gewartet. Das Ereignis, das zuerst eintritt, gewinnt, und der entsprechende Sequenzfluss wird ausgewählt.
In der obigen Abbildung wird zunächst eine Lagerbestellung erfasst und ans Lager versandt. Anschließend wird am ereignisbasierten Gateway gewartet. Geht eine Bestätigung ein bevor ein Tag vergangen ist, wird sie geprüft und der Prozess ist beendet. Ist hingegen zuerst ein Tag vergangen ohne dass eine Bestätigung eingetroffen ist, so wird im Lager nachgefragt, bevor erneut am ereignisbasierten Gateway gewartet wird. In einem realen Prozess würde noch eine Abzweigung nach dem Zeitereignis benötigt, über die der Prozess beendet wird, wenn eine bestimmte Zahl von Tagen vergangen ist. Ansonsten könnte eine Endlosschleife entstehen.
Leider verfügen nicht alle BPM-Systeme zur Prozessausführung über den ereignisbasierten Gateway. So nutze ich für die Lehre die kostenfreie Community Edition des Systems „Bonita“, deren Modellpalette keinen ereignisbasierten Gateway erhält. Man muss daher eine andere Methode finden um dennoch dasselbe Verhalten zu erzielen. Das Finden derartiger „Workarounds“ ist eine nützliche Übung zur Vertiefung des eigenen Verständnisses der BPMN-Ablauflogik.
Die folgende Abbildung zeigt eine mögliche Lösung. Hier wurde das Warten auf die Ereignisse in einen Unterprozess verlagert. Nach dem Start des Unterprozesses wird der Sequenzfluss zunächst an einem parallelen Gateway in zwei parallele Pfade aufgeteilt, denn es soll ja zugleich auf beide Ereignisse gewartet werden. Im Hauptprozess wurde eine boolesche Variable „Rechtzeitige Bestätigung-Flag“ definiert, die angibt, ob die Bestätigung rechtzeitig angekommen ist. Als Default-Wert enthält sie zunächst den Wert „true“. Geht nun als erstes die Bestellung ein, so wird der Unterprozess durch das Terminierungsereignis beendet. Im übergeordneten Prozess wird an dem datenbasierten Gateway der untere Pfad gewählt, da das Flag unverändert den Wert „true“ hat.
Unterprozess zum Warten auf Ereignisse (Klicken zum Vergrößern)
Ist hingegen ein Tag vorüber bevor eine Bestätigung eingegangen ist, so wird der Wert des Flags auf „false“ gesetzt, und es wird im übergeordneten Prozess der obere Pfad gewählt. Bevor erneut gewartet wird, muss der Wert des Flags wieder auf den Default-Wert „true“ zurückgesetzt werden. Dies wurde nicht als eigener Task modelliert, es kann z. B. in dem Nachfrage-Task mit durchgeführt werden.
Die Terminierungsereignisse sind notwendig, da nach dem Eintreten des eines Ereignisses ansonsten immer noch auf das andere Ereignis gewartet und der Unterprozess nicht beendet würde.
Die nächste Abbildung zeigt eine andere Lösungsmöglichkeit. Hier wurde das Warten als Task mit angehefteten Ereignissen modelliert. Es handelt sich um eine Art Dummy-Task, der nichts tut, außer eben Warten. Er wird nicht auf normalem Wege beendet, sondern nur über die angehefteten, abbrechenden Ereignisse. Wenn das erste dieser beiden Ereignisse eintritt, wird der Task abgebrochen und es wird dem von dem Ereignis ausgehenden Ausnahmefluss gefolgt.
Ein Warte-Task mit abbrechenden Ereignissen (Klicken zum Vergrößern)
Bei der Implementierung als ausführbarer Prozess wurde das unbegrenzte Warten des Tasks dadurch erreicht, dass er einem Dummy-Benutzer zugeordnet wurde, d. h. einem Benutzer, der zu keiner realen Person gehört. Der Task wartet daher in einer Taskliste, die nie jemand zu sehen bekommt.
Da der Prozess mit einem expliziten Startereignis beginnt, könnte man fordern, dass jeder Task einen regulären ausgehenden Sequenzfluss besitzen muss. Selbstverständlich könnte man einen Sequenzfluss aus dem Wartetask herausführen und zu einem Endereignis gehen lassen. Allerdings würde dieser Sequenzfluss niemals genutzt.
Mehr zu BPMN in:
Das hier beschriebene Beispiel stammt aus dem BPMS-Buch:
