Reading Time: 9 minutes

Mule 3 underwent some significant architectural improvements, I talked about this back when Mule 3.0 was released in my “Mule 3 Architecture: Back to Basics” blog post.  These improvements  enable a much simpler way of configuring Mule that is more powerful while at the same time much more intuitive.  As we release Mule 3.1 I really want to encourage everyone to “Go with the Flow!!”

In this post we’ll cover the basics of “Mule Flow”; what it is, when to use it and how to integrate with it.

What is a Flow?

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

A Mule Flow is a new way to orchestrate services.  Flow is a very flexible way to build integrations by simply choosing building blocks from Mules wide range of functionality and glueing them together intuitively.

When should I use a Flow?

It’s simple.  If both these questions return false then you should be using Flow:

  • Does a configuration pattern exist for what you need to do already?  (Check here for patterns that come with Mule, also check with the rest of your team in case anyone has implemented any.)
  • Do you want to implement you own pattern so it can be re-used?

What happened to ‘service’?

It is important to note that flows can be used alongside Mule 2 style services in the same configuration file.  They can also be used alongside and integrate with Mule 3 Patterns.

How does Mule Flow work?

I won’t revisit the pipes and filters or message processor discussions here but you can read those post if you are interested.

From the user’s perspective a flow is a linear list of integration building blocks where each building block does something with or to the message being processed.   We call these message processors.  The exception to this is the optional first element in the flow that defines where new messages come from, we call this the message sources.

When the message source receives (or generates) a new message the flow is executed.  When the flow is executed each message processor is invoked in the order they are defined in configuration one after another, each message processor receiving the result of the previous message processor.  Sometimes message processors are nested, in this case these are invoked  before the main flow continues (exactly how they are invoked depends on their parent).

Note: There are some exceptions to the above for <async> element and when a message processor returns null but we won’t cover these here.

How is a Mule Flow configured?

We just covered how a Flow works and what it’s made up of.  Configuring it is exactly as you would expect

<flow name="..">
    - 0..1 Message Source(s)
    - 1..n Message Processor(s)
    - 0..1 Exception Handler
    - 0..1 Threading Profile
</flow>

If a message source is not configured then the follow can only be invoked by looking up the flow instance programmatically (locally), or from a reference from another flow.  If you need to recieve messages from multiple sources than a <composite-source> element can used to hold 1-> message sources.
This configuration approach allows you to very directly configure your requirements, you can literally almost go almost straight from an architecture diagram to your Mule configuration file without having to jump through any hoops. And not only that, once your done it’s very easy to understand whats been implemented

What can I use in a Flow?

Anything you could always do with Mule can be configured and used as part of a <flow>.  This includes inbound and outbound endpoints, message routing/transformation/filtering along.  Of course the same transaction, error-handling and threading mechanisms are used with <flow> as were used with services in Mule 2.

The list of building blocks in the Mule user guide provides a comprehensive list of what can be configured within a <flow>.

Example

This is a fairly complex example that would have taken multiple services with Mule 2.  Take a look at it and see if you can follow what it does:

Ok, I hope you didn’t cheat and scroll-down but had a good chance to read and understand what this flow does.  I’ll summarize what this flow does just so you can compare notes:

  • Pick up all files in ‘/myDirectory’ that have a ‘.xml’ extension.
  • Transform the xml document using the ‘transform-to-my-format.xslt’ xslt stylesheet.
  • Split the transformed incoming (order list) message into multiple (order) messages.
  • For each order message do the following
    • Use an xpath expression to determine the type of order (book, cd, other)
    • If it’s a book order then invoke the “org.my.company.BookOrderService” component, if it’s a cd then invoke the “cdOrders” flow else send the message to ‘failedOrders’ JMS queue.
    • Asynchronously update product inventory by calling out to the ‘updateInventory’ flow
    • Use a custom transformer (org.my.company.ConfirmationEmailTransformer) to create a order confirmation email and send it to the customer.

How to get started with Mule Flow

This provides an introduction to Mule Flow.  In order to start using Mule Flow you first want to download Mule 3.1.  Flow documentation can be found in the Mule user guide. Going forward all new examples and blog posts will be using Flow so you can use these are further examples.  As always keep the questions, comments and bugs coming so we can use them to further improve the product,