Reading Time: 15 minutes

Last month we released Mule 3.3 M1, our first milestone on the way to Mule 3.3.  While for production you should use Mule 3.2.1, we hope these milestones are a great way to play around with the latest and greatest features. This is a great opportunity to provide feedback and have an impact on what we are doing for the Mule 3.3 release.

We’ve been busy working on Milestone 2 during January, which we have just made available publicly.  This blog post will take you on a brief tour of what we’ve been up to. On the highlighted list, we have upgraded Spring Framework to its latest version so you can keep up using the new features and enjoying the latest bug fixes. We also introduce the forEach message processor which simplifies the iteration over a collection of elements in the current message. We keep improving CXF support and ease of use to make your life easier. We also implemented new exception strategies on error handling which makes the setup of common error handling scenarios really simple. By the way, you are still on time to steer the course of Mule 3.3. Here is how. Let’s take a look at what’s new!

Spring 3.1 Upgrade

Existing Mule configurations will continue working with no changes needed. In case you’re declaring the spring schema version in your xml config and you want to use any of the new Spring 3.1 features, you’ll need to upgrade the spring schema versions to 3.1.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

One of the new Spring 3.1 features is the Bean Definition Profiles. The Spring profiles allow the registration of different beans depending on the target environment. The example below shows how to use different connector configurations depending on the environment selected using profiles:

In order to select which profile to use, the profile system property can be set using a jvm argument when starting Mule:
$MULE_HOME/bin -M-Dspring.profiles.active=”dev”
The profile selection will be the same for all the Mule applications deployed on the same instance.

Foreach

The idea behind the foreach message processor is to simplify the iteration over a collection of elements present in the current message. This allows the user to perform an operation using each item in the selected collection and then continue processing the original message.

Currently in Mule, in order to perform iteration you either need to use a splitter and aggregator pair or implement a custom component or groovy script. If you use a splitter/aggregator pair you will of course always lose the original message.

In the example below we can see how foreach can be used to iterate over a list of items from a purchase order using an XPath expression and call different endpoints depending on the value of the GiftWrap attribute. After the items are processed the original message is used to send an email to the customer:

You can get a sample XML purchase order here and the full example configuration from here

Further Improvements to CXF Support

Error handling

Extensive work has been done around ensuring a consistent behavior when an error occurs in a flow with CXF in Mule and to make it compliant with Mule’s exception strategies.

WS-Security

A new WS-Security element is included in this Milestone to improve the usability on enabling WS-Security and to integrate the new Validator concept added by WSS4J 1.6 after the CXF upgrade performed in the first Milestone of Mule 3.3.

This element aims to act as a placeholder and to facilitate the security configuration on the CXF message processors by reducing the configuration verbosity and internal CXF knowledge required to enable WS-Security.

Through this element it will be possible to configure the integration of CXF with the Mule Security Manager, set the security properties and provide custom Validators to override the default ones used to validate a received security token.

The WS-Security syntax is the following:

In the following configuration example we create a sender-vouches SAML2 Assertion, where the Assertion is signed, and then perform validation on the received Assertion.

Configuration on the CXF client:

Where the ‘saml2CallbackHandler’ is a CallbackHandler that populates the SAML 2.0 Assertion [see org.mule.module.cxf.wssec.SAML2CallbackHandler]

Configuration on the CXF service:

Where the ‘samlCustomValidator’ extends the SamlAssertionValidator and validates the received SAML Assertion [see org.mule.module.cxf.wssec.SAMLCustomValidator]

JiBX

The JiBX databinding has been added to the list of databindings supported by CXF message processors in Mule. This databinding has been included by CXF since its version release 2.4.

<cxf:simple-service serviceClass="org.mule.component.simple.EchoComponent">
    <cxf:jibx-databinding/>
</cxf:simple-service>

Version Upgrade

Following up on the CXF upgrade performed in Mule 3.3 M1, in this second Milestone the version of CXF has been upgraded to the latest available release at the moment, Apache CXF 2.5.1. In this new release, over 75 JIRA issues reported by users have been fixed.

Error Handling

Rollback Exception Strategy

Rollback exception strategy allows message reprocessing in case of an error. You can configure inbound message redelivering times and define actions in case that those redelivery times are exceeded. This feature resolves a very common error handling scenarios in messaging systems. It will let you manage poison messages and sent them to a dead letter queue with little configuration.

Take for instance the following use case: Read message from JMS queue, try to process it. If processing fail retry processing 3 times. If reprocessing times is exceeded then send the message to a dead letter queue.

All the configuration you need is:

The inbound message will be redelivered two times in case of an error, but if the configured redelivered time is exceeded, the inbound message will be consumed and sent to a dead letter queue

Choice Exception Strategy

How many times did you need to define different error handling execution paths? Well, choice exception strategy is here to simplify your problem. With it, in case of an exception, you can route the message to different exception strategies based on the content of the message.

Suppose your boss comes along and tells you that you need the following behavior for file orders processing: You must process order files. In cases where the file is over 1MB, it can’t be processed and must be moved to another folder. If the file is empty then it must be discarded. If message processing fails, retry processing it 2 times. If it keeps failing, move the file to an error folder. Before getting crazy, let’s see how Mule can do that for you:

This flow will only accept messages under 1 MB and not empty. If a file bigger than 1 MB is processed then it will be moved to a bigfiles folder. If an empty file arrives it will be consumed without doing any processing and finally, if message processing fails, it will be redelivered, but if configured redelivery times are exceeded then it will be sent to an error folder

Exception Strategy Reuse

As a good developer I’m sure you like to honor the DRY principle and with Mule 3.3 exception strategies, there’s no exception. Now you can reference globally defined exception strategies from a flow.

What if your application is based on moving JMS messages around and you want to provide a default customized exception strategy for every flow? Mule 3.3 will allow you to redefine the default exception strategy for flows.

Now flows ordersFlow and productsFlow will have an exception strategy global exception strategy named redeliveryExceptionStrategy

We need you!

Want to help with Mule 3.3?  Here are a number of  things you can do:

  1. Download 3.3 M2 and use it.  Provide feedback via the Mule User Forum (it’d be helpful if you use a “[MULE 3.3]” prefix) or create a JIRA issue if you find a bug.
  2. Talk to us.  Do you think we are focusing on the right areas to improve Mule usability or missing something important?  Tell us!  Use the Mule User Forum or comment on this blog post.
  3. Review design proposals.  As we work on improvements we’ll be putting together design proposals for review and posting them to the Mule Developer Forum .  If you have feedback, please respond. We’ll take all feedback into account as it is very valuable to us.  Here is an example post.
  4. Contribute Code.  Think something needs to be in 3.3 and don’t want to wait for us to get to it?  Feel free to take things into your own hands and have a go at it yourself and then file a patch.  To ensure we integrate your patch speedily you’ll want to make sure you: i) explain well what your patch is for; ii) include a good quality test case; and iii) don’t break any backwards compatibility.

Download Mule now!

Hoping to hear from you,
The Mule team.