Aus 7 mach 8: Prozessmigration von Camunda 7 auf Camunda 8 - Teil 1

Kurzer Rückblick - Was bisher geschah

Im April 2022 hat Camunda die neue Major Version Camunda 8 veröffentlicht, die auf den ersten Blick viele Ähnlichkeiten mit Camunda 7 aufweist und von der langjährigen Erfahrung des Unternehmens mit Process Engines sowie einer starken Community profitiert. Wenn man jedoch genauer hinschaut, wurde das Fundament zugunsten einer Cloud-nativen Architektur komplett erneuert. Camunda 8 verspricht erhebliche Verbesserungen in den Bereichen Performance und Skalierbarkeit. Außerdem ist neu, dass Camunda 8 sich nur noch als Remote Engine betreiben lässt - was wiederum impliziert, dass die Ausführung von Tasks vollkommen losgelöst von der Process Engine erfolgen muss.

Ablauf der Prozessmigration

In diesem Abschnitt möchten wir einen kurzen Überblick über die Schritte der Migration von Camunda 7 zu Camunda 8 geben. Zunächst ein wichtiger Hinweis: Ziel unserer Blogreihe ist es, zu veranschaulichen, wie die Migration einer Prozessanwendung konkret aussieht. Um jedoch mehr Kontext zu bieten und dir zu ermöglichen, die Inhalte besser einzuordnen, werden wir auch das große Bild der Migration kurz skizzieren. Bei der Empfehlung der Schritte orientieren wir uns an dem Vorgehensmodell, das von Camunda in der Dokumentation beschrieben wird, sowie an bewährten Best Practices.

Wie bei jedem Migrationsvorhaben sollte vor der Entscheidung, zu Camunda 8 zu migrieren, das Produkt (und das damit verbundene neue Lizenzmodell) gründlich evaluiert werden. Ein guter Ausgangspunkt ist die Dokumentation von Camunda, die Camunda Academy oder Blogbeiträge wie dieser hier. Es ist entscheidend, die Vorteile und den Mehrwert der neuen Plattform sowie mögliche Einschränkungen und den Umfang einer Migration zu verstehen. Sobald die Entscheidung für die Migration zu Camunda 8 feststeht, können die konkreten Schritte der Migration geplant werden.

Ablauf der Prozessmigration

Schritt 1: Migrationsvorbereitung

Der erste Schritt ist die Migrationsvorbereitung, die verschiedene Aspekte umfassen kann:

• Festlegung des Umfangs der Migration: Welche Prozesse, Modelle und Anpassungen sollen migriert werden?
• Detaillierte Analyse: Welche Funktionalitäten von Camunda 7 nutzen wir derzeit, und sind diese auch in Camunda 8 verfügbar? Welche unternehmensspezifischen Implementierungen und Integrationen existieren?
• Migrationsplan entwickeln: Ein strukturierter Migrationsplan sollte die nächsten Schritte, Aufgaben und Verantwortlichkeiten festlegen.
• Setup und Einrichtung von Camunda 8: Soll Camunda 8 self-managed oder in der Camunda Cloud betrieben werden?

Wir haben hier einige zentrale Inhalte und Fragestellungen zusammengefasst, um dir Denkanstöße zu geben. Unser Anspruch für diese Blogreihe ist jedoch nicht, einen umfassenden Migrationsguide bereitzustellen. Wenn du daran interessiert bist, kontaktiere uns gerne persönlich oder schau dir die Dokumentation für Camunda 8 an.

Schritt 2: Migration der Modelle

Zunächst empfehlen wir, alle zur Prozessanwendung gehörenden Modelle zu migrieren. Dazu zählen alle BPMN-Modelle, DMN-Modelle und im weitesten Sinne auch Camunda Forms. Bei den BPMN-Modellen liegt der Fokus darauf, die technische Attributierung der einzelnen Elemente – also aller Tasks, Expressions und Events – so anzupassen, dass sie auf Camunda 8 lauffähig sind. Bei den DMN-Modellen kommt es lediglich darauf an, ob man als Expresssions-Language zuvor bereits FEEL (Friendly Enough Expression Language) oder JUEL (Java Unified Expression Language) verwendet hat. Im ersteren Fall ist der Anpassungsaufwand für die DMN-Modelle sehr gering, da sie bereits von Camunda 8 unterstützt werden. Im zweiten Fall muss man zunächst die JUEL-Expressions zu FEEL migrieren.

Schritt 3: Migration der Geschäftslogik

Hier geht es um die Migration der Geschäftslogik sowie der entsprechenden Schnittstellen. Dies umfasst zum einen die Umstellung von Delegate Expressions auf das bereits in Camunda 7 bekannte External Task Worker Pattern bei der Bearbeitung von Service Tasks (mehr dazu in unserem Blogartikel Camunda BPM External Task Worker), das nun in Camunda 8 in sogenannten Zeebe-Job-Workern umgesetzt wird. Zum anderen betrifft dies auch die Anpassung der REST-Schnittstellen der User Tasks und der Nachrichtenkommunikation.

Generell schlägt Camunda hier zwei Strategien für die Vorgehensweise vor: Refactoring und Relocation.

• Refactoring: Refactoring bezeichnet den Prozess der Überarbeitung des bestehenden Codes, um ihn an die neuen Anforderungen von Camunda 8 anzupassen. Dabei werden Java Delegates durch die Zeebe-Job-Worker mit dem External Task Pattern ersetzt, was eine bessere Integration in die neue Architektur ermöglicht und die erweiterten Funktionen von Camunda 8 optimal nutzt.

• Relocation: Relocation hingegen ermöglicht es, die bestehende Geschäftslogik weitgehend unverändert in die neue Umgebung zu übertragen. Hierbei wird ein Projekt namens C7 Adapter verwendet, das als Proxy zwischen der Camunda 8-Engine und dem bestehenden Camunda 7-Delegate-Code fungiert, sodass die vorhandene Implementierung unter bestimmten Voraussetzungen weiterhin genutzt werden kann.

Unsere Empfehlung: Sofern es keine dringenden Gründe gibt, raten wir zu einem vollständigen Refactoring, da dies die sauberste und zukunftssicherste Lösung ist.

Hinweis: Bei der Migration unserer eigenen Prozessanwendung haben wir festgestellt, dass die Grenzen zwischen Schritt zwei und drei fließend sein können und diese nicht ausschließlich sequenziell betrachtet werden können. In einigen Fällen kann es sinnvoll sein, iterativ vorzugehen: Zuerst eine Task des Modells migrieren, dann die Implementierung dieser Task anpassen und anschließend die nächste Task migrieren. Für erste kleine Migrationsvorhaben von trivialen Prozessanwendungen kann dieses Vorgehen ein tiefergehendes Verständnis fördern.

SCHRITT 4: MIGRATION DER PROZESSANWENDUNG

Camunda schlägt generell zwei Hauptstrategien zur Migration von Prozessanwendungen vor:

• Big Bang: Bei dieser Strategie erfolgt die Migration einer Prozessanwendung zu einem fest definierten Zeitpunkt, inklusive aller Laufzeitdaten. Dies kann zu einem schnelleren Übergang führen, erfordert aber auch die Migration von laufenden Prozessinstanzen (siehe unten). Zu migrierende Instanzen werden für die Dauer der Migration pausiert.
• Parallelbetrieb: Diese Strategie sieht den Parallelbetrieb von Prozessanwendungen vor - einmal unter Camunda 7 und einmal unter Camunda 8. Neue Instanzen laufen nur noch auf Camunda 8 und die Prozessanwendung unter Camunda 7 wird genau solange betrieben, bis alle alten Prozessinstanzen durchgelaufen sind.

Zusätzlich dazu sehen wir noch folgendes Szenario:

• Auslaufproduktion: Unter Umständen ist es möglich, den Start neuer Prozessinstanzen solange zu unterbinden bis alle Instanzen ausgelaufen sind und erst dann die neue Prozessanwendung unter Camunda 8 zu starten. Das hängt natürlich stark von der Laufzeit der Prozessinstanzen ab und ob diese Verzögerung irgendwelche negativen Auswirkungen auf die Fachlichkeit hat.

Im Lebenszyklus einer Prozessinstanz fallen verschiedene Arten von Daten an, die für eine Migration in Frage kommen:

1. Laufzeitdaten: laufende Prozessinstanzen werden von Camunda 7 in einer relationalen Datenbank gespeichert. Du kannst diese Daten aus Camunda 7 auslesen und verwenden, um die entsprechenden Prozessinstanzen mit ihren Daten in Camunda 8 zu erzeugen. Es steht auch ein Migrationstool der Community bereit, um bei dieser Aufgabe zu unterstützen. Die Migration von Prozessinstanzen erfordert besondere Aufmerksamkeit, da Camunda 8 nur noch die Speicherung von JSON Values als Prozessvariablen erlaubt. Generell gestaltet sich die Migration von Workflow-Engine-Daten zu Camunda 8 als komplexerer Prozess.
2. Historische Daten: Historische Daten aus der Workflow-Engine selbst können nicht migriert werden. Dies bedeutet, dass vergangene Prozessinstanzen und deren Verlauf (Stand: Zeitpunkt des Blogbeitrags) nicht in die neue Umgebung übertragen werden können.
3. Daten in Camunda Optimize: Diese Daten können erhalten und migriert werden.

Unsere Empfehlung: Mit der Migration von laufenden Prozessinstanzen entstehen zusätzliche Aufwände. Im Regelfall sehen wir dafür keinen Grund und empfehlen für einen begrenzten Zeitraum einen Parallelbetrieb von Camunda 7 und Camunda 8 bis alle alten Instanzen ausgelaufen sind. Anschließend kann der Camunda 7 Prozess abgeschaltet werden. Eine Ausnahme stellen für uns langlaufende Prozesse dar, da hier neue Fachlichkeit aber auch Wartungsarbeiten (z.B. Security-Updates) stets in beiden Prozessanwendungen implementiert werden müssten. Letztendlich muss aber im Einzelfall beurteilt werden, welches Vorgehen am besten geeignet ist.

KFZ-GLASBRUCH - UNSER BEISPIELPROZESS

Um die Migration von Camunda 7 auf 8 anschaulich darzustellen, nutzen wir in unserer gesamten Blogreihe das stark vereinfachte Fallbeispiel Kfz-Glasbruch, das den Prozess der Bearbeitung von Glasschäden an Windschutzscheiben in einer Versicherung modelliert. Der Prozess beginnt mit dem Eingang einer Schadensmeldung von Kund:innen, die einen Glasschaden an ihrer Windschutzscheibe melden. Zunächst wird überprüft, ob die Versicherungsnummer in der Meldung angegeben ist, da diese häufig vergessen wird. Ist die Nummer nicht vorhanden, wird sie durch Sachberarbeiter:innen manuell ermittelt und nachträglich in das Meldungsformular eingetragen.

Der nächste Schritt wäre die Anforderung eines Prüfberichts eines externen Dienstleisters, der prüft, ob der Schaden von der Versicherung gedeckt ist. Da dieser Dienst teuer ist und nur ab einer bestimmten Schadenshöhe sowie unter bestimmten Kriterien sinnvoll angefordert werden soll, wird vorher eine Entscheidungstabelle für die Notwendigkeit eines Prüfberichts abgefragt. Falls ein Prüfbericht erforderlich ist, wird dieser in Auftrag gegeben und anschließend empfangen. In Abhängigkeit von der endgültigen Bewertung des Schadens wird dann entweder die Zahlung angewiesen oder der Schadensfall abgelehnt.

Unser Beispielmodell des Kfz-Glasbruch Prozesses

Relevante Veränderungen für die Migration von Kfz-Glasbruch

Nun wollen wir einen Überblick über die Unterschiede zwischen Camunda 7 und Camunda 8 geben, die für unsere Prozessmigration relevant sind. Wenn du noch mehr über die generellen Unterschiede erfahren möchtest, empfehlen wir dir den Blogbeitrag Camunda 8 vs. Camunda 7: Wo liegen die Unterschiede? unserer Kollegen. Camunda 8 setzt weiterhin auf die BPMN, dadurch verändert sich das Prozessmodell nach der Migration rein optisch bei der Nutzung von Camunda 8 in der Regel nicht. Einige wenige BPMN-Elemente werden von Camunda 8 derzeit noch nicht unterstützt (siehe Camunda 8 BPMN coverage vs. Camunda 7 BPMN coverage). Auch wenn das Prozessmodell gleich bleibt, lässt es sich nicht ohne weiteres wiederverwenden, da die technischen Attributionen angepasst werden müssen. Das hat unter anderem Auswirkungen auf Expressions (z.B. an von Gateways ausgehenden Sequenzflüssen) - diese müssen wir von JUEL auf FEEL migrieren.

In der Prozessanwendung zu unserem Kfz-Glasbruch-Prozess wurde Camunda 7 als Embedded Engine betrieben, also mit dieser als Artefakt mit eingebunden und gemeinsam deployed. In Camunda 8 ist der Betrieb wie eingangs erwähnt nur noch als Remote Engine möglich - entweder in der Camunda Cloud oder self-managed. In unserer exemplarischen Migration wollen wir die Camunda Cloud nach dem SaaS Modell verwenden - die Prozessanwendung selber enthält dann gemäß dem External Task Pattern nur noch asynchron arbeitende Zeebe-Job-Worker, die sich per Schnittstelle gegen die Engine verbinden, um sich Arbeit abzuholen und das Ergebnis zurück zu schreiben. Die Verwendung von Delegate Expressions beziehungsweise direkten Verweisen auf Java-Klassen ist daher nicht mehr möglich. Das hat zur Konsequenz, dass die JavaDelegates aus unserer Camunda 7 Prozessanwendung zu External Task Workern umgebaut werden müssen.

Außerdem lässt sich aufgrund des Remote-Ansatzes das Transaktionsverhalten mittels “Asynchronous Continuations” nicht mehr steuern, alle Tasks sind automatisch “asyncBefore” und “asyncAfter”. Eine Verzahnung von Datenbanktransaktionslogik mit den Transaktionen der Engine ist auch nicht mehr möglich. Auf Transaktionen werden wir in den nachfolgenden Artikeln noch genauer eingehen.

ZUSAMMENFASSUNG

In diesem ersten Artikel haben wir die allgemeinen Schritte einer Migration auf hoher Flughöhe vorgestellt, unser Beispielmodell der Kfz-Glasbruch eingeführt und die wesentlichen Veränderungen zur Prozessanwendung skizziert. In den kommenden Blogartikeln erwarten dich detailliertere Einblicke. Wir werden uns intensiv mit der technischen Attributierung der einzelnen Elemente unseres BPMN-Modells befassen und deren Migration sowie Implementierung erläutern. Dabei werden wir auch Codebeispiele bereitstellen, um die Umsetzung zu veranschaulichen.

Du möchtest noch mehr über Camunda und Prozessautomatisierung erfahren? Dann schau doch bei unseren anderen Blogposts zu Business Process Management 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 2 (coming soon)
• 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.