Error handling in event driven systems like Mule can be a challenge to understand, if you have worked with Mule you’ll know that there are exception strategies and this post will help you get the most out of them.
How error handling works in Mule
Note: In this blog we are going to talk about flow since it’s the preferred configuration style but the same applies to services.
Mule errors are represented by exceptions, so when your transformer, endpoint or any other processor fails it throws an exception. When an exception is thrown, you need a way to manage it. In Mule, the key is <default-exception-strategy> element. Once an exception is thrown normal flow execution will stop and will continue processing on the exception strategy. Inside it you can put message processors to do whatever you want to handle the exception. Currently <default -exception-strategy> only allows one message processor, but you can overcome this issue by using a <processor-chain> element.
When an issue arises in production it can be quite daunting to reproduce it in a test environment. Ideally one debugs the live application. But logs don’t tell the whole story. And a severe issue may require the application be taken down. How can it be stopped and debugged at the same time? With Mule composite sources and Mule Management Console (MMC) end-point control you can eat your cake and have it, too.
The Mule team is very pleased to announce the general availability of Mule ESB 3.1. This release packs a lot of new shiny awesomeness.
We received loads of great feedback on Mule Cloud Connect and the team has been working hard on new improvements. Cloud Connectors now have specific XML schemas making it really easy to orchestrate data services between cloud and enterprise applications. This means Cloud Connectors can now be used in flows. For example, to create a new Twitter component for use in a flow use the following:
One of the joys of Mule 3’s new Message Processor (MP for short) architecture is the power that arises from being able to combine message processors into different patterns. To make this as flexible as possible, the routing message processors that were designed to be used in flows each do a single job, making them highly reusable. This allows you to build up a flow piece by piece, or alternatively modify an already working flow, without having to change its basic structure. Let’s look at an example.
Three months ago, I’ve introduced the newly created Erlang Transport for Mule 3 in this blog. To illustrate a usage scenario for this transport, which allows fast and seamless bi-directional communications between the JVM and the Erlang worlds, I presented an example where Mule was exposing a JSON over HTTP service for provisioning users in RabbitMQ.
At that time, the new configuration mechanism named Flow was not fully baked so I implemented the example “Mule 2 style“, which means that I used Services tied together with VM queues.
Now that Mule 3.0.0 is out, my challenge for today’s post was to redo the configuration “Mule 3 style“, i.e. using by Flows.