In diesem Blogpost erläutern wir die Erkenntnisse eines Experiments, eine Camunda 7-Prozessanwendung auf Flowable zu migrieren.
Warum sollten wir eine solche Migration überhaupt ausprobieren? Camunda hat bereits im April 2022 das End-of-Life für die Camunda Platform 7 angekündigt. Die Community Edition wird im Oktober 2025 ihre letzte Version (7.24) erleben, danach werden die zugehörigen Ressourcen archiviert. Enterprise-Kunden bekommen noch bis mindestens 2030 Support. Vor dem Hintergrund des angekündigten Endes von Camunda 7 müssen sich Anwender dieser Plattform Gedanken über den Umgang mit ihren Prozessanwendungen machen und, wie sie in einer absehbaren Zeit ohne Camunda 7 auskommen werden.
Der Nachfolger, Camunda 8, ist ein neuartiges Produkt, mit vielen Features und Verbesserungen, welches für den Einsatz in der Cloud ausgelegt ist. In einem vorherigen Beitrag haben wir bereits die Unterschiede zwischen den beiden Versionen dargestellt. Camunda 8 bietet zahlreiche Vorzüge bei Performance und Skalierbarkeit sowie dem angebotenem Funktionsumfang im Bereich Low-Code und Konnektoren. Auch das Betriebsmodell der Remote-Engine birgt im skalierten Unternehmenseinsatz durchaus Vorteile, da insbesondere verteilten Teams sich noch stärker auf die Umsetzung von Fachlichkeit fokussieren können. Abhängig vom bisherigen Einsatzszenario kann es aber auch notwendig sein, Alternativen zu beleuchten, da es beispielsweise keine Möglichkeit für den Betrieb als embedded Process-Engine gibt. Ebenfalls können notwendige architekturelle Veränderungen und der Betrieb der Plattform Herausforderungen darstellen. Dieser Blogpost ist weder eine explizite Migrationsempfehlung, noch soll er einen Vergleich verschiedener Process-Engines darstellen. Um dies zu bewerkstelligen, müssten wie deutlich weiter ausholen, als uns ein einzelner Blogpost erlaubt.
Für Fragestellungen zur Migration Camunda 7 auf Camunda 8, empfehlen wir unsere Blogserie "Aus 7 mach 8".
In diesem Blogpost werden wir euch nun anhand eines beispielhaften Prozesses zeigen, wie die Migration von Camunda 7 zu Flowable aussehen könnte. Dabei geht es weniger um eine detaillierte Anleitung oder gar Empfehlung, sondern vielmehr um Einblicke und Erkenntnisse, die wir bei unserem Experiment gesammelt haben.
Eine englische Version des Artikels finden Sie hier.
Ausgangssituation
Die Ausgangssituation bildet folgender fiktiver Rechnungsprozess1: 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-Task2 (Blog Beitrag: Camunda External-Task-Worker)
- Prozessschnittstelle zum Starten von Prozessinstanzen umgesetzt als Rest-Controller
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 an die Fertigstellung eines Tasks denken müssen, so bietet die Flowable-Lösung eine Implementierung als 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:
|
|
 |
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.
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 zwar geschafft, die Camunda 7 Prozessanwendung zu einer Prozessanwendung auf Basis der OpenSource Lösung Flowable 7 zu migrieren und zu starten, jedoch zeigt der Versuch, dass für eine produktionsreife Migration noch weitere Schritte notwendig sind, vor allem bei komplexeren Lösungen als der ausgedachte Rechnungsprozess. Der Erfolg unseres Experiments wird durch die korrekte Ausgabe im Anwendungslog quittiert, welches in beiden Fällen gleich aussieht:
Zusammenfassend möchten 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 Ausnahme sind verständlicherweise 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.
Soweit die positiven Neuigkeiten. Es gibt aber auch Schwächen auf Seiten Flowables:
- Leider ist die Modellierung des Prozesses nicht so einfach und intuitiv möglich wie mit dem Camunda Desktop Modeler oder einem kompatiblen Produkt. Das Zusammenspiel aus IntelliJ-Plugin und händischen Anpassungen im XML ist zwar möglich, aber nicht wirklich alltagstauglich.
- 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.
Wichtiger Hinweis: Die hier skizzierten Erfahrungen stammen aus einem Experiment und sind nicht als Migrationsempfehlung zu verstehen. Generell sollte man sich fundiert (und umfangreicher als wir es in diesem Blogpost tun können) mit dem Thema einer Migration auseinandersetzen und fundiert mögliche Alternativen (insbesondere camunda 8) und Architekturen bewerten.
Haben Sie Fragen zu den Themen BPMN, Camunda oder Prozessautomatisierung, oder suchen Sie Unterstützung bei der Migration Ihrer Prozessanwendungen? Kontaktieren Sie uns gerne!
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
