Continuing my previous blog post Error Handling Patterns in Mule, in this post I will show you how to implement the following use cases:
- Rollback transaction and send notification email
- Stop flow execution based on exception type
Note: All examples in this blog are presented using the flow configuration style since it’s the preferred style to configure Mule, but the same applies to services.
Rollback transaction and send notification email
In this case, if an exception is thrown we want to rollback the transaction and send a notification about the failure. For this example we are going to use an SMTP endpoint so we can notify by email.
Flow configuration: We will read a JMS message from queue in, then force it to fail so the exception strategy is called to rollback the transaction and send a notification.
[1] – For any exception thrown, rollback the transaction
[2] – Change the payload to the message we want to send in the email notification. We send the message being processed in addition to the exception message.
[3] – Endpoint configuration to send notification email.
How to stop flow from receiving more message for certain exceptions
Sometimes when some external service becomes unavailable we may consider stopping a flow from consuming more messages since we already know that it will fail every time.
Flow configuration: We will read a VM message from path in, then call an HTTP outbound endpoint with a very short response time, which will make it fail. If the exception is a java.net.ConnectException, we stop the flow. Otherwise, we log the exception message.
[1] – If the exception is of type ConnectionException, then we want to stop the flow.
[2] – In any other case, we just log the exception.
If you want to restart the stopped flow later you can use the Mule Management Console (and JMX support).
Want to know more?
If you want to read more about implementing exception strategy use cases, read Mule Error Handling: Most Common Scenarios part 1. In case you want to know how exception strategy works in greater detail, you can read the Getting the most out of Mule Error Handling blog post and also take a look at our Mule Error Handling documentation
Error Handling Tips
- <default-exception-strategy> and <custom-exception-strategy> can only have one message processor as child. To overcome this we use the <processor-chain> element to be able to include more than one message processor
- Sometimes we need to inspect the cause of the exception and not the exception itself to be able to determine the exact exception. This is because Mule wraps the thrown exception when it’s thrown by a component or an endpoint.
