We’ve just released Mule ESB 3.3 into the wild. This is a big release for us and and marks a huge step forward in the ease of use of Mule and what you should expect from an integration platfrom. Not only has Mule Studio been significantly improved and the brand new DataMapper added, but Mule itself has also undergone a number of significant improvements.
With the flexibility and power of Mule Flows introduced in Mule ESB 3.0 along with Mule Studio including DataMapper and the improvements to Mule itself in this new release, Mule ESB 3.3 really is “Mule 3 Reloaded”. Read the recent whole product release announcement for an overview of everything that is being released with Mule ESB 3.3, then continue reading this post to get the low down on some of the most important new feature in Mule.
While Mule ESB 3.0 greatly improves usability with the introduction of Flows, in Mule ESB 3.3 we wanted to further improve the usability of Mule in order to make things even simpler for existing users and to bring new users into the fold. Before starting on Mule ESB 3.3, we scoured our user forum and jira and talked to a number of Mule users as well as our support team in order to determine where users and customers have the most usability issues with Mule. We then prioritized these improvements and used them to drive Mule ESB 3.3.
The highlights of this work that I’ll cover in this post are:
- new pattern-based exception strategies
- brand new Mule Expression Language
- much simplified iteration over data structures within messages
- new set of elements to easily perform simple operations on messages.
- more intelligent message transformation.
- multiple improvements to HTTP and Web Services support in Mule.
- upgrades to the latest versions of open source libraries that work with Mule such as CXF and Spring.
Now, let’s jump ahead and get into some of the details.
Error Handling
Mule ESB 3.3 has taken a pattern approach to exception handling provides three new exception strategies that cover a large percentage of scenarios that we see. Using these, it’s much simpler to configure your flows’ behavior under error conditions without the need to customize exception strategies, and of course these new patterns are built in to MuleStudio.
‘Catch’ Exception Strategy
If you want to handle errors in your flow much like you catch exceptions in Java, this is the strategy you need. When an exception is thrown in your flow the catch exception strategy catchs the exception allowing you to perform alternative processing. The result of this error processing is, of course, returned as a response. With this strategy transactions are committed and, from the client perspective, everything is good. Read more …
‘Rollback’ Exception Strategy
If you want to ensure that the incoming message is not consumed by Mule when an error occurs in your flow, this is the strategy you need. If there is a transaction in progress it will be rolled back. In fact, even if you aren’t using transactional message source resource-based transports such as file and ftp, Mule leaves the message on the source system. There is full support for configuring the maximum number of redeliveries permitted and thats for any transport. This strategy supports two nested child flows giving you a huge amount of flexibility; the first is invoked on every rollback and can be used to send an error notification, while the second is invoked when the number of redeliveries have been exceeded and can be used for forwarding the message to a dead letter queue. Read more …
‘Choice’ Exception Strategy
Often the action you need to perform when an error occurs depends on the type of exception. Was the error an issue with connectivity or a business exception? The choice exception strategy allows you to define an exception strategy that composes multiple ‘catch’ and ‘rollback’ strategies as required to achieve the exact behavior that you want for each exception condition. Each nested exception strategy defines a ‘when’ clause using the Mule Expression Language and you can even do things like specify a catch-all strategy by leaving this clause out. Read more …
Global Exception Strategies
To top off these improvements we’ve made sure you can both reuse implementations of these strategies by defining global exception strategies as well as allowing you to define a default exception strategy at the application level.
The snippet above gives you an idea how these new strategies can be used to define a reusable exception strategy that leverage both catch and rollback strategies for different types of exception. These strategies are fully supported by Mule Studio.
Mule Expression Language
Expressions have been an important part of Mule since Mule 2.2; they enable basic filtering, transformation and routing using a single expression. Over time we’ve gradually added more and more expression-powered components to Mule and because of this, expressions have been become a more and more important tool when designing and building Mule applications. It’s for this reason we decided to consolidate the existing expression evaluators into a single, much more powerful expression language.
There is too much goodness in the new expression language to detail everything here, so I’ll just have to give you some tidbits. You can find complete Mule expression language documentation here.
In the above snippet values from the context objects ‘server’ and ‘message’ along with logical operators in order to perform content-based routing.
In this snippet you can how easy it is to extend the Mule Expression Language by importing classes and defining aliases and even defining global functions that are then usable in all expressions anywhere within your application.
There is a lot you can do with the new Mule Expression Language – too much to walkthrough in this post – so make sure you look our for further blog posts on this.
Note: By the way, if you really want to use the old expression evaluators or don’t have time to switch, don’t fret: all existing traditional “expression evaluator” expressions are still fully supported.
Foreach
With the new foreach message processor, iteration over a collection of elements in a message is now easier than ever. Rather than having to fiddle with splitters and aggregators or use custom code, you simply define how you wish to split the message using Mule expressions, and then define message processors within the foreach scope that will be invoked for each message part. Once iteration is complete, the processing of the flow continues with the original message without any need for any aggregation. Note, if the message is mutated within the foreach these modifications will be present after the foreach.
The example above shows a simplified order processing flow, where the files received from the inbound file endpoint are split into orders using xpath, each order being processed using a Java component.
Whats Next?
1) Well the first thing you should do is grab Mule 3.3:
Other Downloads | Release Notes
2) Next refer to the documentation for more information about new features
3) Give us feedback. Find a bug? Want to suggest something for Mule ESB 3.4 or simply want to tell us how great Mule ESB 3.3 is? Visit our community forum.
4) Keep reading our blog for more valuable posts on getting the most out of Mule ESB 3.3.
And of course, spread the word 🙂
The Mule Team
