Controlling Message Flow- Mule ESB

Gudi Manirathnam

Topics :

Filter Types

Synchronous and Asynchronous flows

Multicasting a message

Routing message based on conditions

Filtering messages

Flow Processing StrategyA flow processing strategy determines how mule implements message

processing for a given flow.

Should the message be processed synchronously (on the same thread)

or asynchronously(on a different thread)?

If asynchronous, what are the properties of the pool of threads used to

process the messages?

If asynchronously ,how will messages wait for their turn to be processed

in the second thread

Flow Processing StrategyAll Mule flows have an implicit processing strategy which Mule applies

automatically,

- Either synchronous or queued-asynchronous.

- Each of these is optimal for certain flows.

The Processing Strategy can be changed

The Common Flow Processing StrategySynchronous

- After the flow receives the message,all processing ,including the

processing of the response, is done in the same thread.

- With the exception of asynchronous scopes Async and For Each.

The Common Flow Processing StrategyQueued -asynchronous

-Default if no other processing strategy is configured.

- Higher Throughput

- Uses a queue to decoupe the flow’s receiver from the rest of the

steps in the flow.

- Works the same way in a scope as in a flow.

- Can fine tune number of threads , number queued , Object Store.

- Asynchronous strategy is same except it doesn’t use a queue so

cannot be distributed across nodes in a cluster.

Determining Flow Processing StrategyMule selects a processing strategy for a flow based on the flow’s

exchange pattern (and if it is transactional).

The flow exchange is determined by the exchange pattern of the

inbound endpoint.

A request-response exchange pattern is used when the sender of the

message expects the response.

- Mule Applies a Synchronous processing strategy

A one way exchange pattern is used when no response is expected.

- Mule Applies a queued – asynchronous processing strategy.

Async ScopeA Branch processing block that executes simultaneously with the parent

message flow.

-Useful for executing time-consuming operations that do not require

sending a response back to the initiating flow.

Send a message copy to the first message processor in its own

processing block and the next message processor in the main flow.

The payload is not copied , the same payload objects will be referenced

by both messages in the two flows.

Async Scope vs Asynchronous FlowAn async scope is similar to an asynchronous flow in that:

It processes the message asynchronously with the main flow, so the message is

simultaneously processed in the async scope without pausing the processing in the

main flow thread

Does not pass data from the scope back into the main flow thread

It can have its own processing strategy

However, unlike an asynchronous flow, an async scope:

Exists in-line with the main flow thread

Is not called by a flow reference component

Is not re-usable

cannot have its own exception handling strategy ,it inherits from the flow it resides

RoutersRoutes messages to various destination in a

mule flow

Some incorporates logic to analyze and

possibly transform messages before routing

takes place.

Some change the payload , some don’t

Flow controls that don’t change the payload

- Choice, Scatter-Gather , First Successful,

Round Robin.

Routers (Contd)Routers

Message Processor Description

Scatter-Gather Multicast a message to multiple targets concurrently

Choice Send a message to the first matching message processor

Collection Aggregator Aggregate messages into a message collection

Collection Splitter Split a message that is a collection

Custom Aggregator A custom-written class that aggregates messages

Custom Processor A custom-written message processor

First Successful Iterate through message processors until one succeeds (added in 3.0.1)

Message Chunk Aggregator Aggregate messages into a single message

Message Chunk Splitter Split a message into fixed-size chunks

Resequencer Reorder a list of messages

Round Robin Round-robin among a list of message processors (added in 3.0.1)

Splitter Split a message using an expression

Scatter-GatherScatter-Gather A number of flow controls aggregate results from multiple routes. Scatter-Gather sends the message to each route concurrently and returns

a collections of all results. Is often used with the combine collections transformer - Flattens a collection of collections into one collection. Eg:

<scatter-gather doc:name="Scatter-Gather"> <flow-ref name="scatter-gather-demoFlow1" doc:name="scatter-gather-demoFlow1"/> <flow-ref name="scatter-gather-demoFlow2" doc:name="scatter-gather-demoFlow2"/> </scatter-gather>

ChoiceChoice The Choice message processor sends a message to the first message

processor that matches. If none match and a message processor has been configured as "otherwise", the message is sent there. If none match and no otherwise message processor has been configured, an exception is thrown.

Eg: <choice doc:name="Choice"> <when expression="#[payload == 'Main Flow']"> <flow-ref name="choice-demoFlow1" doc:name="choice-demoFlow1"/> </when> <when expression=""> <flow-ref name="choice-demoFlow2" doc:name="choice-demoFlow2"/> </when> <otherwise> <logger message="Default ::#[payload]" level="INFO" doc:name="Logger"/> </otherwise> </choice>

Collection Aggregator The Collection Aggregator groups incoming messages that have matching

group IDs before forwarding them.

The group ID can come from the correlation ID or another property that links messages together.

Eg:

<collection-aggregator timeout="6000" failOnTimeout="false"/>

Collection Splitter The Collection Splitter acts on messages whose payload is a Collection

type. It sends each member of the collection to the next message processor as

separate messages. Attribute “enableCorrelation” to determine whether a correlation ID is set

on each individual message. Eg:

<collection-splitter enableCorrelation="IF_NOT_SET"/>

Custom Aggregator A Custom Aggregator is an instance of a user-written class that aggregates

messages. This class must implement the interface MessageProcessor. Often, it will be useful for it to subclass AbstractAggregator, which

provides the skeleton of a thread-safe aggregator implementation, requiring only specific correlation logic.

Eg: <custom-aggregator failOnTimeout="true" class="com.mycompany.utils.PurchaseOrderAggregator"/>

First Successful The First Successful message processor iterates through its list of child message

processors, routing a received message to each of them in order until one processes the message successfully. If none succeed, an exception is thrown.

Success is defined as: If the child message processor thows an exception, this is a failure. Otherwise:

If the child message processor returns a message that contains an exception payload, this is a failure.

If the child message processor returns a message that does not contain an exception payload, this is a success.

If the child message processor does not return a message (e.g. is a one-way endpoint), this is a success.

Eg: <first-successful> <http:outbound-endpoint address="http://localhost:6090/weather-forecast" /> <http :outbound-endpoint address="http://localhost:6091/weather-forecast" /> <http:outbound-endpoint address="http://localhost:6092/weather-forecast" /> <vm:outbound-endpoint path="dead-letter-queue" /> </first-successful>

Resequencer The Resequencer sorts a set of received messages by their correlation

sequence property and issues them in the correct order. It uses the timeout and failOnTimeout attributes to determine when all the messages in the set have been received.

Eg:<resequencer timeout="6000" failOnTimeout="false"/>

Round Robin The Round Robin message processor iterates through a list of child message

processors in round-robin fashion: the first message received is routed to the first child, the second message to the second child, and so on. After a message has been routed to each child, the next is routed to the first child again, restarting the iteration.

Eg:

<round-robin> <http:outbound-endpoint address="http://localhost:6090/weather-forecast" /> <http:outbound-endpoint address="http://localhost:6091/weather-forecast" /> <http:outbound-endpoint address="http://localhost:6092/weather-forecast" /></round-robin>

Splitter A Splitter uses an expression to split a message into pieces, all of which are

then sent to the next message processor. Like other splitters, it can optionally specify non-default locations within the message for the message ID and correlation ID.

Eg:

<splitter expression="#[payload]" doc:name="Splitter"/>

Example with Scatter Gather – Multicasting a Message

Example with Choice– Routing Message Based on a Condition

Filters Determine whether a message can proceed in a mule

flow - Keeps subsequent processors from receiving irrelevant or incomprehensible messages

Some implement basic logic operators(and,or,not)

Can be combined for more logical conditions

Can be defined as global filters and referenced for reuse

There are 12 bundled filters - And, Or ,Not apply Boolean logic - Message filter nests other filters - Idempotent ensures a message is not delivered more than once. - You can create a custom filter

FiltersIdempotent Filter An idempotent filter checks the unique message ID of the incoming message

to ensure that only unique messages are received by the flow. The ID can be generated from the message using an expression defined in the

idExpression attribute. By default, the expression used is #[message:id], which means the underlying endpoint must support unique message IDs for this to work. Otherwise, a UniqueIdNotSupportedException is thrown.

Exception Filter An Exception Filter matches on the type of an exception. You supply the class

indicating the exception type to the Expected Type property.

FiltersMessage Filter• The Message Filter is used to control whether a message is processed by using a filter. In

addition to the filter, we can configure whether to throw an exception if the filter does not accept the message and an optional message processor to send unaccepted messages to.

And/Or/Not Logic Filters Logic filters apply the And/Or/Not logic to one or more nested filters that they enclose. When

you use these logic filters, you add nested filters to them from within the And/Or/Not-filter nested pane.

Use the And Filter to combine two or more filters. The And Filter accepts the message and returns true only if all of its enclosed filters return true.

The Or Filter returns true if any of its enclosed child filters return true. That is, it accepts the message if the message matches the criteria of any of its filters.

The Not Filter inverts its enclosed filter. That is, the Not Filter accepts the message and returns true if the message does not match the filter criteria. For example, if the enclosed filter normally returns true for a specific message, when nested within the Not filter it returns false

Example With Payload Filter – Filtering Messages

Thank you