The entire application can manage the value of the client context identifier in the ClientContextId property. For example, a server session might control the client context identifier for a client using the OERequestInfo instance returned to the client in the server response, or act as a client to another server using the OERequestInfo instance sent to that other server in its own remote request.

In addition to the client context identifier, instances of OERequestInfo provide additional context information that depends on whether the client or server is originating the instance.

OpenEdge context information accessible by a server session provides:

  • OpenEdge version information for the current server session — The server 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.
  • Server version information returned to a client — This identifies the OpenEdge Release information for the server returned to the client from the server session in response to the current client request. This is the same information provided to the agent using its own LOCAL-VERSION-INFO attribute. The server session provides this information to the client using the VersionInfo property on the OERequestInfo instance referenced by the CURRENT-RESPONSE-INFO attribute on the session'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 session 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 server session 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 server session 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 server session handling the request 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 the ABL Reference.

For session-free connections, the typical way for both the client and server to manage context is for both the client and server to manage context. A client request can be executed, not only on any available session on the server, but on any one of many servers that support the business application for a single user login session. You can also use this same configuration for one or more servers that support a single user login session for an unbound session-managed application..

Because none of the context management attributes provided for a session-managed application work for a session-free application (except for the SERVER-CONNECTION-BOUND attribute), the context database must:

  • Be shared by all server instances that support the user login session
  • Use an entirely application-defined means (such as the ClientContextId property) to identify and distinguish user login session 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 each session handling the remote requests.

For more information on managing context from the ABL client, see Accessing client context regardless of application model.