Die Wahrheit der Live-Automatisierung
Maximilian schaltet sich aus Kyoto zu und liefert dir eine ACTION BPMN-Episode zur Prozessautomatisierung. Das Ziel: eine simple Kreditkartenzahlung in Camunda 8 auf die Engine bringen.
Du siehst: Die Reise von der schicken Fachbereichs-Modellierung zur funktionierenden IT-Applikation steckt voller Fallstricke.
Die Camunda 8 Fakten
Zuerst der kritische Blick auf Camunda 8 im Vergleich zur Vorgängerversion:
- Feature-Status: Camunda 8 erreicht laut Maximilian 90 Prozent Feature-Complete in Bezug auf die BPMN-Symbole von Version 7.
- Das fehlt: Er vermisst vor allem die conditional events. Du brauchst sie, wenn du auf das Erreichen eines Schwellenwerts in einer Prozess-Variable reagieren musst.
- Zielgruppe: C8 eignet sich wegen seines vollen Umfangs und der Preisstruktur primär für mittlere bis große Unternehmen und komplexe, monetär relevante Prozesse.
Vom Design zum roten Fehler
Der Zahlungsprozess ist klar: Zuerst prüfst du das vorhandene Guthaben. Reicht das nicht, belastest du die Kreditkarte.
Die Überführung dieses Fachbereichs-Modells in den Camunda Modeler löst sofort Fehler aus. Die IT muss liefern:
- Worker-Definition: Service Tasks brauchen einen eindeutigen Job Type (Worker-Namen). Das verhindert, dass sich Worker bei der Abarbeitung streitig werden. Best Practice ist ein eindeutiger, hierarchischer Name (
at.firma.showcase.DeductCredit.v1). - Fluss-Logik: Sequenzflüsse an einem Gateway benötigen eine Bedingung (z. B.
Credit sufficient = false). - Startformular: Ein Formular für die Eingabe von Guthaben und Preis bindest du direkt an das Start-Event.
Der Live-Demo-Stopp
Maximilian spielt den Umsetzer und deployt den Prozess direkt auf den Camunda SaaS-Cluster. Gleichzeitig startet er die zugehörige Java/Spring Boot Applikation. Diese soll die drei notwendigen Worker (DeductCredit, ChargeCreditCard, RestoreCredit) registrieren und die Jobs der Engine abholen.
Du siehst: Nach dem Start der Prozessinstanz über das Formular in der Engine bricht die Kommunikation ab. Der Worker-Manager reagiert nicht wie gewünscht.
- Die Analyse: Die Worker-Applikation holt die Aufträge der Engine nicht ab. Maximilian vermutet ein Berechtigungsproblem in der Cloud-Konfiguration.
- Die Realität: Software wirft Fehler. Das passiert auch bei Profis und beweist die Komplexität der Orchestrierung.
Die Theorie des Fehler-Handlings
Trotz Demo-Misserfolg zeigt Maximilian dir im Code, wie du den Fehlerfall abfängst:
- Wenn die Logik im Code die Kreditkarte nicht belasten kann (z. B. wegen Time-out), wirft die Applikation einen BPMNError.
- Dieser
BpmnErrorbesitzt einen Code und wird direkt an das Error-Boundary-Event im BPMN-Modell übergeben. - Das Error-Event löst die im Modell konfigurierte Kompensation aus.
- Der Prozess rollt zurück und führt die Aktivität Restore Credit aus. Diese bucht das ursprüngliche Guthaben zurück.
Du brauchst solche Kompensationsmechanismen, wenn es um sensible Themen wie Zahlungen geht. Ein Prozess muss auch im Fehlerfall wissen, wie er den Ursprungszustand wiederherstellt.
Maximilian gesteht: Die Fehlersuche wird ihn jetzt noch beschäftigen.
UPDATE: Minuten nach Ende der SHOW lief alles. (War klar)
#BPMN #Camunda8 #Prozessautomatisierung #JobWorker #LiveAction #Kreditkartenzahlung #SoftwareArchitektur