Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.1)
  3. Mule Apps

  4. Using Flows for Orchestration

Using Flows for Orchestration

Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Introduction

A flow is a simple, yet flexible mechanism that enables you to orchestrate services using the sophisticated message flow capabilities of Mule. You can use a flow to automate integration processes and construct Mule message processing solutions by placing Mule elements in a valid order.

When to Use a Flow

A flow is the most versatile and powerful integration mechanism available in Mule.

Flows are valuable for many use cases, including:

  • Simple integration tasks

  • Scheduling data processing

  • Connecting cloud and on-premise applications

  • Event processing for which multiple services need to be composed

The Anatomy of a Flow

A flow is, in essence, a chain of Mule components. If you think of a Mule component as a lego block, a flow is the structure you build by combining the blocks. A flow has a message source, which is the source of messages that are processed by the component chain.

Flow Configuration

Configure a flow by using the XML <flow> element. Each flow has a name attribute, message source (unless it’s a private flow), one or more components, and an optional error handler.

Basic Structure

<flow name="">
    - 0..1 Source
    - 1..n Component(s)
    - 0..1 Error Handler
</flow>

Flows seem simple, yet they can be quite powerful. When combined with expressions in Mule, they enable the sophisticated processing of message contents. There are many elements that leverage expressions, including:

Example

Simple Book Order Processing Flow

<flow name="orderHandling">
  <file:listener directory="/myDirectory">
    <scheduling-strategy>
      <fixed-frequency/>
    </scheduling-strategy>
    <file:matcher filenamePattern="*.xml"/>
  </file:listener>
  <ee:transform>
    <ee:message>
      <ee:set-payload resource="createBookOrdersTransformation.dwl"/>
    </ee:message>
  </ee:transform>
  <foreach collection="#[payload.orders filterObject ((value, key, index) -> value.type == 'books')]">
      <http:request method="POST" path="/book/inventory"/>
      <http:request method="POST" path="/book/order"/>
      <email:send toAddresses="#[payload.customer.email]">
        <email:body >
          <email:content ><![CDATA[#['Your order has been placed.']]]></email:content>
        </email:body>
      </email:send>
      <db:insert>
        <db:sql >INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount)</db:sql>
        <db:input-parameters><![CDATA[#[{ id : payload.customer.id, amount: payload.order.total }]]]></db:input-parameters>
      </db:insert>
    </choice>
  </foreach>
  <error-handler >
    <on-error-continue>
      <jms:publish destination="failedOrders"/>
    </on-error-continue>
  </error-handler>
</flow>

Flow Behavior

When the source receives or generates a message, Mule triggers the flow and invokes the configured components in a chain in the same order as the components are configured. Some components accept child component elements. Mule processes these before returning and continuing processing the main list.

Private Flows

A private flow is a flow that can’t be accessed from outside the Mule app because it has no source defined. Therefore, private flows are only used if they are referenced from another construct running in the same Mule app. When configuring Mule using XML, use the <flow-ref> element to include one flow in another.

A private flow differs from a subflow in that a private flow has its own context and error handler.

Private Flow Example

<flow name="privateFlow">
  <set-payload value="b"/>
</flow>

<flow name="publicFlow">
  <http:listener path="/in" config-ref="listenerConfig"/>
  <set-payload value="a"/>
  <flow-ref name="privateFlow"/>
  <logger message="#[payload]"/>
</flow>

Reusing Logic Across Applications

When your logic needs to be shared among different Mule apps, we recommend parameterizing it and exposing it through the XML SDK, which allows creating custom modules. Like with flows, the operations that custom modules expose can contain any Mule components. Custom modules are clearly parameterized and typed.

See Also