Reading Time: 6 minutes

Routers in Mule implement the Message Router pattern described in the seminal work on integration patterns: Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf. Addison-Wesley Professional; October 20, 2003. They allow you to route a Mule event from one Event Processor to one or many Event Processors.

In this blog, I will highlight the Choice router, how it differs in Mule 4 from Mule 3 and show how to take advantage of the latest features in Mule 4.

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

The Choice router in Mule is an implementation of the Content-Based Router enterprise integration pattern. It examines the message content and routes the message onto a different channel, based on data contained in the message. The routing is based on a boolean expression that tests an assertion. The value may be obtained from any source that is visible to the choice router, such as data contained in the message payload, attribute, or variable. 

Let’s take a look at a simple example in Mule 3 and Mule 4 that routes a message based on a value in the payload.

Mule 3 Choice

In the Mule application below, a simple payload is constructed as a JSON object, as shown in figure 1 and passed to the Content router.

{
  "myKey": "myValue"
}

Figure 1: Input payload

What you will observe in the Mule configuration file are three main features:

  1. The expression attribute of the choice message processor uses MEL (Mule Expression Language).
  2. The JSON data must be transformed into a Java HashMap before passing to the choice router.
  3. The otherwise scope is mandatory. Resulting in developers typically placing in an empty logger configuration just to satisfy this requirement.

The full source code for this example is in the mule3-choice.xml Mule configuration file in the mule4-core-component-migration-blog repository.

Mule 4 Choice router

The Mule 4 Choice router differs in a few ways and brings some improvements.

On examining the Mule configuration below you will notice three main differences:

  1. The expression attribute uses DataWeave expressions — DataWeave is now the only transformation and expression language in Mule. MEL has been removed.
  2. There is no requirement to transform the payload into a HashMap. In fact, it is possible to work with application/json, application/xml, and any supported MIME type, without transforming it to an intermediary format first.
  3. The otherwise scope is now optional.

The full source code for this example is in the mule4-choice.xml Mule configuration file located in the mule4-core-component-migration-blog repository.

Conclusion

In Mule 4 the Choice router is much improved. 

It fully supports DataWeave as the expression language, which brings a large range of functions that make it much easier and flexible to work with your data. This includes a wide array of operators, selectors, functions, and modules out-of-the-box. 

The configuration is cleaner thanks to the removal of the obligatory otherwise scope and the transformation into a Java Map type.

Overall the Choice router has been given a facelift, resulting in a cleaner and more powerful implementation of the content router enterprise integration pattern.

For more information, see the full code source examples for both the Mule 3 and Mule 4 .