Architecture

1. Mule Application Architecture

2. 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. 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 throughput
clusters or transactions to maximize reliability
object-stores to ensure data persistence
These represent only a fraction of the features you can implement through a
Mule application.

4. 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. 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.

6. 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

7.  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

9. 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.

10. 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 Flow
The data as the payload of the Mule Message.
If required, a series of attachments
that can accompany the message.

11. 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.

12. 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

13.  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

14.  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