2. - At the simplest level, Mule applications accept and process events
as messages through several message processors plugged together in
a flow.
- Large or streaming messages can be processed as records in a batch
job
- Essentially every Mule flow contains a series of message
processors that accept, then process messages
=> Understanding the basic flow architecture and batch job structure is
key to understanding Mule
3. Flow
• A flow is the construct within which you link together several
individual elements to handle the receipt, processing, and eventual
routing of a message.
• You can connect many flows together to build a complete application
which you can then deploy on premise, on Mule or another
application server, or in the cloud.
• The units with which flows are constructed are known generically
as building blocks (in Studio’s graphical representation of a
flow) or elements (in XML configuration).
6. Batch Jobs
• A batch job is a top-level element in Mule which exists outside all
Mule flows.
• Batch jobs split large messages into records which Mule processes
asynchronously.
• You can initiate a batch job which is a block of code that splits
messages into individual records, performs actions upon each record,
then reports on the results and potentially pushes the processed
output to other systems or queues.
8. Batch Jobs
• Batch processing is particularly useful when working with the
following scenarios:
• Integrating data sets, small or large, streaming or not, to parallel process
records
• Synchronizing data sets between business applications.
• Extracting, transforming and loading (ETL) information into a target system,
such as uploading data from a flat file (CSV) to Hadoop
• Handling large quantities of incoming data from an API into a legacy system
9. Message Sources
• Mule processes messages (i.e. events) initiated in external resources
• The first building block of most flows or batch jobs is a receiver which
receives new messages and places them in the queue for processing.
• This message source – an inbound HTTP endpoint – receives
messages from one or more external sources, thus triggering the
execution of a flow or batch job
• Message sources in Mule are usually Anypoint Connectors, elements
which provide connectivity to a specific external source, either via a
standard protocol or a third-party API.
10. Message Processors
• In Mule, message processors are grouped together by category.
• Mule transformers are the key to exchanging data between nodes, as they
allow Mule to convert message payload data to a format that another
application can understand
• Mule uses components to conduct backend processes for specific business
logic such as checking customer and inventory databases. Components route
messages to the correct application.
• Mule includes a variety of filters, scopes, and routers to customize how a flow
or batch job processes messages
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
• The message payload, which contains your business-specific data.
12. Mule Message Structure
• Batch processing is particularly useful when working with the
following scenarios:
• Integrating data sets, small or large, streaming or not, to parallel process
records
• Synchronizing data sets between business applications.
• Extracting, transforming and loading (ETL) information into a target system,
such as uploading data from a flat file (CSV) to Hadoop
• Handling large quantities of incoming data from an API into a legacy system
13. Mule Message Structure
Header:
• The metadata contained in the message header consists
of properties which provide useful information about the message.
• Contained within the message object, variables represent data about
a message.
14. Mule Message Structure
Header:
• Properties have two main scopes: inbound and outbound.
• Inbound properties are immutable, are automatically
generated by the message source and cannot be set or
manipulated by the user.
• 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
15. Mule Message Structure
Header:
• Outbound properties are mutable, 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
16. Mule Message Structure
Header:
• Variables are user-defined metadata about a message. Variables
have three scopes:
• Flow variables apply only to the flow in which they exist.
• Session variables apply across all flows within the same application.
• Record variables apply only to records processed as part of a batch.
17. Mule Message Structure
Message Payload:
• The message payload is the most important part of the Mule
message because it contains the data your Mule application
processes
• The payload doesn’t necessarily stay flow the same as it travels through a
flow. Various message processors in a Mule can affect the payload along the
way by setting it, enriching, or transforming it into a new format. You can also
extract information from a payload within a flow using a MEL expression
