Camunda 7 Migration zu Flowable

Business Process Management

process-engine-migration-banner

Bereits im April 2022 hat Camunda das Ende des Produkts Camunda Platform 7 angekündigt. So wird die Community Edition im Oktober 2025 mit der Version 7.24 ihre letzte Veröffentlichung erfahren und die dazugehörigen Ressourcen auf GitHub archiviert. Kunden der Enterprise Version erhalten noch für einen überschaubaren Zeitraum zusätzlichen Support und ggf. Patch-Versionen auf dem entsprechenden Code-Stand. Der Nachfolger, Camunda 8, ist ein neuartiges Produkt, welches für den Einsatz in der Cloud vorgesehen ist und nur eingeschränkt mit seiner Vorgängerversion kompatibel ist. In einem vorherigen Beitrag haben wir bereits die Unterschiede zwischen den beiden Versionen dargestellt.

Vor dem Hintergrund des angekündigten Endes von Camunda 7 müssen sich Anwender dieser Platform Gedanken über den Umgang mit ihren Prozessanwendungen machen und wie sie in einer absehbaren Zeit ohne Camunda 7 umgehen werden. Camunda 8 ist dabei vielleicht nicht immer die erste Wahl, da sowohl die Migration als auch der Betrieb große Herausforderungen bedeuten können und der Einsatz des SaaS-Angebots aus nicht immer präferiert wird. Des Weiteren wird es ab Version 8.6 (Veröffentlichung im Oktober 2024) eine Änderung der Lizenzbestimmungen geben, nach welcher es keine Variante des Produkts mehr geben wird, die kostenlos in Produktion betrieben und genutzt werden darf. Aus diesem Grund möchten wir in diesem Artikel versuchen eine beispielhafte Prozessanwendung auf Basis von Camunda 7 zu anderen Lösungen zu migrieren.

Eine englische Version des Artikels finden Sie hier.

Ausgangssituation

Die Ausgangssituation bildet folgender fiktiver Rechnungsprozess¹: Rechnungseingangsdaten werden nach Betreff und Höhe geprüft. Abhängig vom Prüfungsergebnis muss die Rechnung händisch überprüft werden, bevor sie angenommen oder abgelehnt wird. Technisch enthalten sind in diesem Szenario folgende Elemente:

Start-Listener
Rule-Task umgesetzt als DMN
User-Task umgesetzt mit Camunda-Form
Service-Task ‘Accept Invoice’, implementiert als Java-Delegate
Service-Task ‘Decline Invoice’, implementiert als External-Task² (Blog Beitrag: Camunda External-Task-Worker)
Prozessschnittstelle zum Starten von Prozessinstanzen umgesetzt als Rest-Controller

Beispielprozess "Invoice Handling"

1: Inhaltlich stark verkürzter Prozess, es kommt vor allem auf die technischen Aspekte der Umsetzung an

2: Der Einfachheit halber befindet sich die Implementierung des External-Task-Workers mit im selben Projekt und ist nicht separat, dennoch findet die Kommunikation über die Rest-Api statt

Der Code zu unseren Beispielen ist auf GitHub zu finden: https://github.com/viadee/process-engine-migrations

Flowable

Genau wie Camunda bietet auch Flowable eine Open-Source-Plattform für Business Process Management (BPM) und Workflow-Automatisierungen auf Basis von BPMN. Beide Produkte haben jedoch mehr gemein als nur ihr Einsatzzweck, denn sowohl Camunda als auch Flowable stammen von der Activiti BPMN Engine ab. Während Camunda ein Fork aus dem Jahr 2013 ist, so entstand Flowable als Fork des gemeinsamen Ursprungs im Jahr 2016. Aus diesem Grund besteht Grund zur Annahme, dass einige der in der Camunda-Prozessanwendung genutzten Konzepte auch mit Flowable funktionieren werden.

Vorgehen bei der Migration

Folgende Schritte haben wir vollzogen um die Prozessanwendung auf Basis von Camunda 7 in eine Flowable Anwendung zu verwandeln.

Dependencies ersetzen

Als Ausgangspunkt für die Migration wird eine Spring Boot-Implementierung angenommen. Als erster Schritt muss die Camunda-Engine durch die Flowable-Engine ersetzt werden. Dafür wird mindestens der flowable-spring-boot-starter benötigt.

Für die Umsetzung des Service-Task als External-Task wird die Flowable Rest-Api vorausgesetzt, für die es ebenfalls ein entsprechendes Artefakt in Form eines Spring Boot-Starters gibt - genau wie man es auch aus der Camunda-Anwendung kennt.

Für die eigentliche Implementierung des External-Task-Workers gibt es bereits einen passenden Spring Boot-Starter, den wir ebenfalls als Abhängigkeit in unserem Projekt ergänzen.

Die notwendigen Abhängigkeiten in der pom.xml unseres Projekts sehen nun folgendermaßen aus, die vollständige Datei ist auf GitHub zu finden.

Nach dem Austausch der Abhängigkeiten gegen die entsprechenden Flowable-Artefakte ergeben sich aufgrund der nun fehlenden Klassen ein paar Kompilierungsfehler im Projekt, die wir beheben müssen.

Anpassung an die Flowable Java-API

Beim Beseitigen der Kompilierungsfehler kommt zum Tragen, dass Camunda und Flowable denselben Ursprung haben und viele Konzepte noch aus Activit-Zeiten stammen. Zum Beispiel die Interface-Klassen aus Activiti, etwa JavaDelegate.java, ExecutionListener.java und weitere. So kommt es, dass jene Java-Interfaces nahezu identisch funktionieren, natürlich mit Ausnahme der notwendigen Importe. Die eigentliche Implementierung bleibt in diesen Beispielen jedoch tatsächlich so wie sie war ohne verändert zu werden. Die Anpassungen am Delegate lauten lediglich:

Bzw. die entsprechende Anpassungen am Start-Listener:

External Task migrieren

Das External-Task-Pattern ist eine vor eingien Jahren eingeführtes Architekturmuster, über welches wir bereits in einem Beitrag berichtet haben. Seitens Camunda gibt es offiziell unterstütze Client-Bibliotheken u.a. für Java und auch einen Spring Boot-Starter, welcher die einige Aspekte der Konfiguration mit Defaults übernimmt. Auf der Seite von Flowable gibt es ebenfalls ein Spring Boot-Starter-Projekt, mit Hilfe dessen sich sog. FlowableWorker in bekannter Weise zu einem vorgegebenem Topic implementieren lassen.

An dieser Stelle gibt es einen Unterschied zwischen der Camunda- und der Flowable-Variante: Während Entwickler:innen in der Camunda-Lösung selbst für das Fertigstellung eines Tasks denken müssen, so bietet die Flowable-Lösung eine Implementierung also autoclosable Methode, d.h. der External-Task wird beendet, sobald die Methode fehlerfrei durchlaufen wurde, ggf. mit einem return-Wert für Variablen, die im Prozesskontext abgelegt werden sollen.

Application Properties anpassen

In unserem Demo-Projekt gehen wir von einem sehr rudimentärem Beispiel aus, welches wir lediglich lokal starten. Aus diesem Grund kommen beide Lösungen ohne eine umfassende Konfiguration aus. Die meisten Eigenschaften entfallen jeweils auf die Konfiguration der External-Tasks-Clients. Hier ein Vergleich der notwendigen Application-Properties (zusammengefasst in einer Datei):

Prozessmodell anpassen

Der in unserem Szenario aufwendigste Punkt ist die Migration des Prozessmodells. Dieses wurde ursprünglich mit Hilfe vom Camunda Desktop Modeler erstellt und ist in BPMN 2.0 modelliert, einem von der OMG verwaltetem Standard - Ein Standard, der jedoch sog. Custom-Extensions erlaubt. Dies bedeutet, dass sich im XML des Prozessmodells an einigen Stellen technische Attribute befinden, die aus dem Camunda-Namespace stammen und spezielle Anweisungen für die dazugehörige Process-Engine darstellen. Ein Service-Task sieht z.B. folgendermaßen aus:

Im Gegensatz zu Camunda stellt Flowable aktuell keinen frei verfügbaren Modeler oder Designer für die Prozessmodelle und Regeltabellen zur Verfügung. So ist in dieser von der MWIG gepflegten Liste BPMN-kompatibler Werkzeuge auch leider kein Flowable-Tool zu finden. Im OpenSource-Release Flowable 7.0.0 wurden das UI und der darin integrierte Modeler entfernt. Der von Flowable angebotene Designer ist an die SaaS-Lizenz geknüpft.

Nichtsdestotrotz, müssen einige Xml-Konstrukte aufgrund der Engine-spezifischen Tags angepasst werden. Für die Migration der Camunda-Prozessanwendung haben wir das Prozessmodell letztendlich mit dem IntelliJ-Plugin Flowable BPMN Visualizer geöffnet um den notwendigen Änderungen für die Migration auf eine andere BPMN-2.0 Engine auf die Spur zu kommen. Mit einer Mischung aus jenem Plugin, der Flowable-Dokumentation und dem Flowable-XML-Namespace sind wir schlussendlich zu einer lauffähigen Version gelangt, mit dessen Hilfe alle bisherigen Komponenten ausgeführt werden und funktionieren. Exemplarisch gegenübergestellt sind nachfolgend die jeweiligen Elemente für die Service-Tasks, jeweils als Java-Delegate und als External-Task. Das finale Ergebnis haben wir jedoch nicht durch eine Migration bzw. Anpassung des Originalmodells, sondern durch eine erneute Anfertigung des Prozessmodels mit Hilfe des IntelliJ-Plugins und manuellen Anpassungen erreicht.

Während der Camunda Desktop Modeler die Sequenzflüsse als eigene incoming- bzw. outgoing-Xml-Elemente in die entsprechenden Aktivitäten einfügt, so werden Prozessflüsse im Flowable Visualizer durch eigenständige sequenceFlow-Elemente mit sourceRef- bzw. targetRef-Attributen dargestellt.

Business Rule Task/ Decision Task

Einen größere Unterschied gibt es bei der Einbindung der Entscheidungsregel. Anders als in Camunda wird in Flowable hierfür eine Service-Task anstatt einer Business-Rule-Task verwendet. Die Service-Task wird von der FlowableEngine und dem Flowable Modeler als Decision Task interpretiert. Wiederum analog zu Camunda wird die Id des DMNs im BPMN referenziert (über den decisionTableReferenceKey).

Als letzter Schritt müssen die Ressourcen für das Prozessmodell und die Entscheidungstabelle für das Auto-Deployment von Flowable in den Ordner /resources/processes bzw. /resources/dmn verschoben werden, sowie die Endung des Prozessmodell von .bpmn auf .bpmn20.xml angepasst werden.

DMN anpassen

Teil der verwendeten DMN-Regel ist die Überprüfung, ob in einer übergebenen Variablen ein bestimmter Text enthalten ist oder nicht. In der ursprünglichen Entscheidungsregel für die Camunda Prozessanwendung wurde dafür ein FEEL-Ausdruck einbaut, der zur Laufzeit von der eingebauten DMN-Engine ausgewertet wird (FEEL: Friendly Enough Expression Language). Da Flowable diese Script-Sprache nicht unterstützt und stattdessen JUEL einsetzt (Java Unified Expression Language), muss die entsprechende Regel modifiziert werden. Aus dem FEEL-Ausdruck contains(reason, "important") wird ${reason.contains("important")}. Der Rest der kleineren Entscheidungstabelle konnte mit Ausnahme einer null-Prüfung, welche ebenfalls mit Hilfe von FEEL implementiert war, übernommen werden.

Vergleich der beiden Regeltabellen:

process-engine-migration-example-dmn-1

User-Tasks-Forms ersetzen

Für die verwendete User-Task-Form im Rahmen der User-Task wurde in der ursprünglichen Prozessanwendung eine Camunda-Form mitgeliefert, die an der entsprechenden Stelle zur Anzeige einer Aufgabe in der Camunda Tasklist geführt hat.

process-engine-migration-example-form

Im Gegensatz dazu bietet Flowable in der OpenSource Variante keine entsprechende Lösung. Aus diesem Grund haben wir als Workaround eine Rest-API geschaffen, über welche zum einen eine Liste aller zu erledigenden Aufgaben abrufen werden kann und zum anderen auch einzelne Aufgaben abgeschlossen werden können. Zusätzlich lassen sich über den zweiten Endpunkt auch die notwendig Variablen in den Prozesskontext speichern, die bei der Auswertung des anschließenden Gateways sind, so wie es letztendlich auch bei der Lösung mit Hilfe der Camunda-Tasklist passiert.

Die Verwendung der Task-Api sieht zum Beispiel folgendermaßen aus:

Fazit

Im Ergebnis haben wir es geschafft, die Camunda 7 Prozessanwendung zu einer Prozessanwendung auf Basis der OpenSource Lösung Flowable 7 zu migrieren. Der Erfolg wird durch die korrekte Ausgabe im Anwendungslog quittiert, welches in beiden Fällen gleich aussieht:

Zusammenfassend möchte wir folgende Aspekte festhalten:

Viele Schnittstellen zur Prozess-Engine funktionieren aufgrund der gemeinsamen Vergangenheit der beiden Produkte sehr ähnlich. Konzepte wie ein etwa ein Java-Delegate lassen sich auf identische Art weiterverwenden - einzige Ausnehme sind verständlicher Weise die notwendigen Java-Importe. Für neuere Konzepte wie das External-Task-Pattern gibt es ebenfalls bereits Ersatzmöglichkeiten, die sich schnell und einfach adaptieren lassen, inkl. einem Spring Boot-Starter.

Auch die Integration des BPMN-Prozessmodells ist sehr ähnlich wie es bereits aus dem Camunda Ökosystem bekannt ist. Die Verwendung von technischen Ausdrücken in der üblichen Schreibweise als „${ … }” ist jeder:m Prozessentwickler:in geläufig und stellt keine Schwierigkeit dar. Die Bezeichnung der techn. Attribute im Bpmn-Xml lassen sich in Dokumentation und Namespace ermitteln. Leider ist die Modellierung des Prozesses nicht so einfach und intuitiv möglich wie mit der Verwendung des Camunda Desktop Modelers oder einem damit kompatiblen Produkt. Das Zusammenspiel aus IntelliJ-Plugin und händischen Anpassungen im Xml ist eher sperrig, wenn auch möglich. Ein Tool zur Anzeige der laufenden Prozesse und Prozessinstanzen zur Ausführungszeit, wie man es als Camunda-Nutzer:in mit dem Camunda Cockpit gewöhnt ist, fehlt leider ebenfalls. Genauso gibt es in der verwendeten Version der Flowable-Lösung keine Möglichkeit Forms für User-Tasks zu entwerfen und diese angereichert mit Daten aus dem Kontext einer entsprechenden Prozessinstanz auf einer Tasklist zur Anzeige zu bringen und bearbeiten zu können. Unter der Annahme, dass die meisten Organisationen sich für die Integration ihres Aktivitätenmanagements jedoch bereits eigene Lösungen etabliert haben, so ist dieser Punkt für den Moment zu vernachlässigen, außer dass das Aktivitätenmanagement perspektivisch natürlich ebenfalls mit Flowable interagieren muss.

Zu beachten, dies ist ein Showcase um die ersten Schritte einer Alternative zu Camunda Platform 7 zu erproben. Für die Migration einer produktiven Anwendung gilt es zuvor mindestens alle verwendeten Konstrukte aus dem BPMN-Modellierungsstandard zu verproben und idealerweise bestehende Integrations- und Regressionstests mit der migrierten Prozessanwendung durchzuführen bevor sie freigegeben wird.

Haben Sie Fragen zu den Themen BPMN, Camunda oder Prozessautomatisierung, oder suchen Sie Unterstützung bei der Migration Ihrer Prozessanwendungen? Kontaktieren Sie uns gerne!

Oder besuchen Sie uns auf einem der kommenden Meetups zum Thema "Camunda 8: Chancen und Herausforderungen, ein Status Quo" in