Scenario: Compound operations with private parent context
This scenario demonstrates how to use the application and channel session IDs when the parent context for several operations belonging to a compound operation must be shared and private during the compound operation process. This situation might apply for a complex operation involving multiple operations. This situation may arise if data for a context hierarchy is required to persist but the context hierarchy may not be required by all operations.
The scenario is shown in the following diagram:
A session has been established with the server, and the workstation context (wks1) associated with the session has already been created by a previous operation. This operation also added a session entry into the application session table, thus establishing a link between the session and the context instance.
The diagram corresponds to the following sequence of actions:
1 The application creates the client operation whose context contains data belonging to user1. This operation is meant to create a specific context in the server, chained to the workstation context, so that any operation from user1 will be chained to the created context. The operation returns an identifier (a subsession) that will be required in subsequent requests to identify user1.
2 The application executes the client operation, which sends the operation to the server with a valid channel session ID.
3 The multichannel support implementation creates the server operation, instantiates the context, and chains it to the workstation context (as shown by the dotted line).
4 The operation performs the following process flow:
▪ Get the unique subsession or application ID (JavaExtensions.getAlphaUniqueSessionId();)
▪ Update the server operation (aServerOperation.setApplicationId(appId);)
▪ Create an entry in the session table with the session ID, application ID, and context. All other parameters are optional but the timestamp must be null. (See the description of the application ID in Establish Session and Execute Request parameters.) Create a subsession keyed collection entry in the session table for the session id(parent session) using the application id(session), and the context. (Context.addApplicationSession(applicationId, sessionId, context):)
▪ Do not unchain the operation. This context will be used by subsequent operations as their parent context when they specify the subsession identifier in the request. The server operation may provide a specialized close operation to ensure that the context is not unchained.
5 The multichannel support implementation sends the response to the client with the valid session and application subsession IDs. The Client/Server Service on the client side maps the application ID from the server to the client operation. The default implementation for HTML returns the IDs to the client in the parameters for the Execute Request Protocol.
6 The client operation uses the application subsession ID and updates the client context hierarchy to maintain the application subsession ID between requests. The management of the application subsession ID between client operation requests is the responsibility of the application implementation.
7 The application creates a new client operation, updated with the application subsession ID (aClientOperation.setApplicationId(appId);)
8 The application sends the operation to the server with the valid application subsession and session IDs.
9 The multichannel support implementation determines the current context from the session table using the application subsession ID, and chains the operation to that context. It is the responsibility of the server operation to provide a specialized close method to unchain both its context and the parent context created during the previous operation.
10 The multichannel support implementation sends the response to the client with the valid session and application IDs. The default implementation for HTML returns the IDs to the client in the predefined parameters of the Execute Request Protocol. The Client/Server Service on the client side maps the application ID from the server to the client operation.
11 The application removes the application subsession ID from the client context hierarchy when the subsession is no longer required. The management of the application subsession ID is the responsibility of the application.
