mule-esb-flows

Mule is a Java-based product which provides an enterprise service bus (ESB) solutions. We can develop Mule applications using Anypoint Studio, an Eclipse plugin.

After a brief introduction to ESB’s and flows, we’ll talk about the different types of flows in Mule, and where we use each type.

An ESB is a mediating layer connecting independent pieces of software. These apps often use different protocols. Consequently, the ESB will take care of transforming and routing the data. This allows for the creation of decoupled services. Therefore, each service does not need to worry about how another service will consume its output.

It is the ESB’s job to make sure that the data is in the correct format. We can find more details about Mule ESB in our previous tutorial.

Components are the building blocks of a Mule application. Thus, it’s these components that are responsible for transforming and routing data. We add components to a Mule application from the Mule Palette, on the right-hand side of Anypoint Studio:

Components are subsequently grouped into flows. A Mule application consists of one or more flows.

A flow is a connected collection of Mule components.

It usually consists of an inbound endpoint component (from where a message originates), and an outbound endpoint component. Therefore, the flow is responsible for the various processing stages in which the message may undergo.

Each flow may have a processing strategy as well as an exception handling strategy associated with it. A flow may also reference another flow using a flow reference component.

There are three different types of flows in Mule:

We use subflows to group common logic. Subflows are processed synchronously; that is, execution of the calling flow halts until the subflow is complete.

Specifically, we can add a subflow from the Mule Palette:

The subflow is called using a flow reference component:

Additionally, subflows inherit the processing strategies and exception handling strategies of the calling flow. We can call a subflow from multiple different flows. Should we not wish to inherit these strategies, we could call a synchronous flow.

Like a subflow, a synchronous flow is also processed synchronously. This means that when we call a synchronous flow, it must complete before the parent flow resumes its execution.

We add synchronous flows to our Mule application by adding regular flows; there is no “synchronous flow” component. We add a regular flow component:

To call the synchronous flow, we again use a flow reference component:

Unlike a subflow, it doesn’t inherit the processing and exception handling strategies of the calling flow. Consequently, the processing and exception handling strategies of the calling flow do not affect the behavior of this type of flow.

For these reasons, this type of flow is ideal for transactional processing since messages processed using synchronous flows execute on a single thread.

Asynchronous flows execute in parallel to the calling flow; i.e., they are processed asynchronously.

We add asynchronous flows to the Mule application in the same way we add synchronous ones. So, what makes the flow asynchronous, is that we call it from within an asynchronous scope. We can do this by wrapping the flow reference component in an async component:

Similarly to synchronous flows – they don’t inherit the processing and exception handling strategies of the calling flow.

Additionally, messages processed using asynchronous flows execute on multiple threads, making this type of flow ideal for time-consuming tasks such as sending out emails or performing I/O operations.

In this short tutorial, we discussed the characteristics of the different types of flows in Mule.

For more information visit the official Mule website.