HTTP Load Distribution Using SAP Message Server


SAP recommends that you use the SAP Web Dispatcher as the entrance point for your Web queries. This is then used as the access point for your network and also executes load balancing for HTTP requests.

You can only use the SAP message server for HTTP load distribution, if the browser is the direct client of the message server. If another component lies between the client (browser) and the message server, (for example, the portal), you cannot use the message server to distribute the load.

If you are using the message server for HTTP load distribution, you must ensure that in all application servers HTTP ports are set up through which the message server gets information from the servers.

You can also transfer the information via HTTPS. Then you have to ensure that HTTPS ports are set up and that the following parameters are set in the profile of the message server:

ms/urlmap_secure = 1  

ms/urlmap_secure = 1  


Usually, an SAP system consists of several application servers which share the network load.

The load is distributed by the message server (there is only one message server in the SAP system). When the user logs on, the message server assigns the user an application server that currently has the least load. This procedure is also used for incoming HTTP requests.

If you are using HTTP load distribution on your system, you cannot use additional Virtual Hosts.


To distribute load balancing with the SAP message server, the following prerequisites must be fulfilled.

?      Parameter ms/ server_port_<xx> must be set in the profile of the message server (see below).

?      The ICF Services sap/public/icf_info/logon_groups and sap/public/icf_info/urlprefix must be activated (transaction SICF), see Server Groups in Internet Communication Frameworks.

Process Flow

Every application server that is participating in load sharing tells the message server how many work processes it can provide and whether it accepts HTTPS connections. At the start of a connection, an Internet client first connects to a message server (which must also be HTTP-compatible). The message server tells the client via a redirect which application server it should connect to. Obviously, HTTPS requests are only sent to HTTPS-compatible application servers.


For this procedure to work, the message server has to open one or several additional ports. Use the following profile parameters to do this:


This parameter specifies the HTTP(s) ports that the message server additionally opens to redirect HTTP requests.

Additional SSL parameters must be set for HTTPS, so that SSL can be used. Also, the message server must be run as a multi-threaded program, as every HTTPS request is processed in its own thread.

You can add or delete ports (services) dynamically in the Message Server Monitor (transaction SMMS).

The outdated parameters ms/http_port and ms/https_port do still function for compatibility reasons, but should not be used any longer.


If you are using the SAP Web Dispatcher, bear in mind that you need parameters ms/http_port and ms/https_port in the profile of the Web Dispatcher, so that the Web Dispatcher can open the connection to the message server. For more information see Profile Parameters of the SAP Web Dispatcher.

There are also other parameters with default values that do not need to be changed. These attachments include:

·         ms/http_max_ports:
Maximum number of additional HTTP ports that the message server can open. The default is 20.

·         ms/http_max_clients:
Maximum number of HTTP clients that can log on simultaneously to the message server. The default is 1000.

·         ms/http_timeout:
If there is no activity on the connection within this time period, the connection to the HTTP client is terminated. The timeout value is expressed in seconds. The default is 20.

·         ms/http_bufferln:
Maximum readable length of the HTTP header. This value is expressed in bytes. The default is 65636.

If SSL is being used, the SSL parameters must be set correctly (see SSL documentation).

Working with Logon Groups

If a log on group is defined for the URL in question (defined in transaction SMLG), the message sever searches for a definition in the list of logon groups. In then performs the load synchronization in this group.

Since with HTTP there are many requests, this logon group must have the attribute “external RFC” so that no one server is flooded with requests.