Mule 3 vs Mule 4 Message Structure

Mule 4’s message structure has been overhauled. Mule 4 has made it easier to work with properties and variables by simplifying Mule Event and Mule Message. Mule 4 doesn’t have any inbound or outgoing properties. The qualities were first introduced by MuleSoft. Mule 4 also included variable concepts, allowing it to deal with all types of variables at the same time rather than dealing with distinct types of variables such as session, flow, and record variables separately as it did in Mule 3. Have a quick review with this mulesoft tutorial which enables you to comprehend the concepts like mulesoft, the need for ESB, its implementation and functionalities, installation and deployment of mule apps, and much more. To understand the differences between mule 3 and mule 4, look into this short analysis which is made on mule 3 vs mule 4.

When a message is received by Mule, flow begins processing it. Mule Client then retrieves an external event, which is triggered by some external systems, such as when a message is received on a queue or when a file is copied to a directory. When it gets an inbound endpoint in a flow, it is turned into a Mule message or flow and begins processing it.

When a trigger hits the event source of flow in Mule 4, flows caused by an event are generated.

Each component in Mule 4 interacts with Mule Event, which then travels sequentially through the flow’s components.

Message structure in Mule 3:

Mule Message: A Mule Message is a piece of data that is handled by one or more flows throughout an application.

Messages are made up of two parts:

1. Header: contains the message’s metadata. Metadata is a collection of attributes that provide information about a message. Properties have inbound (We can’t change what’s been created automatically by the message source.) and outbound (set by the user in a flow or produced automatically by Mule) properties.

2. Payload: contains accurate business data.

Variables: Variables are used to hold per-event values that can be used within a Mule app’s flow.

There are three different variable types:

1. Flow Variables: Within the flow, data is stored.

2. Session Variables: To keep track of data throughout the app.

3. Record Variables: To keep track of data during batch processing.

Message Structure in Mule 4:

Mule Message:

Events and Messages have been streamlined in Mule 4 to make it easier to study and construct apps.

Mule Event:

The “Message” and “Variables” events in Mule are both present.

Message:

The payload and properties of a Mule Message are included.

1) Payload: Payload can be accessed using the term “payload” in the body of the mule message, and fields can be accessed using DataWeave scripting language like “payload. <fieldname>”. Mule 4’s default scripting language is DataWeave expression language, as MEL was removed in Mule 3 to alleviate the stress of converting into Java objects.

Payload data access:

2) Attributes: Attributes store message metadata, such as headers and properties received or returned by a connector, and also other metadata that the connector populates. Depending on the connector, the metadata exposed to the message differs. The keyword “attributes” can be used to access attributes. The permissible identifiers for attribute names include characters, underscores, and numbers. When an Operation or Source generates a new Message as a result of its execution, both parts of the Message (payload and attributes) are replaced with the new values, and the old attributes are destroyed. You can either store the previous attributes in a variable or set the target parameter in the invoked operation if you need to keep any information from the attributes across operation invocations.

Attribute accessing:

Variables:

Variables are used to store arbitrary user data, such as operation results, auxiliary values, and so on.

Any supported data type, such as strings, objects, and numbers, can be saved.

It can also hold current messages using the “message” keyword, and also current message payloads and characteristics using the “payload” keyword. The keyword “vars” can be used to access variables.

Variables can be created in the following ways:

1. The Set Variable component could be used to create variables.

2. Using a target variable to send data to the connection from within an operation.

3. Using a DataWeave.

4. Scripting component usage.

Remove/delete variables:

Using the component “remove variable”.

Mule 4 does not have any transport hurdles, hence session variables are no longer needed.

Batch processing, which works as a scope in Mule 4, removes record variables. Variables can be used instead. Variables defined during the process phase are automatically linked to the processing record and stored during the processing phase. Variables produced during the processing phase will only exist during that phase, whereas variables created before or after batch processing will exist throughout the processing phase and after the phase is completed.

Accessing Variables:

Comparison among mule 3 and mule 4 structure

Here we are going to compare the syntaxes and other things among mule 3 and mule 4 structures.

Message Collections:

Dealing with various payloads is one of the main benefits of the Mule 4 Message structure. Mule 3 had a specific structure called the Mule Message Collection that was utilized by components that returned numerous payloads. Any component in Mule 4 that needs to handle numerous messages can simply set the message’s payload to a Mule Messages List. You could even use DataWeave or any other component to iterate over these messages.

Conclusion:

In this blog, you have seen the flow of components in mule application, the message structure of mule 3 and mule 4 that includes parts of mule messages, different variable types, accessing attributes, removing variables, along with the comparisons made on syntaxes, variables, and properties of mule 3 and mule 4.