In diesem Artikel erklären wir die Funktionsweise aller BPMN Gateways sowie unsere Tipps und Modellierungsrichtlinien.

Computer Algorithmen werden häufig mit Kochrezepten verglichen. Erst die Zwiebeln andünsten, dann das Fleisch dazu, und so weiter. Manchmal wird parallel schon mal Pasta gekocht aber meistens läuft eins nach dem anderen. Man kann zwar eine Knoblauchzehe mehr verwenden aber große Entscheidungen muss man beim Kochen nicht treffen.

Wenn Prozesse auch so schön linear wären, bräuchten wir keine BPMN Gateways und Prozessberater womöglich auch nicht. Denn Gateways sind zum einen Punkte an denen der richtige Pfad anhand von vorhergegangenen Entscheidungen eingeschlagen wird. Zum anderen sind sie Verzweigungspunkte an denen Aufgaben parallelisiert und wieder synchronisiert werden. 

Exklusive Gateways

Schauen wir uns dazu ein Beispiel an:

Gerade im Sommer haben die Eisdielen Hochbetrieb. Optimierte Prozesse sorgen für mehr Durchsatz und damit auch für mehr Umsatz. Deswegen wird man noch bevor man seine Lieblingssorten bestellen kann, gefragt: Becher oder Waffel? Und zack da haben wir auch schon eines der wichtigsten BPMN Gateways: Das “Verzweigende Datenbasierte Exklusive Oder”-Gateway kurz XOR-split-Gateway.

Was dem*der Eisverkäufer*in völlig klar ist, sprechen wir im theoretischen Kontext lieber noch mal aus. Das Exklusive Gateway lässt nur eine einzige Option zu. Es gibt keine Waffel im Becher! In der BPMN Welt bedeutet das, dass für jeden Token, der in das Gateway hineinläuft, genau ein Token aus dem Gateway herausläuft. Es können beliebig viele Sequenzflüsse aus dem Gateway hinaus führen.

Eine Weitere Entscheidung könnte die Anzahl der Kugeln sein und man könnte von 1-6 jeweils in einen eigenen Prozesspfad verzweigen. Dass wir die Entscheidung anhand von Daten treffen, sollte klar sein. Eisverkäufer*innen, die diese Entscheidung aus dem Bauch heraus treffen, erfreuen sich auch keiner großen Beliebtheit.

Unsere Tipps für XOR Gateways:

• Das Gateway kann selbst keine Entscheidung treffen, sondern fragt zuvor getroffene Entscheidungen ab. Meistens braucht man also eine Aktivität vor dem Gateway. Tatsächlich sind XOR-splits direkt nach einem Blanko-Startevent ein typischer Anfängerfehler
• Wir beschriften jedes Gateway mit einer Frage und jeden ausgehenden Sequenzfluss mit der passenden Antwort
• Verschachtelung sollte vermieden werden. Das Diagramm soll von anderen Menschen verstanden werden und muss dafür übersichtlich bleiben. Manchmal lohnt es von einer Konvention abzuweichen, wenn das Prozessdiagramm dadurch leichter zu lesen ist
• Es ist erlaubt in einem Gateway sowohl mehrere Eingänge als auch mehrere Ausgänge zu haben. Wir raten allerdings davon ab

Nachdem nun also Becher oder Waffel bereit sind, hat die Entscheidung keinen weiteren Einfluss mehr auf den Prozess. Man könnte jetzt zwei gleiche Pfade parallel nebeneinander führen aber das wäre unübersichtlich. Deshalb hilft uns die BPMN mit dem “Zusammenführenden Datenbasiertem Exklusiv”-Gateway (XOR-join). Wir führen beide Prozesspfade zusammen und müssen den restlichen Prozess nur einmal modellieren.

Auch hier gilt, es können beliebig viele Sequenzflüsse in ein zusammenführendes Gateway laufen und jeder Token der reinkommt, wird weitergeleitet. Token warten nicht im XOR-join Gateway bis aus jedem Sequenzfluss ein Token gekommen ist – es wird also nicht synchronisiert.

Parallele Gateways

Gutes Stichwort. Wie läuft das eigentlich mit der Parallelisierung und Synchronisation? Dafür verwendet man in BPMN Diagrammen das parallele Gateway, auch AND-Gateway genannt. Die Praxis hat gezeigt, dass die Bezeichnung für die synchronisierende Variante Gateway (AND-join) etwas ungünstig ist. Wichtig ist bei beiden der Tokenfluss. Läuft ein Token in ein parallelisierendes Gateway so läuft für jeden ausgehenden Sequenzfluss genau ein Token heraus. Der eine Token wird also aufgespalten.

Äquivalent zum Split muss jeder eingehende Sequenzfluss einen Token geliefert haben, bevor ein Token das parallele synchronisierende Gateway (AND-merge) verlässt. Mit anderen Worten: die Token der Eingänge werden zu einem verschmolzen. Es geht erst weiter, wenn jeder Eingang einen Token geliefert hat. Dabei geht es nicht, um die Anzahl Tokens. Kommen mehrere Token über einen Eingang, muss trotzdem jeder auf die anderen Eingänge warten.

Betonen wir den Unterschied zwischen XOR-join und AND-join anhand eines Beispiels. 

In einem Restaurant bestellen wir Essen. Der Kellner soll uns das Essen und das Besteck bringen. Im oberen Prozessdiagramm ist und AND-join verwendet und beide Token werden synchronisiert, und es geht erst weiter wenn Besteck und Essen da sind. Im unteren Prozessbild wurde ein XOR-join verwendet und der Gast würde zweimal das Essen verspeisen. Allerdings würde einmal das Besteck fehlen und einmal das Essen.

Mit diesen 4 Arten von Gateways können wir bereits sehr viele Szenarien abdecken. Der Theoretiker würde sogar sagen, man braucht nicht mehr als XOR und kann alles darstellen. Die BPMN wurde aber unter anderem entwickelt, um komplexe Prozesse greifbar darzustellen. Da nützt die Theorie nicht viel, wenn das BPMN Diagramm unübersichtlich wird. 

Ereignisbasierte Gateways

Sehr viel übersichtlicher werden Prozess Modelle mit den Ereignisbasierten Gateway. Ein Workflowpattern, welches bislang von keiner anderen Modellierungssprache umgesetzt wurde. Mussten die Eisverkäufer*innen bis jetzt, jede Entscheidung von uns erfragen, können sie mit dem Ereignisbasiertem Gateway den richtigen Sequenzfluss anhand von Ereignissen wählen. Das können zeitliche Ereignisse, zum Beispiel Öffnen und Schließen der Eisdiele, sein. Aber auch eingetretene Bedingungen, wenn zum Beispiel das Eis frühzeitig ausverkauft ist. Als mögliche Ausgänge können alle BPMN Zwischenereignisse dienen. 

Wichtig ist, dass wieder nur ein Token aus dem Gateway heraus laufen kann. Das Ereignis, welches als erstes eintrifft, bestimmt den Prozesspfad. Es gibt kein synchronisierendes oder zusammenführendes Ereignisbasierendes Gateway. Sollen Pfade wieder zusammengeführt werden, können XOR-joins verwendet werden. Da aus dem Ereignisbasiertem Gateway nur ein Token heraus läuft, entstehen in Kombination mit AND-joins leicht Deadlocks! Besser einmal mehr den Tokenfluss testen als einmal zu wenig.

Inklusives Gateways

Neben dem exklusivem Oder gibt es auch noch das inklusive Oder. Auch wieder Datenbasiert, auch wieder in den Varianten verzweigend oder zusammenführend zu haben. Ein Beispiel für das Inklusive Oder aus unserer Eisdiele finden wir bei der Auswahl der Eissorten. Ich stehe vor der Entscheidung Schoko, Vanille oder Erdbeere, könnte aber auch Kombinationen oder alle drei nehmen.

Hier wird der Tokenfluss spannend. Erst beim Durchlaufen der Prozessinstanz wird festgelegt, wie viele Token das OR-split Gateway verlassen werden. Das Synchronisierende Oder Gateway wiederum weiß zur Instanz auf wie viele Token es warten muss. Was im Diagramm leicht zu beschreiben ist, macht die technische Umsetzung zum Teil sehr schwer. In der Praxis weichen viele Programme von der Spezifikation ab.

Streng nach BPMN kann es bei inklusiven Oder Gateways zu Deadlocks kommen, wenn einer der Token in ein Endereignis läuft, und es ähnlich wie beim AND-join nie zu einer Synchronisation kommen kann. Die meisten Software-Anbieter erkennen die Situation und erlauben dem wartenden Token bei einem Deadlock die Durchreise. 

Ein guter Grund für uns mit OR-Gateways sehr sparsam um zu gehen und lieber auf ausführlichere Modellierung mit AND und zwei XORs zurück zu greifen.

Komplexe Gateways

Die BPMN beschreibt zusätzlich auch noch das Komplexe Gateway. Hier kann die Logik frei beschrieben werden und komplexe Szenarien in einem Gateway zusammengefasst werden. Wieder geht es um Übersichtlichkeit und Verständlichkeit. Wird BPMN als Brücke zwischen Mensch und Maschine verstanden, so sind komplexe Gateways zwar eine Erleichterung für den Menschen aber bergen Risiken bei der Übersetzung ins technische.

Die hochgradig optimierte Eisdiele benutzt das Komplexe Gateway, um irreguläre Öffnungszeiten zu beschreiben.  Mitarbeiter sollen die Wettervorhersage prüfen, ob Regen angesagt ist und schauen ob weniger als fünf Eissorten noch nicht ausverkauft sind. Außerdem soll in Betracht gezogen werden, ob ein wichtiges Fußballspiel ansteht. Mittels einem komplexen Gateways können wir übersichtlich modellieren, dass die Eisdiele frühzeitig geschlossen wird, wenn zwei der drei Bedingungen erfüllt sind. Zugegeben, wir mussten da schon ein bisschen konstruieren aber immer wenn ein Schwellenwert an Bedingungen überschritten werden muss, kann man über komplexe Gateways nachdenken, oder man lässt es gleich weg. 

Instanziierend Gateways

Damit kommen wir zu zwei Spezialfällen. Die Instanziierenden Ereignisbasierten Gateways können zur Instanziierung dienen. In der gestarteten Instanz wartet man entweder auf das erste Event, das eintritt oder bis alle beschriebenen Events eingetroffen sind. Damit kann man einen typischen Fehler vermeiden, bei dem mehrere Startevents in ein synchronisierendes Gateway führen. Was auf dem Papier gut aussieht, schlägt in der Praxis fehl, weil jedes eintretende Startevent eine neue Prozessinstanz auslösen würde. Selbst wenn beide Events eingetreten sind, würden einsame Token ewig in ihrer eigenen jeweiligen Instanz warten.

So, jetzt haben wir einiges über BPMN Gateways gelernt und uns wirklich ein Eis verdient. Lasst es euch schmecken!

Photo by Mark Grafton on Unsplash