Von Activiti zu nativem Java: Wann sich eine Process Engine nicht mehr lohnt

In einem unserer Systeme liefen drei Geschäftsprozesse – unter anderem für die Archivierung von Urkunden – als BPMN-Modelle auf einer Activiti-Engine. Die eingesetzte Version war in die Jahre gekommen, und ein Upgrade hätte einen erheblichen Aufwand bedeutet. Wir standen vor der Frage: Engine modernisieren oder die Prozesse direkt im Code abbilden?

Wir haben uns für Letzteres entschieden. Dieser Beitrag beschreibt, warum, wie wir vorgegangen sind und was wir beim nächsten Mal anders machen würden.

Ausgangslage

Die drei Prozesse waren fachlich überschaubar. Trotzdem hing an ihnen eine komplette Process Engine mit eigenem Datenbankschema, eigener Konfiguration und eigenen Abhängigkeiten.

Im Betrieb zeigten sich zwei Probleme. Erstens schlugen Prozessinstanzen gelegentlich fehl und ließen sich danach nicht sauber fortsetzen. Zweitens war die Fehlersuche mühsam: Wer verstehen wollte, warum ein Prozess an einer bestimmten Stelle hängen blieb, musste zwischen BPMN-Modell, Engine-Tabellen und Java-Code hin- und herspringen.

Ein Upgrade hätte daran wenig geändert. Aktuelle Activiti-Versionen setzen auf Java 17 und Spring Boot 3 (Activiti 8.0.0 Release Notes) – für uns wäre das ein größerer Migrationsschritt gewesen, nur um drei einfache Abläufe weiterzubetreiben.

Wann eine Process Engine sinnvoll ist

Wir sind nicht grundsätzlich gegen Process Engines. Sie spielen ihre Stärken aus, wenn

• Prozesse lang laufen und menschliche Aufgaben, Fristen oder Eskalationen enthalten,
• viele Systeme, Abteilungen oder Personen beteiligt sind,
• Abläufe häufig geändert werden und die Fachabteilung das Modell selbst pflegen soll,
• Nachvollziehbarkeit und Monitoring einzelner Instanzen zentral sind.

Bei wenigen, kurzen und stabilen Prozessen kehrt sich das Verhältnis um. Dann kosten Betrieb, Wartung und Upgrades mehr, als die Engine an Flexibilität zurückgibt.

Diese Abwägung betrifft gerade viele Teams: Für Camunda 7 Community Edition erschien mit Version 7.24 im Oktober 2025 das letzte Feature-Release, danach gibt es keine weiteren Releases und keine Sicherheitsupdates mehr (Camunda, 2025). Wer dort betroffen ist, sollte ehrlich prüfen, ob eine Migration auf eine neue Engine nötig ist – oder ob einfacher Code die bessere Wahl wäre.

Vorgehen

1. Einstiegspunkte verstehen. Zuerst haben wir alle REST-Aufrufe nachverfolgt, die einen Prozess starten, und die Stellen identifiziert, an denen Ergebnisse an die Benutzer zurückgehen. Damit war klar, wo die neue Implementierung andocken muss.

2. Aktivitäten zusammenfassen. Der bestehende Activiti-Code war auf viele kleine Methoden verteilt, von denen etliche fachlich zusammengehörten. Wir haben die rund zehn Einzelschritte zu drei zusammenhängenden Methoden verdichtet. Das hat den Code verständlicher gemacht und war die Grundlage für alles Weitere.

3. Ohne Engine neu implementieren. Die drei Methoden haben wir anschließend ohne Bezug auf Activiti umgesetzt. Den Prozesszustand, den vorher die Engine über Prozessvariablen verwaltet hat, speichern wir jetzt in einer eigenen Tabelle. Abfragen wie createTaskQuery() wurden durch gewöhnliche JPA-Abfragen mit Hibernate ersetzt.

4. Wiederholen und aufräumen. Diesen Ablauf haben wir für alle drei Prozesse wiederholt und zum Schluss den Code refaktoriert.

Der Ansatz entspricht im Kleinen dem, was Martin Fowler als Strangler Fig beschreibt: Das Neue wächst schrittweise neben dem Alten, bis das Alte nicht mehr gebraucht wird.

Aufwand

Die Umstellung hat insgesamt etwa einen Monat gedauert – mehr, als die fachliche Einfachheit der Prozesse vermuten ließ. Die meiste Zeit ging nicht in das Schreiben des neuen Codes, sondern in das Aufspüren von Verhalten, das die Engine stillschweigend übernommen hatte, und in das Beheben der daraus entstehenden Fehler.

Was wir gelernt haben

Planung spart Zeit. Anfangs sind wir zu direkt in den Code eingestiegen. Wir haben uns in Details verloren, und wenn etwas nicht funktionierte, war schwer nachzuvollziehen, welche Änderung die Ursache war. Kleinere, klar abgegrenzte Schritte – jeweils mit Test – hätten uns am Anfang viel Zeit erspart.

Eine Engine macht mehr, als man denkt. Timeouts, parallele Prozessinstanzen, das Fortsetzen nach einem Fehler und das Wiederaufsetzen ab dem letzten erfolgreichen Schritt: All das hat Activiti mitgebracht, und all das mussten wir selbst nachbauen. Wer eine Engine ablöst, sollte diese Liste vorab vollständig erstellen.

Fazit

Für unseren Fall war die Ablöse die richtige Entscheidung. Die Prozesse sind heute einfacher zu lesen, zu testen und zu debuggen, und eine ganze Abhängigkeit samt Upgrade-Pfad ist weggefallen. Eine allgemeine Empfehlung gegen Process Engines ist das nicht – aber ein Plädoyer dafür, ihren Einsatz regelmäßig zu hinterfragen.

Quellen

• Activiti: Release 8.0.0 – Activiti & Activiti Cloud Developers Guide
• Camunda: Camunda 7 Enterprise End of Life (EoL) Extension Announcement (Februar 2025)
• Fowler, Martin: Strangler Fig (2024)
• Object Management Group: Business Process Model and Notation (BPMN) 2.0