A Mule4 message is composed of a payload and its attributes. Mule event is immutable, so every change to an instance of a Mule event results in the creation of a new instance.

A Mule 4 Event is composed of these objects:


While we have already seen in Mule 3, Mule message is, itself, embedded within a Mule message object and it may contain variables, attachments, and exception payloads.

mule-3-message-structure
mule-4-extended-structure
In Mule 3, When the request is received by Mule message source. It is then converted into a Mule message or flow and starts processing it when it receives an inbound endpoint in a flow.
In Mule 4, flows triggered by an event are generated when a trigger reaches the event source of flow. This trigger could be an external event triggered by a resource that might be external to the Mule app.

You can create, or update, variables in these ways:

  • Using the Set Variable component.
  • Using a Target Variable from within an operation, such as the Read operation to the File connector or the Store operation to the Database connector.
  • Using the Datwave Transform Component (EE-Only).
  • Using Scripting Component (in scripting module)

You can also delete/remove:

  • Using the Remove Variable component.

    After creating a variable, you can access and use it within the scope of a Mule flow where you created it, which includes any flows that are joined with it through a Flow Ref component.
     vars : Keyword for accessing a variable, for example, if the name of your variable is myVar, you can access it like this: vars.myVar

Note that a variable in the Mule event is different from variables defined in a DataWeave script, which are local to the script and not accessible outside of it.

Message Collections:

One of the major changes to the new Mule Message structure is when dealing with collections. In Mule 3, components that returned multiple payloads, used a special structure called the MuleMessageCollection. But in Mule 4, any component that needs to deal with multiple messages can simply set the payload of the message to a List of Mule Messages. We can then iterate over these messages using DataWeave, For Each, or other components based on requirement.

Comparison between Mule 3 Structure and Mule 4 Structure

Mule 3
Syntax
Mule 4
Syntax
Description
Mule Message
#[message]
Simplified
#[message]
Consists of payload and attributes
Inbound properties
#[message.inboundProperties.’http.version’]
Replaced by Attributes
#[attributes.header]
Replaced with attributes and have advantage that we can store it in variables to access throughout your flow.
Outbound properties
#[message.outboundProperties.’MULE_ENCODING’]
Removed

We can achieve it by using dataweave expression.
Flow Variables
#[flowVars.varName]
Replaced
#[vars.varName]
Replaced with variables but acts same as Mule 3
Session Variables
#[sessionVars.varName]
removed Removed as transport barriers are no more exists. We can store values in variables itselves.
Record Variables
#[recordVars.varName]
removed Removed as batch jobs is a scope which lives inside flow, we can store in variables.
Attachements
#[message.inboundAttachements]
removed
Inbound and outbound attachments have been removed. The affected connectors now handles the attachment using Dataweave.

List of predefined keyword used in 

  • vars
  • app
  • attributes
  • authentication
  • correlationId
  • dataType
  • error
  • message
  • mule
  • payload
  • server


Happy Learning 🙂

By Manish Kumar

I am having around 10 years of IT experience in Integration Architecture, Requirement gathering, Effort Estimation, Application Design\Development\Testing and Deployment including 5+ years of experience in MuleSoft ESB and Hybrid Integrations. DevOps and Cloud Integration is my area of interest.

2 thoughts on “Mule 4 components – InDepth”

Leave a Reply

Your email address will not be published. Required fields are marked *