Prozessmodellierung mit BPMN: vom Diagramm zum laufenden Prozess

Prozessmodellierung mit BPMN endet nicht mit dem Diagramm, denn das Diagramm wird nie ausgeführt. Ausgeführt wird eine Graphstruktur, die beim Deployment aus dem XML gebaut wird: „The XML files are parsed and transformed into a process definition graph structure. This graph structure is executed by the process engine.“ (Camunda-7.24-Handbuch, Process Engine Concepts) Zwischen dem Bild, das im Workshop abgenommen wird, und dem, was in Produktion läuft, liegt also eine Übersetzung. Dort entstehen die Abweichungen, um die es in diesem Artikel geht.

Dass ein BPMN-Modell nicht schon deshalb läuft, weil es gültiges BPMN ist, steht in Was ist BPMN?. Hier geht es darum, woran es scheitert. Es fehlt eine Transaktionsgrenze, eine Bedingung hängt an einer Kante, an der sie niemand auswertet, ein Standardpfad fehlt, oder es fehlt eine Pflichtangabe, die nirgends im Bild steht. Alle vier Fälle stehen unten, jeweils in Camundas eigenem Wortlaut.

Was ändert sich an Ihrer Prozessmodellierung, wenn eine Engine das Modell ausführt?

Ausgeführt wird nicht das Bild, sondern der Graph aus dem XML. Was nicht im XML steht, existiert für die Engine nicht, und was im XML steht, aber nicht gezeichnet wird, wirkt trotzdem.

Die nächste Überraschung betrifft die Bauform der Engine selbst: „The process engine is a piece of passive Java code which works in the Thread of the client.“ (Camunda 7.24, Transactions in Processes) Von sich aus treibt die Engine kein Diagramm voran. Sie leiht sich den Thread desjenigen, der sie aufruft, arbeitet den Prozess ab, bis auf jedem aktiven Pfad ein Wartezustand erreicht ist, und gibt die Kontrolle zurück. Eigene Threads hat nur der Job Executor, und was der tut, steht weiter unten.

Das Token ist dabei ein Bild und kein Objekt. Die Seite zu den Engine-Konzepten schreibt: „While an execution can be imagined as a token moving through the process, an activity instance represents an individual instance of an activity (task, subprocess, …).“ Was existiert, ist die Execution, ein Datensatz, und pro aktiven Pfad legt die Engine einen an.

Wo bleibt ein Prozess stehen, und warum genau dort?

An einem Wartezustand. Ob ein Element einer ist, hängt vom Elementtyp ab und nicht von der Modellierung. Camunda beschreibt ihn als Aufgabe, die später erledigt wird; die Engine schreibt dabei den aktuellen Stand der Execution in die Datenbank und wartet darauf, erneut angestoßen zu werden: „persists the current execution to the database and waits to be triggered again“. Diese Punkte sind gleichzeitig die Transaktionsgrenzen: „We talked about wait states as transaction boundaries where the process state is stored to the database, the thread returns to the client and the transaction is committed.“ (Transactions in Processes) Zustand speichern, Thread zurückgeben, Transaktion bestätigen, an einer Stelle, die im Diagramm wie jede andere aussieht.

Die zweite Spalte ist kein Detail für Korrekturleser. Receive Task und User Task stehen dort nur als Beschriftung in einer eingebetteten SVG-Grafik. Wer die Seite in eine Leseansicht überführt oder ihren Text ohne die Grafiken übernimmt, verliert genau diese beiden Einträge.

Warum liegt eine Transaktionsgrenze dort, wo im Bild nichts steht?

Weil man sie dorthin setzen kann und sie unsichtbar bleibt. Der Übergang von einem Wartezustand zum nächsten ist laut der Camunda-Seite zu Transaktionen immer Teil einer einzigen Transaktion: „The transition from one such stable state to another stable state is always part of a single transaction, meaning that it succeeds as a whole or is rolled back on any kind of exception occuring during its execution.“ Der Tippfehler „occuring“ steht so in der Quelle; wir zitieren ihn unverändert, damit der Satz dort wiederzufinden ist.

Dieselbe Seite ergänzt: „Keep in mind that Asynchronous Continuations can add transaction boundaries to other tasks as well.“ Die Schalter dafür heißen camunda:asyncBefore und camunda:asyncAfter und stehen als Attribute am Element im XML, etwa camunda:asyncBefore="true". Camunda führt sie als Erweiterungsattribute in einem eigenen Namensraum: „The following attributes are extension attributes for the camunda namespace http://camunda.org/schema/1.0/bpmn.“ (Extension Attributes) Zwei Modelle können im Bild identisch aussehen und sich zur Laufzeit vollständig anders verhalten. Die Transaktionsseite nennt diese Attribute selbst das vorgesehene Mittel: „To control the scope of transactions, explicit save points can be added before and after activities using Asynchronous Continuations.“

Vier Folgen davon stehen auf derselben Transaktionsseite und sind im Diagramm nicht abzulesen:

• Ein paralleles Gateway macht ohne asynchrone Fortsetzung nichts parallel. „Parallel process paths are not executed in parallel in terms of Java Threads, the different paths are executed sequentially, since we only have and use one Thread.“
• Ein Timer innerhalb derselben Transaktion feuert nie. „Timers cannot fire before the transaction is committed to the database.“
• Ein Fehler beim Start hinterlässt keine Instanz. „If an exception occurs when calling startProcessInstanceByKey the process instance will not be saved to the database at all.“ Sie suchen im Cockpit nach etwas, das nie existiert hat.
• Ein Rollback nimmt nur Transaktionales zurück. „Non-transactional work like creation of files or the effects of invoking non-transactional web services will not be undone. This can end in inconsistent state.“

Der vierte Punkt berührt die Architektur: Kann zwischen dem Aufruf eines Fremdsystems und dem nächsten Wartezustand noch etwas schiefgehen, wird der Aufruf im Fehlerfall wiederholt, und das Fremdsystem sieht ihn zweimal.

Vor einer Verwechslung warnt Camunda ausdrücklich, und sie betrifft genau das Symbol, das wie eine Transaktion aussieht: „It is important not to confuse the BPMN transaction subprocess with technical (ACID) transactions. The BPMN transaction subprocess is not a way to scope technical transactions.“ (Transaction Subprocess) Der Rahmen im Bild ist eine fachliche Klammer; laut derselben Seite umspannt eine BPMN-Transaktion typischerweise mehrere technische. Die technische Klammer setzen Sie mit den asynchronen Fortsetzungen aus dem Absatz darüber.

Was passiert, während der Prozess wartet?

Eine Datenbankzeile wartet mit. Jeder Timer und jede als asynchron markierte Aufgabe erzeugt laut Camunda einen Job, und dieser Job steht in der Datenbank: „Jobs are persisted to the database, in the ACT_RU_JOB table.“ (Camunda 7.24, The Job Executor) Abgeholt werden diese Zeilen vom Job Executor, und der ist bei einer eingebetteten Engine standardmäßig aus: „When using an embedded process engine, by default, the Job Executor is not activated when the process engine boots.“ Die Timer-Referenz ergänzt: „Timers are only fired when the Job Executor is enabled.“ Ein Modell mit einer Eskalationsfrist lässt sich damit fehlerfrei deployen und eskaliert trotzdem nie; einen Hinweis darauf nennt keine der gelesenen Camunda-Seiten.

Läuft der Job Executor, ist er trotzdem keine Uhr. Ein Fälligkeitsdatum ist laut der Job-Executor-Seite „not a real-time boundary by which the job is guaranteed to be executed“, und eine Backoff-Strategie verdoppelt die Wartezeit, wenn nichts zu tun ist; die Voreinstellung der maximalen Wartezeit gibt Camunda mit 60 Sekunden an. Wer eine Frist auf die Minute genau modelliert, modelliert eine Genauigkeit, die die Engine nicht zusagt.

Auch das Verhalten im Fehlerfall ist voreingestellt und steht nicht im Modell. Zu den Wiederholungsversuchen schreibt die Job-Executor-Seite: „a job will be retried a number of times (by default 2 so that the job is tried three times in total)“, und zum konfigurierten Intervall: „Regardless of the values, the interval is always (at least) 5 minutes.“ Sind die Versuche aufgebraucht, entsteht ein Incident vom Typ failedJob: „The incident indicates that the corresponding execution is stuck and will not continue automatically. Administrative action is necessary.“ (Incidents) Diese Zahlen sind Camundas Angaben über das eigene Produkt und keine Aussage über einen Aufwand. Und laut der Job-Executor-Seite sind asynchrone Fortsetzungen und Timer voreingestellt exklusiv: „All asynchronous continuations and timer events are thus exclusive by default.“ Zwei Zweige derselben Instanz laufen damit im Normalfall nacheinander. Camunda nennt dieses Verhalten auf derselben Seite ausdrücklich eine Heuristik: Sie greift nur für die Jobs, die beim Nachschlagen bereits vorliegen, und ein danach entstehender Job kann „be processed by another job execution thread in parallel“.

Welche Konstrukte führt die Engine aus, und welche zeichnet sie nur?

Camunda führt für Version 7.24 eine eigene Übersicht über die Abdeckung der BPMN-2.0-Elemente. Sie ist rein farblich, und der einzige Satz, der die Einfärbung erklärt, lautet: „The elements marked in orange are supported.“ (BPMN 2.0 Implementation Reference) Im Fließtext nennt die Seite die Rubriken und, in der Ereignistabelle, die Zeilenbeschriftungen, etwa None, Message, Timer, Signal und Error; die Namen der übrigen Symbole stehen dort nur als Beschriftung in eingebetteten SVG-Grafiken. Welche Elemente unterstützt sind, sagt allein die orange Einfärbung, und die überlebt keine Textkopie.

Zwei Zeilen verdienen einen Zusatz. Beim Service Task ist nur eine der beiden Ausführungsarten ein Wartezustand: Der External Task wartet laut Transaktionsseite, der interne Delegate läuft durch, und im Bild ist beides dasselbe Rechteck. Hinter dem ereignisbasierten Gateway darf laut Camunda nur ein intermediateCatchEvent stehen; zu Receive Tasks an dieser Stelle schreibt Camunda: „(Receive Tasks after an event-based Gateway are not supported by the engine yet.)“ (Event-based Gateway) Das Wort „yet“ steht so in der Quelle; wir leiten daraus keine Zusage für die Zukunft ab.

Und es gibt Verhalten ohne Ort im Bild: „Execution Listeners can be attached to any event within the normal token flow, e.g., starting a process instance or entering an activity.“ (Delegation Code) Ein Diagramm, das Sie abnehmen, sagt Ihnen nicht, wie viel Code beim Betreten einer Aktivität ausgeführt wird.

Warum wählt die Engine einen anderen Pfad als den, den Sie im Bild sehen?

Weil sie eine andere Beschriftung liest als Sie. „Gateways control token flow in a process“, schreibt Camunda in der Gateway-Übersicht, und der entscheidende Hinweis steht bei den exklusiven Gateways: „Note that the name of the flow (used in the diagram, meant for the human being) might be different than the formal expression (used in the engine).“ (Exclusive Gateway) Der Name am Pfeil ist für Menschen, die Bedingung ist für die Engine, und niemand prüft, ob beide dasselbe sagen. Ein Pfeil, der im Bild „Betrag über 10 000“ heißt, kann eine Bedingung tragen, die etwas anderes auswertet, und das Modell bleibt gültig.

Zwei weitere Regeln derselben Seite entscheiden über den Pfad. Treffen mehrere Bedingungen zu, gewinnt nicht die im Bild obere: „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.“ Und trifft keine zu: „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.“ Ein Standardpfad entscheidet deshalb darüber, ob der Prozess weiterläuft oder mit einer Ausnahme im Log endet. In der Referenz zum inklusiven Gateway stehen derselbe Fehlerfall („If no condition evaluates to true, an exception is thrown.“) und dasselbe Gegenmittel („This can be prevented by specifying a default outgoing sequence flow.“), während die Zusammenführung dort nur auf die Kanten wartet, auf denen tatsächlich etwas unterwegs ist.

In der Referenz zum parallelen Gateway steht unter der Überschrift „Limitation“ eine Eigenart, die Camunda ausdrücklich der eigenen Umsetzung zuschreibt („in Camunda’s implementation of the parallel gateway“). Die Zusammenführung zählt Token, nicht Kanten: „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.“ Im Klartext heißt das: Kommen zwei Token über dieselbe Kante an, löst die Zusammenführung aus, obwohl die zweite Kante leer geblieben ist.

Einen verwandten Fall spielt Camunda in der eigenen Modellierungsreferenz am Beispiel eines Mittagessens durch, dort allerdings ohne parallele Zusammenführung: mit AND aufgeteilt, ohne AND-Zusammenführung direkt an eine XOR-Zusammenführung geführt, und der nachfolgende Schritt läuft zweimal. „Its token passes through the XOR merge and ‚eat meal‘ executes again!“ (camunda.com/bpmn/reference) Dazu kommt eine Falle aus der Referenz zum Sequence Flow, die gar kein Gateway braucht: „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 aus einem Kästchen sind kein Zeichenfehler, sondern zwei Pfade.

Was steht in einer Bedingung, und wo läuft sie?

Am Pfeil steht ein Text für Menschen; ausgewertet wird ein Ausdruck oder ein Skript: „Currently, conditionalExpressions can be used with UEL and scripts. The expression or script used should resolve to a boolean value, otherwise an exception is thrown while evaluating the condition.“ (Sequence Flow) Ein Ausdruck, der versehentlich etwas anderes als einen booleschen Wert liefert, verzweigt damit nicht falsch, er bricht ab.

Wer darin schreibt, was er aus Java kennt, stößt auf ausdrückliche Grenzen. Camunda listet vier davon unter „Note, compared to EL 4.0 this JUEL implementation has the following limitations:“, darunter Collections-Literale sowie statische Felder, Funktionen und Enums, und außerdem: „Lambda expressions (e.g., inline functions ${((x,y)->x+y)(3,4)}) are NOT supported.“ (Unified Expression Language)

Die zweite Ausdruckssprache ist FEEL, und der Wechsel dorthin ist kein reiner Syntaxwechsel: „In contrast to the Unified Expression Language FEEL does not support Expression language as delegation code and does not provide access to beans and internal context variables.“ Ganz oben auf derselben Seite steht, in einem Warnkasten unter der Überschrift „FEEL Support Limitation“, eine Grenze, die mit dem Modell nichts zu tun hat: „Please note that the WildFly and JBoss application servers do not support FEEL outside of DMN execution in Camunda 7.“ (Friendly Enough Expression Language) Dieselbe Bedingung läuft damit auf einem Applikationsserver und auf einem anderen nicht.

Was hindert ein gültiges Modell daran, überhaupt zu starten?

Eine einzige Angabe, die im Diagramm nicht vorkommt, genügt: „The history time to live is mandatory, any deployment or re-deployment of any model resource (BPMN, DMN, CMMN) that contains a historyTimeToLive of null will be prevented. Unless explicitly disabled via process engine configuration.“ (History cleanup) Ein vollständig gültiges BPMN-Modell wird also beim Deployment abgelehnt, solange diese Prüfung nicht ausdrücklich abgeschaltet ist.

Genau diese Angabe ist auch die einzige, die Camundas eigenes Prüf-Plugin für Camunda 7 kontrolliert. Das Repository camunda/bpmnlint-plugin-camunda-compat trägt auf api.github.com die Beschreibung „A bpmnlint plug-in for Camunda BPMN compatibility.“ Es ist nicht archiviert, steht unter der MIT-Lizenz und wurde zuletzt am 28. August 2026 bewegt; Beschreibung, Archivstatus, Lizenz und Änderungszeitpunkt wurden am 2. September 2026 über die GitHub-API geprüft. In der Konfiguration camunda-platform-7-24 in index.js steht genau eine Regel, „history-time-to-live“, und im Ordner rules/camunda-platform liegt genau eine Datei. Die übrigen Regeldateien liegen unter rules/camunda-cloud und gehören zu den camunda-cloud-Konfigurationen, also zur Camunda-8-Linie.

Alles andere in diesem Artikel prüft das Plugin für Camunda 7 nicht: keine Regel zu fehlenden Standardpfaden, zu Bedingungen an den falschen Kanten, zu Wartezuständen oder zu asynchronen Fortsetzungen. Und unter den Seiten, die wir für diesen Artikel gelesen haben, zählt keine auf, was ein gültiges Modell zusätzlich braucht; die Angaben verteilen sich über Referenz, Handbuch, Erweiterungsattribute und History-Konfiguration.

Was heißt das für Ihre Prozessmodellierung?

Sechs Punkte, jeder aus einem Zitat oben abgeleitet und keiner darüber hinaus.

1. Den Standardpfad auch am inklusiven Gateway setzen, nicht nur am exklusiven. Trifft keine Bedingung zu, ist das laut Camunda an beiden eine Ausnahme zur Laufzeit.
2. Bedingungen dort lesen, wo sie ausgewertet werden. Maßgeblich sind die Reihenfolge im XML und der Ausdruck, nicht die Reihenfolge im Bild und nicht die Beschriftung.
3. Keine Bedingung an eine Kante hängen, an der sie niemand auswertet. Am parallelen Gateway und auf dem Standardpfad bleibt sie wirkungslos, und niemand meldet das.
4. Vor jedem Aufruf eines Fremdsystems entscheiden, wo die Transaktion endet. Ein Rollback nimmt den Aufruf nicht zurück.
5. Im eingebetteten Betrieb prüfen, ob der Job Executor eingeschaltet ist, bevor ein Timer ins Modell kommt. Sonst ist die Frist gezeichnet und feuert nie.
6. historyTimeToLive setzen, bevor das Modell zum Deployment geht. Es ist die einzige Regel, die Camundas Prüf-Plugin für Camunda 7 kennt.

Was hier fehlt, fehlt mit Absicht. Keine der gelesenen Camunda-Seiten nennt eine Faustregel dafür, wie viele asynchrone Fortsetzungen ein Modell haben sollte, und keine beziffert die Wirkung: kein Durchsatz, keine Latenz, nur die qualitative Aussage der Transaktionsseite „The execution is plain Java computing which is very efficient in terms of performance.“ Und wie häufig diese Fehler sind, sagen wir nicht; dazu gibt es keine Statistik, und wir zählen keine fremden Modelle.

Mit welchem Symbolvorrat Sie in der Praxis auskommen, steht in BPMN 2.0: die Elemente, die Sie tatsächlich brauchen. Der Artikel beschränkt sich auf das, was eine Engine ausführt.