|
This documentation is not how actually mule properties behave. It's how mule properties should behave in a future. Please leave a comment if you expect a different behavior or additional behavior is needed |
Mule has five property scopes:
Name |
Scope |
|
|---|---|---|
INBOUND properties |
|
|
OUTBOUND properties |
|
|
INVOCATION properties |
|
|
SESSION properties |
|
|
APPLICATION properties |
|
|
Inbound Message Properties
Inbound properties scope will hold the headers/properties sent by the caller flow/service/external source.

When a message arrives to a mule endpoint it can contain headers/properties. Those properties will be placed as inbound properties of the mule message.
Inbound message properties are read only since users should not be able to change incoming properties.
When a message is sent to another endpoint, in case that the called endpoint sends a response, the inbound properties are removed, and new Inbound properties will be created from the headers/properties received in the response message.
Inbound properties are also created by the Mule transport to help describe the inbound message, e.g. file size set and dateby the file transport.
Outbound Message Properties
Outbound properties scope will contain all the properties that will be deliver together with the message payload when calling an outbound endpoint.

When a message is deliver to another endpoint then all the properties in outbound scope will be sent together with the message as headers. In case that the outbound endpoint do not support headers then outbound properties won't be send.
After calling an outbound endpoint that returns a response outbound properties are lost.
Invocation Properties
Invocation properties scope is the same as the execution of the flow where they are defined
An Invocation property will be present in the invoked flow and will last for all the flow execution.
Invcation properties are not propagated to other flows, but will be propagated if another flow or sub-flow is called using flow-ref. In case that a flow is called using flow-ref, and that flow is async, then any change to those properties will not be reflected in the callers flow.
Session properties
Session properties scope is defined for the life of the execution of a Message inside mule
Mule session scope is created when a message enters a mule flow/service and it will preserved until the message leaves mule. That means that session properties will be propagated from one flow/service to another.
Mule session propagation is done only when mule endpoints transport supports message headers (i.e. JMS, HTTP, VM).
In case that a flow is called in an async way, then mule session properties will be propagated to the async flow, but any change to those properties within the async flow will not be reflected in the caller flow. The same applies to async flows called using flow-ref.
In case that a mule session property value is not Serializable then it won't be propagated.
In case that for a certain outbound endpoint session properties must not be propagated, then you can set the attribute propagateSessionProperties="false". (NEW FEATURE)
FOR DOCUMENTATION: Every time that the called outbound endpoint do not need session properties from caller flow, use propagateSessionProperties="false" to improved performance, since all the information
In case that for a certain inbound endpoint you don't won't to be aware of caller session properties, then you can set the attribute receiveSessionProperties="false". (NEW FEATURE)
Application properties
Application properties scope is tied to the application lifecycle
Application properties are read only.
To Be Defined
- How INBOUND and OUTBOUND scopes should behave when a message is splitted/aggregated