Mule Application Architecture

2

At the simplest level, a Mule application accepts a succession of

messages one at a time, then processes each message in the order it was

received. Sometimes, the Mule application returns a different message to

the source of the original message. In other cases, the application might

send the message in its original or altered form to one or more third

parties. Or it might do both.

3

In still other cases, Mule might decline to process (i.e., discard) a message that does not meet specific criteria.

Advanced Mule applications support much more than this sort of linear message processing. You can set up mechanisms to handle different messages in different ways. Furthermore, you can construct applications that utilize:

various queue-and-thread arrangements to maximize throughputclusters or transactions to maximize reliabilityobject-stores to ensure data persistenceThese represent only a fraction of the features you can implement through a Mule application.

Mule ESB Flow

About Mule Execution Units

Mule ESB supports several architectural approaches to building Mule applications. MuleSoft recommends Flows, the newest, most convenient, and most flexible architecture as the preferred execution unit for most Mule applications. However, Services and Patterns remain available, and may prove useful in certain specialized situations.

Flows

Flows qualify as the most powerful and flexible way to construct Mule applications, because you can arrange pre-packaged building blocks into a sequence of message-processing events that fit your application needs exactly.

5

Flows can be particularly effective for the following use cases:

Simple integration tasks

Scheduled data processing

Integration with either Cloud-based or on-premise applications

Event processing where multiple services need to be orchestrated

Mule provides a pair of interfaces for building flows. You can choose

between:

typing lines of XML code into your application configuration file

using Studio, Mule’s drag-and-drop graphical interface, to arrange

building block icons into visual sequences

Subsequently, you configure these sequenced building blocks using

other Studio graphical tools, or by editing XML code in the

configuration file.

Patterns

Mule ESB provides Configuration Patterns, which are optimized for several common message-processing cases. If your application falls outside the area covered by the group of Configuration Patterns bundled with Mule, you should use a flow instead.

Mule Component Overview

About Flows

At the simplest level, Flows are sequences of message-processing events. As the following schematic illustrates, a message that enters a flow may be:

validated (filtered) enriched (appended) transformed into a new format, sometimes by first

undergoing transformation into an intermediate format processed by custom-coded business logic logged to a database evaluated to determine what sort of response gets returned

to party that submitted the original message

What is Sub Flow

Sub flow is a private flow which is not visible outside the current flow

A sub flow will not have a Message Source.

Mule Message

The Data received from an endpoint is packaged into an object that implements Mule Message interface

A Message contains:A series of properties that vary

depending on the transport Variables – Session and FlowThe data as the payload of the Mule Message. If required, a series of attachments that can accompany the message.

Mule Message Structure

The Mule message is the data that passes through an application via one or more flows. It consists of two main parts:

The message header, which contains metadata about the message The message payload, which contains your business-specific data. 

Mule Message Properties and Variables

Message header consists of properties which provide useful information about the message

variables represent data about a message Properties have two main

scopes: inbound and outbound. Inbound Property

 Inbound Message properties are immutable Automatically generated by the message

source and cannot be set or manipulated by the user.  

They contain metadata specific to the message source that prevents scrambling of data formats or other processing mishaps later in the message's lifecycle.

A message retains its inbound properties only for the duration of the flow; when a message passes out of a flow, its inbound properties do not follow it

Inbound Message properties

They contain metadata similar to that of an inbound property, but an outbound property is applied after the message enters the flow 

Outbound properties can be set automatically by Mule or a user can set them by manually inserting one or more transformer elements in the flow.

If the message is passed to a new flow via a flow-ref rather than a connector, the outbound properties remain outbound properties rather than being converted to inbound properties

Outbound Message Properties