Each map instance executes within a specific execution context that is set by the connector controller. The Mapping API represents the map execution context with an instance of the MapExeContext class.
For every map that Map Designer generates, the map's execution context
is accessible through a system-defined variable named
cwExecCtx. You can reference this variable in the Variables
folder in Activity Editor or when you call a Mapping API method that requires
the execution context, including those in Table 63.
Table 63. Mapping API methods that require the map execution context
Purpose | Mapping API method | For more information |
---|---|---|
Calling a submap | runMap() | "Transforming with a submap" |
Maintaining a relationship |
| Implementing relationships |
Table 64 shows the two pieces of information that you most often need
from the map execution context.
Table 64. MapExeContext Methods for Context Information
Execution Context Information | MapExeContext Method |
---|---|
The calling context |
getInitiator(),
setInitiator()
|
The original-request business object |
getOriginalRequestBO()
|
This section discusses both these pieces of map-execution-context information.
The calling context indicates the purpose for the current
map execution. When transforming
relationship attributes, you usually need to take actions based on the
map's calling context. Table 65 lists the valid constants for calling contexts.
You can reference these calling contexts as constants in the MapExeContext object that is available in every map that Map Designer creates.
Example: You reference the SERVICE_CALL_REQUEST calling context as MapExeContext.SERVICE_CALL_REQUEST.
Figure 92 illustrates when each of the calling contexts occurs in an
event-triggered flow. Event-triggered flow is initiated when a
connector sends an event to a collaboration in InterChange Server.
Figure 92. Calling contexts in an event-triggered flow
As Figure 92 shows, any mapping request coming from a connector to InterChange server (that is, a map from application-specific business object to generic business object) has a calling context of EVENT_DELIVERY. Any mapping request coming from InterChange server to a connector (that is, a map from generic business object to application-specific business object) has a calling context of SERVICE_CALL_REQUEST. Mapping requests sent by connectors in response to a collaboration's service call request can have contexts of SERVICE_CALL_RESPONSE or SERVICE_CALL_FAILURE.
Figure 93 illustrates when each of the calling contexts occurs in a call-triggered flow. Call-triggered flow is initiated when an access client sends a direct Server Access Interface call to a collaboration in InterChange Server.
Figure 93. Calling contexts in a call-triggered flow
As Figure 93 shows, any mapping request coming from an access client to InterChange server (that is, a map from application-specific business object to generic business object) has a calling context of ACCESS_REQUEST. Any mapping request coming from InterChange Server to an access client (that is, a map from generic business object to application-specific business object) has a calling context of ACCESS_RESPONSE.
Another important part of the map's context is the
original-request business object. This business object is
the one that has initiated the map execution. Table 66 shows the calling contexts and the associated
original-request business object.
Table 66. Calling contexts and their associated original-request business objects
For example, the generic business object is the original-request business object for maps that execute with a calling context of SERVICE_CALL_RESPONSE, SERVICE_CALL_FAILURE, or SERVICE_CALL_REQUEST. These maps use the generic business object to store relationship instance IDs for the relationship attributes being transformed. Having the relationship instance IDs is necessary for the map to look up the relationship instance and fill in the relevant participant data for newly created or updated objects.
Example: The following example illustrates how this might work in a customer synchronization scenario. Suppose you are using the system to keep data synchronized between Application A and Application B. Both applications store customer data, and the customer ID attributes are managed using a relationship. For the purposes of this example, details about the collaborations and connectors involved are omitted.
When a new customer is added in Application A:
When transforming the customer ID attribute, the map creates a new relationship instance in the customer ID relationship table and inserts the new relationship instance ID into the customer ID attribute of the generic business object.
No changes occur to the relationship tables. Application B successfully adds the new customer to the application.
The reason for this execution is to fill in the new participant data for the relationship instance created in step 1. In this case, the new participant data is the customer ID for the new customer added to application B.
Figure 94 illustrates when the map execution for each step occurs for
a call-triggered flow that successfully adds a new customer ID to Application
B.