Aus 7 mach 8: Prozessmigration von Camunda 7 auf Camunda 8

Business Process Management, Forschung & Entwicklung

In Teil 3 unserer Serie zur Migration von Prozessanwendungen von Camunda 7 nach Camunda 8 migrieren wir Business Rule Tasks, DMN-Regeln, User Tasks und Nachrichtenkorrelation.

Du hast die vorangegangenen Artikel verpasst? Macht nichts, schau doch einfach hier:

Wir empfehlen dir unbedingt alle Artikel zu lesen, da dieser Artikel hier auf den Überlegungen aus Teil 1 und 2 aufbaut. In Teil 1 haben wir einen kurzen Überblick über die wesentlichen Schritte der Migration gegeben und unseren Beispielprozess zur Bearbeitung eines Kfz-Glasbruchschadens eingeführt. In Teil 2 haben wir Start Events, Gateways, Expressions und Service Tasks migriert.

Zur Orientierung hier nochmal unser Beispiel-Prozessmodell:

Unser Beispiel-Prozessmodell der Kfz-Glasbruchversicherung

Business Rule Tasks

Schauen wir uns nun die Migration von Business Rule Tasks an. Camunda 8 unterstützt den DMN-Standard genauso wie Camunda 7 und es müssen zunächst zwei XML-Attribute in der DMN-Regel angepasst werden - bei der modeler:executionPlatform muss “Camunda Cloud” angegeben werden und bei modeler:executionPlatformVersion die aktuellste Camunda Version (in unserem Fall “8.6.0”). Wenn man die DMNs in den Camunda Cloud Web Modeler importiert, geschieht das automatisch. Unsere DMN-Tabelle aus dem Beispiel sieht wie folgt aus:

Die DMN-Tabelle zur Entscheidung über die Anforderung eines Prüfberichts aus dem Beispielprozess

Darüber hinaus ist vor allem entscheidend, welche Scriptsprache in den DMN-Tabellen unter Camunda 8 verwendet wurde. Unter Camunda 7 gab es da neben FEEL noch weitere Optionen (u.a. JUEL, JavaScript oder Groovy), Camunda 8 unterstützt hingegen nur noch FEEL. Sollte also nicht vorher schon FEEL verwendet worden sein, müssen die Ausdrücke in FEEL überführt werden. In unserem Fall haben wir bereits vorher FEEL verwendet, daher müssen wir auch nichts weiter tun.

Bezüglich der Business Rule Task musste in Camunda 7 im Modeler unter “Map decision result” ausgewählt werden, wie das “Decision result” im Prozesskontext abgelegt werden soll. Ausschlaggebend dafür war die Output-Struktur der DMN Tabelle (abhängig von der Hit Policy und der Anzahl Output-Spalten). Es gab basierend auf Java-Datentypen folgende Optionen:

Mögliche Arten von Decision results in Camunda 7

Unter Camunda 8 gibt es diesen Dialog nicht mehr, da das Ergebnis immer von der Engine als JSON-Wert im Prozesskontext abgelegt wird. Je nach Struktur der DMN-Tabelle, ist der JSON-Wert dann entweder ein JSON-Objekt, ein Array oder ein flacher Wert (String, Number, Boolean , …). Das hat als Konsequenz, dass die Struktur der Ergebnisvariable nicht mehr dank des Dropdown statisch bekannt ist, sondern dynamisch durch die aufgerufene DMN zum Zeitpunkt der Ausführung bestimmt wird.

In unserem Fall haben wir in der DMN für die Entscheidung über die Notwendigkeit eines Prüfberichts die Hit-Policy “Unique” und eine Output-Spalte vom Typ boolean. Das Ergebnis (true oder false) wird dann unter dem im Modell angegebenen Variablennamen als einfacher, flacher JSON value im Prozesskontext abgelegt und kann im nachfolgenden Gateway per FEEL-Expression abgefragt werden. Daher ist an unserer DMN letztendlich nichts weiter anzupassen.

Migration der Business Rule Task von Camunda 7 zu Camunda 8

User Tasks

Bei der Migration von User Tasks kommt es maßgeblich darauf an, wie diese unter Camunda 7 umgesetzt wurden. In nachfolgender Tabelle haben wir zusammengefasst, welche Optionen es unter Camunda 7 gab und welche es in Camunda 8 gibt:

Typ	Beschreibung	C7	C8
Camunda Forms	Erlaubt die Erstellung von Formularen (JSON-basiert) über den eigens von Camunda dafür implementiertem Form Designer (im Camunda Modeler integriert). Die Formulare werden dann in der Camunda Tasklist bei der Bearbeitung von User Tasks gerendert.
Generated Task Forms	Automatische Generierung von Formularen anhand von Metadaten, die im Prozessmodell angereichert werden (Konfiguration im Propertys Panel des Camunda Modelers)
Embedded Task Forms	Referenz auf ein Formular auf Basis von HTML und JavaScript, das in der Camunda Tasklist bei Bearbeitung der User Task eingebettet ist und mit der Prozessanwendung deployed wird.
External Task Forms	Erlaubt die Anbindung an eine separate, ggf. bereits in der Organisation vorhandene Anwendung zur User-Task-Verwaltung (Eigenentwicklung oder Standardsoftware). Ein “Form key” (C7) bzw. eine “External form reference” (C8) referenziert das für den User Task zu verwendende Formular. Die eigene Anwendung kann dann über die API der Process Engine User Tasks zuweisen, bearbeiten usw.

Für unseren Beispielprozess hatten wir zur Aufgabensteuerung in Camunda 7 die Camunda Task List in Verbindung mit “Embedded Task Forms” verwendet. Für Camunda 8 sind wir auf Camunda Forms umgestiegen, da die Möglichkeit der Embedded Forms nicht mehr existiert. Die Formulare aus dem Beispielprozess sind nicht kompliziert und lassen sich in unserem Fall einfach mit dem Formular Designer von Camunda nachbauen. Diese müssen zunächst wie Prozessmodelle und DMN-Tabellen auch in Camunda deployed werden.

Als nächstes muss im Prozessmodell am User Task der Formulartyp Camunda Form ausgewählt werden, gefolgt von der Referenzierung unserer Form-ID. Nutzt man den Camunda Web Modeler in der Cloud, kann man auch einfach Link-Button an der User Task verwenden, um die entsprechende Camunda Form zu verknüpfen (siehe Screenshot). Nun ist das Camunda Formular verknüpft und angebunden. Darüber hinaus müssen wir uns nun für einen Implementation Type entscheiden, es gibt zwei mögliche Optionen: “Zeebe user task” oder “Job worker”. Wir haben uns als Type für den Zeebe-User-Task entschieden, da Camunda dann das komplette User-Task-Life-Cycle-Management übernimmt. User Tasks mit Job-Worker-Implementierung auf der anderen Seite verhalten sich wie Service Tasks. Eine Job-Worker-Implementierung sollte man nur benutzen, wenn man eine sehr spezifische Implementierung eines User Tasks benötigt, die sich nicht mit Zeebe-User-Tasks umsetzen lässt. Mehr Informationen dazu findest du in der Dokumentation für Camunda 8.

Migration der User Task von Camunda 7 zu Camunda 8

Exkurs: User Task mit eigener Webanwendung bearbeiten

Im produktiven Betrieb haben wir bisher hauptsächlich External Task Forms gesehen. Viele Kunden implementieren eigene Aufgabenverwaltungen oder nutzen bestehende Lösungen aufgrund einer Vielzahl von unternehmensspezifischen Anforderungen, die Camunda Tasklist nicht erfüllen kann. Aus diesem Grund gehen wir in diesem Exkurs nochmal gesondert auf die Migration unter Verwendung einer eigenen Aufgabenverwaltung mittels der Camunda API ein. Aktuell stellt dies eine Herausforderung dar, da sich die Struktur und die Endpunkte der API mit der Migration auf Camunda 8 grundlegend verändert haben. Zusätzlich existieren aktuell noch mehrere verschiedene APIs, darunter die sogenannte Camunda-8-API, die Tasklist-API und die Zeebe-API. Daher müssen die API-Aufrufe für die Migration auf Camunda 8 entsprechend angepasst werden.

Zum Zeitpunkt dieses Blogbeitrags (Januar 2025) arbeitet Camunda an der Verbesserung der Vereinheitlichung der vielen APIs um eine bessere Developer Experience zu erreichen. Ziel ist es, dass die Camunda-8-API künftig die Haupt-API sein wird. Aktuell benötigt man noch eine Kombination aus Tasklist-API und Camunda-8-API für das User-Task-Handling - in der Version 8.7, die im Februar 2025 veröffentlicht werden soll, wird die Tasklist API deprecated sein und die Camunda 8 API dann alle nötigen Operationen beinhalten. Um eine gewisse Aktualität dieser Blogreihe trotz der hohen Dynamik der Weiterentwicklung von Camunda 8 zu erhalten, werden wir nur exemplarisch am API-Aufruf für die Fertigstellung von User Tasks zeigen, was sich ändert.

Zunächst einmal hat sich die Authentifizierungsmethode für API-Aufrufe geändert. In Camunda 7 gab es standardmäßig noch eine HTTP Basic Authentification (Details siehe hier) oder man konnte eine eigene Authentifizierungsmethode mittels des AuthenticationProvider-Interfaces implementieren. Camunda 8 (SaaS) setzt auf eine Authentifizierung mittels JSON Web Token (JWT). Dafür sind ein paar Schritte mehr nötig. So müssen wir zunächst wie im zweiten Teil unserer Serie schon für Zeebe-Job-Worker beschrieben, einen Client in der Camunda Console erstellen (mit entsprechenden Berechtigungen). Wir empfehlen, dieser Anleitung in der Dokumentation Schritt für Schritt zu folgen.

Der eigentliche Inhalt des API-Aufrufs sah dann wie folgt aus:

POST /task/{id}/complete

Wenn wir nun eine Task abschließen wollen sieht der entsprechende Aufruf der Camunda 8 API wie folgt aus (der JWT muss als Bearer-Token in den HTTP-Headern mitgegeben werden):

POST /v2/user-tasks/{userTaskKey}/completion

Abschließend lässt sich sagen, dass nahezu alle API-Calls bei einer Migration angepasst werden müssen. Einen Überblick über alle weiteren Operationen findet man in der Dokumentation für Camunda 8.6 beziehungsweise in der Dokumentation für die demnächst kommende Version 8.7 (next). Zur leichteren Verwendung der APIs lässt sich auch hier der Zeebe-Client aus dem Camunda SDK verwenden, das es neben der bereits zuvor gezeigten Spring/Java-Implementierung übrigens auch als Implementierung für Node.js gibt. Es gibt auch OpenAPI-Spezifikationen, mit denen man sich in beliebigen Programmiersprachen selber Clients generieren kann.

Nachrichtenkorrelation (Send Task / Receive Event)

Die Implementierung der Send Task erfolgt analog zu Service Tasks (siehe Teil 2 unserer Blogreihe) und wird aus diesem Grund nicht noch einmal erläutert. Das Interessante hier ist die Nachrichtenkorrelation, die am Receive Event (oder wahlweise Receive Task) stattfindet. Schaut man sich erstmal nur das BPMN-Model an, unterscheidet sich die Konfiguration nur dahingehend, dass bei Camunda 8 das neues Feld “Subscription correlation key” hinzugekommen ist.

Migration der Receive Task von Camunda 7 zu Camunda 8

In unserer Camunda 7 Prozessanwendung haben wir ähnlich wie zum Start von Prozessen eine REST-Schnittstelle in der Prozessanwendung implementiert, die der Prüfdienstleister aufrufen kann, um uns seinen Bericht zukommen zu lassen. Im Rest Controller haben wir dann mit dem Runtime Service über die Kombination aus dem Namen der Nachricht aus dem Prozessmodell sowie der Prozessinstanz-ID korreliert:

Da wir unter Camunda 7 einfach über die Prozessinstanz-ID korreliert haben, wollen wir diese auch unter Camunda 8 zur Korrelation verwenden. Neu in Camunda 8 ist, dass nicht wie bisher über die Prozessinstanz-ID korreliert werden kann, sondern nur noch über einen Correlation Key (siehe Codebeispiel unten und Screenshot oben). Dieser muss vor dem Erreichen des Receive Events im Prozesskontext als Variable abgelegt werden. Im Prozessmodell muss dann am Receive Task im Feld "Subscription correlation key" der Name dieser Variable hinterlegt werden. Wir haben also unsere Prozessinstanz-ID zuvor in der Prozessvariable "int_processInstanceID" abgelegt und tragen den Namen der Variable am Receive Event als Subscription correlation key im Modell ein (siehe Screenshot oben). Nun können wir in unserer Prozessschnittstelle wie folgt eine Korrelation durchführen:

Hinweis: Bei unserer Recherche sind wir auf die Empfehlung von Camunda gestoßen, nicht die Prozessinstanz-ID zur Korrelation zu verwenden, sondern einen Business-Schlüssel (z.B. eine Schadennummer). Wir behalten hier aber trotzdem der Einfachheit halber die Logik der bestehenden Prozessanwendung bei und korrelieren über die Prozessinstanz-ID.

Zusammenfassung

Camunda 8 bietet uns die Möglichkeit, unsere Prozesse zu modernisieren und die Vorteile einer cloud-nativen Architektur zu nutzen. Ein wichtiger erster Schritt hierbei ist die Migration der bisher mit Camunda 7 automatisierten Prozesse, um diese weiterbetreiben und auf Camunda 8 weiterentwickeln zu können.

In unserer dreiteiligen Serie von Blogartikeln haben wir gezeigt, wie die Prozessmigration am Beispiel Kfz-Glasbruch konkret ablaufen kann. Wir haben wichtige Aspekte wie die Umstellung auf Job Worker und die Anpassung der APIs hervorgehoben. Vor allem User Tasks und Nachrichtenkorrelation bergen einige Herausforderungen, die wir aufgegriffen und diskutiert haben.

Generell haben wir nur die Spitze des Eisberges betrachtet. In unserer Blogserie haben wir lediglich einen einzelnen Prozess migriert, die Migration einer ganzen Prozesslandschaft ist um einiges komplexer. Der Wechsel auf das Betriebsmodell der Remote-Engine hat viele infrastrukturelle Implikationen. Außerdem haben wir in der Praxis immer wieder eigene Erweiterungen, Plugins oder Komponenten für das Camunda-Ökosystem bei unseren Kunden gesehen, wie z.B. Dashboards für das Camunda Cockpit, Plugins für die Process Engine, Middlewares für das Routing von User Tasks oder Anwendungen zur Verwaltung von DMN-Tabellen. Soll Camunda 8 self-managed betrieben werden, steht man vor größeren Einrichtungsaufwänden - unser Kollege Mario Micudaj berichtet darüber in seinem Artikel Camunda 8 Self-Managed betreiben: Eine Alternative zu SaaS?. Auch auf die Zusammenarbeit in der Organisation muss sich gegebenenfalls verändern, da durch das Betriebsmodell von Camunda 8 vermehrt Aufgaben zentral koordiniert oder Ressourcen zentral bereitgestellt werden müssen. In einigen Unternehmen haben wir sogenannte “Center of Excellence” für Prozessautomatisierung gesehen, die querschnittliche Aufgaben übernehmen und koordinieren, z.B. den Betrieb einer zentralen Plattform. In anderen Unternehmen wurde ein dezentralerer Ansatz verfolgt und jedes Team betreibt seine eigene(n) Engine(s). Für letztere entstehen größere Reorganisations- und Abstimmungsaufwände.

Du möchtest mehr über die grundsätzlichen Unterschiede zwischen Camunda 7 und Camunda 8 erfahren? Dann schau doch mal in diesen Blogpost unserer Kollegen Christoph Schönnenbeck, Florian David Zang und Florian Runschke. Hier findest du außerdem weitere Blogposts von uns zum Thema Camunda.

Du bist noch am Anfang oder mitten in der Migration von Camunda 7 auf Camunda 8 und möchtest über unsere Empfehlungen diskutieren oder Erfahrungen austauschen? Schreib uns gerne an und wir melden uns persönlich bei dir!

Hier findest du die anderen Teile unserer Blogreihe:

Die Autor:innen

Gero Zimmer 2 Gero Zimmer ist Berater für Agile Methoden und Prozessautomatisierung. Während er als Team Coach Teams bei agilen Veränderungsprozessen begleitet, unterstützt er als Integrationsarchitekt Kunden bei der Integration von Prozesssteuerungsplattformen in heterogenen Anwendungslandschaften sowie der Entwicklung von Prozessanwendungen.

janina lau-2 Janina Lau ist seit 2024 Beraterin bei der viadee. Ihr Schwerpunkt liegt im Business Process Management und der Business Analyse. Ihre Masterarbeit schrieb sie über LLMs im Bereich Data Science.