Im vergangenen Monat fand ein weiterer Hackday des Kompetenzbereichs Business Process Management & Workflow Automation statt. In diesem haben wir im Team daran gearbeitet, den in einem vorigen Hackday erstellten BBHT-Referenzprozess von Camunda 7.18 auf Camunda 8.1 zu migrieren.
Ziel war es, den aktuellen Entwicklungsstand von Camunda 8 im Hinblick auf seine Nutzbarkeit in unserem typischen Kundenumfeld zu evaluieren und ein Zwischenfazit zu ziehen.
Nach einer kurzen Begrüßung, Einführung und Aufteilung auf Subteams bearbeiteten wir agil die Themen
- Anpassung des Prozessmodells,
- Prozessstart,
- Migration von Service- und User-Tasks sowie
- Deployment in die Camunda Cloud
Dabei konnten innerhalb kurzer Zeit erste Erfolge verbucht werden, und der erste Prozess wurde nach nur zwei Stunden Arbeit gestartet.
Im weiteren Verlauf des Hackdays zeigte sich jedoch, dass Camunda 8 noch einige Features fehlen, die heute in Camunda 7 verfügbar sind und die bei unseren Kunden und auch in unserem Referenzprozess aktuell verwendet werden. Diese haben wir nachfolgend zusammengefasst.
Unterstützung von BPMN-Elementen
Im Vergleich zu der klassischen Workflow-Engine in Camunda 7 zeigt sich bei Camunda 8 ein anderer Umfang an unterstützten Notationselementen der BPMN.
Eine Unterstützung im gleichen Umfang findet sich bei Tasks und Gateways, ebenso wie bei Pools und Lanes. Ein erster Unterschied zeigt sich bei der Unterstützung von Subprozessen - hier bietet Camunda 8 derzeit keine Unterstützung für Transaktionssubprozesse; was ein Fall ist, der in der Realität jedoch eher selten auftritt.
Die größten Unterschiede finden sich bei den Events. Hier ist ein - im Vergleich zu Camunda 7 - stark eingeschränkter Umfang zu finden.
Die Event-Arten “None”, “Message”, “Timer”, “Error” und “Terminate” werden nach wie vor vollständig unterstützt. Anders sieht es mit den folgenden, bisher in Camunda 7 unterstützten, Event-Typen aus:
- Conditional
- Link
- Signal
- Escalation
- Compensation
- Cancel
Abbildung: In Camunda 8 nicht mehr unterstützte Modellierungselemente
Die Event-Typen “Conditional”, “Link”, “Escalation” und “Cancel” (das nur im Kontext der Transaktionssubprozesse genutzt wird) kommen im Umfeld unserer Kunden selten bis gar nicht vor; daher ist es hier verschmerzbar, dass diese bislang nicht umgesetzt wurden.
Anders sieht es mit dem “Signal” und vor allem dem “Compensation”-Event aus. Es fehlt insbesondere die Kompensation, die in fachlich getriebenen Prozessen häufig verwendet wird, um vorher ausgelöste Datenänderungen bei Ausnahmebehandlungen oder dem Abbruch eines Prozesses rückgängig zu machen. Es gibt auch keine Workarounds, um die Semantik der Kompensation durch eine andere Modellierung zu ersetzen.
Implementierung von Service Tasks
Camunda 7 stellt grundsätzlich zwei Arten zur Verfügung, um Service Tasks zu implementieren: zum Einen in Form von sog. Delegates, die eine Java-Implementierung “im Bauch” der Camunda-Prozessanwendung darstellen, und zum Anderen mithilfe von Workern - eigenständigen Programmen, die remote bei der Prozessanwendung per REST-API anfragen, ob neue Service-Aufgaben vorliegen und diese dann für sich beanspruchen, abarbeiten und das Ergebnis an die Prozessanwendung zurückmelden.
Camunda 8 verfolgt mit der neuen Zeebe-Engine nun nicht mehr den Ansatz, Prozessanwendungen im Ganzen auszuliefern, sondern bietet die Engine als Service Plattform an, die externe Worker orchestriert.
Das erleichtert die Umstellung für Projekte, die bereits in Camunda 7 mit externen Workern gearbeitet haben, da hier die Anpassungen geringer sind.
Dennoch ist die Migration der Delegates zu externen Workern ebenfalls nicht mit zu großen Schmerzen verbunden und geht mit ein wenig Vorausplanung gut von der Hand. Für eine schnelle Erstmigration wurde von der Camunda-Community sogar ein Adapter zur Verfügung gestellt, mit dem bestehende JavaDelegates weiterhin genutzt werden können.
Workflow Engine Plugins
Ein häufig bei unseren Kunden eingesetztes Hilfsmittel von Camunda 7 sind “Execution Listener”, die als Plugin in der Workflow Engine unabhängig von einem konkreten Prozess ausgeführt und wiederkehrende Aufgaben erledigen konnten. Hierzu gehörten beispielsweise die Prüfung sowie Vorbelegungen von Prozesskontextvariablen, das Loggen von ausgeführten Prozessschritten oder das Senden von Benachrichtigungen an Sachbearbeiter:innen bei der Zuweisung von User Tasks.
Dieses Plugin-Konzept ist in Camunda 8 nicht mehr enthalten. Abhängig vom Anwendungsfall ist es möglich, die Funktionalität in die externen Worker zu verlagern, oder Plugin-Aktionen in eigene, der Workflow Engine vorgeschaltete Dienste zu verlagern.
Direkte Datenbankzugriffe
Die Daten in Camunda 7 werden in relationalen Datenbanken persistiert. Da Camunda die Datenstruktur offen gelegt und ausführlich dokumentiert hat, war es sehr einfach möglich, Daten zu Prozessen, ihren Instanzen, Ausführungen und Kontextvariablen direkt aus der Datenbank abzufragen oder (in Ausnahmefällen) sogar auch zu beschreiben.
In unserem Kundenumfeld wird dieses Feature z.B. für die Überführung von Prozessdaten in Data Warehouses genutzt. In Camunda 8 gibt es diese Möglichkeit in der Cloud-Variante nicht mehr. Stattdessen kann das mitgelieferte Camunda Optimize für das Prozess-Monitoring und -reporting verwendet werden. Für eine selbst-gehostete Installation können Prozessdaten über den Zeebe Elasticsearch Exporter exportiert und per ETL in ein DWH übertragen werden.
User Task-Formulare
Bei den User Tasks stellt Camunda die Möglichkeit zur Verfügung, im Camunda Modeler einfache Task Forms zusammenzustellen, die im BPMN-Modell zu einer User Task hinterlegt werden können.
Für einfache User Tasks mit vorgegebenen Werten ist dies ein gutes Werkzeug; bei komplexeren User Tasks sind die Mittel des Tools leider schnell ausgereizt.
Abbildung: Modellierung einfacher User Task-Formulare in Camunda Modeler
Da die meisten größeren Unternehmen aber eigene Tasklisten anbieten (entweder in Form von Eigenentwicklungen oder in CRM-Systemen integriert), bietet sich hier stattdessen eine Integration an die bestehenden Lösungen an. Hierfür sind eine Vielzahl von Bibliotheken für unterschiedliche Programmiersprachen zu finden, die einem diese Arbeit erleichtern. Bestehende Anbindungen an Camunda 7 müssen umgeschrieben werden; die APIs ähneln sich jedoch, so dass der Umstieg erleichtert wird.
Cloud oder lokal?
Die Entwicklung fand zuerst unter Nutzung der Camunda 8-Cloudlösung statt.
Die Anlage sowohl des Camunda Cloud-Accounts als auch der Zeebe-Engine-Instanz war sehr nutzerfreundlich und verlief problemlos. Auch das Modellieren, Deployen und Starten des Prozesses verlief absolut unkompliziert. Gelegentlich traten Synchronisierungsprobleme im Web Modeler auf, die aber durch ein Neuladen schnell zu beheben waren.
In der freien Lösung der Camunda Cloud können maximal fünf Benutzer-Accounts für das verteilte Arbeiten miteinander verbunden werden. Bei der Evaluation haben wir ebenfalls die Kosten der Cloudlösung betrachtet. Die kleinste Abonnement-Variante “Professional” stellt sich wie folgt dar:
- Es kann ein BPMN-Modell ohne Kosten deployed werden; jedes weitere Modell wird mit 30$ veranschlagt.
- Pro Monat können von diesem Modell 50 Prozessinstanzen kostenlos ausgeführt werden; jede weitere Instanz schlägt mit 2$ zu Buche.
- Im Modell enthaltene DMN-Entscheidungen führen nach den ersten 50 kostenfreien Instanzen zu Mehrkosten von 0,50$ je Instanz.
- Es gibt 10 kostenfrei Benutzer:innen für die Camunda-Oberflächen; weitere werden mit 80$ je Nutzer veranschlagt.
- Für alle Benutzer:innen, die eine User Task bearbeiten dürfen, werden 15$ per Benutzer veranschlagt.
Camunda bietet hier an vielen Stellen Discounts an, wenn man sich hier für einen “Enterprise”-Plan entschließt.
Da sich vermutlich nicht jeder Kunde für eine Cloudlösung entscheidet, haben wir zudem auch ein lokales Deployment des Camunda 8-Stacks getestet. Die lokale Variante konnte bereits nach kurzer Zeit eingerichtet werden.
Bei dem Versuch, mithilfe von Docker eine Camunda 8-Umgebung auf Entwicklungsrechnern zu starten, stellten wir fest, dass dieses mit Rechnern mit x86-Architektur (Windows oder ältere MacBooks) gut funktioniert. Auf der ARM-basierten Architektur neuerer MacBooks jedoch konnte die Camunda 8-Umgebung - trotz installiertem Rosetta Stone - nicht gestartet werden.
Fazit
Ist Camunda 8 bereit für den produktiven Einsatz?
Wie so häufig lautet die Antwort: es kommt auf den Anwendungsfall an. Für Prozesse, die nicht auf besondere Events wie die Kompensation angewiesen sind, ist Camunda 8 schon jetzt eine Alternative. Für bestehende Geschäftsprozesse, die den erweiterten Umfang an BPMN-Elementen nutzen, empfehlen wir derzeit noch den Einsatz von Camunda 7.
Bei dem Wechsel auf Camunda 8 sollte man sich im Voraus darüber klar sein, wie hoch das monatliche Volumen an Prozess- und Entscheidungsinstanzen sein wird, und entsprechende Kosten für die Cloud- oder die produktiv eingesetzte Self-Managed-Lösung einplanen.
