BPMN Gateways erklärt: XOR, AND, OR und Ereignisbasierte Verzweigungen im Detail

Wenn du auf ein Prozessmodell schaust, stechen sie sofort ins Auge: die Rauten. In der klassischen Welt der Flussdiagramme haben wir gelernt, dass diese Symbole für "Entscheidungen" stehen. Ein Manager schaut auf das Blatt, denkt nach und wählt einen Weg. In BPMN 2.0 ist das anders – und dieses Detail ist entscheidend, wenn du Modelle bauen willst, die technisch korrekt sind und von der IT verstanden werden.

In diesem Artikel lernst du, wie du diesen Mechanismus nutzt, um komplexe Logiken sauber darzustellen, ohne technische Sackgassen (Deadlocks) zu bauen.

Wir müssen zuallererst ein fundamentales Missverständnis aus dem Weg räumen, das selbst erfahrenen Modellierern oft unterläuft: Ein Gateway trifft selbst keine Entscheidung. Das klingt im ersten Moment paradox, ist aber logisch. Die eigentliche Entscheidung – also die fachliche Prüfung – findet immer in der Aktivität vor dem Gateway statt. Der Task "Bonität prüfen" liefert das Ergebnis. Das Gateway dahinter ist lediglich der Verkehrspolizist. Es schaut auf die Daten, die der Task geliefert hat, und winkt den Prozessfluss (den Token) in die entsprechende Richtung durch . Es ist also kein "Denker", sondern ein reiner Mechanismus zur Pfadsteuerung.

Bevor wir uns die spezifischen Symbole und ihre Regeln ansehen, müssen wir einen Schritt zurücktreten und verstehen, was ein Gateway strukturell mit deinem Prozess macht. Ein Gateway dient in BPMN dazu, den Sequenzfluss zu steuern – es ist der Mechanismus, der den Pfad deines Prozess-Tokens kontrolliert. Dabei hat jedes Gateway immer eine von zwei möglichen Funktionen, abhängig von der Flussrichtung: Es sorgt entweder für Divergenz (Aufteilung) oder für Konvergenz (Zusammenführung.

Die Aufteilung (Divergenz / Split)

Wenn ein Prozess an einem Punkt ankommt, an dem der weitere Verlauf nicht mehr linear ist, sprechen wir von einem Split. Hier trifft ein einzelner eingehender Sequenzfluss auf das Gateway, das den Fluss dann auf mehrere ausgehende Pfade verteilt.

Stell dir vor, der Prozess-Token kommt an einer Kreuzung an. Das Gateway entscheidet nun basierend auf seiner Logik, wie es weitergeht. Bei einem exklusiven Gateway muss der Token beispielsweise einen einzigen Weg wählen, basierend auf Daten aus dem vorherigen Schritt. Bei einem parallelen Gateway hingegen wird der Token vervielfältigt, sodass er mehrere Wege gleichzeitig beschreiten kann. Das Gateway fungiert hier also als Verteiler, der den Prozess in verschiedene Äste aufgliedert.

Die Zusammenführung (Konvergenz / Join)

Die zweite Funktion ist technisch oft anspruchsvoller und eine häufige Fehlerquelle bei Einsteigern. Hierbei führen mehrere eingehende Sequenzflüsse wieder zu einem einzigen ausgehenden Pfad zusammen4. Das Gateway fungiert als Schleuse, um die zuvor aufgeteilten Pfade wieder zu bündeln. Dabei ist es entscheidend zu verstehen, dass es zwei völlig unterschiedliche Arten gibt, wie diese Schleuse arbeiten kann: das einfache Zusammenführen (Merge) und das Synchronisieren.

Beim einfachen Zusammenführen (Merge) verhält sich das Gateway wie ein Trichter. Es leitet jeden Token, der an einem der Eingänge ankommt, sofort und ohne Verzögerung zum Ausgang weiter. Das Gateway wartet nicht. Dies ist typisch für exklusive Pfade, bei denen ohnehin nur ein einziger Token erwartet wird.

Ganz anders verhält es sich bei der Synchronisation. Hier blockiert das Gateway den Weiterfluss aktiv. Wenn ein Token ankommt, wird er festgehalten. Das Gateway wartet geduldig, bis aus allen anderen erwarteten Pfaden ebenfalls die Tokens eingetroffen sind. Erst wenn alle da sind, werden sie zu einem einzigen Token verschmolzen, und der Prozess darf weiterlaufen. Diese Logik ist zwingend notwendig, wenn parallele Arbeiten abgeschlossen sein müssen, bevor der nächste Schritt beginnen kann.

Das am häufigsten genutzte Gateway in der Prozessmodellierung ist das Exklusive Gateway (Exclusive Data-Based Gateway). Wenn du in deinem Prozess an einen Punkt gelangst, an dem es nur genau einen richtigen Weg geben darf, ist dieses Symbol deine Wahl.

Das Symbol erkennen

In der Praxis wirst du diesem Gateway in zwei verschiedenen Formen begegnen. Der Standard erlaubt sowohl eine leere Raute als auch eine Raute mit einem großen "X" im Inneren1. Lass dich davon nicht verwirren, denn beide Varianten bedeuten technisch exakt dasselbe. Die Variante ohne das "X" wird in der "Method & Style"-Lehre oft bevorzugt, da sie in komplexen Diagrammen sauberer wirkt und weniger visuelles Rauschen erzeugt. Wichtig ist jedoch vor allem eines: Entscheide dich in deinem Projekt für eine Variante und bleibe konsequent dabei.

Der Split: Ein Weg, und nur einer

Wenn wir dieses Gateway nutzen, um einen Pfad aufzuteilen, sprechen wir von einer exklusiven Entscheidung. Stell dir vor, dein Prozess-Token kommt am Eingang an. Das Gateway fungiert nun als Prüfstelle für die Daten, die der Prozess bis hierhin gesammelt hat. Es bewertet die Bedingungen an den ausgehenden Sequenzflüssen und öffnet genau eine Schranke.

Es wird exakt derjenige Pfad gewählt, dessen Bedingung "Wahr" ist. Da die Logik exklusiv ist, kann der Token niemals zwei Wege gleichzeitig nehmen – es ist wie an einer Weggabelung im Wald, an der du dich entscheiden musst, ob du links oder rechts gehst .

Best Practice: Die richtige Beschriftung

Damit dein Modell für jeden Betrachter – vom Azubi bis zum Vorstand – sofort verständlich ist, nutzen wir eine feste Konvention für die Beschriftung. Da das Gateway eine Datenprüfung darstellt, solltest du das Gateway selbst immer mit einer konkreten Frage beschriften, beispielsweise "Bonität ok?". Die ausgehenden Pfade beschriftest du anschließend mit den passenden Antworten, also "Ja" und "Nein".

Diese Kombination aus Frage am Gateway und Antwort am Pfeil macht die Logik lesbar wie einen Dialog. Vermeide es, die Pfade mit Zuständen wie "Bonität vorhanden" und "Bonität fehlt" zu beschriften, wenn am Gateway selbst kein Text steht, da dies den Lesefluss stört.

Der "Default Flow": Dein Sicherheitsnetz

Was passiert aber in dem seltenen Fall, dass keine der definierten Bedingungen zutrifft?

Technisch gesehen würde der Prozess an dieser Stelle stehen bleiben, da der Token keinen gültigen Weg findet. Um diesen Fehler zu verhindern, bietet BPMN den sogenannten Default Flow (Standardfluss).

Du erkennst diesen Pfad an einem kleinen Schrägstrich (Slash), der quer durch den Anfang des Pfeils verläuft. Dieser Weg fungiert als "Auffangbecken". Er wird vom Gateway immer dann gewählt, wenn alle anderen spezifischen Bedingungen "Falsch" sind. Er steht sinngemäß für "Ansonsten". Es ist guter Stil, bei XOR-Splits diesen Notausgang zu definieren, um technische Fehler in der Prozessausführung sicher abzufangen.

Der Join: Einfaches Durchleiten

Wenn du das XOR-Gateway nutzt, um verschiedene Pfade wieder zusammenzuführen (Merge), verhält es sich technisch sehr simpel. Da durch die exklusive Natur des Splits ohnehin nur ein einziger Token auf einem der Pfade unterwegs sein kann, muss das Gateway am Ende auf niemanden warten. Es gibt hier keine Synchronisation.

Sobald ein Token aus einem der eingehenden Pfade das Gateway erreicht, wird er sofort und ohne Verzögerung zum Ausgang weitergeleitet. Das Gateway dient an dieser Stelle also rein der optischen Zusammenführung, um den Prozessfluss wieder auf eine gemeinsame Linie zu bringen.

Während wir beim XOR-Gateway immer vor einer Wahl standen, schalten wir beim Parallelen Gateway (Parallel Gateway) in den Modus der Gleichzeitigkeit. In der betrieblichen Praxis laufen viele Dinge nicht strikt nacheinander ab, sondern unabhängig voneinander. Wenn ein neuer Mitarbeiter eingestellt wird, muss die IT-Abteilung den Laptop vorbereiten, während die Personalabteilung gleichzeitig den Arbeitsvertrag archiviert. Da diese Aufgaben nicht aufeinander warten müssen, nutzen wir hier das parallele Gateway. Du erkennst es an dem Plus-Zeichen (+) im Inneren der Raute.

Der Split: Vervielfältigung des Tokens

Wenn wir dieses Gateway nutzen, um einen Pfad aufzuteilen, geschieht technisch etwas Faszinierendes: Der Prozess-Token wird vervielfältigt. Sobald der Token am Eingang ankommt, werden alle ausgehenden Pfade gleichzeitig aktiviert. Das Gateway klont den ankommenden Token für jeden einzelnen Ausgang .

Das bedeutet, dass ab diesem Moment mehrere Tokens gleichzeitig im Prozess unterwegs sind. Da das Gateway bedingungslos alle Wege beschreitet, ist es ein grober Fehler, an die ausgehenden Sequenzflüsse Bedingungen zu schreiben (wie "Nur wenn X"). Das Gateway würde solche Beschriftungen ignorieren, da es technisch gar nicht in der Lage ist, Pfade zu blockieren. Der Fluss geht immer überall weiter.

Der Join: Die Synchronisation

Die eigentliche technische Stärke des Parallelen Gateways liegt in der Zusammenführung. Hier fungiert es nicht als einfacher Trichter, sondern als intelligentes Wartezimmer. Wenn wir Aufgaben parallel gestartet haben, wollen wir den Prozess meist erst dann fortsetzen, wenn wirklich alle Teilaufgaben erledigt sind. Wir können den Prozess nicht abschließen, solange der Laptop noch fehlt oder der Vertrag nicht unterschrieben ist.

Das AND-Gateway realisiert hier das Prinzip der Synchronisation. Wenn der erste Token aus einem der Pfade ankommt, wird er vom Gateway festgehalten. Der Prozess wartet an dieser Stelle. Erst wenn auf allen eingehenden Sequenzflüssen ein Token eingetroffen ist, öffnet sich die Schranke. Das Gateway verschmilzt die wartenden Tokens wieder zu einem einzigen Token und schickt diesen auf die Reise zum nächsten Schritt .

Achtung: Die Gefahr des "Deadlock"

Diese Synchronisations-Logik birgt ein Risiko, das jeden Anfänger früher oder später trifft: den Deadlock. Da das AND-Gateway stur darauf wartet, dass auf jedem Eingang ein Token erscheint, friert der Prozess ein, sobald auch nur einer fehlt.

Stell dir vor, du führst zwei Pfade zusammen. Auf dem oberen Pfad gab es jedoch weiter vorne eine XOR-Entscheidung, bei der der Token "falsch" abgebogen ist und diesen Zweig nie erreicht hat. Das Parallele Gateway am Ende weiß davon nichts. Es wartet ewig auf den Token, der niemals kommen wird. Der Prozess bleibt technisch stehen und kann nicht beendet werden. Eine eiserne Regel für saubere Modellierung lautet daher: Nutze einen AND-Join nur dann, wenn du absolut sicherstellen kannst, dass alle eingehenden Pfade auch tatsächlich aktiv sind .

Manchmal ist die Geschäftswelt nicht schwarz-weiß wie beim XOR (Entweder-Oder) und auch nicht immer totalitär wie beim AND (Alles muss passieren). Oft bewegen wir uns in Grauzonen, in denen wir flexibel bleiben müssen.

Stell dir einen Check-Out-Prozess im Online-Shop vor. Ein Kunde kauft ein Produkt. Zusätzlich könnte er eine Versicherung dazu buchen. Er könnte auch eine Geschenkverpackung wählen. Vielleicht wählt er beides, vielleicht keines von beiden. Für genau solche Szenarien, bei denen eine oder mehrere Optionen zutreffen können, nutzen wir das Inklusive Gateway (Inclusive Gateway). Du erkennst es an dem Kreis (O) im Inneren der Raute.

Der Split: Einer, mehrere oder alle

Das OR-Gateway funktioniert wie eine intelligente Kombination aus den beiden vorherigen Typen. Jeder ausgehende Pfad besitzt eine Bedingung, genau wie beim XOR. Der entscheidende Unterschied ist jedoch: Diese Bedingungen werden unabhängig voneinander geprüft.

Wenn der Token am Eingang ankommt, bewertet das Gateway alle Bedingungen gleichzeitig. Ist Bedingung A wahr? Dann wird ein Token diesen Weg geschickt. Ist Bedingung B auch wahr? Dann wird zusätzlich ein zweiter Token diesen Weg geschickt. Es werden also so viele Tokens erzeugt, wie Bedingungen zutreffen. Das können einer, zwei oder alle sein.

Da es theoretisch möglich ist, dass keine der Bedingungen zutrifft, würde der Prozess in diesem Fall stehenbleiben. Deshalb ist es auch beim OR-Gateway eine wichtige Best Practice, immer einen Default Flow (den Pfad mit dem Strich) zu definieren, der greift, wenn keine der spezifischen Bedingungen erfüllt ist .

Der Join: Die intelligente Synchronisation

Das Zusammenführen ist beim OR-Gateway technisch die größte Herausforderung und unterscheidet gute Process Engines von schlechten. Das Gateway muss nämlich "wissen", worauf es warten soll.

Erinnern wir uns: Das AND-Gateway wartet stur auf alle Eingänge. Das XOR-Gateway wartet auf gar keinen und leitet sofort weiter. Das OR-Gateway hingegen wartet auf alle Tokens, die tatsächlich unterwegs sind. Es schaut quasi flussaufwärts und prüft: "Welche Pfade wurden beim Split aktiviert?".

Wenn beim Split drei Wege möglich waren, aber nur zwei aktiviert wurden, wartet der Join am Ende geduldig auf genau diese zwei Tokens. Den dritten Pfad ignoriert er, weil er weiß, dass dort nichts kommen wird. Sobald alle aktiven Tokens eingetroffen sind, verschmilzt das Gateway sie wieder zu einem einzigen Token und lässt den Prozess weiterlaufen . Diese Fähigkeit, "tote" Pfade zu ignorieren und nur auf aktive zu warten, macht das OR-Gateway extrem mächtig, aber auch komplex in der technischen Umsetzung.

Bisher haben wir den Weg immer basierend auf Daten gewählt ("Ist der Betrag > 100€?"). Die Entscheidung fiel also sofort, wenn der Token das Gateway erreichte. Aber was passiert, wenn wir den weiteren Weg nicht von Daten abhängig machen wollen, sondern davon, was als Nächstes in der Welt passiert?

Hier kommt das Ereignisbasierte Gateway (Event-Based Gateway) ins Spiel. Du erkennst es an der Raute, in der das Symbol eines Zwischenereignisses (ein doppelter Kreis mit einem Fünfeck) abgebildet ist .

Die Logik: Wer zuerst kommt, mahlt zuerst

Dieses Gateway funktioniert völlig anders als die bisherigen. Stell es dir wie den Startschuss zu einem Wettrennen vor. Wenn der Prozess-Token am Gateway ankommt, trifft er keine Entscheidung. Er wartet.

An den ausgehenden Pfaden hängen in diesem Fall keine Aktivitäten, sondern zwingend Ereignisse (oder Empfangs-Tasks). Das Gateway lauscht nun auf diese Ereignisse.

• Weg A: Wir erhalten eine Nachricht vom Kunden.

• Weg B: Ein Timer von 7 Tagen läuft ab.

Der Token bleibt im Gateway liegen, bis eines dieser Ereignisse eintritt. Das Ereignis, das zuerst passiert, gewinnt das Rennen. Der Token läuft diesen Weg weiter, und alle anderen wartenden Pfade werden sofort deaktiviert .

Dieses Muster ist extrem wichtig für robuste Prozesse. Es verhindert, dass ein Prozess ewig auf eine Antwort wartet, indem es einen zeitlichen "Notausgang" (Timeout) bietet.

Der Vollständigkeit halber müssen wir kurz über das Komplexe Gateway sprechen (Raute mit einem Sternchen *). In der Praxis wirst du es selten brauchen, aber du solltest wissen, dass es existiert.

Es wird für komplizierte Szenarien genutzt, die sich mit den Standard-Logiken (XOR, AND, OR) nicht abbilden lassen. Ein klassisches Beispiel ist das Diskriminator-Muster: Du startest drei Aufgaben parallel, willst den Prozess aber fortsetzen, sobald die erste davon fertig ist – die anderen beiden sollen ignoriert werden . Da dieses Verhalten schwer zu lesen ist, empfiehlt es sich meistens, den Prozess zu vereinfachen, anstatt dieses Symbol zu nutzen.

Du kennst jetzt die Symbole. Aber wie setzt du sie so ein, dass dein Modell professionell aussieht und nicht wie "Spaghetti mit Kästchen"? Hier sind drei goldene Regeln aus dem "Method & Style"-Ansatz.

1. Vermeide implizite Splits

BPMN erlaubt es technisch, einfach zwei Pfeile aus einer Aufgabe zu ziehen, ohne ein Gateway dazwischen zu setzen. Das nennt man einen "impliziten Split" (es verhält sich meist wie ein AND). Tu das nicht. Es ist schlechter Stil, weil der Leser raten muss: "Ist das jetzt ein Oder? Ein Und?". Setze immer ein Gateway, wenn sich ein Pfad teilt. Das macht die Logik explizit und unmissverständlich .

2. Balanciere deine Gateways (Symmetrie)

Versuche, deine Modelle symmetrisch zu halten. Wenn du einen Prozess mit einem XOR-Gateway teilst, versuche ihn idealerweise auch mit einem XOR-Gateway wieder zusammenzuführen. Wenn du mit einem AND teilst, führe mit einem AND zusammen. Natürlich gibt es Ausnahmen (z. B. wenn ein Pfad in einem End-Ereignis endet und nicht zurückkehrt), aber als Grundregel hilft Symmetrie dem Auge, der Struktur zu folgen.

3. Nutze den Default Flow beim XOR/OR

Wir haben es oben schon kurz erwähnt, aber es ist wichtig genug für eine Wiederholung: Wenn du ein Gateway nutzt, das Bedingungen prüft (XOR oder OR), definiere immer einen Default Flow (den Pfad mit dem kleinen Strich). Das ist dein technischer "Notausgang". Er verhindert, dass der Prozess abstürzt, wenn durch einen Datenfehler keine der definierten Bedingungen zutrifft .

Damit hast du das Rüstzeug, um jeden Prozessfluss logisch zu steuern. Hier ist dein Spickzettel für die tägliche Arbeit: