Einführung

Wenn wir Geschäftsprozesse mit CIB Seven beziehungsweise Camunda 7 digitalisieren, dann müssen wir uns nach der fachlichen Modellierung sehr schnell um die technische Umsetzung der Service Tasks kümmern. Genau an dieser Stelle wird es in vielen Projekten unnötig kompliziert: viel Boilerplate, wenig Transparenz, schwer testbare Integrationen und kaum wiederverwendbare Bausteine.

Dieses Projekt zeigt einen anderen Weg.

Wir verwenden Kogito, um External Tasks nicht nur technisch abzuarbeiten, sondern den gesamten Ablauf fachlich und technisch sauber zu modellieren. Das Ziel ist nicht, Programmcode zu vermeiden. Das Ziel ist besserer Code: klarer, testbarer, verständlicher und für alle Projektbeteiligten transparenter.

Die zentrale Frage ist:

Können wir die Vorteile von BPMN auch für die Implementierung von Services und Integrationen mit CIB Seven nutzen, ohne auf saubere Java-Entwicklung zu verzichten?

Die Antwort ist: Ja. Und in vielen Fällen wird die Implementierung dadurch sogar besser.

Wichtig für Stakeholder und Product Owner

Mit diesem Ansatz entstehen einige sehr praktische Vorteile:

Wir sprechen im Projekt eine gemeinsame Sprache.
Die Definition der User Stories wird präziser.
Fachlichkeit, Daten und technische Integrationen werden früher sichtbar.
Der Implementierungsstand eines Services ist für das Team deutlich transparenter.
Späteres Refactoring wird reduziert, weil die Services von Anfang an genauer beschrieben sind.
Ziel dieses Artikels
In diesem Artikel zeige ich, wie man mit Kogito einen CIB Seven External Task Worker umsetzt, der:

External Tasks aus CIB Seven abholt
sie innerhalb eines modellierten Prozesses verarbeitet
Business-Services aus Java aufruft
und das Ergebnis wieder an CIB Seven zurückmeldet
Es geht hier nicht darum, alle Quarkus-, Security- oder Infrastrukturthemen vollständig zu behandeln. Im Mittelpunkt steht die Vorgehensweise.

CIB Seven Prozessintegration
In diesem Projekt nutzen wir Kogito als Orchestrierungsschicht für CIB Seven External Tasks.

Die Kommunikation mit CIB Seven läuft über die bekannten REST-Endpunkte:

• fetchAndLock
• completE
• failure

Statt diese Aufrufe verstreut in technische Hilfsklassen zu verstecken, modellieren wir den Ablauf in BPMN und kapseln die technische Kommunikation in einer klaren Java-Service-Schicht.

Kogito Worker
Der erste Schritt ist der Worker-Prozess.

Er fragt CIB Seven in kurzen Intervallen, ob External Tasks für einen bestimmten Topic vorhanden sind. In diesem Projekt übernimmt das die BPMN-Datei ShortPollWorkerExample.bpmn gemeinsam mit der Java-Klasse CibSevenFunctions.

Der Worker:

• sendet einen fetchAndLock Request
• Übergibt Topic, Worker-ID und Lock-Dauer
• erhält die offenen External Tasks von CIB Seven zurück

Damit ist bereits ein wichtiger Vorteil sichtbar: Schon der technische Polling-Ablauf ist modelliert und nicht nur “irgendwo im Code”.

Kogito Handler
Die abgeholten Tasks werden im nächsten Schritt verarbeitet.

Dafür gibt es den Handler-Prozess ShortPollHandlerExample.bpmn. Er übernimmt die aktivierten External Tasks, bereitet die Daten auf und ruft die eigentliche Fachlogik auf. Nach erfolgreicher Verarbeitung wird der Task in CIB Seven abgeschlossen.

Falls etwas schiefläuft, kann stattdessen ein Fehler an CIB Seven gemeldet werden.

Das bedeutet:

• Der technische Integrationsfluss ist sichtbar
• Die einzelnen Verarbeitungsschritte sind fachlich lesbar
• Fehlerfälle können bewusst modelliert und getestet werden

Kogito Service

Neben Worker und Handler enthält das Projekt auch einen einfachen Beispiel-Service: ComplexServiceExample.bpmn zusammen mit ServiceExample.java.

Dieses Beispiel zeigt sehr schön, wie Kogito mit normalen Java-Services zusammenspielt. Die Business-Logik bleibt eine normale CDI-Bean. Es ist kein schwergewichtiges Delegate-Konzept notwendig. Stattdessen wird der Service direkt im BPMN-Service-Task verwendet.

Der große Vorteil dabei ist:

• die Orchestrierung bleibt im Modell
• die Business-Logik bleibt in Java
• beides ist sauber voneinander getrennt

Vorteile

Lasst uns mit den wichtigsten Vorteilen anfangen:

• Services werden modelliert. Schon im Refinement können Ablauf, Daten und Umsysteme gemeinsam beschrieben werden.
• Services werden von allen Projektbeteiligten besser verstanden.
• Integrationen mit CIB Seven werden transparent und nachvollziehbar.
• Einzelne Schritte sind wiederverwendbar.
• Jeder Schritt kann gezielt getestet werden.
• Die technische Umsetzung bleibt schlank und näher an der Fachlichkeit.
• Die generierten REST- und OpenAPI-Strukturen helfen zusätzlich bei API-First-Ansätzen.

Ok, aber …
Die wichtigsten Fragen aus Projekten tauchen fast immer sehr schnell auf.

Entwickler

F: Brauchen wir neben CIB Seven wirklich noch Kogito?

A: Kogito ersetzt CIB Seven nicht. CIB Seven bleibt die Workflow- und Prozessplattform. Kogito hilft uns dabei, die Implementierung der Services und Integrationen sauber, testbar und fachlich sichtbar zu gestalten. In diesem Kontext ist Kogito eher ein Entwicklungsbeschleuniger als ein konkurrierendes BPMN-System.

F: Kann ich meine Services weiterhin vollständig testen?

A: Ja. Genau das ist einer der großen Vorteile. Die Java-Services können isoliert getestet werden, und die Kogito-Prozesse können zusätzlich über Integrations-Tests geprüft werden. Im Projekt ist bereits ein Test für ComplexServiceExample enthalten.

F: Unterstützt das einen API-First-Ansatz?

A: Ja. Kogito generiert REST-Endpunkte und Schemas für die Prozesse. In Verbindung mit Quarkus und Swagger UI wird sehr schnell sichtbar, welche Inputs und Outputs ein Prozess oder Service erwartet.

F: Muss ich spezielle Delegate-Klassen bauen?

A: Nein. In vielen Fällen reicht eine normale Java-Klasse mit @Singleton. Diese kann direkt aus einem BPMN-Service-Task aufgerufen werden.

F: Kann ich bestehende Java-Bibliotheken weiter nutzen?

A: Ja. Das Projekt ist ein normales Quarkus-/Java-Projekt. Dadurch können vorhandene Bibliotheken und Integrationsbausteine weiterverwendet werden.

Projektverantwortliche

F: Ist dieser Ansatz wirtschaftlich sinnvoll?

A: Ja, vor allem aus drei Gründen:

Die Services werden früher und präziser beschrieben.
Integrationen mit Umsystemen wie CIB Seven werden früher sichtbar und testbar.
Der Code ist zu jedem Zeitpunkt deutlich besser dokumentiert, weil das Prozessmodell einen Teil der Dokumentation übernimmt.
F: Ist der Ansatz wiederverwendbar?

A: Ja. Gerade Polling, Task-Handling, Fehlerbehandlung und Mapping lassen sich in weiteren Projekten sehr gut wiederverwenden.

Wie nutzt man das Projekt?

Die Konfiguration erfolgt in application.properties.

Dort werden unter anderem gesetzt:

die CIB Seven REST-URL
die Basic-Auth-Zugangsdaten
Quarkus- und Kogito-Einstellungen
Starten könnt ihr das Projekt mit:

mvn quarkus:dev
oder für Build und Test mit:

mvn clean install
Zusätzlich stehen euch in Quarkus unter anderem zur Verfügung:

Dev UI
Swagger UI
Health Checks
Fazit
Dieses Projekt zeigt sehr konkret, wie Kogito als technische und fachliche Brücke für CIB Seven External Tasks eingesetzt werden kann.

Der große Gewinn liegt nicht nur darin, dass Tasks abgeholt und abgeschlossen werden. Der eigentliche Gewinn ist, dass der Weg dazwischen modelliert, verständlich, testbar und wiederverwendbar wird.

Gerade in Projekten mit vielen Integrationen, mehreren Beteiligten und hohem Abstimmungsbedarf ist das ein enormer Vorteil.

https://github.com/Marcin-Pankowski/Kogito-CIB-Flow-External-Task-Worker