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:
- 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.
- The application executes the client operation, which sends the operation
to the server with a valid channel session ID.
- The multichannel support implementation creates the server operation,
instantiates the context, and chains it to the workstation context (as shown
by the dotted line).
- 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.
- 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.
- 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.
- The application creates a new client operation, updated with the application
subsession ID (aClientOperation.setApplicationId(appId);)
- The application sends the operation to the server with the valid application
subsession and session IDs.
- 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.
- 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.
- 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.