Mule Integration WorkshopControlling Message Flow

Rajarajan Sadhasivam

Chapters

Schedule

Filter Types

Synchronous and Asynchronous flows

Multicasting a message

Routing message based on conditions

Filtering messages

Flow Processing Strategy

A 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 Strategy

All 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 Strategy

Synchronous

- 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 Strategy

Queued -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 Strategy

Mule 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 Scope

A 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

Routers

Routes 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-Gather

Scatter-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>

Choice

Choice

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

Filters

Idempotent 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