The service message object (SMO) context lets mediation primitives pass data that is not part of the message payload, between themselves.
SMO context objects are either user-defined or system-defined. You define the structure of user-defined context objects, and WebSphere® Integration Developer defines the structure of system-defined context objects.
Generally, you define the structure of a user-defined context object in a business object, and use the business object in the input node of the request flow. User-defined context objects can be used to store properties that mediation primitives use later in the flow.
The userContext is slightly different to other user-defined context objects. It is used to pass data that is not part of the message payload, between multiple SCA components in the same module.
context/transient/oldAddress
The correlation context is used when mediation primitives want to pass values from the request flow to the response flow. You can use the correlation context to link a specific request message with its response.
The transient context is used for passing values between mediation primitives in the current flow: either the request flow or the response flow. The transient context cannot link requests and responses.
For example, an XSLT mediation primitive might save an input message to the transient context, and create a new input message for a Service Invoke mediation primitive. After the Service Invoke call, the next XSLT mediation primitive could create another message by combining the Service Invoke response, and the original message stored in the transient context.
The shared context is a storage area you can use if you want to aggregate data: there is only one shared context per thread, per flow. Generally, there is one thread for the request flow and one thread for the response flow. Therefore, the request flow has one shared context and the response flow has another shared context. Theoretically, if you had a Service Invoke mediation primitive between a Fan Out and a Fan In, the Service Invoke could make an asynchronous call with callback. An asynchronous call with callback creates a new thread, and a new request (or response) flow. However, the runtime does not allow this and forces Service Invoke calls, inside a Fan Out and Fan In, to be asynchronous with response. Therefore, there is no contention for the use of the shared context.
If you use a Service Invoke mediation primitive outside of a Fan Out and Fan In aggregation sequence, and you use an invocation style of asynchronous with callback, then the shared context is empty after the service invocation.
After you have defined the shared context you can use it to store data during aggregation operations. You need to design the shared context business object carefully, to make sure it is suitable for all aggregation scenarios within a specific flow. The content of the shared context business object does not persist across a request and response flow through callout invocation: the shared context content is only available within the scope of a single request or response flow.
Generally, you might use a userContext object if you had a module that contained different types of SCA components, and you wanted to pass data between the components.
For example, you could populate a userContext from a Java component, using the context service API. You could then access the userContext data from a mediation flow component, using the SMO.
You can control whether a userContext object is created by using a qualifier on the export.
In order to understand how the different user-defined contexts are used, you need to know that there can be multiple copies of an SMO within one mediation flow. Each instance of an SMO has its own correlation context and transient context. Therefore, if there are multiple copies of an SMO within one flow, there are multiple versions of the correlation context and transient context.
However, there is only one shared context per thread, per flow. Therefore, you can have multiple instances of an SMO, but they can all use the same shared context. For example, a request flow path might split and rejoin, but the different paths would all have access to the same shared context.