iFlow Error Handling

Fehler passieren in jeder Integration – die Frage ist, ob dein iFlow darauf vorbereitet ist. Ohne explizites Error Handling landet jede unerwartete Exception direkt im Failed-Status, ohne dass du dem Aufrufer eine sinnvolle Antwort geben oder das ursprüngliche Payload sichern kannst. Der Exception Subprocess ist das zentrale Werkzeug, um das zu verhindern.

Das Konzept: Exception Subprocess

Der Exception Subprocess ist ein separater Prozessblock im iFlow-Editor, den du über die Palette als „Process Exception Subprocess“ einfügst. Wichtig: Er wird nicht mit dem Main Flow verbunden. Er greift automatisch, sobald eine unbehandelte Exception im übergeordneten Integration Process auftritt.

Zwei Dinge bestimmen, wie der iFlow danach dasteht:

• Error End Event → iFlow endet mit Status „Failed“
• End Message Event → iFlow endet mit Status „Completed“, du kannst dem Aufrufer eine formatierte Fehlerantwort zurückgeben

Im Subprocess stehen dir die Properties ${exception.message} und ${exception.stacktrace} zur Verfügung – damit kannst du den Fehler loggen, in einen Datastore oder eine JMS Dead-Letter Queue schreiben oder eine E-Mail an das Operations-Team senden.

Typische Fallstricke

Der häufigste Irrtum: Man erwartet, nach dem Exception Subprocess in den Main Flow zurückzukehren. Das funktioniert nicht – CPI kehrt per Design nicht in den Main Flow zurück. Wenn du bestimmte Schritte sowohl im Normalfall als auch nach einer Exception ausführen musst, lagere sie in einen Local Integration Process aus und rufe diesen aus beiden Pfaden auf.

Weitere Punkte, die in der Praxis regelmäßig Probleme machen:

• Data Store Write mit Duplicate Key: Diese Exception wird nicht vom Exception Subprocess abgefangen – die Datenbanktransaktion rollt zurück.
• Exceptions aus Local Integration Processes werden im aufrufenden Main Process nicht gefangen.
• Router im Exception Subprocess ist nicht nutzbar, um z. B. verschiedene HTTP-Statuscodes unterschiedlich zu behandeln. Besser: das fehlerhafte Stück in einen separaten iFlow auslagern und per ProcessDirect aufrufen.
• Das MPL bleibt im Error-Status, selbst wenn du die Exception abgefangen und einen End Message Event gesetzt hast.

Zentralisiertes Error Handling

Sobald du mehr als eine Handvoll iFlows betreibst, lohnt sich ein dedizierter Error-Handling-iFlow. Das Muster: Jeder Exception Subprocess schreibt Fehlerdetails (Payload, Properties, Stacktrace) in eine zentrale JMS-Queue. Ein separater iFlow pollt diese Queue und übernimmt Logging, Alerting und ggf. Retry-Logik. So vermeidest du duplizierte Fehlerbehandlungslogik in jedem einzelnen iFlow und hast einen zentralen Ort für Monitoring und Anpassungen.

Exception Subprocess
  └─► Local Process: Prepare Error Message
        └─► JMS Receiver: QUEUE_ERROR_HANDLING
              └─► (separater iFlow pollt Queue)
                    ├─► Mail Adapter: Alert an Ops-Team
                    └─► DataStore Write: Archivierung

Fazit

Jeder produktive iFlow gehört mit einem Exception Subprocess ausgestattet – das ist keine Kann-Entscheidung. Für synchrone Szenarien: End Message Event verwenden und eine strukturierte Fehlerantwort zurückgeben. Für asynchrone Szenarien: Payload in JMS oder Datastore sichern, damit ein Retry möglich bleibt. Wer mehrere iFlows betreibt, sollte früh auf ein zentrales Error-Handling-Pattern setzen – der Wartungsaufwand zahlt sich schnell aus.