Determining the Server Group 
The SAP Web dispatcher determines the server group responsible for processing a request in the following way:
The 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 the SAP Web dispatcher decides whether the prefix is an ICF prefix (that is, 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 the 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 the 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 also an ICF prefix.
The start page and the root directory are handled in a special way, since 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 determines which root directory should be used. Permitted values are abap and j2ee, although the value can also be changed dynamically using 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 (see Assign Logon Groups), or the internal group !DIAG, or !DIAGS (if HTTPS is forwarded, more information: SAP Web Dispatcher and SSL). In this case !DIAG/!DIAGS are all application servers that have configured an HTTP/HTTPS port (see icm/server_port_<xx>).
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 Portal. 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 also be configured here (see Configuring Logon Groups on AS Java). If no group has been configured, the 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 the SAP Web dispatcher is to forward the request (HTTP or HTTPS, not end-to-end) SSL-encrypted (parameter wdisp/ssl_encrypt, more information: SAP Web Dispatcher and SSL), it has to select !DIAGS or !J2EES as the internal group. Otherwise the algorithm runs the same way.
More information about the internal groups of the Web dispatcher: Architecture and Functions of the SAP Web Dispatcher.