Entering content frameBackground documentation ITS User Sessions Locate the document in its SAP Library structure

Each time a user logs on through a Web browser to start an application driven by the Internet Transaction Server (ITS), this establishes one or more user sessions.

The number of user sessions started depends on the type of application. For example:

The following graphic shows how the ITS handles new user session requests coming from the Web browser through the Web server and WGate:

This graphic is explained in the accompanying text

To establish a user session, the ITS follows five main steps, as shown in the above graphic:

  1. When a user starts an ITS service and logs on through a Web browser, this starts a new user session, which is sent to the Web server and the WGate.

The WGate checks whether multiple AGate instances are assigned. If so, the WGate assigns the new session to one of these instances to balance the load. The assignment method is essentially random, although the WGate does take the capacity of each instance into account.

  1. Since there are multiple AGate processes, the WGate sends a request to the ITS Mapping Manager, which holds information about the current load of the different AGate processes.
  1. The ITS Mapping Manager assigns the new user session request to an AGate process – usually the one with the highest process ID - and reports the process ID to the WGate.

If the AGate process with the highest process ID is overloaded, the ITS Mapping Manager looks for another process. This way, it makes the best use of previously used data from AGate process internal memory caching.
  1. The WGate sends the new user session data to the assigned AGate process, which establishes a session context.

The session context remains in the AGate process memory until the user terminates the session in the Web browser. For each new user session, the ITS generates unique session cookie data, so that the session can be re-identified later.
  1. The AGate process sends the request to the R/3 System.

Most new session requests generate a request to a backend R/3 System were an associated R/3 session is created.

These five steps are only required to establish a new user session. For existing user sessions, only steps 1, 4 and 5 are necessary.

When a new user session has been established, a response is sent back to the Web browser with session cookie data, which identifies the session. In subsequent steps within the same user session, the Web browser sends the cookie data back to the WGate and the AGate. The WGate uses this data to identify the right AGate instance and, within that AGate instance, the right AGate process. It can then send the session request data directly to the right AGate process as described in step 4 above

AGate processes or instances never share session contexts, because this would constitute an additional overhead and reduce performance. The session context in an AGate process allows only one formal user logon to the ITS and the R/3 System.

It is good practice for all users to end sessions explicitly by using the logoff procedure offered in all applications. This guarantees that:

The number of concurrent open user sessions allowed in one AGate process is a tuning parameter constrained by the amount of system memory available.

If a user session has not been used for some time (that is, the user has not sent any requests from the Web browser), the ITS terminates the session after a time defined by the service parameter ~timeout , but retains the session context for a time defined by the service parameter ~usertimeout .

For further information about service parameters, see ITS Service Parameters.

For further information about WGate configuration, see the ITS Administration Guide.

Leaving content frame