Tag: flow

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 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 , 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.

Ross Mason on Tuesday, January 11, 2011

Run Mule, Run! Mule 3.1 is out

6

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.

Connect

We received loads of great feedback on Mule 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 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 piece by piece, or alternatively modify an already working , 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 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.