Flows and subflows in Mule

1. Presented By
Sindhu VL

2.  Mule applications are built around one or
more flows.
 Typically, a Mule application begins processing a
message it is received by an inbound endpoint in a
flow.
 This flow can then either implement all processing
stages, or route the message to other flows or
subflows to perform specific tasks.
 Relative to the flow which triggered its execution,
a flows and subflows can process messages either
synchronously or asynchronously.

5.  Asynchronous Flow B can perform time-
consuming tasks, such as writing data to an
external database or emailing a message,
without stalling Flow A, the flow that triggered
its execution.
 Flow A and Flow B can respond differently to
errors.
 Breaking up complex operations into a series of
smaller flows or subflows makes applications –
whether in a GUI or in XML code – easier to
read.

6.  The processing actions in a flows or subflows
can be called and used by multiple flows in an
application.
 In clusters of Mule servers, messages can
migrate between nodes when sent to an
asynchronous flow. This allows for load
balancing between nodes and higher
performance of application. (See our advanced
use case for an example.)

7.  When its execution is triggered by another flow
in an application, a flow exists as one of three
types:
1. Subflow
2. Synchronous Flow
3. Asynchronous Flow

8. 
A subflow processes messages
synchronously (relative to the flow that
triggered its execution) and always inherits
both the processing strategy and exception
strategy employed by the triggering flow.
While a subflow is running, processing on the
triggering flow pauses, then resumes only after
the subflow completes its processing and
hands the message back to the triggering flow.

9. 
A synchronous flow, like a subflow, processes
messages synchronously(relative to the flow that
triggered its execution). While a synchronous flow
is running, processing on the triggering flow
pauses, then resumes only after the synchronous
flow completes its processing and hands the
message back to the triggering flow. However,
unlike a subflow, this type of flow does notinherit
processing or exception strategies from the
triggering flow.

This type of flow processes messages along a
single thread, which is ideally suited
to transactional processing.

10. 
An asynchronous flow simultaneously
and asynchronously processes messages in
parallel to the flow that triggered its execution.
When a flow passes a message to an asynchronous
flow, thus triggering its execution, it
simultaneously passes a copy of the message to the
next message processor in its own flow. Thus, the
two flows – triggering and triggered – execute
simultaneously and independently, each finishing
on its own. This type of flowdoes not inherit
processing or exception strategies from the
triggering flow.

This type of flow processes messages along
multiple threads.

11.  A subflow can isolate logical processing blocks, making
the graphical view more intuitive and the underlying
XML code much easier to read.
 Subflows are ideally suited for code reuse, so you can
write a particular block of code once, then reference the
same subflow repeatedly from within the same
application. The diagram below offers an example of a
subflow that is executed twice by different flow
reference components in the same flow.
 Subflows inherit the processing strategies and
exception strategies of the flow that triggers it, which
means you don’t have to define these same
configuration details again when building a subflow.

13.  Like a subflow, a synchronous flow processes messages
synchronously relative to the flow that triggered it. Unlike a
subflow, a synchronous flow does not inherit the triggering
flow’s processing or exception strategies. Thus, you can set
the synchronous flow’s processing and exception strategies
to behave differently from the exception strategy you
configured for the flow(s) which triggered its execution.
 Moreover, because it does not inherit a triggering flow’s
parameters, a synchronous flow can accept calls from
multiple flows within an application (see image below)
using its own processing and exception strategies. In other
words, a flow:synchronous flowrelationship is n:1. (Of
course, a flow can call multiple synchronous flows, so the
relationship could really be described as n:n.)

15.  Asynchronous flows begin processing a message when
triggered by another flow. Since this type of flow does
not need to return data to the flow which triggered it, it
can execute simultaneously to its triggering flow. In
other words, when Flow A triggers asynchronous Flow
B, it neither passes programmatic control to the
asynchronous flow, nor does it pause its own message
processing. In the image below, the asynchronous flow
uses its own exception strategy and can be called
multiple times within a single flow or many times by
multiple flows to inject data into an external database.

17. ThankYou!!!!!!!!