The message structure of Mule 4 is completely changed now. Mule 4 has simplified Mule Event and Mule Message to make it easier to work with properties and variables. There are no inbound or outbound properties in Mule 4. MuleSoft introduced the attributes. Also, Mule 4 came up with the variable concepts; it can simultaneously deal with all types of variables instead of dealing with the different types of variables like session, flow, and record variables individually in Mule 3.
In Mule 3, the flow starts processing a message when the request is received by Mule, then Mule Client retrieves an external event, which is triggered by some external systems like the message received on a queue or when a file is copied to a directory. 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 the flow.
In Mule 4, each component interacts with Mule Event, then the Mule event travels sequentially through the flow components.
Mule 3 message structure:
Mule Message: Mule Message is data that is processed throughout an application via one or more flows.
Messages contain mainly two parts:
- Header: contains metadata about the message. Metadata consists of properties that provide helpful information about the message. Properties contain inbound (automatically created by message source, we cannot modify) and outbound (set by the user in a flow or automatically created by Mule) properties.
- Payload: contains actual business data.
Variables: Variables are used to store per-event values for use within a flow of a Mule app.
We have three types of variables:
1. Flow Variables: To store data within the flow.
2. Session Variables: To store data throughout the application.
3. Record Variables: To store data within batch processing.
Mule 4 Message Structure:
Mule Message:
In Mule 4, Event and Messages are simplified to easily learn and develop the applications.
Mule Event:
Mule event contains “Message” and “Variables.”
Message:
Mule Message contains payload and attributes.
- Payload: In the body of the mule message, you can access payload using the keyword, “payload,” and fields by using DataWeave scripting language like ‘payload. <fieldname>’. DataWeave expression language is the default scripting language in Mule 4 as MEL is removed in Mule 3 to avoid the stress of converting into Java objects.
Accessing payload data:
- Attributes: Attributes contain message metadata that can consist of headers and properties received or returned by a connector, as well as other metadata that is populated by the connector. The metadata available to the message varies depending on the connector. We can access attributes by using the keyword “attributes”. The characters, underscores, and numbers are the valid identifiers for attribute names. When any Source or Operation produces a new Message because of its execution, both parts of the Message (the payload and attributes) are replaced with the new values, and the previous attributes are lost. If you need to preserve any information from the attributes across operation invocations, you can either store the previous attributes in a variable or set the target parameter in the invoked operation. Accessing attributes:
Variables:
Variables hold arbitrary user information such as operation results, auxiliary values, and so on.
The stored data can be any supported data type like strings, objects, and numbers.
It can also store current messages using the “message” keyword and also store current message payload using the “payload” keyword and current message attributes using the “attributes” keyword.
Variables can be accessed using the keyword “vars”.
Ways to create variables:
1. You can create variables using the Set Variable component.
2. Using the target variable from within an operation to the connector.
3. Using DataWeave.
4. Using scripting component
Delete/remove variables:
Using the “remove variable” component.
Session variables are removed as transport barriers no longer exist in Mule 4.
Record variables are removed by batch processing, which behaves like a scope in Mule 4. So, instead, we can use variables. Variables that are created in the process phase are automatically tied with the processing record and stored throughout the processing phase. Variables created during the processing phase will exist during the processing phase only and variables created before or after batch processing will exist throughout the processing phase and on completion of the phase.
Accessing Variables:
Comparison between mule 3 structure and mule 4 structure
Message Collections:
One of the major advantages of the Mule 4 Message structure is dealing with multiple payloads. In Mule 3, components that returned multiple payloads used a special structure called the Mule Message Collection. 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. You can then iterate over these messages using DataWeave or each or other components.
If you are interested in more information about how MuleSoft works, MuleSoft best practices, or proper MuleSoft implementation don’t hesitate to contact XTIVIA as we are one of MuleSoft’s integration partners.