Determining the Server Group

Use

SAP Web Dispatcher identifies the server group responsible for processing a request in the following way:

SAP Web Dispatcher first checks whether the request is an ABAP or a Java request, and uses the ABAP or Java load balancing accordingly.

The check is run against the URL prefix.

URL Prefix Check

How SAP Web Dispatcher decides whether the prefix is an ICF prefix (for the Internet Communication Framework of AS ABAP) is described in detail below. With URL http://hostname:port/A/B/page.htm the prefix to be examined is the character string /A/B.

If SAP Web Dispatcher decides it is an ICF prefix, the request is sent to the ABAP server (the ICF). If the prefix is not recognized by the ICF, the request is sent to the AS Java. To ascertain what type of prefix it is, SAP Web Dispatcher searches for the prefix in the URL mapping table. In the above example, if the URL mapping table contains the entry /A/, but not the entry, /A/B/, the prefix is an ICF prefix.

The start page and the root directory are handled in a special way because when you search through the list of prefixes you cannot search through the root directory (it would always be found because all URL prefixes begin with /). If the URL is a root URL, the profile parameter is/HTTP/default_root_hdl ascertains which root directory is to be used. Permitted values are abap and j2ee, although the value can also be changed dynamically in transaction RZ11 or SMMS.

The following flow diagram shows the algorithm that is used.

URL Prefix Check

Example

The URL mapping table of the Web Dispatcher could contain, for example, the following URL prefixes:

/sap/bc/contentserver/

/sap/public/formgraphics/

/logon/

/echo/

/its/

/sap/

If the URL http://saphost:8080/index.html is specified, the prefix to check for is /. This cannot be found in the URL mapping table, and it contains only one forward slash. If parameter is/HTTP/default_root_hdl = j2ee is set (default setting), the Web Dispatcher performs Java load balancing and searches in the root directory of the determined server for file index.html. This file is then returned to the client through the application server ICM.

ABAP load balancing and Java load balancing are described below.

ABAP Load Balancing

With ABAP load balancing, in the stateless case the request is assigned to the next application server in the queue in accordance with load balancing. The server group that can process the request is either an ABAP logon group or the internal group !DIAG or !DIAGS. In this case !DIAG/!DIAGS are all application servers that have configured an HTTP/HTTPS port.

If it is a stateful connection, the system selects the application server that is processing the transaction.

Provided it is available, stateful connections are dispatched using the external session identifier (Session Dispatching), which is generated from the SAP EP. If no external session identifier is available, the ABAP session identifier is evaluated.

While the value of the ABAP session identifier contains the server name to which a request is then forwarded, the external session identifier does not contain any such server name. Which is why in the case of dispatching using the external session identifier, the server names are stored in a table in the shared memory of the Web Dispatcher.

The following graphic shows the algorithm that is used.

ABAP Load Balancing

ESID is the external session identifier sap-ext-sid and Session-Cookie is the ABAP session identifier sap-contextid.

Java Load Balancing

Logon groups can be configured here too. If no group has been configured, SAP Web Dispatcher uses the internal group !J2EE.

In the case of stateless requests the Web dispatcher performs load balancing in the group specified or in the internal group !J2EE (!J2EES if SSL is used, see below).

If it is a stateful connection, the system selects the application server that is processing the transaction.

Providing it is available, stateful connections are dispatched using the load balancing identifier, which is generated on the AS Java server.

If no load balancing identifier is available, the J2EE session identifier is evaluated.

While the value of the load balancing identifier contains the server name to which a request is then forwarded, the J2EE session identifier does not necessarily contain any server name.

Which is why in the case of dispatching using the J2EE session identifier, the server names are stored in a table in the shared memory of the Web Dispatcher.

The following graphic shows the algorithm that is used.

Java Load Balancing

The saplb-Cookie is the load balancing identifier, and jsessionid cookie is the J2EE session identifier.

Special Case: HTTPS Re-encryption

If SAP Web Dispatcher is to forward the request SSL-encrypted (HTTP or HTTPS, not end-to-end), it has to select !DIAGS or !J2EES as the internal group. Otherwise the algorithm runs the same way.