Controlling message flow
-
Upload
rajarajan-sadhasivam -
Category
Software
-
view
285 -
download
0
Transcript of Controlling message flow
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"/>
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