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 flow diagram 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 are supplied with the ICM and have configured an HTTP/HTTPS port (see icm/server_port_<xx>).
If it is a stateful connection, the system selects the SAP Web AS that is processing the transaction.
Provided it is available, stateful connections are dispatched using the external session identifier (ESID), 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.
A description of the external session identifier and the ABAP session identifier can be found in Session Identifiers.
The following graphic shows the algorithm that is used.
Here ESID is the external session identifier sap-ext-sid (see External Session Identifier), and Session-Cookie is the ABAP session identifier sap-contextid (see ABAP Session Identifier).
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.
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 SAP Web AS that is processing the transaction.
Providing it is available, stateful connections are dispatched using the load balancing identifier, which is generated on the J2EE 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.
A description of the load balancing identifier and the J2EE session identifier can be found in Session Identifiers.
The following graphic shows the algorithm that is used.
Here saplb-Cookie is the load balancing identifier (see Load Balancing Identifier), and jsessionid-Cookie is the J2EE session identifier (see 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, 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: