The implementation of the Enterprise Integration Patterns, first documented by Gregor Hohpe, is an important aspect of Mule.
These patterns are accepted solutions to recurring problems within a given context and as such provide both a framework for both designing and building messaging and integration systems as well as a common language for teams to use when architecting solutions.
The fact that Mule implements these patterns greatly reduces the effort required when building integrations, you design your solution using these well-known patterns and then simply configure and use these same patterns in Mule.
In this “Integration Patterns” series of blog posts I’ll introduce the fundamental patterns people use when building Mule applications, noting anything specific to Mule and providing configuration examples. I’ll cover one pattern per post, let me know if there is anything specific you’d like me to cover. My first post covered the Content Enricher Pattern, today we’ll look at Content-based Routing.
Content-based Routing
Problem: How do we handle a situation where the implementation of a single logical function (e.g., inventory check) is spread across multiple physical systems?
Use a Content-Based Router to route each message to the correct recipient based on message content.
The Content-Based Router examines the message content and routes the message onto a different channel based on data contained in the message. The routing can be based on a number of criteria such as existence of fields, specific field values etc. When implementing a Content-Based Router, special caution should be taken to make the routing function easy to maintain as the router can become a point of frequent maintenance. In more sophisticated integration scenarios, the Content-Based Router can take on the form of a configurable rules engine that computes the destination channel based on a set of configurable rules.
Mule
Mule uses filters to perform content-based routing. The evaluation of a filter determines if the current message should be routed to a given route or not. These routes can be any message processor including outbound endpoints.
Filters allow you to assert conditions on the current message, such the message contents, the presence or value of message headers and even attachments. Mule provides many filter implementations out of the box, the most powerful being the expression-filter which leverages Mule Expressions to allow very simple configuration of XPATH, Groovy, and OGNL based filters.
Mule’s implementation of this patterns is the ChoiceRouter. The ChoiceRouter will always choose one, and only one, route. If none of the defined routes match (because the filter evaluates to false) then, if configured, a default route is used. It’s behavior can be compared to a the use of “if / else if / else ” blocks in JAVA.
Note: Because in Mule Flow’s all routers support any message processor and not just outbound endpoints these patterns can often by applied to scenarios where selective message processing is required and not just selective routing to one of multiple outbound endpoints.
Xml Configuration
The ChoiceRouter is configured in Mule XML configuration using the “choice” element. Let’s have a look at two example configuration snippets.
The first snippet shows how “choice” is used to perform content-based routing of asynchronous message flow between different JMS queues using XPath. Notice how the ‘otherwise’ route is used to route to a dead-letter queue.
This next snippet shows how “choice” is used to perform selective message processing as part of a synchronous message flow initiated by a HTTP request using groovy.
Summary
I hope this post provided a good concise explanation of this pattern along with all you need to begin using it in your Mule Flows. Next time I plan to cover message filtering. Please be sure to comment with questions on this post or to suggest future posts. If you aren’t already a Mule user then I recommend you download Mule and seeing how easy it is to build integration using Mule Flows and Integration Patterns.
