Mule Message Structure in Mule 3
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 message.The metadata contained in the message header consists of properties which provide useful information about the message.
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. They contain metadata specific to the message source that prevents scrambling of data formats or other processing mishaps later in the message’s lifecycle. 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.
Outbound properties are mutable; they are set during the course of a flow and can become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport. 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. Note that if the message is passed to a new flow via a flow-reference rather than a connector, the outbound properties remain outbound properties rather than being converted to inbound properties
The message payload, which contains your business-specific data.
A Mule message is, itself, embedded within a Mule message object. Some Mule message objects may contain variables, attachments, and exception payloads. However, as attachments and exception payloads are not frequently used or manipulated, this overview document does not include details about them.
Mule message is basically a java object.
The message header, which contains metadata about the message.The metadata contained in the message header consists of properties which provide useful information about the message.
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. They contain metadata specific to the message source that prevents scrambling of data formats or other processing mishaps later in the message’s lifecycle. 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.
Outbound properties are mutable; they are set during the course of a flow and can become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport. 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. Note that if the message is passed to a new flow via a flow-reference rather than a connector, the outbound properties remain outbound properties rather than being converted to inbound properties
The message payload, which contains your business-specific data.
A Mule message is, itself, embedded within a Mule message object. Some Mule message objects may contain variables, attachments, and exception payloads. However, as attachments and exception payloads are not frequently used or manipulated, this overview document does not include details about them.
Mule message is basically a java object.
The above mule message structure is applicable for mule 3.in mule 4 message structure is changed.
Message Payload :
The message payload is the most important part of the Mule message because it contains the data your Mule application processes. You may apply metadata in the message header or message object to communicate information about your message or secure it from being tampered with, but the core of the message – the data you are transporting – is the reason the message exists in the first place.
The payload doesn’t necessarily stay the same as it travels through a flow. Various message processors in a Mule flow 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.
Setting a Message Payload :
Use a Set Payload message processor to completely replace the content of the message’s payload. Enter a literal string or a Mule expression that defines the new payload that Mule should set. The following example replaces the payload with a string that reads "Hello, my friend!".
Message Payload :
The message payload is the most important part of the Mule message because it contains the data your Mule application processes. You may apply metadata in the message header or message object to communicate information about your message or secure it from being tampered with, but the core of the message – the data you are transporting – is the reason the message exists in the first place.
The payload doesn’t necessarily stay the same as it travels through a flow. Various message processors in a Mule flow 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.
Setting a Message Payload :
Use a Set Payload message processor to completely replace the content of the message’s payload. Enter a literal string or a Mule expression that defines the new payload that Mule should set. The following example replaces the payload with a string that reads "Hello, my friend!".
Enriching a Message Payload :
In some cases, you may wish to call an external resource and use the response to enrich the message payload, rather than replace it. To do so, you can use a Message Enricher scope (or wrapper) to encapsulate one or more message processors which perform the task of fetching the information. Once obtained, Mule adds to, or enriches, the message payload with the result of the call to the resource.
Viewing the Mule Message :
In Studio, you can visualize the structure of a Mule Message at any given point of the flow. All you have to do is select an element in the flow and click the DataSense icon.
This opens the DataSense explorer, and displays both the structure of the message that enters the element, and the structure of the message that leaves it. This is useful to know the names of variables and properties that are available at that point, as well as the payload’s internal structure.
In some cases, you may wish to call an external resource and use the response to enrich the message payload, rather than replace it. To do so, you can use a Message Enricher scope (or wrapper) to encapsulate one or more message processors which perform the task of fetching the information. Once obtained, Mule adds to, or enriches, the message payload with the result of the call to the resource.
Viewing the Mule Message :
In Studio, you can visualize the structure of a Mule Message at any given point of the flow. All you have to do is select an element in the flow and click the DataSense icon.
This opens the DataSense explorer, and displays both the structure of the message that enters the element, and the structure of the message that leaves it. This is useful to know the names of variables and properties that are available at that point, as well as the payload’s internal structure.
No comments:
Post a Comment