This document discusses using flows for service orchestration in Mule ESB. It defines a flow as a chain of message processors that enables automation of integration processes. Flows are valuable for simple integration tasks, scheduled data processing, connecting cloud/on-premise apps, and event processing involving multiple services. A flow has a message source, processors configured in XML using <flow>, and an optional exception strategy. Flows can be powerful when combined with expressions to perform sophisticated message processing. Private flows differ in that they are not accessible via endpoints and are only used internally within a Mule instance.

1. USING FLOWS FOR SERVICE
ORCHESTRATION
Presented By
SindhuVL

2. Introduction :
 A Flow is a simple yet very flexible mechanism
that enables orchestration of services using the
sophisticated message flow capabilities of Mule
ESB. Using Flow, you may automate integration
processes and construct sophisticated
integration solutions by simply building them
from the connectors provided by Mule. Because
of the flexibility of Flow, it is much easier to
create solutions that more closely match your
requirements. Flow is new in Mule 3.

3. When to Use a Flow :
 Flows are valuable in many situations,
including:
 Simple integration tasks
 Scheduled data processing
 Connecting cloud and on-premise
applications
 Event processing where multiple services
need to be composed

4. The Anatomy of a Flow :
A flow is in
essence just a
chain of Message
Processors.Think
of each Message
Processor as a
Lego block where
a Flow is
something you
build with them.
A flow also has a
message source,
the source of
messages that

5. Flow Configuration :
A Flow is
configured in XML
using the <flow>
element. Each flow
has a name
attribute, a
message source
(unless it’s a private
flow), one or more
message
processors and an
optional exception
strategy.

6. Flows seem simple,
yet can be quite
powerful. In
particular, when
combined with
expressions in Mule,
they can allow for
very sophisticated
processing of the
message contents.
There are many
elements that
leverage expressions,
including:
 Transformers
 Filters
 Routing
 Message Enricher

7. Example :

8. Flow Behavior :
 When a message is received or generated by
the message source the flow is started and
the configured message processors are
invoked in a chain in the same order as they
are configured.
 Some message processors accept child
message processor elements, in this case
these are processed before returning and
continuing processing the main list.

9.  Note:When the last element in the flow
configuration is a one-way <outbound-
endpoint> there’s no result of it’s execution so
the returned payload of the message is going
to be NullPayload. If the one-way <outbound-
endpoint> is followed by another processor, it
receives as input the same message that the
outbound-endpoint receives instead of
NullPayload.

10. Architecture :

11. Private Flows :
 A private flow is one that cannot be accessed from
outside the JVM via a Mule Endpoint because it has
no message source defined.
 Private Flows are therefore only used if they are
referenced from another construct running in the
same Mule instance.When configuring Mule using
XML the <flow-ref>element is used to include one
flow in another.
 A private Flow differs from the use of a "Processor
Chain" in that a Flow has it’s own context and
exception strategy where as when a processor chain
is referenced, it is executed in the context of the flow
that references it.

12. Private Flow Example :

13. ThankYou!!!!!!!!!!