Migration von Camunda 7 Prozessen auf Camunda 8

Camunda ist eine leistungsstarke Plattform für die Prozess- und Entscheidungsautomatisierung. Die Migration von Camunda 7 auf Camunda 8 stellt besondere Herausforderungen dar. Dieser Blogbeitrag soll Ihnen das Wissen und die Werkzeuge an die Hand geben, um den Umstieg strategisch zu planen und durchzuführen. Wir erklären die wichtigsten Unterschiede zwischen Camunda 7 und 8, warum sich eine Migration lohnt und wie die Migration anhand eines einfachen Beispiels gelingen kann. Dieser Migrationsleitfaden soll helfen, sich in der Komplexität zurechtzufinden und fundierte Entscheidungen auf dem Weg einer ersten Migration zu treffen.  
Dieser Blogbeitrag konzentriert sich auf die neuen Funktionen und Möglichkeiten von Camunda 8. Die Migration von bestehenden Camunda 7 Instanzen, einschließlich Prozessinstanzen und Datenbank, wird dabei nicht betrachtet. 

Für die praktischen Beispiele wird die BPM Übung von Novatec Consulting auf GitHub verwendet. Im ‚possible-solution‘-Branch von Kapitel 2 befindet sich eine Camunda 7.20 Spring Boot Anwendung mit einem BPMN-Prozess, einer DMN-Tabelle und mehreren Java-Delegates. Wir werden auf Camunda 8.6 migrieren. 

Hauptunterschiede

Camunda 7 und Camunda 8 unterscheiden sich in einigen wichtigen Aspekten. Wir werden kurz und prägnant auf diese eingehen, da es in diesem Blogbeitrag primär um die praktischen Migrationsschritte drehen soll: 

• Architektur: Camunda 8 basiert auf einer Cloud-nativen Architektur, d.h. es ist auf Skalierbarkeit und Ausfallsicherheit ausgelegt. Camunda 7 ist in erster Linie für On-Premise-Implementierungen konzipiert, die ein umfangreiches Infrastrukturmanagement erfordern können. 
• Job Worker vs. Java Delegates: In Camunda 7 werden häufig Java Delegates oder Job Worker (in Form von External Tasks) für die Ausführung von Geschäftslogik innerhalb von BPMN-Prozesse verwendet. In Camunda 8 werden stattdessen typischerweise Job Worker oder Konnektoren verwendet. 

Camunda 7: Service Tasks und Java Delegates: 

• Ausführungsmodell (Execution Model): Wenn in Camunda 7 ein BPMN-Prozess eine Service Task erreicht, wird das zugehörige Java Delegate oder die externe Task direkt in der Prozess-Engine ausgeführt. Dies bedeutet, dass die Geschäftslogik eng mit der Prozessausführung gekoppelt ist. 

• Deployment: Java Delegates wurden in der Regel als Teil der Anwendung verpackt, die die BPMN-Prozesse enthielt. Dies bedeutete, dass jede Änderung an der Geschäftslogik ein neues Deployent der gesamten Anwendung erforderte

@Component
public class StudentDelegate implements JavaDelegate {
    StudentInputPort studentInputPort;
    public StudentDelegate(StudentInputPort StudentInputPort) {
        this.studentInputPort = StudentInputPort;
    }
 
    @Override
    public void execute(DelegateExecution execution) {
        // Retrieve process variables from Camunda execution
        String email = (String) execution.getVariable("email");
 
        // Execute the use case
        boolean studentExists = studentInputPort.checkIfStudentExists(email);
 
        // Set process variable based on the result
        execution.setVariable("studentExists", studentExists);
    }
}

Camunda 8: Job Worker

Im Gegensatz dazu führt Camunda 8 einen flexibleren und entkoppelten Ansatz mit dedizierten Job Workern ein: 

• Execution Model: In Camunda 8 sind Job Worker externe Komponenten, die in beliebigen Programmiersprachen (z.B. Java, Node.js, Python) implementiert werden können. Sie warten auf Aufträge von der Prozess-Engine und führen diese selbstständig aus. Dadurch wird die Geschäftslogik von der Prozessausführung entkoppelt, was eine größere Flexibilität und Skalierbarkeit ermöglicht. 
• Kommunikation: Das Kommunikationsmodell hat sich auf ein asynchrones Muster verlagert. Wenn ein BPMN-Prozess eine Aufgabe erreicht: 
  • Die Prozess-Engine erstellt einen Auftrag (job) und stellt ihn in eine Warteschlange (queue). 
  • Job Worker fragen diese Warteschlange nach verfügbaren Aufträgen ab. 
  • Sobald ein Job Worker einen Auftrag erhält, führt er ihn unabhängig von der Prozess-Engine aus. 
  • Die Engine blockiert nicht, während sie auf den Abschluss eines Auftrags (job) wartet, sondern setzt die Verarbeitung anderer Aufgaben (tasks) oder Aufträge (jobs) fort. 
  • Skalierbarkeit: Mehrere Instanzen von Job Workern können unabhängig voneinander eingesetzt werden, um Aufgaben gleichzeitig zu bearbeiten. So können Unternehmen ihre Verarbeitungskapazitäten je nach Bedarf skalieren, ohne dass die Kernprozess-Engine beeinträchtigt wird. 
  • Flexibilität beim Deployment: Da Job Worker von den BPMN-Prozessen selbst getrennt sind, können sie unabhängig entwickelt, bereitgestellt (deployed) und skaliert werden. Das bedeutet, dass Sie Ihre Geschäftslogik aktualisieren können, ohne Ihre gesamte Workflow-Anwendung neu bereitstellen zu müssen. 

Beachten Sie, dass es in Camunda 8 keine Unterstützung für Java Delegates mehr gibt. Stattdessen wird der Code typischerweise von Job Workern oder Konnektoren ausgeführt. 

Konnektoren

Camunda 7: Konnektoren standen zur Verfügung, erforderten jedoch eigene Implementierungen oder Bibliotheken von Drittanbietern, um die Integration mit externen Systemen zu ermöglichen. 

Camunda 8: Konnektoren sind robuster und benutzerfreundlicher. Sie bieten vorgefertigte Integrationen mit verschiedenen Diensten (z.B. REST APIs, Datenbanken, etc.) out-of-the-box. Dies ermöglicht es Entwicklern, ihre Workflows einfach mit externen Systemen zu verbinden, ohne umfangreichen Code schreiben zu müssen.  
 
Einige Informationen zu Out-of-the-Box-Konnektoren finden Sie in der Übersicht der Camunda 8-Dokumentation, und ein Beispiel für einen Konnektor ist im AWS S3 Connector auf dem Camunda Marketplace verfügbar.

Zusammenfassung

Für weitere Lektüre siehe: Conceptual differences with Camunda 7 and Camunda 8 | Camunda 8 Docs . 

Warum auf Camunda 8 migrieren? 

Bevor wir uns die Migrationsschritte anschauen, wollen wir kurz erwähnen, warum sich eine Migration lohnen könnte: 

• Cloud-native Architektur: Camunda 8 ist für Cloud-Umgebungen konzipiert und bietet eine bessere Skalierbarkeit und Ausfallsicherheit. Somit passt es gut in die Cloud-Strategien eines Unternehmens. 
• Verbesserte Leistung: Camunda 8 nutzt eine neue Engine namens Zeebe, die die Leistung verbessert und die Latenzzeit reduziert (siehe weiterführende Informationen: Scaling Workflow Engines at Intuit with Camunda 8 and Zeebe | Camunda). 
• Verbesserte Benutzerfreundlichkeit: Die neue Tasklist und das Cockpit, in Camunda 8 nun Operate genannt, bieten eine intuitivere Oberfläche. Camunda 8 bietet außerdem Funktionen für die Zusammenarbeit bei der Erstellung von BPMN/DMN-Modellen, was die Prozessgestaltung erleichtert. 
• Message buffering: Camunda 8 ermöglicht das buffering von Nachrichten (messages), was die Komplexität von Prozessmodellen reduziert und die Datenkonsistenz verbessert. 
• Benutzerfreundliche Skriptsprache (FEEL): FEEL ist für Fachanwender leicht zu verstehen und unterstützt JSON-Datenstrukturen, was den Bedarf an technischem Fachwissen reduziert. 
• Out-of-the-box Konnektoren: Die Verwendung von vorgefertigten oder benutzerdefinierten Konnektoren verbessert die Automatisierung und Orchestrierung von Prozessen ohne umfangreiche Programmierkenntnisse. 

Themen

Im Folgenden werden wir verschiedene technische Bereiche von Camunda 7 unabhängig voneinander behandeln, so dass Sie jedes Thema für sich lesen können, wenn Sie nur an bestimmten Migrationsthemen interessiert sind. 

Wie bereits erwähnt, werden wir für einige praktische Beispiele unser BPM-Übung von GitHub verwenden. In Kapitel 2 auf dem ‚possible-solution‘ Zweig befindet sich eine Camunda 7.20 Spring Boot Anwendung mit einem BPMN-Prozess, DMN-Tabelle und mehreren Java Delegates: NovatecConsulting/bpm-exercise: First Steps with BPMN2.0 and Camunda7 . Wir werden auf Camunda 8.6 migrieren. 

Ihre aktuelle Situation und Umgebung 

Prüfen Sie Ihr aktuelles Setup: 

Bevor Sie mit der Migration beginnen, sollten Sie Ihre derzeitige Camunda 7 Umgebung prüfen. Identifizieren Sie die folgenden Punkte: 

• Prozesse: Listen Sie alle BPMN-Prozesse auf, die Sie implementiert haben. 
• Entscheidungsmodelle: Identifizieren Sie die verwendeten DMN-Entscheidungstabellen. 
• Benutzerdefinierter Code: Überprüfen Sie jeglichen benutzerdefinierten Java-Code oder externe Dienste, die in Ihre Workflows integriert sind (das Refactoring von Java Delegates zu Job Workers wird in einem nachfolgenden Blogbeitrag behandelt). 
• Beachten Sie, dass eine Aktualisierung Ihres Projekts erforderlich sein wird (das Entfernen der eingebettete Engine und Hinzufügen des Zeebe-Client wird notwendig sein). Achten Sie auf den Wechsel von Camunda 7 APIs zu Zeebe APIs oder Zeebe Client (dieses Thema gehört nicht zum Umfang dieses Blogbeitrags). 
   

Analysieren Sie Ihre bestehenden Prozesse 

Beginnen Sie mit der Analyse Ihrer bestehenden BPMN-Prozesse in Camunda 7. Identifizieren Sie alle Komponenten, die migriert werden müssen: 

• Java Delegates: Dies sind benutzerdefinierte Java-Klassen, die Geschäftslogik implementieren. 
• Service Tasks: Diese Tasks rufen externe Dienste auf oder führen bestimmte Aktionen aus. 
• User Tasks: Diese bleiben weitgehend unverändert, können aber Anpassungen in den Benutzeroberflächen erfordern. 
   

Beachten Sie, dass einige Aktivitäten und Werkzeuge, die in Camunda 7 verfügbar waren, in Camunda 8 nicht mehr vorhanden sein können. Diese können in späteren Versionen von Camunda 8 eventuell nachgeliefert werden. Eine Übersicht über alle Camunda 8 Versionen finden Sie hier. 

SaaS vs Self-Managed

Sie können entweder Ihre eigene Cloud-Umgebung einrichten und Camunda 8 selbst einsetzen (Self-Managed) oder ein Cluster von Camunda mieten und als Software-as-a-Service (SaaS) Lösung betreiben. Obwohl beide Optionen Teil der gleichen Anwendung sind, gibt es wichtige Merkmale und Unterschiede, die bei der Wahl zu berücksichtigen sind. Die Entscheidung hängt von Faktoren wie Vorschriften, Zeit- und Budgetbeschränkungen ab. Da es den Rahmen dieses Artikels sprengen würde, diese Unterschiede im Detail zu erläutern, konzentrieren wir uns in unserem Beispiel auf die Nutzung von Camunda 8 SaaS.

Praktische Bedeutung für unsere Anwendung 

In unserer Camunda 7 Anwendung aus Kapitel 2 aus unserem GitHub Repository (NovatecConsulting/bpm-exercise: First Steps with BPMN2.0 and Camunda7) fanden wir: 

• Einen BPMN-Prozess in main/resources: exam-registration.bpmn 
• Eine DMN-Tabelle in main/resources: examRegistrationPeriod.dmn 
• Ein Execution Listener in main/java/adapters/camunda: StartExectionListener.java 
• Mehrere Java Delegates in main/java/adapters/camunda 

Für unsere Umgebung verwenden wir eine Camunda 8 SaaS Instanz. 

Für unser einfaches Beispiel werden wir den Open Source Konverter verwenden, um eine schnelle Migration zu erreichen. Wir konvertieren unseren Camunda 7 BPMN-Prozess in einen Camunda 8 BPMN Prozess unter Verwendung der Webapp. 

Der Prozess sieht völlig gleich aus. Was sich geändert hat: 

• Alle JUEL-Ausdrücke in den Sequence Flows wurden zu FEEL konvertiert. 
• Alle Delegate-Aufrufe in den Service und Send Tasks mit ‚${exampleDelegate}‘ wurden von ‚delegateExpression‘ in Job-Typen mit ‚camunda-7-adapter‘ umgewandelt. 
• Das Element ‚fromData‘ in den Benutzeraufgaben (User Tasks) konnte nicht transformiert werden. Es sind weitere manuelle Anpassungen erforderlich. 
   

Mit der Konvertierung wird automatisch ein Bericht erstellt, der alle Elemente auflistet, die geändert oder transformiert wurden. 

Als Hinweis am Rand: Die manuelle Versionierung von Prozessen wird nicht mehr unterstützt (siehe hier). 

BPMN Elements

Update User Tasks

User Tasks behalten von Version zu Version meist eine ähnliche Struktur, können jedoch durch Änderungen an der Benutzeroberfläche (UI) oder neue Funktionen in Camunda 8 Anpassungen erfordern. Überprüfen Sie daher alle mit User Tasks verknüpften Formulare und stellen Sie sicher, dass die Frontend-Anwendungen, die mit diesen Aufgaben interagieren, entsprechend aktualisiert sind. 

Timer Events

Timer Intermediate Events werden unterstützt, erfordern dennoch möglicherweise Anpassungen, je nachdem wie Timeouts in der neuen Version verwaltet werden. 

Gateways

Es ändert sich fast nichts: Exklusive, parallele und ereignisgesteuerte (Event-Based) Gateways werden in Camunda 8 vollständig unterstützt und funktionieren weiterhin wie erwartet. Komplexe Gateways sind in Camunda 8 noch nicht enthalten. 

Messaging Events

In Camunda 8 wurden die Message Events für eine bessere Integration mit externen Systemen erweitert. Stellen Sie sicher, dass Ihre Nachrichtenkorrelationslogik entsprechend der neuen Ereignisbehandlungsmechanismen (event handling mechanisms) aktualisiert wird. Das Abonnement (subscriptions) von Nachrichten: Nachrichten werden nicht mehr direkt an Prozessinstanzen gesendet. Stattdessen basiert die Korrelation auf Abonnements, die den Nachrichtennamen und den ‚correlationKey‚ enthalten. 

Architektur 

Camunda 7: Verwendet eine monolithische Architektur, in der das Messaging direkt über die Prozess-Engine verwaltet wird. 

Camunda 8: Hier wird die Nachrichtenübermittlung häufig über externe Systeme oder Event-Streaming-Plattformen (wie Kafka) abgewickelt. 

Event handling 

Camunda 7: Nachrichten werden direkt innerhalb der Prozessinstanz verarbeitet, d.h. die Logik für den Empfang und die Verarbeitung von Nachrichten ist in der Engine selbst implementiert. 

Camunda 8: Bietet ein verbessertes Event Handling, das eine asynchrone Verarbeitung von Nachrichten ermöglicht. Das bedeutet, dass Prozesse besser auf externe Ereignisse reagieren können, ohne ständig aktiv sein zu müssen. 
 

Praktische Bedeutung für unsere Anwendung 

Betrachten wir den konvertierten Prozess, der nun eine Camunda 8 BPMN ist. 

Es gibt zwei User Tasks. In Camunda 7 gab es vom Typ ‚Generated Task Forms‘, wobei alle Formularfelder im Prozessmodell in den Eigenschaften der User Task definiert waren. Dies ist mit Camunda 8 nicht mehr möglich. Bei Camunda 8 können wir zwischen den Typen ‚Camunda Form‘ und ‚External form reference‘ wählen. Mit der Camunda 8 SaaS-Instanz nutzen wir ‚Camunda Form‘, vergeben eine Form ID und erstellen das Formular im Camunda Modeler. 

Das Timer Boundary Event bleibt gleich. Der Typ ‚Dauer‘ (duration) mit dem Wert ‚P7D‘ funktioniert in Camunda 7 und 8 gleich. 

Das Gleiche gilt für die Gateways: Die Ausdrücke in den Sequence Flows müssen von JUEL zu FEEL angepasst werden. Unser Camunda-7-zu-Camunda-8-Konverter hat diese Anpassung automatisch vorgenommen. Wir überprüfen lediglich, ob die FEEL-Ausdrücke korrekt und sinnvoll sind. Die Konvertierungsergebnisse sind einfach zu verstehen, z.B.: 

• Condition expression: Bitte überprüfen Sie den transformierten Ausdruck: ‚${studentExists}‘ -> ‚=studentExists‘. 
• Condition expression: Bitte überprüfen Sie den transformierten Ausdruck: ‚${!studentExists}‘ -> ‚=not(studentExists)‘. 

In unserem Prozess gibt es drei Message Tasks, die alle Send Tasks sind. Der Konverter hat daraufhin folgendes gemacht: 

• Das Attribut ‚delegateExpression‘ wurde auf ’sendTask‘ gemappt. Der Delegate-Aufruf an ‚${emailDelegate}‘ wurde in den Job-Typ ‚camunda-7-adapter‘ umgewandelt. Bitte überprüfen Sie Ihre Implementierung. 
   

Die Migration, die wir von Kapitel 2 des GitHub Repos durchführen, werden wir in einem Kapitel 3 bereitstellen. Dort könnne Sie sich den Code gerne selbst ansehen.

Camunda 7 Adapter

In diesem Kapitel wenden wir uns nun der Implementierung dieses sogenannten „camunda-7-Adapters“ zu, der von Spring Boot-Anwendungen verwendet werden kann. Dieses Open-Source-Projekt ermöglicht uns die Wiederverwendung bestehender Java Delegates, indem es sie alle sammelt und unter einem einzigen Worker-Topic ‚camunda-7-adapter‘ zur Verfügung stellt. Dieser Adapter ist nicht darauf ausgelegt, alle möglichen Situationen abzudecken, kann jedoch in bestimmten Fällen direkt eingesetzt werden.Die folgenden Schritte werden Sie durch den Prozess der Implementierung dieses Frameworks führen. 

1. Zuerst müssen wir den Camunda-Adapter als Abhängigkeit hinzufügen 

Gradle:

Implementation( “org.camunda.community.migration:camunda-7-adapter:${version}”)

Maven:

<dependency>
    <groupId>org.camunda.community.migration</groupId>
    <artifactId>camunda-7-adapter</artifactId>
    <version>${version}</version>
</dependency>

Die neueste Version ist hier zu finden. Ersetzen Sie die Abhängigkeiten von Camunda 7 durch Camunda 8. Beginnen Sie mit dem Hinzufügen des Camunda 8 SDK. 

Gradle:

Implementation( “io.camunda:spring-boot-starter-camunda-sdk:${sdkVersion}” )

Maven:

<dependency>
    <groupId>io.camunda</groupId>
    <artifactId> spring-boot-starter-camunda-sdk </artifactId>
    <version>${sdkVersion}</version>
</dependency>

Beachten Sie, dass nicht jede SDK Version mit dem Camunda 7 Adapter kompatibel ist. Zum Zeitpunkt der Erstellung dieses Artikels ist die letzte SDK Version, die mit der letzten Adapterversion kompatibel ist, sdkVersion = 8.6.5 mit adapterVersion = 0.10.1. Entfernen Sie nun die restlichen Camunda 7 Abhängigkeiten. 

3. Falls eine Jasper-Konfiguration oder eine andere Komponente vorhanden war, die die Engine nach außen sichtbar machte, entfernen Sie diese. Solche Komponenten sind nicht mehr erforderlich. 

4. Fügen Sie die Annotation ‚@EnableCamunda7Adapter‘ zu Ihrer Hauptklasse hinzu. 

5. Wenn Sie automatische Deployments von Klassenpfad-Ressourcen genutzt haben, fügen Sie die ‚@Deployment‘-Annotation hinzu und listen Sie alle Ressourcen auf, die Sie deployed sehen wollen. Wildcards werden ebenfalls unterstützt: 

Java:

Import io.camunda.zeebe.spring.client.annotation.Deployment;
 
@SpringBootApplication
@EnableCamunda7Adapter
@Deployment( resources = { “classpath:/path/to/converted-c8-exam-registration.bpmn” , “classpath:/business/decisions/*.dmn“ } )
public class Application {
    public static void main(String... args) {
        SpringApplication.run(Application.class, args);
    }
}

Bei dieser Konfiguration werden beispielsweise eine einzelne BPMN-Datei mit dem Namen „converted-c8-exam-registration.bpmn“ und alle DMNs, die sich in „/business/decision“ befinden, deployed. 

6. Schließlich können wir unsere Aufmerksamkeit auf das BPMN-Diagramm selbst richten. Um einen früheren Delegate-Ausdruck in einen Camunda-8-kompatiblen Worker umzuwandeln, setzen Sie einfach ‚camunda-7-adapter‘ als Job-Typ und fügen Sie einen benutzerdefinierten Header mit ‚delegateExpression‘ als Schlüssel und ‚${delegateName}‘ als Wert hinzu (wie oben im vorherigen Kapitel erwähnt). Im Grunde wurde die Definition lediglich in einen Header-Wert verlagert, anstatt in der Job-Definition selbst zu bleiben. Und fertig. Sie sollten nun in der Lage sein, Ihre BPMN mit der bestehenden Spring Boot Anwendung und einem Camunda 8 Cluster auszuführen. 

Die Migration zu Camunda 8 unter Verwendung des Camunda-7-Adapters bietet mehrere Vorteile: Sie ist schnell, einfach zu handhaben und erfordert keine expliziten Worker-Kenntnisse. Allerdings gibt es auch Einschränkungen, wie z.B. die Beschränkung auf die Camunda 7 Delegate API und die Kompatibilität mit der Camunda 8 SDK Version. DMN 

Decision Tables migrieren 

Die Migration von DMN ist im Wesentlichen nur ein Wechsel von JUEL zu FEEL. Die Konfigurationseinstellungen von modeler:executionPlatform und modeler:executionPlatformVersion in der XML werden automatisch aktualisiert, wenn Sie eine DMN-Datei in Camunda 8 Modeler hochladen: Adjust DMN models | Camunda 8 Docs. 

Praktische Bedeutung für unsere Anwendung 

Wir brauchten nichts an der DMN anzupassen. Daher haben wir die DMN so wie sie ist in unser Camunda 8 SaaS hochgeladen: 

Camunda Forms

Bei der Migration von Camunda 7 auf Camunda 8 ändert sich die Handhabung von Formularen. Hier ist eine Aufschlüsselung, was mit Camunda Forms während der Migration passiert: 

Form Types

In Camunda 7 gibt es mehrere Möglichkeiten, Formulare für User Tasks zu definieren: 

• Embedded Forms: HTML-Formulare, die direkt im BPMN-Modell definiert sind. 
• External Forms: Formulare, die außerhalb der Camunda Engine gehostet werden, oft unter Verwendung von Webanwendungen. 
• CamundaForms: Ein spezieller Typ von Formularen, der den Camunda Form Builder verwendet. 

In Camunda 8 können Sie zwar immer noch externe Formulare verwenden, aber das Konzept der Camunda Formulare hat sich geändert und eingebettete Formulare sind nicht mehr verwendbar. Der Fokus liegt mehr auf der Integration mit modernen Frontend-Frameworks und Anwendungen. 

Embedded (HTML) Forms

Wenn Sie in Camunda 7 eingebettete Formulare verwendet haben, müssen Sie diese in Camunda 8 auf ein neues Format migrieren: 

Recreate Embedded Forms: 

• Sie müssen alle eingebetteten Formulare neu erstellen, z. B. mit einer kompatiblen Frontend-Technologie (wie React, Angular oder Vue.js), da Camunda 8 einen flexibleren Ansatz für die UI-Entwicklung fördert. 
• Ändern Sie die entsprechenden User Tasks in Ihrem BPMN-Modell, um die neuen externen Formulare zu referenzieren. In Camunda 8 können Sie dies tun, indem Sie das Attribut Form Key auf die URL des externen Formulars setzen. 

Konvertierung der Formulare in Camunda 8 Forms: 

• Modellieren Sie die Formulare im Camunda 8 (Web) Modeler neu. 
• Diese Option bietet die Möglichkeit, in Zukunft weitere Formulare ohne weiteren Implementierungsaufwand erstellen zu können. 
• Ordnen Sie die Camunda 8 Formulare der entsprechenden User Task zu. 

External Forms verwenden

Für externe Formulare, die bereits in Camunda 7 implementiert wurden: 
Keine größeren Änderungen erforderlich: Funktionieren Ihre externen Formulare korrekt und sind sie über URLs erreichbar, können sie in Camunda 8 weiterhin verwendet werden. Überprüfen Sie lediglich, ob die Integrationspunkte weiterhin gültig sind. 

 
Datenbindung und Variablen 

Achten Sie bei der Migration von Formularen darauf, wie Datenbindung und Variablenbehandlung funktionieren: 

• Stellen Sie sicher, dass alle in Ihren Formularen verwendeten Variablen den Prozessvariablen in Ihren BPMN-Modellen korrekt zugeordnet sind. 
• Überprüfen Sie, wie Benutzereingaben erfasst und an die Prozess-Engine zurückgesendet werden. 
   

Fazit 

Zusammenfassend lässt sich sagen, dass Sie bei der Migration von Camunda 7 auf Camunda 8 Ihren Ansatz für Formulare erheblich anpassen müssen. Während externe Formulare oft mit minimalen Änderungen wiederverwendet werden können, müssen eingebettete Formulare mit modernen Webtechnologien oder dem Camunda 8 Modeler neu erstellt werden.  
 

Praktische Bedeutung für unsere Anwendung 

In unserer Anwendung haben wir unsere Camunda Formulare im Kapitel ‚BPMN Elemente‘ behandelt, d.h. wir haben die Formulare im Camunda 8 Modeler neu erstellt.

Fazit

Die Migration von Camunda 7 auf Camunda 8 erfordert eine sorgfältige Planung und Durchführung mehrerer Schritte, einschließlich der Umstellung von Java Delegates auf Job Worker und die Verwendung von Konnektoren für Service-Interaktionen. In unserem Beispiel haben wir die Verwendung des Camunda-7-Adapters in einer Art „erster Migration“ gezeigt. Im nächsten Schritt werden wir uns mit dem Refactoring von Java Delegates zu Job Workern beschäftigen. Dies wird in einem weiteren Blogbeitrag behandelt. 
 

Wenn Sie Fragen haben oder Unterstützung bei Ihrer Migration benötigen, können Sie sich gerne an uns wenden! 
 

Ressourcen 

Öffentliches GitHub-Repository (Novatec): NovatecConsulting/bpm-exercise: First Steps with BPMN2.0 and Camunda7