In Teil 2 unserer Serie zur Migration von Prozessanwendungen von Camunda 7 nach Camunda 8 geht es an die Umsetzung und wir migrieren das Start Event, Gateways, Expressions und Service Tasks.
Du hast den ersten Teil verpasst? Macht nichts, schau doch einfach hier vorbei: Aus 7 mach 8: Prozessmigration von Camunda 7 auf Camunda 8 - Teil 1.
Wir empfehlen dir unbedingt, den ersten Teil zu lesen, da dieser Artikel auf den Überlegungen aus Teil 1 aufbaut. Dort haben wir einen kurzen Überblick über die wesentlichen Schritte der Migration gegeben und unseren Beispielprozess zur Bearbeitung eines Kfz-Glasbruchschadens eingeführt. Zu Erinnerung - der Prozess sah wie folgt aus:
Unser Beispiel-Prozessmodell der Kfz-Glasbruchversicherung aus Teil 1
Fertig? Los! - die Migration des Prozessmodells
Nun wollen wir uns die Hände schmutzig machen und genau diesen Prozess migrieren! Dafür müssen wir zunächst unser Prozessmodell Camunda 8 tauglich machen. Prinzipiell muss am Modell einiges angepasst werden - das betrifft vor allem Metadaten für die technische Ausführung (z.B. die Ausführungsplattform, für die modelliert wurde) und die technische Konfiguration der einzelnen Aktivitäten (sehen wir im Verlauf des Blogartikels noch). Was genau zu tun ist, hat Camunda hier im Detail beschrieben.
Anstatt die notwendigen Anpassungen händisch im XML-Code zu erledigen, haben wir für diesen initialen Schritt den Backend Diagram Converter aus dem Camunda Community Hub verwendet. Das hat uns ein wenig Arbeit gespart, allerdings haben wir einige Dinge bei der Konvertierung gesehen, die nicht ganz so gut funktioniert haben. So wurden z.B. die Delegate-Expressions in JUEL (Java Unified Expression Language) bei den Execution-Listenern 1:1 übernommen. Wir sehen aber auch rege Aktivitäten auf GitHub, was darauf schließen lässt, dass der Converter ständig weiterentwickelt wird. Wir würden den Converter trotz der kleineren Auffälligkeiten empfehlen, da man zumindest BPMN-Dateien erhält, die kompatibel zu Camunda 8 sind und somit eine gute Ausgangsbasis zur weiteren Anpassung darstellen.
Vorbereitung der Prozessanwendung
Unser Beispielprozess wurde unter Camunda 7 in einer einzigen zusammenhängenden Prozessanwendung implementiert, sprich alle Delegates, Listener etc. liegen in einem Artefakt und werden mit diesem deployed. Mit einer Remote Engine wäre es auch möglich, die Implementierungen auf mehrere Artefakte aufzuteilen. Wir wollen nach unserer Migration weiterhin eine einzige Prozessanwendung haben. Für Camunda 8 steht ein Java SDK zur Verfügung, das alle wichtigen Methoden zur Interaktion mit der der API von Camunda 8 bereitstellt. Dieses benutzen wir später für den Prozessstart, die Implementierung von Zeebe-Job-Workern und der Nachrichtenkorrelation. Das SDK binden wir ganz einfach über folgende Maven-Dependency in unsere Prozessanwendung ein:
Da mit Camunda 8 eine Remote Engine verwendet wird, muss in der application.properties bzw. application.yml der Prozessanwendung zunächst die Verbindung zur Engine konfiguriert werden. Verwendet man Camunda 8 als SaaS-Lösung, muss man die hierbei verwendeten Client-Credentials zuvor in der Camunda Console anlegen:
STARTEREIGNIS UND PROZESSSCHNITTSTELLE
Beginnen wir damit, das Startereignis des Prozessmodells anzupassen. Auf den Screenshots ist jeweils zu sehen, was sich im Vergleich zu Camunda 7 bei Camunda 8 geändert hat:
Migration des Start Events von Camunda 7 zu Camunda 8
Name und ID bleiben einfach wie vorher (wie bei allen anderen Elementen auch). Lediglich die Häkchen unter “Asynchronous continuations” sind verschwunden, dazu später mehr.
Um den Prozess tatsächlich zu starten, haben wir in unserer Camunda-7-Prozessanwendung einen REST-Service als Prozessschnittstelle implementiert. Im entsprechenden RestController haben wir dann den Prozess über den Runtime-Service von Camunda 7 mittels der Process-ID gestartet. Diese muss im Prozessmodell nicht am Start Event, sondern am entsprechenden Pool eingetragen sein. Der Start des Prozesses sieht dann wie folgt aus:
Um unseren Prozess in Camunda 8 zu starten, verwenden wir im RestController anstelle des Runtime Service den Zeebe Client aus dem Camunda 8 SDK:
Einschub: Transaktionalität
Wie man im Screenshot sehen kann, sind die Häkchen für “Asynchronous Continuations” beim Start Event entfallen - das betrifft auch alle anderen Events und auch alle Tasks und Gateways. In Teil 1 haben wir es bereits kurz erwähnt: in Camunda 8 gibt es keine Möglichkeit mehr Transaktionsgrenzen mittels dieser Häkchen zu setzen und somit Datenbanktransaktionen über mehrere Prozessschritte hinweg zu verwenden. Das ist dem Umstand geschuldet, dass es das Konzept der Embedded Engine mit Camunda 8 nicht mehr gibt. Neben dem manuellen Setzen von Transaktionsgrenzen war es sogar möglich, dass Process Engine und Businesslogik sich Datenbankverbindung und Transaktionsmanager teilen. Mit einer Remote Engine geht das nicht mehr und daher sind bei Camunda 8 alle Tasks automatisch immer “asyncBefore” und “asyncAfter” (siehe Dokumentation).
Auf unseren Beispielprozess hat das veränderte Transaktionsverhalten keinen nennenswerten Einfluss und wir müssen nichts weiter tun. Die generellen Implikationen und Lösungsansätze kann man in den beiden Blogartikeln Navigating Technical Transactions with Camunda 8 and Spring und Achieving Consistency without Transaction Managers von Bernd Rücker, Mitgründer von Camunda, nachlesen.
Gateways und Expressions
Als nächstes schauen wir uns Gateways und Expressions an. An den Gateways selbst ändert sich nichts, dafür allerdings an den ausgehenden Sequenzflüssen. In Camunda 8 werden keine JUEL-Expressions verwendet, sondern nur noch Expressions in FEEL (Friendly Enough Expression Language). FEEL wurde als Teil des DMN-Standards der Object Management Group (OMG) definiert. Sie wurde entwickelt, um Ausdrücke so zu schreiben, dass sie sowohl für Fachexpert:innen als auch für Entwickler:innen leicht verständlich sind. Hier kannst du mehr über FEEL erfahren.
Wie auf dem Screenshot zu sehen, wurde zum Beispiel aus der JUEL Expression ${not empty extIn_vsnr} die FEEL Expression not(extIn_vsnr=null).
Migration der Gateways und Sequenzflüsse von Camunda 7 zu Camunda 8
SERVICE TASKS
Nun schauen wir uns die Service Tasks in unserem Modell an. Diese hatten wir zuvor in Camunda 7 als Delegate Expressions implementiert. Wie bereits in Teil 1 beschrieben, können wir keine Delegate Expressions und somit keine Java Delegates mehr verwenden. Stattdessen müssen wir für die einzelnen Tasks Zeebe-Job-Worker (nach dem External-Task-Pattern) implementieren. Mehr zu diesen Hintergründen findest du auch in unserem Blogartikel zu den Unterschieden zwischen Camunda 7 und 8.
Die asynchrone Natur der Zeebe-Job-Worker hat einige Konsequenzen, die man berücksichtigen muss. Im Gegensatz zu synchronen Delegates reservieren sich Worker die entsprechenden Jobs in Zeebe und arbeiten diese asynchron ab. Dementsprechend gibt es seitens der Engine auch ein Timeoutverhalten - sollte also ein Worker das (in der Spring-Konfiguration anpassbare) Timeout überschreiten, verfällt die Reservierung und der Job ist wieder freigegeben. Da Jobs so gegebenenfalls mehrfach ausgeführt werden können, müssen Worker idempotent sein.
Im Prozessmodell müssen wir nun bei den Service Tasks, die bisher den Implementierungstyp “Delegate expressions” hatten, im “Job type” den zugehörigen Namen des Zeebe-Jobs angeben. So spezifizieren wir, welche Zeebe-Job-Worker die Aufgabe übernehmen können.
Migration der Service Task von Camunda 7 zu Camunda 8
In den Parametern der Methode “vertragAnhandVsnrLesen” können wir mittels der Annotation @Variable alle Variablen angeben, die wir aus dem Prozesskontext benötigen, das SDK abstrahiert uns den manuellen Abruf der Variable dadurch. Analog dazu beinhaltet der Return-Value der Methode die Variablen, die von Zeebe aktualisiert bzw. erstellt werden. In unserem ersten Teil haben wir bereits erwähnt, dass Prozessvariablen nur noch als JSON-Value gespeichert werden. Die notwendige JSON-Serialisierung bzw. JSON-Deserialisierung nimmt uns das SDK an der Stelle ab. Eine durchaus relevante Implikation der neuen Camunda-Architektur ist die Größenbeschränkung des gesamten Prozessvariablenhaushalts auf max. 4 MB (inkl. Engine-interner Daten). In unserem Beispiel ist das kein Problem, wir haben in der Praxis aber durchaus größere Variablen gesehen (z.B. mit PDFs). Abhilfe können z.B. externe Datenbanken, Dokumentenmanagementsysteme oder Caches schaffen - das muss man aber im Einzelfall genauer betrachten.
Die anderen Service Tasks haben wir analog zu diesem migriert.
Zusammenfassung
Im zweiten Teil unser Blogartikel-Serie zur Migration von Camunda 7 auf Camunda 8 haben wir uns die Ärmel hochgekrempelt und Start Event, Gateways, Expressions und Services Tasks migriert. Im nächsten Artikel werden wir uns Business Rule Tasks, User Tasks und Nachrichtenkorrelation genauer anschauen.
Du möchtest noch mehr über Camunda und Prozessautomatisierung erfahren? Dann schau doch bei unseren anderen Blogposts zu Business Process Management vorbei oder besuche eine unserer Schulungen! Du befindest dich bereits mitten in der Migration und möchtest über unsere Empfehlungen diskutieren oder Erfahrungen austauschen? Dann schreib uns gerne an und wir melden uns persönlich bei dir!
Hier findest du die anderen Teile unserer Blogreihe:
Aus 7 mach 8: Prozessmigration von Camunda 7 auf Camunda 8 - Teil 1
Aus 7 mach 8: Prozessmigration von Camunda 7 auf Camunda 8 - Teil 3 (coming soon)
Die Autor:innen
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 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.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
