Describes how to control the message flow by using various flow components

1. Controlling Message Flow
- Mule ESB
Gudi Manirathnam

2. Topics :
Filter Types
Synchronous and Asynchronous flows
Multicasting a message
Routing message based on conditions
Filtering messages

3. 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

4. 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

5. 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.

6. 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.

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

8. 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.

9. Async Scope vs Asynchronous Flow
An 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

10. 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.

11. 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

12. 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>

13. 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>

14. 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"/>

15. 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"/>

16. 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"/>

17. 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>

18. 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"/>

19. 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>

20. 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"/>

21. Example with Scatter Gather – Multicasting a Message

22. Example with Choice– Routing Message Based on a Condition

23. 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

24. 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.

25. Filters
Message 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

26. Example With Payload Filter – Filtering Messages

27. Thank you