Implementing Enterprise Integration Patterns With MuleSoft: Message Routing

Introduction

In the integration world, there are a number of Integration patterns that have been identified and used during our implementation. Each implementation might be using one or more integration patterns.  

There are few universal integration patterns that are most commonly used, and it is a general solution to some business problems or integration design problems that reoccur repeatedly. 

In this article, we will be discussing how Message Routing can be used with MuleSoft.

Below are the few integration patterns related to Message Routing that can be mapped with MuleSoft Module or Object.

1.) Content-Based Router

In CBR integration patterns, the message is routed on the basis of the incoming content to a different channel. This routing can be done on various criteria such as the existence of fields, values, etc.

For example, in my incoming request if message type = order then route request to order system or message type = invoice then route the request to invoice system.

MuleSoft provided choice router to implement content-based routing integration pattern. Choice Router will basically evaluate the content and depending on defined criteria, it will route the request to the corresponding router and in case no condition matches, the request will be routed to the default router. In case the criteria matches for multiple routes, the request will be routed to the first match route.

Here is the video tutorial explaining the choice router.

2.) Aggregator

Aggregator is integration patterns that aggregate or combine the related messages and processed as a group.

MuleSoft Aggregators module provides the three types of Aggregators which collect and release the data depending on conditions configured. Aggregator module will receive the data and depending on the expression it will extract the data and send for aggregation and release or complete the aggregation depending on the configuration.

Common Configuration

Object Store

All information related to Aggregator is stored in Object Store and it can persistent as well as transient (In-Memory) Object Store.

Persistent Object Store is reliable and data can be persisted even in case the application restarted but slower.

In-Memory Object Store is faster and data cannot be recovered in case the application restarted.

Content

The expression that defines what to aggregate. The result of the evaluation is the value stored in the aggregation.

Type of Aggregators

• Size-Based Aggregator
• Time-Based Aggregator
• Group-Based Aggregator

Size-Based Aggregator aggregates the data until predefined size limits reached, executing routes and listeners.

• Max Size is the total number of the elements to be aggregated before we mark aggregation to be complete or release.
• Timeout is the maximum time to wait for aggregation to complete or release.

Here is the video tutorial explaining the Size-Based Aggregator.

Time-Based Aggregator aggregates the data until the time period is completed, executing routes and listeners.

• Period is maximum time to wait before aggregation to complete or release.

Here is the video tutorial explaining the Time-Based Aggregator.

Group-Based Aggregator aggregates in the group according to GroupId, executing routes and listeners.

• Group Id is the expression to be evaluated for every new message received in order to get the ID for the group where it should be aggregated. 
• Group Size is the maximum size to assign to the group with the group ID resolved.
• Eviction Time is the time to remember a group ID once it was completed or timed out (0 means: don’t remember, -1: remember forever).

Here is the video tutorial explaining the Group-Based Aggregator.

3.) Splitter

Splitter is an integration pattern that splits the message and processed it individually. MuleSoft provides ForEach and Parallel ForEach to split the messages and process them one-by-one or in parallel.

Parallel ForEach allows you to process the collection of messages by splitting the collection into parts that are simultaneously processed in separate routes. Once all the messages have been processed, the results are aggregated in the same order as they split before, and flows continue.

Parallel For Each vs. For Each

ForEach [Videos]

Parallel ForEach [Videos]

4.) Message Filter

Message filter is very useful integration patterns and it is used to filter the message depending on the content. 

MuleSoft provides validation module to filter the message on specified criteria  and in case if any message validation failed, it will throw validation errors.

Implementing Validation Module With MuleSoft - Part I

Implementing Validation Module With MuleSoft - Part II

Implementing Validation Module With MuleSoft - Part III

5.) Dynamic Routing

Dynamic Router evaluates all rules and routes the message to the recipient whose rules are fulfilled.

MuleSoft provides various components to achieve Dynamic Routing like Round Robin Router, First Successful Router, Choice Router, Scatter Gather Router.

Implementing Round Robin Router With MuleSoft

Implementing First Successful Router With MuleSoft

6.) Scatter Gather

Scatter Gather is an integration pattern that sends the message to multiple routes in parallel and collects the response from each route and aggregates it.

MuleSoft provides Scatter Gather router that multicasts the request to multiple routes in parallel and aggregates the response from each route. The Scatter-Gather component executes each route in parallel, not sequentially. Parallel execution of routes can greatly increase the efficiency of your Mule application and may provide more information than sequential processing. 

Now, you know how to implement message routing integration pattern with MuleSoft.