Try OpenEdge Now
skip to main content
Developing AppServer Applications
Programming the AppServer : Managing state-free and stateless client context : Managing context from the AppServer with OERequestInfo objects
 

Managing context from the AppServer with OERequestInfo objects

The entire application can manage the value of the client context identifier in the ClientContextId property. For example, an AppServer agent might control the client context identifier for a client using the OERequestInfo instance returned to the client in the AppServer response, or act as a client to another AppServer using the OERequestInfo instance sent to that other AppServer in its own remote request.
In addition to the client context identifier, instances of OERequestInfo provide additional context information that depends on whether the AppServer client or agent is originating the instance.
OpenEdge context information accessible by an AppServer agent provides:
*OpenEdge version information for the current AppServer agent — The agent session can access the LOCAL-VERSION-INFO attribute on its SESSION system handle to find its OpenEdge Release information. This object reference attribute returns a Progress.Lang.OEVersionInfo class instance with OEMajorVersion, OEMinorVersion, and OEMaintVersion properties that provide this information. This Release information is also returned in the response to each client request.
*OpenEdge AppServer version information returned to a client — This identifies the OpenEdge Release information for the AppServer returned to the client from the AppServer agent in response to the current client request. This is the same information provided to the agent using its own LOCAL-VERSION-INFO attribute. The agent provides this information to the client using the VersionInfo property on the OERequestInfo instance referenced by the CURRENT-RESPONSE-INFO attribute on the agent's SESSION handle. The client can then access this information using the RESPONSE-INFO attribute on the server object handle it uses to make a remote request.
*OpenEdge version information of the client application — This identifies the OpenEdge Release of the client application that executed the current request. The agent can read this information using the VersionInfo property on the OERequestInfo instance referenced by the CURRENT-REQUEST-INFO attribute on the agent's SESSION handle.
*Client context identifier for the current request — This is the value of the ClientContextId property on the OERequestInfo instance referenced by the server handle's REQUEST-INFO attribute when the client makes a remote request. The AppServer agent can retrieve this property value on the OERequestInfo instance referenced by the CURRENT-REQUEST-INFO attribute on its SESSION handle.
*Identifier for the current request only — The client automatically generates a globally unique identifier for the current request in the RequestId property on the OERequestInfo instance referenced by the server handle's REQUEST-INFO attribute. The AppServer agent can read this property value on the OERequestInfo instance referenced by its SESSION handle's CURRENT-REQUEST-INFO or CURRENT-RESPONSE-INFO attribute. This value is read-only and cannot be changed by any application code.
*Client context identifier in response to the current request — Before completing its current request, the AppServer can set a different client context identifier value as a part of its response to the client by setting the ClientContextId property available through the CURRENT-RESPONSE-INFO attribute of its SESSION handle. Otherwise, by default, the existing property value available through its CURRENT-REQUEST-INFO attribute is used. The client can read this value after the remote request completes using the RESPONSE-INFO attribute on the server handle.
For more information on these class properties and handle attributes, see OpenEdge Development: ABL Reference.
For state-free logical connections (bindings), the typical way to manage context for a client session is for the application service to rely on a context database. In state-free bindings, a client request can be executed, not only on any agent of an AppServer, but on any one of many AppServers that support the application service for a single user login session. You can also use this same configuration for an AppServer running in the stateless operating mode.
Because none of the context management attributes provided for stateless operating mode work in state-free mode (except for the SERVER-CONNECTION-BOUND attribute), the context database must:
*Be shared by all AppServer instances that support the application service
*Use an entirely application-defined means (such as the ClientContextId property) to identify and distinguish client sessions that use the application service and to key the context database for this purpose
Together with this context database, you can use the Activate and Deactivate configuration procedures to restore context for every client request or provide the necessary context database management solely within the context of remote requests.
For more information on managing context from the ABL client, see Accessing client context regardless of session model.