BPMN-Gateways

BPMNs Ausführungsmodell ist ein Token, das durch das Diagramm wandert. Ein Gateway ist das Einzige, was die Anzahl der Token verändert: eine Verzweigung kann aus einem Token mehrere machen, eine Zusammenführung mehrere wieder zu einem. Alles Weitere über Gateways folgt daraus.

Eine Anmerkung zum Namen. Die Spezifikation sagt Gateway; die meisten sagen Gate und suchen danach. Es ist dasselbe, und die Raute ist dieselbe Raute - aber in einen Diagrammtitel gehört Gateway, denn das ist das Wort, nach dem jedes BPMN-Werkzeug und jeder Reviewer liest.

Zwei Konsequenzen sind es wert, festgehalten zu werden. Erstens leistet ein Gateway keine Arbeit - es wertet Bedingungen aus, die bereits berechnet wurden, und wenn etwas geprüft werden soll, ist das eine Aufgabe vor dem Gateway. Zweitens braucht eine Verzweigung meist eine passende Zusammenführung derselben Art, denn was zusätzliche Token erzeugt hat, muss sie wieder zusammenführen, sonst laufen sie getrennt bis zum Ende.

Dasselbe Symbol macht beide Aufgaben, und welche gerade, hängt nur davon ab, ob es mehr ausgehende oder mehr eingehende Flüsse hat. Ein Gateway mit einem Eingang und drei Ausgängen verzweigt; drei hinein und einer hinaus führt zusammen.

Das Vokabular lohnt sich festzulegen, denn für den zusammenlaufenden Fall gibt es drei Wörter. Ein zusammenlaufendes paralleles Gateway ist ein Join: es wartet auf jeden Zweig. Ein zusammenlaufendes exklusives Gateway ist ein Merge: es wartet auf nichts und lässt jedes Token durch. Beide werden als dieselbe Raute gezeichnet wie beim Verzweigen, und einen Merge einen Join zu nennen ist der Weg, auf dem ein Diagramm Arbeit als erledigt ausweist, die nie lief.

Alles aus den beiden Abschnitten oben ist eine Fertigkeit: Finger auf das Startereignis legen und zählen. Hier ist der Schadensprozess vom Kopf dieser Seite, Schritt für Schritt durchgegangen, mit der Zahl lebender Token nach jedem Schritt.

1. „Claim received“ tritt ein. Ein Token. Es sitzt auf dem Fluss in das erste Gateway.
2. Die parallele Verzweigung. Zwei Token. Es werden keine Bedingungen ausgewertet und nichts gewählt - eine parallele Verzweigung gibt immer ein Token pro ausgehendem Fluss aus.
3. Policenprüfung und Betrugsprüfung laufen. Weiterhin zwei. Sie sind wirklich nebenläufig: das Diagramm behauptet nichts darüber, welche zuerst fertig ist, und muss es auch nicht.
4. Der parallele Join. Zurück auf eins. Das zuerst ankommende Token wartet dort. Kommt das zweite, verbraucht der Join beide und gibt eines aus.
5. „Covered?“ Ein Token, ein Zweig. Ein exklusives Gateway ändert die Anzahl nie - nur, auf welchem Fluss das Token liegt.
6. Regulieren oder ablehnen, dann das Ende. Null. Die Prozessinstanz ist fertig, wenn das letzte Token von einem Endereignis verbraucht wird.

Jetzt machen Sie es absichtlich kaputt, denn beide klassischen Fehler sind allein am Zählstand sichtbar.

Machen Sie das erste Gateway exklusiv und lassen Sie den Join parallel. Die Verzweigung gibt jetzt ein Token aus, also läuft eine Prüfung. Der parallele Join wartet weiterhin auf zwei. Auf dem zweiten Fluss kommt nie etwas an, und der Schaden bleibt für die Lebensdauer des Systems im Join stehen. Das ist der Deadlock, und er kostete eine geänderte Markierung.

Lassen Sie die Verzweigung parallel und machen Sie den Join exklusiv. Zwei Token kommen an, und ein exklusiver Merge wartet auf nichts, also gehen beide direkt durch. „Covered?“ wird zweimal ausgewertet, die Reguliersaufgabe läuft zweimal, und der Kunde wird zweimal bezahlt. Das ist schlimmer als der Deadlock, denn ein Deadlock meldet sich selbst und eine Doppelzahlung nicht.

Das ist die Konstruktion, die „wir warten auf die Unterlagen, aber nicht ewig“ in einem Bild ausdrückbar macht. Jede andere Art, das zu zeichnen - ein Timer-Randereignis an einer Warteaufgabe, eine Schleife mit Bedingung - verdoppelt entweder die Timeout-Logik oder versteckt sie.

Zwei Regeln gehören dazu. Die Ziele eines ereignisbasierten Gateways müssen eintretende Zwischenereignisse oder Receive-Aufgaben sein, nie einfache Aufgaben: das Gateway ist ein Rennen zwischen Dingen, die ankommen, und eine Aufgabe kommt nicht an. Und die Zweige müssen zeitlich wirklich exklusiv sein, was sie automatisch sind - das zuerst eintretende verwirft die übrigen.

Bedingungen leben an den ausgehenden Sequenzflüssen, nicht am Gateway. Schreiben Sie sie als kurze Ausdrücke, die ein Leser auswerten kann - amount > 10000, policy status = active - und setzen Sie sie näher an das Gateway als an das Ziel.

Genau ein Zweig eines verzweigenden Gateways sollte der Standardfluss sein, gezeichnet mit einem kleinen Strich über dem Ende. Er wird genommen, wenn keine andere Bedingung gilt, und er verhindert, dass ein Prozess an einem Gateway stehen bleibt, weil die Daten etwas waren, womit niemand gerechnet hat.

Wer Gateways gelernt hat, greift für jede Verzweigung der Welt danach, und das Ergebnis ist ein Diagramm, das zu 40 % aus Rauten besteht. Vier andere BPMN-Konstrukte drücken eine Entscheidung in den folgenden Fällen besser aus, und sie zu kennen ist der halbe Unterschied zwischen einem Prozessmodell, das auf eine Seite passt, und einem, das es nicht tut.

Der Test ist, ob die Verzweigung Teil des Prozesses oder Teil einer Entscheidung ist. Ein Schaden, der in die Schnellbearbeitung oder in die manuelle Prüfung geht, ist Prozess: die beiden Pfade sehen unterschiedlich aus und ein Leser muss beide sehen. In welches von neun Risikobändern ein Schaden fällt, ist eine Entscheidung: die Pfade sind danach identisch, und es aufs Diagramm zu nehmen kostet acht Rauten für eine Aussage. Siehe ein BPMN-Diagramm zeichnen dazu, wo diese Grenze in der Praxis meist liegt.

1. Parallele Verzweigung, exklusiver Merge. Die Verzweigung erzeugte zwei Token; der exklusive Merge lässt beide durch, und alles danach passiert zweimal.
2. Inklusive Verzweigung, paralleler Join. Der Deadlock von oben. Passen Sie Ihre Gateways aneinander an.
3. Arbeit im Gateway. Eine Raute mit der Aufschrift „Prüfen und weiterleiten“ ist eine Aufgabe und ein Gateway in einem Umriss. Trennen Sie sie.
4. Unbeschriftete Zweige. Zwei Linien, die eine Raute verlassen, ohne dass etwas daran steht, lassen den Leser raten, und die Hälfte rät falsch.
5. Kein Standardfluss. Die eine Eingabe, an die niemand gedacht hat, kommt an, und das Token hat keinen Weg.
6. Einfache Aufgaben nach einem ereignisbasierten Gateway. Nicht zulässig, und meist war ein exklusives Gateway gemeint.

Gateways und Ereignisse sind die beiden Hälften der BPMN-Ablaufsteuerung: Gateways entscheiden, Ereignisse warten und unterbrechen. Ein nur mit Gateways modellierter Prozess wächst zu langen Polling-Ketten; einer, der Randereignisse dort nutzt, wo er sollte, bleibt sehr viel näher an dem, was tatsächlich passiert.