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.
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.
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
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 🙂
Happy Learning 🙂
Hello Manish,
Nice blog! I am editor at Java Code Geeks (www.javacodegeeks.com). We have the JCG program (see http://www.javacodegeeks.com/join-us/jcg/), that I think you’d be perfect for.
If you’re interested, send me an email to eleftheria.drosopoulou@javacodegeeks.com and we can discuss further.
Best regards,
Eleftheria Drosopoulou
Nice article…!