Camunda-7-Migration: was Ihr Bestand entscheidet

Wohin eine Camunda-7-Migration führen kann, entscheidet Ihr Bestand, nicht der Vergleich der Zielprodukte. Vier Eigenschaften Ihrer Installation legen fest, welche Ziele offen bleiben und welche ausscheiden: die Bauform der Engine, die Transaktionsgrenze zwischen Engine und Fachcode, der Anteil Ihres Java-Codes an der Camunda-7-API und die Stellen, an denen dieser Code die öffentliche API umgeht.

Camunda schreibt das selbst in der eigenen Migrationsanleitung: „It is not sufficient to exchange a library; you might have to adjust your BPMN models, refactor code, and probably also re-architect your solution. This effort greatly depends on how your existing Camunda 7 solution is built.“ (docs.camunda.io, Migrating from Camunda 7)

Dieser Artikel vergleicht deshalb keine Produkte. Er nennt die vier Eigenschaften, jeweils mit dem Artefakt, an dem Sie sie in Ihrem eigenen Repository ablesen, und mit der Feststellung, die daraus folgt. Er wiederholt die Produktvergleiche nicht, sondern erhebt den Befund, aus dem sich ein Vergleich überhaupt erst lesen lässt. Alle vier Feststellungen können Sie heute treffen, ohne mit jemandem zu sprechen.

Warum entscheidet der Bestand und nicht das Zielprodukt?

Weil der Abstand zwischen zwei Camunda-7-Beständen größer ist als der zwischen zwei Zielprodukten. Camunda beschreibt diese Spannweite selbst: „Solutions range from small implementations with clean delegates to large solutions with hundreds of processes using internal API hacks.“ (docs.camunda.io, Migration journey)

In den hier gelesenen Camunda-Quellen steht keine zusammengeführte Liste der Stellen, an denen ein Bestand an eine Grenze stößt. Sie stehen verteilt auf sieben Seiten: den konzeptionellen Unterschieden, der Vorbereitungsanleitung, dem Migrationsweg, den Einschränkungen und den Variablentypen des Data Migrators sowie den beiden Werkzeugseiten zu Code-Konvertierung und Diagram Converter. Das ist kein Verschweigen. Camunda dokumentiert diese Grenzen ausführlich und gegen das eigene Interesse, in den hier gelesenen Quellen nur eben nicht an einer Stelle. Die nächsten vier Abschnitte ziehen sie zusammen, und jeder benennt das Artefakt, an dem Sie den Befund ablesen.

Wo steht, welche Bauform Sie betreiben?

Das Artefakt: Ihre pom.xml oder build.gradle. Welche der von Camunda dokumentierten Betriebsarten bei Ihnen läuft, steht in Ihrer Installation, nicht in einer Vergleichstabelle (docs.camunda.org, Architecture). Steht die Engine als Abhängigkeit in Ihrem Build und startet und stoppt mit Ihrer Anwendung, ist die Antwort eindeutig.

Läuft Ihre Anwendung nicht auf der JVM, benennt Camunda den Fall unter der Überschrift „Polyglot applications (C#, Node.js)“ selbst: „When you run your application in Node.js or C#, for example, you exchange one remote engine (Camunda 7) with another (Camunda 8). As Zeebe comes with a different API, you need to adjust your source code.“ (docs.camunda.io, Conceptual differences) Übrig bleibt dort eine Anpassung des Quelltextes an eine andere API. Einen Architekturwechsel nennt Camunda für diesen Fall nicht.

Am anderen Ende benennt Camunda im Migrationsweg den Fall, für den es in Camunda 8 keine Entsprechung gibt: „Your solution relies on an architecture that is not possible with Camunda 8. For example, software vendors that embedded Camunda 7 as a Java library into their own build, relying on shipping exactly one self-contained Java application.“ Zwei Sätze weiter steht auf derselben Seite, was dazugehört: „Most often, you could still migrate those scenarios if you rearchitect the solution.“ (docs.camunda.io, Migration journey) Ein Ausschluss ist das nicht, eine Einschränkung schon.

Teilen sich Engine und Fachcode eine Transaktion?

In Camunda 7 ist der Weg von einem Wartezustand zum nächsten eine einzige 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 steht so in der Quelle. Zur Bauform schreibt dieselbe Seite: „The process engine is a piece of passive Java code which works in the Thread of the client.“ (docs.camunda.org, Transactions in Processes)

Für Camunda 8 kehrt Camunda die Regel um, und zwar in der eigenen Vorbereitungsanleitung: „You should not trust ACID transaction managers to glue together the workflow engine with your business code.“ Die prüfbare Fassung derselben Aussage steht wenige Zeilen weiter: „A process solution that relies on five service tasks to be executed within one ACID transaction, probably rolling back in case of an error, will make migration challenging.“ (docs.camunda.io, Migration readiness)

Das Artefakt: Ihre Engine-Konfiguration und Ihr BPMN-XML. Camunda 7 integriert sich von Haus aus in fremdes Transaktionsmanagement: „Out of the box, the process engine supports integration with Spring and JTA“, und im Modell steht das Gegenstück als Attribut: „An asynchronous continuation before an activity is enabled using the camunda:asyncBefore extension“ (docs.camunda.org, Transactions in Processes). Für Camunda 8 lautet die Vorgabe: „Instead, embrace eventual consistency and make every service task its own transactional step. If you are familiar with Camunda 7 lingo, this means that all BPMN elements will be async=true.“ (docs.camunda.io, Migration readiness) Zählbar ist damit das Gegenteil: wie viele Ihrer BPMN-Elemente heute weder camunda:asyncBefore noch camunda:asyncAfter tragen.

Diese Zahl ist keine Aufwandszahl und wird auch keine, wenn man sie multipliziert. Sie ist eine Feststellung darüber, wie viele Stellen Ihres Modells heute stillschweigend von einer gemeinsamen Transaktion profitieren.

Wie viel von Ihrem Java-Code hängt an der Camunda-7-API?

Ein Java-Delegate ist über genau ein Interface definiert: „this class needs to implement the org.camunda.bpm.engine.delegate.JavaDelegate“ (docs.camunda.org, Delegation Code). Der Suchbegriff für die Bestandsaufnahme ist deshalb der Paketname, nicht der Klassenname.

Camunda veröffentlicht diese Bestandsaufnahme selbst, als Arbeitsanweisung. Auf der Seite zur Code-Konvertierung steht sie in einem vorformulierten Block für ein KI-Werkzeug, aber die Anweisung ist eine Auswertung, die Sie heute in Ihrem eigenen Repository ausführen können. Camundas Anweisung lautet: Nehmen Sie jede Java-Datei, „that imports from org.camunda.bpm.*“, und ordnen Sie sie einer von sieben Klassen zu. Aufgezählt sind dort Client-Code gegen ProcessEngine, RuntimeService, TaskService und RepositoryService, Java-Delegates, Execution-Listener, External-Task-Worker, JUEL-Ausdrücke, Testcode und Konfiguration (docs.camunda.io, Code conversion).

Das Artefakt: Ihre Import-Anweisungen. Denselben Anteil kann ein Werkzeug messen, das Camunda auf der Seite zum Migrationsweg nennt: „The Code Migration Detector (based on ArchUnit) can check how much Camunda 7 API is used in your codebase to allow you refactor to reduce the footprint step-by-step.“ (docs.camunda.io, Migration journey) Das ist die Feststellung in ihrer belastbarsten Form: nicht geschätzt, sondern gegen Ihren eigenen Quelltext geprüft.

Für die Rezepte, die diesen Code anschließend umschreiben, nennt Camunda eine Zugangsvoraussetzung, die in einem Bestand auf der Community Edition auffällt: „The use of camunda-7-to-8-code-conversion-recipes artifact requires access to the Camunda Enterprise Maven repository.“ Das ist ein Zugriffsrecht auf ein Repository und keine Aussage über die Lizenzierung von Camunda 8. Auf derselben Seite steht außerdem: „The recipes are still under development. Expect recipes to work out-of-the-box only in simple scenarios.“ (docs.camunda.io, Code conversion)

Wo umgeht Ihr Code die öffentliche API?

Die vierte Eigenschaft lässt sich nicht zählen, nur suchen. Camunda formuliert sie als drei Verbote für Camunda 8: „Never cast to Camunda implementation classes, use any ThreadLocal object, or influence the transaction manager in any way.“ Im Satz danach kommt eine vierte Auflage dazu: „Java delegates should always be stateless and not store any data in their fields.“ (docs.camunda.io, Migration readiness)

Das Artefakt: Ihr Java-Quelltext und Ihr BPMN-XML. Umgekehrt sind das drei Suchbegriffe für Ihren eigenen Code: Casts auf Klassen mit .impl. im Paketnamen, ThreadLocal und jeder Eingriff in den Transaktionsmanager.

Die Camunda-7-Dokumentation lässt diesen Weg ausdrücklich offen und rät im selben Absatz davon ab: „it is also possible to provide a class that implements the org.camunda.bpm.engine.impl.pvm.delegate.ActivityBehavior“, gefolgt von „However, note that this is not a very good practice and should be avoided as much as possible.“ (docs.camunda.org, Delegation Code) Wer diesem Rat gefolgt ist, findet an dieser Stelle nichts. Wer nicht, findet die Stellen an genau diesem Paketnamen.

Die zweite Hälfte steht nicht im Java-Code, sondern im Modell. Für Camunda 8 rät Camunda davon ab: „Don’t call Spring beans in expressions (for example to leverage Java code to do data transformations).“ (docs.camunda.io, Migration readiness) Im BPMN-XML von Camunda 7 erkennen Sie diese Stellen an zwei Attributen, camunda:expression und camunda:delegateExpression. Die Camunda-7-Dokumentation beschreibt das zweite so: „The attribute camunda:delegateExpression is used for expressions which evaluate to a delegate“, und die Beispiele dort lauten ${myBean} und ${myBean.createDelegate()}. Für camunda:expression steht auf derselben Seite ${myBean.myMethod(execution)}, ein Aufruf an eine Bean-Methode (docs.camunda.org, Unified Expression Language).

Folge und Gegengewicht stehen bei Camunda auf derselben Seite, der Vorbereitungsanleitung zu Camunda 8. Zur Folge: „Such code cannot be executed within Camunda 8 FEEL expressions, and the logic needs to be moved elsewhere.“ Zum Gegengewicht: „If you write simple expressions, they can be migrated automatically, as you can see in the test case of the migration community extension.“ (docs.camunda.io, Migration readiness) Es kommt also nicht auf die Anzahl Ihrer Ausdrücke an, sondern darauf, ob hinter einem Ausdruck Java hängt.

Was entscheidet über Ihre Camunda-7-Migration?

Was von Ihrem laufenden Betrieb kommt mit?

Die erste Frage ist, ob Sie laufende Instanzen überhaupt mitnehmen müssen. Camunda schreibt im Migrationsweg: „If you drain out your Camunda 7 processes, or if they are typically very short-lived, you do not need runtime instance migration.“ (docs.camunda.io, Migration journey) Bei kurzlebigen Prozessen ist dieser ganze Abschnitt für Sie gegenstandslos, und auch das ist eine Eigenschaft Ihres Bestands.

Müssen Sie sie mitnehmen, entscheidet der Inhalt Ihrer Variablentabelle. Der Data Migrator listet Variablentypen, bei denen er die Instanz auslässt: „The following Camunda 7 variable types are not supported and will cause the process instance migration to be skipped“, darunter „Java objects serialized as application/x-java-serialized-object like List, Set, Map, float, byte, char or custom types“. Die Folge steht auf derselben Seite über der Tabelle, als erster Punkt unter der Überschrift „Unsupported types“: „Skip the entire process instance“ (docs.camunda.io, Data Migrator: variables). Das ist in Ihrer eigenen Datenbank zählbar, bevor irgendetwas migriert wird.

Auch der Zustand, in dem eine Instanz gerade steht, zählt. Zu zusammenführenden parallelen Gateways schreibt Camunda: „Process instances with active joining parallel gateways cannot currently be migrated. The migrator will skip these instances during migration.“ Zu Multi-Instance-Elementen: „Processes with active multi-instance elements can currently not be migrated.“ Für Prozesse mit Timer-Start-Event nennt dieselbe Seite Voraussetzung und Grenze in einem einzigen Punkt: „Timer start events: prior to migration, you must ensure that your process has at least one none start event. Processes that only have a timer start event cannot be migrated.“ (docs.camunda.io, Data Migrator: limitations)

Läuft in Ihrem Bestand CMMN, betrifft das die Historie. Zum History Data Migrator schreibt Camunda: „CMMN entities: CMMN user tasks and CMMN variables are not supported and are skipped during migration.“ (docs.camunda.io, Data Migrator: limitations)

Bei der asynchronen Fortsetzung werden verkürzte Darstellungen falsch, deshalb hier die genaue Fassung. Camunda schreibt: „Camunda 8 does not support asynchronous continuation before or after any kind of wait state.“ Und weiter: „Service-task-like activities are executed asynchronously by default in Camunda 8“ sowie „a service task waiting for asynchronous continuation before will be correctly migrated“. Ein Service-Task mit asyncBefore kommt also korrekt mit. Nur Instanzen, die an anderen Elementen warten, etwa an einem Gateway, laufen im Zielmodell ohne Warten weiter. Zwei weitere Voraussetzungen nennt dieselbe Seite für die Migration laufender Instanzen: „The minimum supported history level is ACTIVITY.“ und „You must add an execution listener of type migrator to all your start events.“ Für die Historienmigration nennt sie eine andere Schwelle: „The minimum required history level in Camunda 7 is FULL to ensure that sufficient data is available for migration.“ (docs.camunda.io, Data Migrator: limitations)

Welche Bestandteile gibt es in Camunda 8 gar nicht?

Vier weitere Fragen sind mit Ja oder Nein zu beantworten, und Sie beantworten sie an Ihrer eigenen Installation, nicht an einem Vergleich. Camunda benennt sie in den konzeptionellen Unterschieden (docs.camunda.io, Conceptual differences):

• Engine-Plugins. „Process engine plugins are not available in Camunda 8, as such plugins can massively change the behavior or even harm the stability of the engine.“
• Cockpit- und Tasklist-Plugins. „Cockpit or Tasklist plugins cannot be migrated.“
• CDI und OSGi. „Due to limited adoption, there is no support for CDI or OSGI in Camunda 8.“
• Jakarta-EE-Anwendungsserver. „Camunda 8 doesn't provide integration into Jakarta EE application servers like Camunda 7 does.“

Dazu kommt die Formulartechnik an Ihren User-Tasks. In der Vorbereitungsanleitung schreibt Camunda: „Use your own user interface for task forms or Camunda Forms; the other form mechanisms are not supported out of the box in Camunda 8.“ (docs.camunda.io, Migration readiness) Welche Technik bei Ihnen hängt, steht an den User-Tasks in Ihren Modellen, nicht im Java-Code.

Was können Sie heute selbst laufen lassen?

Für die Modelle betreibt Camunda den Diagram Converter selbst: „Use the hosted Diagram Converter at https://diagram-converter.camunda.io/. This option requires no local setup and is suitable for quick evaluations or one-off migrations.“ Zur Vertraulichkeit schreibt Camunda auf derselben Seite: „Your models are not stored on this platform, and all processing happens in-memory.“ (docs.camunda.io, Diagram Converter) Wer sein Prozessmodell nicht aus dem Haus geben darf, hat mit diesem einen Satz die Zusage, an der er die gehostete Variante messen kann, und sie stammt von Camunda, nicht von uns.

Das Ergebnis ist eine Liste von Befunden in vier Stufen, und zwei davon bedeuten, dass das Werkzeug den Fall nicht lösen konnte: „WARNING: A Camunda 7 concept cannot be directly mapped to a Camunda 8 equivalent.“ und „TASK: Manual changes are required to make the diagram work in Camunda 8.“ Die dritte, „REVIEW: The conversion will modify some expressions or attributes.“, verlangt eine fachliche Prüfung. Die vierte ist die unauffällige: „INFO: No action needed. Diagram conversion can successfully map attributes to the Camunda 8 implementation.“ (docs.camunda.io, Diagram Converter) Die Anzahl dieser Befunde ist kein Aufwandsmaß, und keine der hier gelesenen Quellen macht eines daraus.

Was bewahrt ein Fork, und woran hängt auch dieser Weg?

Die Gegenprobe zur ersten Eigenschaft. Was ein Fork der Community Edition bewahrt, sagt der jeweilige Anbieter selbst. Operaton schreibt in der eigenen FAQ, auf die Versionslinie 1.x bezogen: „The 1.x versions of Operaton prioritize full compatibility with Camunda 7. Your BPMN models, process definitions, and execution logic will continue to work without changes.“ Für spätere Versionen sagt dieselbe Seite das nicht zu. Operaton nennt außerdem drei Betriebsarten, die erste davon „embed the engine in your Java application (Spring Boot, Quarkus, Jakarta EE)“ (operaton.org/faq). Für einen eingebetteten Bestand heißt das: Die Eigenschaft, die in Camunda 8 keine Entsprechung hat, bleibt in dieser Versionslinie erhalten.

Eine eigene Bestandsfrage hat auch dieser Weg, und CIB nennt das Suchmuster dafür selbst: „You can search for the string pattern org.camunda.* inside the BPMN files to find the processes with the camunda namespace.“ Der Grund steht daneben: „All such objects are stored in the database and are not automatically renamed to the cibseven namespace during migration“, und ein Zugriff darauf „may result in ClassNotFoundException“. Das Gegengewicht steht auf derselben Seite: CIB nennt zwei Konfigurationseigenschaften, useCibSevenNamespaceInScripting und useCibSevenNamespaceInReflection, die diese Objekte beim ersten Zugriff umbenennen, und schreibt dazu, sie lägen in den Konfigurationsdateien der Tomcat-, Wildfly- und Run-Distributionen ab CIB seven 2.0 bei, seien dort aber „disabled by default“ (docs.cibseven.org, Camunda Migration). Der Befund ist damit eine Konfigurationsfrage, die vor dem ersten Zugriff geklärt sein muss.

Camunda äußert sich in keiner der hier gelesenen Quellen zu einem dieser Projekte, weder zustimmend noch ablehnend. Camunda-Zitate und Anbieterzitate stammen hier aus getrennten Quellen.

Auf seiner Seite zur Migration nennt Flowable Camunda zweimal. Die erste Nennung betrifft laufende Instanzen: „If you have in-flight process instances, you may need to enable the Flowable 5 compatibility engine. This works for any Flowable 5 equivalent engine (such as Activiti 5 and Camunda 7).“ Für Klassen-Delegates an Service-Tasks hält dasselbe Dokument Codeänderungen für nötig: „In certain use cases, such as for example using class delegates for a service task, a change to the code will need to be applied“. Eine Camunda-7-Historienmigration oder einen Camunda-7-Codepfad dokumentiert Flowable an dieser Stelle nicht (documentation.flowable.com, Migration).

Ein Prüfwerkzeug gibt es auch hier, und in dessen Beschreibung steht die zweite der beiden Nennungen: „Flowable Leap (Legacy Execution Analysis of Processes) is a tool that can analyze BPMN models from other BPM products, such as Camunda and Activiti, and highlight any incompatibilities with running them on Flowable.“ Mit einer Einschränkung, die zählt, sobald Ihre Datenbank keine der drei genannten ist: „Flowable Leap includes drivers for H2, MySQL and PostgreSQL“, und „The online version of Flowable Leap cannot connect to your database to analyze BPMN models.“ (documentation.flowable.com, Migration)

Was dieser Artikel über eine Camunda-7-Migration bewusst nicht sagt

Eine Schwelle. In keiner der hier gelesenen Quellen steht, ab wie vielen Prozessdefinitionen, wie vielen Java-Delegates oder wie vielen laufenden Instanzen eine Entscheidung kippt. Die vier Eigenschaften lassen sich feststellen, sie lassen sich aber nicht in einen Grenzwert übersetzen, und wir erfinden hier keinen.

Aus demselben Grund steht hier keine Angabe zu Aufwand, Dauer oder Kosten. Ebenso wenig steht hier, welche Bauform verbreitet ist: In keiner der hier gelesenen Quellen veröffentlicht ein Anbieter dazu Zahlen, und der Satz, die meisten Bestände liefen eingebettet, wäre eine Vermutung.

Und das Gegengewicht gehört auf dieselbe Seite. Camunda schreibt auf der eigenen Migrationsseite: „Camunda 7 Enterprise Edition remains supported through April 2030, but we recommend all new projects be developed on Camunda 8.“ (camunda.com/platform-7/migrate) Und im eigenen Migrationsleitfaden: „While there is some urgency to start migration efforts, you are not yet under hard pressure.“ (docs.camunda.io, Migration journey) Wer die vier Feststellungen heute trifft, trifft sie, um die Entscheidung vorzubereiten, nicht um einen Termin einzuhalten.

Zwei Artikel gehen die Ziele durch, die hier nur als Befund vorkommen: Camunda 7 vs. Camunda 8 stellt die beiden Produkte gegenüber, und Camunda-7-Forks im Vergleich geht CIB seven und Operaton nebeneinander durch.

Wenn Sie die Entscheidung lieber zusammenhängend lesen wollen, bevor Sie mit jemandem sprechen: Das Handbuch Der Camunda PATH geht dieselbe Entscheidung am Stück durch.