BPMN 2.0: die Elemente, die Sie tatsächlich brauchen

Welche Elemente aus BPMN 2.0 ein ausführbares Modell braucht, beantwortet die Spezifikation selbst: Die Teilmenge Common Executable listet in Tabelle 2.3 genau 22 Einträge, darunter Sequenzfluss, Teilprozess, exklusives, paralleles und ereignisbasiertes Gateway, leeres Start- und Endereignis, Benutzer- und Serviceaufgabe sowie Aufrufaktivität. Die zweite Hälfte der Frage ist die interessantere: Welche Elemente aus der Spezifikation führt Ihre Engine nicht aus? Für Camunda 7 steht die Antwort auf einer einzigen Seite, der Implementierungsreferenz für Version 7.24: „This page gives you an overview of the BPMN 2.0 elements and the current coverage of the process engine.“ (docs.camunda.org, BPMN 2.0 Implementation Reference) Maßgeblich für das, was auf Ihrem Server läuft, ist diese Seite und nicht die Spezifikation.

In dieser Referenz ist „unterstützt“ eine Farbe und kein Satz. Die Seite schreibt dazu eine einzige Zeile: „The elements marked in orange are supported.“ Die Zeichenkette „not supported“ kommt im Text der Seite kein einziges Mal vor. Die Übersichtsseite markiert, was unterstützt ist, und sagt über kein Element das Gegenteil; wo Camunda eine Einschränkung ausspricht, steht sie auf einer Unterseite. Das klingt nach einer Feinheit und ist der Unterschied zwischen einer belegbaren und einer erfundenen Aussage.

Für Datenobjekt, Datenspeicher, Gruppe, Textanmerkung, undefinierte Aufgabe und komplexes Gateway gibt es in der Referenz nicht einmal eine Unterseite. Die Navigation der Referenz gliedert sich in Ereignisse, Gateways, Teilprozesse, Aufgaben und die Camunda-Erweiterungen; einen Zweig für Daten und Artefakte hat sie nicht. Bei den erwartbaren Unterseiten unter docs.camunda.org/manual/7.24/reference/bpmn20, etwa /data/data-object/, /artifacts/group/ und /gateways/complex-gateway/, antwortet der Server am 2. September 2026 mit einer Weiterleitung auf die Startseite des Handbuchs. Der Status dieser Elemente ergibt sich ausschließlich aus der fehlenden Farbe auf der Übersichtsseite.

Wie viele BPMN-2.0-Symbole gibt es, und welche führt Camunda 7 aus?

Eine Gesamtzahl nennt keine der beiden Quellen; zählbar ist nur, was auf Camundas Abdeckungsseite für 7.24 gezeichnet und markiert ist. Wir haben die Markierungen am 2. September 2026 im Seitenquelltext ausgezählt, und zwar so: 24 Symbolkacheln, davon 17 mit der Markierungsklasse am Kachelrahmen, und darunter eine Ereignismatrix mit 13 Ereigniszeilen, von denen 11 mindestens eine orange markierte Zelle tragen. Zehn dieser Zeilen sind als ganze Zeile markiert, die Zeile „Conditional“ nur Zelle für Zelle. Die Schleifenmarkierung fällt aus dieser Zählung heraus: Die Seite zeichnet sie im Abschnitt „Tasks“ mit, gibt ihr aber keinen eigenen Kachelrahmen, und an den Kacheln lässt sich ihr Status deshalb nicht ablesen.

Welche Elemente markiert Camunda 7.24 nicht als unterstützt?

Sieben der 24 Symbolkacheln tragen kein Orange, dazu zwei der 13 Zeilen in der Ereignismatrix. Die folgende Tabelle listet sie auf und zeigt daneben, ob die Referenz zu dem jeweiligen Element überhaupt einen Satz schreibt. In acht von neun Fällen tut sie das nicht.

Aus dieser Tabelle folgt genau ein belegbarer Satz: Die Referenz markiert das Element nicht als unterstützt. Wer daraus „Camunda führt das nicht aus“ macht, hat die Quelle verlassen, denn dieser Satz steht dort nirgends. Für die instanziierende Empfangsaufgabe liegt der Fall anders, weil Camunda auf der Unterseite zum ereignisbasierten Gateway tatsächlich etwas dazu schreibt.

Die Schleifenmarkierung ist der Fall, den die Kacheln gar nicht abbilden, und Camunda klärt ihn in Prosa. Auf der Seite „Task Markers“ steht: „The loop marker is not natively supported yet by the engine.“ Dieselbe Seite ergänzt: „Be assured that we have the loop marker in our backlog to be added to the engine.“ Dieser Satz nennt weder eine Version noch ein Datum, und er ist überholt. Camunda schreibt auf seiner Ankündigungsseite: „Camunda 7.24 LTS (Long Term Support) is the last minor release of Camunda 7. No new feature-adding releases of Camunda 7 will be built anymore.“ Was im Backlog steht, kann in Camunda 7 also nicht mehr ausgeliefert werden. Wer eine Schleife braucht, modelliert sie im Diagramm aus.

„Und“ oder „oder“ in BPMN: was unterscheidet die Rauten zur Laufzeit?

Für die drei Rauten, die „und“ und „oder“ ausdrücken, ist die Frage auf der Ebene der Symbole schnell beantwortet: Kreuz, Plus, Kreis. Die vierte Raute, die ereignisbasierte, gehört nicht in diese Reihe, weil sie keine Bedingungen auswertet, sondern auf Ereignisse wartet; die Tabelle darunter nimmt sie mit auf, denn Camundas Implementierungsreferenz für 7.24 markiert auch sie als unterstützt. Worauf es ankommt, ist, was die Engine beim Teilen und beim Zusammenführen mit den Pfaden tut. Camunda dokumentiert das je Gateway-Typ auf einer eigenen Referenzseite für 7.24.

Exklusiv: die Reihenfolge in der XML-Datei entscheidet, nicht die im Bild

Camunda schreibt auf der Seite zum exklusiven Gateway: „In case multiple sequence flow have a condition that evaluates to ‚true‘, the first one defined in the XML is exclusively selected for continuing the process.“ Maßgeblich ist damit allein die Reihenfolge in der XML-Datei; die Anordnung der Pfeile im Bild sagt darüber nichts aus. Trifft dagegen gar keine Bedingung zu, wird es unangenehmer: „If no sequence flow can be selected (no condition evaluates to ‚true‘) this will result in a runtime exception, unless you have a default flow defined.“

Parallel: die Zusammenführung zählt Token

Die Seite zum parallelen Gateway grenzt ausdrücklich ab: „An important difference with other gateway types is that the parallel gateway does not evaluate conditions.“ Eine Bedingung an einer UND-Raute ist damit reine Dekoration, sichtbar im Bild und wirkungslos in der Engine. Die zweite Eigenheit steht auf derselben Seite unter der Überschrift „Limitation“, und Camunda kennzeichnet sie als eigene Umsetzung: Die Zusammenführung löst aus, sobald so viele Token angekommen sind, wie es eingehende Sequenzflüsse gibt. „Note that in Camunda’s implementation of the parallel gateway, the gateway triggers as soon as the following holds: The number of arrived tokens is equal to the number of incoming sequence flows. It is not required that a token arrives on every incoming flow.“ Zwei Token über denselben eingehenden Pfad erfüllen die Bedingung also genauso wie je eines über zwei Pfade.

Inklusiv: Camunda dokumentiert selbst eine Abweichung von der Spezifikation

Auf der Seite zum inklusiven Gateway steht zur Zusammenführung: „all concurrent executions arriving at the inclusive gateway wait at the gateway until an execution has arrived for each of the incoming sequence flows that have a process token“, und dazu: „This is an important difference to the parallel gateway.“ Auch hier gilt: „If no condition evaluates to true, an exception is thrown. This can be prevented by specifying a default outgoing sequence flow.“ Für das letzte der vier Beispiele auf dieser Seite nennt Camunda eine Abweichung offen beim Namen: Dort wartet ein zweites, zusammenführendes inklusives Gateway, bis die vorgelagerte Aufgabe abgeschlossen ist und der zweite Token ankommt, und löst deshalb nur einmal statt zweimal aus, obwohl Camunda im selben Absatz schreibt: „According to the BPMN 2.0 specification, since both tokens pass the same sequence flow (true), the inclusive gateway should trigger twice.“ Im Beispiel davor, in dem dieses zweite Gateway fehlt, löst die Raute nach Camundas eigener Beschreibung zweimal aus. Für das Beispiel mit dem zweiten Gateway empfiehlt Camunda deshalb eine andere Raute: „In cases like this one, it is recommended to use an Exclusive Gateway“.

Ereignisbasiert: nur empfangende Zwischenereignisse dahinter

Die Seite zum ereignisbasierten Gateway nennt drei Einschränkungen, und eine davon erklärt eine Kachel aus der Tabelle oben: „An event-based Gateway may only be followed by elements of the type intermediateCatchEvent. (Receive Tasks after an event-based Gateway are not supported by the engine yet.)“ Dazu kommt: „An event-based Gateway must have two or more outgoing sequence flows.“ Und die Pfeile hinter dieser Raute sind keine gewöhnlichen: „These sequence flows are never actually ‚executed‘.“ Sie legen nur fest, auf welche Ereignisse die Instanz wartet.

Warum läuft eine Instanz doppelt weiter, wenn eine Raute fehlt?

Weil BPMN 2.0 ohne Raute parallel ist. Camunda formuliert es auf der Seite zum Sequenzfluss als Grundregel: „After an element is visited during process execution, all outgoing sequence flows are followed. This means that the default nature of BPMN 2.0 is to be parallel: two outgoing sequence flows will create two separate, parallel paths of execution.“ Zwei Pfeile an einer Aufgabe erzeugen damit zwei Wege, die beide weiterlaufen. Bedingungen an diesen Pfeilen ändern daran weniger, als das Bild vermuten lässt: „When multiple sequence flows are selected that way, multiple executions will be generated and the process is continued in a parallel way.“ Eine Bedingung filtert also, sie entscheidet nicht. Wer genau einen Weg will, braucht die exklusive Raute.

Der Standardpfad ist dabei nicht auf Rauten beschränkt. Auf derselben Seite steht: „All BPMN 2.0 tasks and gateways can have a default sequence flow. This sequence flow is only selected as the outgoing sequence flow for that activity if none of the other sequence flows could be selected. Conditions on a default sequence flow are always ignored.“ Der letzte Halbsatz spart in Reviews Zeit: Wer auf dem Standardpfad zusätzlich eine Bedingung notiert, hat damit nichts abgesichert.

Was macht Camunda 7 mit einem BPMN-Datenobjekt oder einem Datenspeicher?

Die Spezifikation nennt das Datenobjekt das zentrale Konstrukt für Daten im Prozessfluss: „The primary construct for modeling data within the Process flow is the DataObject element.“ Im selben Dokument steht aber auch, dass die Verbindung zwischen Aufgabe und Datenobjekt keinen Token trägt: „Tokens do not flow along a Data Association, and as a result they have no direct effect on the flow of the Process.“ Der Datenspeicher bezeichnet etwas anderes, nämlich Daten, die länger leben als der Prozess: „A DataStore provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process.“ (BPMN 2.0.2, PDF der Object Management Group)

Camundas Referenz für 7.24 markiert beide nicht als unterstützt und hat zu beiden keine eigene Seite. Die Daten einer laufenden Instanz liegen in Camunda 7 in Prozessvariablen, und das Handbuch beschreibt sie, ohne ein einziges BPMN-Datensymbol zu nennen: „Variables can be used to add data to process runtime state or, more particular, variable scopes.“ (docs.camunda.org, Process Variables) Die Begriffe „data object“ und „data store“ kommen auf dieser Seite am 2. September 2026 kein einziges Mal vor. Ein Datenobjekt im Diagramm ist damit Dokumentation: Es zeigt einem Leser, welche Daten an dieser Stelle gemeint sind. Wer erwartet, dass daraus eine Prozessvariable entsteht, stützt sich auf nichts, was in einer der beiden Quellen steht.

Wozu dienen BPMN-Gruppe und Textanmerkung?

Beide sind Artefakte, und die Spezifikation äußert sich zu beiden ausdrücklich. Zur Gruppe: „The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally.“ Zur Textanmerkung: „The Text Annotation object can be connected to a specific object on the Diagram with an Association, but does not affect the flow of the Process.“ (BPMN 2.0.2, PDF der Object Management Group) Camundas Referenz für 7.24 markiert beide nicht als unterstützt. Anders als beim Datenobjekt ist das hier folgenlos: Ein Element, das den Ablauf des Prozesses nach eigener Definition nicht verändert, muss eine Engine auch nicht ausführen. Gruppe und Textanmerkung dürfen in Ihren Modellen bleiben. Beide machen ein ausführbares Diagramm für Menschen lesbarer, ohne dass sich an der Ausführung etwas ändert.

Wo ist Camunda 7 enger als BPMN 2.0, und wo breiter?

Die Spezifikation kennt selbst eine Teilmenge für ausführbare Modelle: „Common Executable focuses on what is needed for executable process models.“ (BPMN 2.0.2, PDF der Object Management Group) Die Elemente dieser Teilmenge stehen in Tabelle 2.3, die zugehörigen Hilfsklassen in Tabelle 2.4. Der Abgleich mit Camundas Abdeckungsseite läuft in beide Richtungen.

Ein Konformitätsvorwurf lässt sich daraus nicht konstruieren, und der Grund steht in der Spezifikation selbst: Die Konformitätsklassen richten sich an Werkzeuge, nicht an Engines. Zur Teilmenge Common Executable heißt es „This conformance sub-class is intended for modeling tools that can emit executable models.“, und zur Konformität allgemein: „For a tool to claim support for a sub-class the following criteria MUST be satisfied: All the elements in the sub-class MUST be supported.“ (BPMN 2.0.2, PDF der Object Management Group) Camunda 7 verfehlt hier keine Konformitätsklasse, weil es gar nicht deren Adressat ist. Die Gegenüberstellung zeigt etwas Nützlicheres: Welchen Umfang Sie brauchen, steht in der Referenz Ihrer Engine.

Drei Stellen, an denen die Engine zusätzliche Regeln aufstellt

• Der Teilprozess braucht ein Start- und ein Endereignis. „Note that the BPMN 2.0 specification allows to omit the start and end events in a subprocess, but the current engine implementation does not support this.“ Dazu: „A subprocess can only have one none start event, no other start event types are allowed.“ (Seite „Embedded Subprocess“)
• Ein Nachrichten-Startereignis gibt es nur auf oberster Ebene. „Message start events are only supported in top-level processes. Message start events are not supported in embedded sub processes.“ (Seite „Message Events“)
• Beim Transaktions-Teilprozess benennt Camunda selbst eine Lücke zur Spezifikation. „The BPMN specification requires that the process engine reacts to events issued by the underlying transaction protocol …“, und dann: „As an embeddable engine, the Camunda engine currently does not support this.“ Dieselbe Seite warnt zusätzlich vor einer Verwechslung: „It is important not to confuse the BPMN transaction subprocess with technical (ACID) transactions.“ (Seite „Transaction Subprocess“)

Welche Elemente sehen nach Arbeit aus und sind keine?

Vier Elemente sehen im Diagramm nach einem Ausführungspunkt aus und sind keiner. Die Belege stehen in der Referenz für 7.24 und in der Spezifikation.

• Die manuelle Aufgabe. „For the engine, a manual task is handled as a pass-through activity, automatically continuing the process when the process execution arrives at it.“ (Seite „Manual Task“) Die Spezifikation 2.0.2 sagt dasselbe: „This is a conceptual model only; a Manual Task is never actually executed by an IT system.“ (BPMN 2.0.2, PDF der Object Management Group)
• Das leere Zwischenereignis. „The engine itself doesn’t do anything in the event, it just passes through it.“ Der Satz steht auf der Seite „None Events“ unter der Überschrift „Intermediate None Event (throwing)“ und gilt dem werfenden Zwischenereignis, nicht dem leeren Start- oder Endereignis.
• Das Link-Ereignis. „Link events are a special case - it has no special execution semantics but serves as a ‚GoTo‘ to another point in the same process model (to be precise: in the same sub process).“ (Seite „Link Events“)
• Die Sendeaufgabe. „The Send Task has the same behavior as a Service Task.“ (Seite „Send Task“) Das Umschlagsymbol ändert für die Engine nichts; es ändert, was ein Leser erwartet.

Wo widerspricht sich Camundas eigene Dokumentation?

An einer Stelle, die man leicht als vollständige Liste zitiert. Die Seite zum Ereignis-Teilprozess nennt fünf auslösende Startereignisse: „Event subprocesses triggered using an Error Start Event, Signal Start Event, Compensation Start Event, Timer Start Event and Message Start Event are supported.“ Die Abdeckungsmatrix auf der Übersichtsseite markiert in den Spalten zum Ereignis-Teilprozess dagegen auch Eskalation und Bedingung orange.

Die beiden Detailseiten stützen die Matrix. Zur Eskalation: „An escalation start event can only be used to trigger an event sub-process - it cannot be used to start a process instance.“ (Seite „Escalation Events“) Zur Bedingung: „Similar to conditional boundary events, conditional start events for event sub process can be interrupting and non interrupting.“ (Seite „Conditional Events“) Vier Seiten desselben Handbuchs, zwei verschiedene Antworten. Wer die fünf zitiert, sollte sie nicht als vollständige Liste weitergeben und immer die Seite nennen, aus der das Zitat stammt.

Zwei Artikel schließen an. Was BPMN als Notation festlegt und was ausdrücklich nicht dazugehört, steht in Was ist BPMN? Wie aus einem abgenommenen Diagramm ein Prozess wird, der auf einer Engine läuft, steht in Prozessmodellierung mit BPMN.