ie @Mule-Dokumentation gibt an, dass die Fangausnahmestrategie der von Java Catch Block ähnelt. Aber leider wird die Nutzlast verbraucht (Nachricht wird verbraucht); Aus dem catch-Block geht die Nutzlast verloren (im Gegensatz zu einer Java-Methode, bei der Sie über einen catch / finally-Block auf die Methoden-Eingabeparameter zugreifen können).

Das Problem bei diesem Entwurf besteht darin, dass in jedem Fall (aus dem Ablauf der Fangstrategie) der Fehler und die zuletzt bekannte angereicherte Nutzlast, die verwendet wurde (die den Fehler verursacht hat), nicht bekannt sind. Dies erschwert die Prüfung der Daten, die den Fehler verursacht haben.

Angenommen, es gibt einen Datenfluss mit 10 Nachrichtenprozessoren, ist es mühsam, den Nachrichtenprozessor zu identifizieren, der den Fehler verursacht hat.

Ich kann 2 Problemumgehungen in Bezug auf die Nutzlast sehen:
1) Verschieben Sie nach dem eingehenden Endpunkt die Nutzdaten vor jedem Nachrichtenprozessor in eine Ablaufvariable (ein weiterer Nachteil ist wiederum, was mit den eingehenden Eigenschaften und Anhängen passiert?)
2) Verwenden Sie die Rollback-Ausnahmestrategie mit null Versuchen (die Transaktion wird zurückgesetzt), und die ursprüngliche Eingabenachricht ist möglicherweise verfügbar. (Nachteil: Es ist schwierig zu überprüfen, warum der Fehler aufgetreten ist und auf welchem Nachrichtenprozessor - Beispiel: Ich habe möglicherweise 5 oder 6 DB-Prozessoren)

Der Grund, warum dies wichtig wird, ist, dass die Unterstützung einer ESB-Anwendung in der Produktion einfacher wird.

Wenn wir zum Beispiel die Payload- und Exception-Details (verknüpft mit einer einzelnen UID) aus dem Catch-Block übermitteln können, können Sie ein Protokollüberwachungstool ausführen und es zu Überwachungszwecken / zum Auslösen von Warnungen in ein Echtzeit-Dashboard verschieben . Der gleiche Ansatz kann einheitlich auf alle Anwendungen / Flows und Java-Komponenten usw. angewendet werden.

MMC ist in diesem Bereich schwach. Wenn Sie beispielsweise Warnungen von einem Stapeljob nach 5 Vorkommen unterdrücken möchten, kann MMC dies nicht tun.

Meine Fragen lauten: 1) Gibt es einen Grund, warum die Nutzlast nicht verfügbar ist? Mögliche Problemumgehung besteht darin, (letzte bekannte Daten) als Teil der Nachricht mit dem Namen originalPayload oder originalInboundProperties in eine andere Variable zu verschieben. 2) Gibt es eine andere einfache Möglichkeit, die Exception und die Payload an einen Appender weiterzuleiten (anstelle von Workarounds)?

Ananth Krishnan (WHISHWORKS.com)