Funktionalität in einer BPMN-basierten Geschäftsprozessanwendung nachhaltig implementieren
Von Ludger Schönfeld, 27.04.2026, Geschätzte Lesedauer: ca. 10 Minuten
Viele Unternehmen stehen aktuell vor der Herausforderung, ihre Camunda‑7‑basierten Geschäftsprozessanwendungen in eine Zukunft ohne Camunda 7 zu überführen. Die Abkündigung ist offiziell (siehe [1]), der Support läuft aus – ein Wechsel auf eine andere BPMN Process Engine wird unausweichlich.
Dabei taucht immer wieder dieselbe Annahme auf: Dass der Wechsel vom klassischen Delegate‑Ansatz hin zum External‑Task‑Pattern automatisch einen „migrationsfreundlichen“ oder gar „engine‑agnostischen“ Zustand erzeugt. Doch genau das ist ein gefährlicher Irrtum.
In diesem Artikel konzentriere ich mich bewusst auf die ergänzende Funktionalität einer Geschäftsprozessanwendung – jene fachliche Logik, die nicht in BPMN‑Abläufen oder DMN‑Modellen steckt, sondern zusätzlich implementiert werden muss. Dieser Teil wird in Migrationsstrategien häufig unterschätzt, obwohl er entscheidend dafür ist, ob eine Anwendung langfristig wartbar, modernisierbar und wirklich unabhängig von einer konkreten BPMN Process Engine bleibt.
Einleitung: Die Situation
Unternehmen, die Camunda 7 als eingebettete Process Engine im Einsatz hatten, stehen heute vor einer strategisch wichtigen Entscheidung. Mit der offiziellen Abkündigung und dem auslaufenden Support wird ein Wechsel auf eine andere BPMN Process Engine unvermeidlich. Viele Teams beginnen daher, ihre bestehenden Geschäftsprozessanwendungen auf eine Migration vorzubereiten.
Auf einer Konferenz im März 2026 wurde jedoch erneut deutlich, wie verbreitet das Missverständnis ist, dass der Wechsel vom klassischen Delegate‑Ansatz hin zum External‑Task‑Pattern (siehe [3]) automatisch zu einem „migrationsfreundlichen“ oder gar „engine‑agnostischen“ Zustand führt. Die dahinterliegende vermeintliche Annahme: Wenn die fachliche Logik nicht mehr direkt in der Process Engine ausgeführt wird, sei man automatisch unabhängiger.
Doch diese Schlussfolgerung greift zu kurz. Das External‑Task‑Pattern wurde seitens Camunda ursprünglich eingeführt, um rechenintensive oder langlaufende Aufgaben aus der Engine auszulagern – und um die Implementierung solcher Aufgaben in beliebigen Programmiersprachen zu ermöglichen, statt an die Java Virtual Machine gebunden zu sein. Heute wird es jedoch häufig als generelles Integrationsmuster interpretiert, was dazu führt, dass fachliche Prozessablauflogik und systemspezifische Integrationslogik vermischt werden. Das erhöht den Wartungsaufwand und schafft unnötigen Implementierungs‑Overhead.
Um echte Migrationsfähigkeit zu erreichen, ist es entscheidend, die ergänzende Funktionalität einer Geschäftsprozessanwendung sauber zu strukturieren. Ausgangspunkt ist dabei immer der Geschäftsprozess selbst: Für jede fachliche Aufgabe stellt sich aus Sicht der Fachexperten die zentrale Frage, wie die benötigte Funktionalität realisiert wird.
Wird sie bereits durch bestehende Systeme der Unternehmenslandschaft bereitgestellt – und kann somit über den definierten Servicevertrag der Geschäftsprozessanwendung wiederverwendet werden? Oder handelt es sich um Funktionalität, die nicht zentral verfügbar ist und deshalb neu implementiert werden muss? In diesem Fall fällt sie in die Verantwortung der Geschäftsprozessanwendung selbst.
Der Servicevertrag der Geschäftsprozessanwendung beschreibt die fachlichen Anforderungen der Geschäftsprozesse an die Systemlandschaft – basierend ausschließlich auf dem Datenmodell der Geschäftsprozessanwendung. Das Konzept stammt aus dem prozessgesteuerten Ansatz nach Volker Stiehl (siehe unten).
Aus dieser Analyse ergeben sich zwei klar voneinander getrennte Kategorien von Funktionalität:
- Vorhandene Funktionalität, die über bestehende Systeme realisiert wird.
- Neue, anwendungsspezifische Funktionalität, die innerhalb der Geschäftsprozessanwendung implementiert und verantwortet wird.
Erst wenn diese beiden Bereiche konsequent unterschieden und architektonisch sauber umgesetzt werden, entsteht eine Anwendung, die langfristig wartbar ist – und tatsächlich unabhängig von der eingesetzten Process Engine. Der Grund dafür liegt in der unterschiedlichen Art ihrer Implementierung:
- Neue, anwendungsspezifische Funktionalität gehört vollständig in die Verantwortung der Geschäftsprozessanwendung. Sie wird daher synchron zwischen Geschäftsprozess und der jeweiligen Funktionalität ausgeführt, sodass fachliche Ablauflogik klar nachvollziehbar bleibt und eng mit dem Prozessmodell abgestimmt ist.
- Vorhandene Funktionalität hingegen wird als Teil der Systemlandschaft betrachtet. Um die Robustheit der Geschäftsprozessanwendung sicherzustellen, erfolgt die Kommunikation mit diesen externen Systemen bewusst asynchron. Dadurch wird verhindert, dass technische Störungen der Umgebung die Geschäftsprozessanwendung blockieren oder destabilisieren.
Diese klare Trennung – synchron intern, robust asynchron extern – führt zu einer Architektur, in der Verantwortlichkeiten eindeutig sind, Integrationspunkte stabil bleiben und die Anwendung auch bei einem Wechsel beispielsweise der Process Engine konsistent weiterbetrieben werden kann.
Um dies greifbar zu machen, betrachten wir ein einfaches Beispiel:
In einem Beschaffungsprozess existiert ein Subprozess, der die Zahlung an den Lieferanten koordiniert. Dazu werden zunächst die relevanten Rechnungsdaten aus der eingehenden Rechnung extrahiert, anschließend durch einen Buchhalter geprüft und schließlich zur Buchung freigegeben.
Wir fokussieren uns auf die Aufgabe „Rechnungsdaten erfassen“ (engl. "Capture Invoice Details"). Aus fachlicher Sicht ist dies eine reine fachliche Aufgabe – unabhängig davon, ob sie später manuell oder automatisiert ausgeführt wird. Für die weitere Diskussion habe ich sie bewusst als BPMN‑undefinierte Aufgabe modelliert.
Für die Umsetzung nutze ich den ganzheitlichen, herstellerneutralen Prozessgesteuerten Ansatz nach Volker Stiehl zur Implementierung BPMN‑basierter Geschäftsprozesse innerhalb einer Geschäftsprozessanwendung, verstanden als digitales Produkt im digitalen Transformationszeitalter. Diese auf BPMN-Prozessmodellen basierende Projektabwicklungs- und Implementierungsmethodik stellt sicher, dass Geschäftsprozessanwendungen flexibel, transparent, nachhaltig und langfristig wartbar implementiert werden. Er kombiniert Best Practices aus Prozessmethodik, agiler Vorgehensweise, Softwareentwicklung und Softwarearchitektur (siehe [2]).
Der hier beschriebene Aspekt –die strukturierte Implementierung der ergänzenden Funktionalität – ist ein zentrales Element der Prozessgesteuerten Architektur, der Referenzarchitektur, die im Rahmen des Prozessgesteuerten Ansatzes als Blueprint für Geschäftsprozessanwendungen dient. Wer mehr über den Prozessgesteuerten Ansatz und die dazugehörige Prozessgesteuerte Architektur erfahren möchte, findet weiterführende Informationen in [2].
Szenario I: Vorhandene Funktionalität & Daten aus der Systemlandschaft wiederverwenden
Abbildung 1: (c) Ludger Schönfeld
Ein großer Teil der benötigten Funktionalität in Geschäftsprozessanwendungen existiert bereits in der Systemlandschaft – etwa in ERP‑, CRM‑ oder DMS‑Systemen. Ziel ist es daher, diese vorhandenen Fähigkeiten wiederzuverwenden, statt sie neu zu implementieren. Das folgende Beispiel zeigt das Prinzip in vereinfachter Form.
Im Beschaffungsprozess betrachten wir die Aufgabe „Rechnungsdaten erfassen“. Aus fachlicher Sicht benötigt der Prozess eine Funktion, die Rechnungsinformationen extrahiert und bereitstellt. Welches System diese Fähigkeit liefert, ist für die Fachexpert:innen irrelevant – entscheidend ist allein die fachliche Anforderung.
Damit die Geschäftsprozessanwendung robust und fehlertolerant bleibt, wird die Umsetzung gestaltet. Schließlich kann niemand garantieren, dass alle beteiligten Systeme jederzeit verfügbar sind.
Wer sich für die konkreten Implementierungsdetails und die technische Ausgestaltung interessiert, findet eine ausführliche Beschreibung in [2].
Auslösen der Anforderung über eine BPMN Send Task
Die fachliche Anforderung der vorhandenen Funktionalität wird im Geschäftsprozess über eine BPMN Send Task ausgelöst. Die Übergabeattribute basieren auf dem fachlichen Datenmodell der Geschäftsprozessanwendung und werden in eine Messaging‑Queue geschrieben.
Die fachlichen Übergabeattribute dokumentiere ich direkt im BPMN Geschäftsprozess, in der Element documentation-Eigenschaft des zugehörigen Message Flows zum fachlichen Partner (hier: „Accounting“). Dadurch bleibt transparent, welche Daten der Prozess übergibt.
Für die technische Umsetzung der Send Task kann häufig ein Standard‑HTTP‑Connector der Process Engine genutzt werden – sofern das Messaging‑System eine HTTP‑API bereitstellt. Falls nicht, wird die Send Task beispielsweise über das External‑Task‑Pattern realisiert: Ein Worker übernimmt dann das Senden der Nachricht über die spezifische API des Messaging‑Systems (z. B. JMS oder proprietäre SDKs).
Ich skizziere hier nur das Prinzip kurz. Wer sich für die konkreten Implementierungsdetails und die technische Ausgestaltung interessiert, findet eine ausführliche Beschreibung in [2].
Beispiel für den Auszug des Servicevertrags "invoice capture request" (Message Flow → Accounting) [Auszug]:
INTERFACE OPERATION (SERVICE CONTRACT)
OBJECTIVE: Send Request "Capture invoice"
ATTRIBUTES:
- orderID
- invoiceDoc
JSON‑Beispiel:
{
"orderID": "ORD-2025001",
"invoiceDoc": "Example Ltd-Invoice.pdf"
}
Rückmeldung über eine BPMN Receive Task
Wenn der Geschäftsprozess eine Rückmeldung erwartet – in unserem Beispiel die erfassten Rechnungsdetails – wird dies über eine korrespondierende BPMN Receive Task modelliert. Sie bildet das fachliche Pendant zur zuvor angeforderten Funktionalität.
Auch hier dokumentiere ich die fachlichen Rückgabeattribute direkt im BPMN‑Modell, und zwar in der Element documentation-Eigenschaft des zugehörigen Message Flows vom fachlichen Partner (hier: „Accounting“). Dadurch bleibt für Fachexpert:innen jederzeit nachvollziehbar, welche Daten der Prozess erhält und in welcher Struktur sie erwartet werden.
Beispiel Auszug des Servicevertrags für "Invoice details" (Message Flow ← Accounting):
INTERFACE OPERATION (SERVICE CONTRACT)
OBJECTIVE: Receive captured invoice details
ATTRIBUTES:
- orderID
- vendor (company / address: street, zipCode, city country)
- invoiceDetails (number, date, currency, amounts, VAT)
JSON-Beispiel:
{
"orderID": "ORD-2025001",
"vendor": {
"company": "Example GmbH",
"street": "Musterstraße 12",
"zipCode": "50667",
"city": "Köln",
"country": "Deutschland"
},
"invoiceDetails": {
"invoiceNumber": "INV-2025001",
"date": "2025-05-13",
"currency": "EUR",
"totalAmount": 1200.50,
"netAmount": 1008.40,
"vatRate": 19,
"vatAmount": 192.10
}
}
Wie die technische Rückmeldung erfolgt
Die technische Umsetzung der Receive Task erfolgt so, dass die Integrationskomponente nach erfolgreicher Verarbeitung die Rückmeldung direkt an die HTTP‑API der Process Engine übergibt. Dort wird eine BPMN‑Message korreliert, die die Receive Task aktiviert und den fachlichen Prozessfluss fortsetzt.
Wichtig ist dabei: Der in der Process Engine ausgeführte Fachprozess enthält keinerlei Integrationslogik. Die Engine empfängt ausschließlich eine fachliche Nachricht, deren Struktur durch den Servicevertrag definiert ist.
Damit bleibt der graphische BPMN-Geschäftsprozess:
- transparent,
- verständlich,
- und vollständig unabhängig von technischen Details.
Die Rolle der Integrationskomponente
Die eigentliche Umsetzung der vorhandenen Funktionalität erfolgt in einer Integrationskomponente. Sie bildet gemeinsam mit dem Messaging‑System den sogenannten Service Contract Implementation Layer (kurz: SCIL). Der SCIL setzt den fachlichen Servicevertrag der Geschäftsprozessanwendung technisch um und bildet ihn auf die bestehende Systemlandschaft ab. Das Messaging‑System stellt dabei die asynchrone Kommunikation sicher, während die Integrationskomponente die vorhandene Funktionalität mithilfe der Systeme aus der Systemlandschaft realisiert – also die fachliche Nachricht verarbeitet, transformiert und an die Zielsysteme übergibt. Für die Umsetzung wird eine Integrationssoftware oder ein Integrationsframework eingesetzt, wie zum Beispiel Apache Camel.
Szenario II: Neue Funktionalität implementieren
Abbildung 2: (c) Ludger Schönfeld
Nicht jede benötigte Funktionalität existiert bereits in der Systemlandschaft. Manche Aufgaben entstehen erst durch die fachlichen Anforderungen eines Geschäftsprozesses – etwa wenn neue Fähigkeiten benötigt werden oder bisher manuelle Arbeitsschritte digitalisiert werden sollen. In solchen Fällen handelt es sich um neue Funktionalität, die spezifisch für die Geschäftsprozessanwendung implementiert werden muss.
Im Geschäftsprozess wird eine solche Aufgabe durch eine BPMN Service Task dargestellt. Sie zeigt, dass der Geschäftsprozess eine fachliche Funktionalität der Aufgabe synchron aufruft und unmittelbar ein Ergebnis erwartet. Aus fachlicher Sicht ist klar definiert, was passieren soll – die technische Umsetzung erfolgt jedoch vollständig außerhalb der Process Engine komponentenbasiert.
Ableitung einer Fachkomponente
Aus dem Geschäftsprozess und den fachlichen Anforderungen leite ich eine oder mehrere Fachkomponenten ab. Jede Fachkomponente übernimmt die Verantwortung für den Lebenszyklus eines bestimmten fachlichen Objekts. Im Beispiel der Rechnung wäre dies etwa ein:
„RechnungService“, der den vollständigen Lebenszyklus des Objekts Rechnung abbildet.
Diese Fachkomponenten sind technisch sauber gekapselt: Sie enthalten ausschließlich fachliche Logik und keinerlei Process Engine‑spezifische Konzepte wie Delegates, Listener oder External‑Task‑Worker. Dadurch bleiben sie unabhängig von der eingesetzten Process Engine und können unverändert weiterverwendet werden – selbst wenn sich die Process Engine ändert.
Anbindung über einen REST‑Controller
Damit der Geschäftsprozess innerhalb der Process Engine diese neue Funktionalität nutzen kann, stelle ich für die Fachkomponente einen REST‑Controller bereit. Er bietet die benötigten Methoden als HTTP‑Endpunkte an. Die Process Engine ruft diese Endpunkte anschließend über ihren HTTP‑Konnektor auf und führt die jeweilige Methode synchron aus.
Der Ablauf ist damit klar strukturiert:
- Die BPMN Service Task ruft per HTTP‑Konnektor den REST‑Endpunkt der Fachkomponente auf.
- Die Fachkomponente verarbeitet die Anfrage, führt die fachliche Logik aus und liefert das Ergebnis zurück.
- Die Process Engine übernimmt das Ergebnis und führt den Prozessfluss fort.
Vorteile dieser Struktur
Die neue Funktionalität ist damit:
- fachlich strukturiert nach klaren Verantwortlichkeiten,
- technisch isoliert und unabhängig von der Process Engine,
- frei von Process Engine‑Konzepten (keine Delegates, keine External Tasks),
- über standardisierte HTTP‑Schnittstellen erreichbar,
- wiederverwendbar, sofern andere Anwendungen über ihren eigenen SCIL darauf zugreifen.
Die vollständige Herleitung, Strukturierung und Implementierung dieser Fachkomponenten beschreibe ich ausführlich in meinem Buch (siehe [2]).
Fazit
Die Abkündigung von Camunda 7 zeigt eindrücklich, wie schnell Unternehmen in technologische Abhängigkeiten geraten können, wenn fachliche Logik und Process Engine‑Spezifika zu eng miteinander verknüpft sind. Der weit verbreitete Irrglaube, dass das proprietäre External‑Task‑Pattern automatisch zu Migrationsfähigkeit oder gar Process Engine‑Agnostik führt, verdeckt dabei die eigentliche Herausforderung: die saubere Strukturierung der ergänzenden Funktionalität einer Geschäftsprozessanwendung.
Die beiden Szenarien verdeutlichen, worauf es wirklich ankommt:
- Vorhandene Funktionalität wird über klar definierte Serviceverträge und eine robuste, asynchrone Integrationsarchitektur wiederverwendet.
- Neue Funktionalität wird als eigenständige Fachkomponente implementiert – fachlich strukturiert, technisch isoliert und unabhängig von Process Engine‑Konzepten.
Gerade heute ist diese Form der Implementierung wichtiger denn je. Wir befinden uns nicht mehr in den stabilen, überschaubaren IT‑Landschaften der 1990er Jahre. Systemlandschaften wachsen schneller, Technologien verändern sich in kürzeren Zyklen, und internationale Märkte zeigen, wie rasant digitale Geschäftsmodelle entstehen und skaliert werden können. Viele Unternehmen unterschätzen diese Dynamik noch immer – und genau deshalb müssen wir architektonisch anders denken.
Eine sauber strukturierte Geschäftsprozessanwendung nach dem Prozessgesteuerten Ansatz nach Volker Stiehl schafft:
- Unabhängigkeit von konkreten Process Engine‑Technologien,
- Flexibilität bei zukünftigen Modernisierungen,
- Transparenz für Fachexpert:innen,
- Nachhaltigkeit in der Weiterentwicklung,
- und eine deutliche Entlastung bei Migrationsvorhaben.
Gerade dieser letzte Punkt ist entscheidend: Wenn vorhandene Funktionalität klar gekapselt und über den Servicevertrag der Geschäftsprozessanwendung realisiert wird, müssen Fachkräfte bei einem Technologiewechsel nicht mehr tief in bestehende Implementierungen eingreifen. Die freiwerdenden Ressourcen können in neue Geschäftsmodelle, Prozessinnovationen oder die Weiterentwicklung der eigenen Architektur fließen.
Wer seine Geschäftsprozessanwendungen auf diese Weise strukturiert, schafft nicht nur eine solide Basis für eine Migration weg von Camunda 7, sondern legt gleichzeitig den Grundstein für eine Architektur, die auch in fünf oder zehn Jahren noch tragfähig ist – unabhängig davon, wie sich Technologien, Process Engines oder Integrationsplattformen weiterentwickeln.
Quellen:
[1] Camunda 7 Docs: External Tasks. https://docs.camunda.org/manual/7.24/user-guide/process-engine/external-tasks/ (03.04.2026)
[2] Schönfeld, Ludger (2026): Business Process Automation. Geschäftsprozesse nachhaltig automatisieren mit BPMN und DMN. Mitwirkung: Prof. Dr. Volker Stiehl. Bonn: Rheinwerk.
[3] Camunda 7 Docs: Support Announcements. https://docs.camunda.org/enterprise/announcement/ (03.04.2026)
Autor
