1

Mule documentation states that catch-exception-strategy is similar to java catch block. But unfortunately, the payload is consumed (message is consumed); from the catch block the payload is lost (unlike a java method where you can access the method input parameters from a catch/finally block).

The problem with this design is that at any instance, (from the catch strategy flow) it is impossible to know the error and last known enriched payload which was used (which caused the error?). This complicates auditing of data which caused the error.

Suppose if there is a flow with 10 message processors, it becomes tedious to identify the message processor which threw error.

I can see 2 workarounds regarding the payload:
1) After the inbound endpoint, push the payload to a flow variable before every message processor (again another disadvantage is what happens to the Inbound properties and attachments?)
2) Use Rollback exception strategy with zero attempts (the transaction will be rolled back), and original input message may be available. (drawback: it is difficult to introspect on why the error happend and on which message processor - example: I may have 5 or 6 DB processors)

The reason why this becomes important is supporting an ESB application in production becomes easier.

For example, from the catch-block if we are able to pipe the payload and exception details (linked to a single UID), then you can run a log monitor tool, push it to a real time dashboard for monitoring purpose/raise Alerts. The same approach can be uniformly applied to all the applications/flows and java components, etc.

MMC is weak in this area - for example, if you want to supress Alerts from a batch job after 5 occurrences, MMC cannot do it.

My questions are: 1) Is there any reason on why the payload is made unavailable? Possible workaround is to push (last known data) to another variable as part of message called originalPayload or originalInboundProperties? 2) Any other straight forward way of piping the exception and payload to an appender (instead of workarounds)?

Ananth Krishnan (WHISHWORKS.com)

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
Ananth Krishnan
  • 11
  • 2
  • What do you mean by "the payload is consumed"? The message should contain the payload at the time the exception occurred. If that's not the case, you're potentially facing a bug. From a pure design standpoint, I find the catch block in flows to be catastrophic: it's "imperative programming in XML", which is not what a MOM should be about. Dealing with errors should be done in a more message-oriented manner IMNSHO (with regular routing for ex.). – David Dossot Apr 16 '15 at 00:18
  • Hi David, if you use a catch-exception strategy block the payload that is enriched/processed in the main flow is lost. This is what Mule documentation states it as consumed. The only way I found is to use a custom exception strategy which gives the handle to the last known good payload for auditing purpose. – Ananth Krishnan Apr 16 '15 at 14:27
  • My objective is: 1) During an exception, log the summary message of the exception stack trace to a log file 2) Log the last known enriched/updated payload to log file Ensure both the log entries have a field called transaction_id with an unique value 3) Return custom exception to the parent flow 4) Use the log data, pull them upto a tool like Splunk/SumoLogic for exception analysis or for data alerts So the custom exception strategy is very close to what I want here. – Ananth Krishnan Apr 16 '15 at 14:35
  • If I use catch-exception strategy, it does not work. It also logs the exception (when the control transforms from main flow to catch-exception strategy block) - this needs to be suppressed as I need the exception summary message along with additional fields (like transaction_id) so that I can query the log data using analysis tools. – Ananth Krishnan Apr 16 '15 at 14:35
  • I think that by consumed they mean that if it's a stream, the stream has been read. What is the message payload type in the catch-exception strategy? – David Dossot Apr 16 '15 at 15:45
  • Hi David, the payload may be a JSON request and java value objects. Whatever the payload, when it transitions between message processors and if there is an error, I need the last known payload so that its useful for auditing and for production support. Else its a nightmare to build uniform auditing/alert mechanism around this. – Ananth Krishnan Apr 16 '15 at 16:02
  • I understand that, I was asking: what are you currently observing? What payload do you get in the catch-exception strategy when an exception occurs in the flow? – David Dossot Apr 16 '15 at 16:45
  • 1
    Hi David, if I use catch-exception strategy, the payload is NullPayload. If I use custom exception strategy (by referring to a java class which extends CatchMessagingExceptionStrategy), I'm able to get the payload and exception (along with root cause). So I'm inclined to use custom exception strategy. The difficulty is that if I use custom exception strategy, the exception strategy should return a custom exception to calling flow - so Im wondering how to do that. – Ananth Krishnan Apr 16 '15 at 22:11
  • Thanks for all the precisions! – David Dossot Apr 16 '15 at 22:37

0 Answers0