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 J2EE request, and uses the ABAP or J2EE 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 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 J2EE engine. 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 URLs 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 graphic shows the algorithm that is used.
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 is set to j2ee (default setting), the Web dispatcher performs J2EE 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 J2EE load balancing are described below.
ABAP Load Balancing
With ABAP load balancing, in the stateless case the request is assigned to the next SAP Web AS in the queue in accordance with load balancing. The server group which can process the request is the internal group !DIAG or !DIAGS (if HTTPS is forwarded, see SAP Web Dispatcher and SSL). In this case !DIAG/!DIAGS are all application servers that have an ICM and have configured an HTTP/HTTPS port (see icm/server_port_<xx>).
If the connection is stateful, the SAP Web AS processing the transaction is chosen (indicated by a cookie or a parameter in the URL).
The following graphic shows the algorithm that is used.
J2EE Load Balancing
Logon groups can be configured here too. If no group has been configured, the SAP Web dispatcher uses the internal group !J2EE. If the session is stateful, this can be identified by a load balancing cookie. For compatibility purposes the session cookie jsessionid can also be used here (compare with Session Identifiers)
In the case of stateless requests the Web Dispatcher performs load balancing in the specified group or in the internal group !J2EE (!J2EES if SSL is used, see below).
The following graphic shows the algorithm that is used.
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, see SAP Web Dispatcher and SSL), it has to select !DIAGS or !J2EES as the internal group. Otherwise the algorithm runs the same way.
For more information about the internal groups of the Web dispatcher see Architecture and Functions of the SAP Web Dispatcher.
See also: