Understanding map execution contexts

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 Express 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 the Activity Editor.

Calling contexts

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 56 lists the valid constants for calling contexts.

Table 56. Calling contexts
Calling-context constant Description
EVENT_DELIVERY The source business object(s) being mapped are event(s) from an application, sent from a connector to InterChange Server Express in response to a subscription request ( event-triggered flow).
ACCESS_REQUEST The source business object(s) being mapped are calls from an application, sent from an access client to InterChange Server Express (call-triggered flow).
ACCESS_RESPONSE The source business object(s) being mapped are sent back to the access client in response to a subscription delivery request.
SERVICE_CALL_REQUEST The source business object(s) being mapped are sent from InterChange Server Express to an application, through a connector.
SERVICE_CALL_RESPONSE The source business object(s) being mapped are sent back to InterChange Server Express from an application as a response to a successful service call request.
SERVICE_CALL_FAILURE The source business object(s) being mapped are sent back to InterChange Server Express from an application after a failed service call request.

You can reference these calling contexts as constants in the MapExeContext object that is available in every map that Map Designer Express creates.

Example: You reference the SERVICE_CALL_REQUEST calling context as MapExeContext.SERVICE_CALL_REQUEST.

Figure 76 illustrates when each of the calling context occurs in an event-triggered flow. Event-triggered flow is initiated when a connector sends an event to a collaboration in InterChange Server Express.

Figure 76. Calling contexts in an event-triggered flow

As Figure 76 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 77 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 Express.

Figure 77. Calling contexts in a call-triggered flow


As Figure 77 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 Express to an access client (that is, a map from generic business object to application-specific business object) has a calling context of ACCESS_RESPONSE.

Original-request business objects

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 57 shows the calling contexts and the associated original-request business object.

Table 57. Calling contexts and their associated original-request business objects
Calling context Original-request business object Original-request business object from example
EVENT_DELIVERY , ACCESS_REQUEST Application-specific business object that came in from the application AppA-specific
SERVICE_CALL_REQUEST , SERVICE_CALL_FAILURE Generic business object that was sent down from InterChange Server Express Generic
SERVICE_CALL_RESPONSE Generic business object that was sent down by the SERVICE_CALL_REQUEST Generic
ACCESS_RESPONSE Application-specific business object that came in from the access request initially AppA-specific

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:

  1. A map transforms an AppA-specific business object to a generic business object with a calling context of EVENT_DELIVERY.

    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.

  2. A map transforms the generic business object to a AppB-specific business object with a calling context of SERVICE_CALL_REQUEST.

    No changes occur to the relationship tables. Application B successfully adds the new customer to the application.

  3. A map transforms the AppB-specific business object to a generic business object with a calling context of SERVICE_CALL_RESPONSE. The context for this map execution includes the generic business object generated in step 1.

    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 78 illustrates when the map execution for each step occurs for a call-triggered flow that successfully adds a new customer ID to Application B.

Figure 78. Example of Calling Contexts

Copyright IBM Corp. 1997, 2003