Show TOC

SAP Application Server List for HTTP Load BalancingLocate this document in the navigation structure


The SAP NetWeaver Application Servers ABAP and SAP NetWeaver Application Server for Java often consist of multiple instances located on different hosts in order to scale the system and assure its availability. Each instance acts as an HTTP server of its own. HTTP requests have to be balanced between the instances.

There are two essential solutions:

  • SAP Web Dispatcher is a self-configuring, out-of-the-box solution for HTTP/HTTPS load balancing in SAP NetWeaver Application Server landscapes.

  • Other HTTP load balancing solutions, be it hardware or software.

The SAP NetWeaver Application Server offers a web service that provides a list of currently active application servers to the load balancer. The information provided by this web service can be used to automate the load balancer configuration and react dynamically to changes in the system, like instances being created or shut down.

This documentation provides a detailed specification of this web service, which is also used by the SAP Web Dispatcher.

This documentation will focus on the basic load balancing of HTTP requests. This load balancing can be performed for stateless requests as well as for the first request of a stateful session. All subsequent request belonging to this session have to be directed to the same application server.

  • This document does not cover concepts how the stickiness of a request is enabled.

  • Certain aspects of the complex SAP request routing logic such as the mapping between URLs and SAP Logon Groups cannot be simply mapped onto a standard web switch configuration.

Basic terms

Knowledge of the SAP NetWeaver application server architecture as well as concepts and basic settings of the SAP Web Dispatcher helps to understand this documentation. You find a reference to the documentation at the end of this document. For the purpose of this document, mainly the following terms need to be understood:

  • An SAP system consists of one or more dialog instance(s) and one special instance, which offers central services to all other instances. One of these is the so called Message Server (executable name: msg_server) which provides information about all other instances of the SAP system and is referred to in the following.

  • Each SAP instance has a sub-structure, referred to as “stacks”. The possible stacks of SAP instances are an ABAP and a Java stack. An SAP instance can include either an ABAP or a Java stack alone or both stacks together ( “dual-stack instance”).


The load balancer periodically fetches a list of all active application servers of an SAP system from its message server via HTTP. This list includes the host names as well as a static value indicating the capacity of each server (see below). This capacity is separated by stacks, i.e. a dual-stack instance has an ABAP capacity and a Java capacity.

When an instance is shutting down or scheduled for shutdown, the capacity of the instance will be set to 0. This means that stateful requests for existing sessions can still be sent to this instance but the instance should be taken out of load balancing, because it will not accept any new logons.

Servers will be dynamically added and removed from the list whenever the SAP message server detects a new server starting up or a running server shutting down (or crashing), respectively.

It is required that a load-balancing device removes crashed servers from its internal server list immediately for the following reasons:

  • The message server may take up to ten minutes to detect a server crash. Therefore, the server list may not reflect the current state of the servers

  • The load balancer should only update the list periodically (e.g. every several minutes)


The specification is valid for all SAP products based on application server release 6.20 upwards with SAP kernel 6.40 upwards. This corresponds to SAP NetWeaver '04 upwards.


The capacity value is an integer, which gives an estimate of the servers' strength. The value 0 (zero) means that the application server is shutting down and has to be taken out of the load balancing.

Currently, the heuristic used by the SAP system determines the static capacity values as follows:

  • AS ABAP: number of dialog processes of the instance.

  • AS Java: number of Java server processes.


This heuristic may be changed by SAP without further notice.

The load balancer should never use the absolute value of these capacity values at all or associate any meaning with them. Only the ratio of capacities between the different servers is significant.

  • If there is an HTTP(S) port in the list, the system is either of the ABAP-only or dual-stack type. In this case, send all requests to the HTTP(S) port and use the LB value from the DIAG line for calculating server capacity.

  • If there is no HTTP(S) port in the list, the system is of the Java-only type. In this case, send all requests to the J2EE(S) port and use the LB value from the J2EE line for calculating server capacity.

It is not mandatory for the load balancer to use the capacity values for making the load balancing decision. Other mechanisms, like response time measurements or host load, can be used as well. However, the meaning of the value 0 (zero) has to be observed (see above).

Host and Port Configuration

The network host name and HTTP port of the message server is configured via SAP configuration parameters rdisp/mshost in the default profile and ms/http_port in the profile of the message server.

For simplicity and performance, a plain text format is used in the HTTP message body to describe the server list as a set of server description records (separated by empty lines) as follows ( CRLF denotes the Control/LineFeed as end-of-line indicator).


Load balancing for a single-stack system (ABAP only or Java only) is much easier than for a dual-stack system, as the request type is clear. If you want to do load balancing for a dual-stack system, the following prerequisites must be met:

  • The system is homogeneous, i.e. all instances contain AS ABAP and AS Java.


    In case that two message servers are configured (one for ABAP, one for Java), the information has to be retrieved from the ABAP message server.

  • Before a request is dispatched to a server, the load balancer checks that both stacks are available in the application server list.


The body of the HTTP response message is structured according to the following syntax.

<server-list> = "version" <major>"."<minor> CRLF
<sap-server-name> CRLF
<protocol-type> <host> <port> <description> CRLF
<protocol-type> <host> <port> <description> CRLF
<sap-server-name> CRLF
<protocol-type> <host> <port> <description> CRLF
<protocol-type> <host> <port> <description> CRLF

CRLF stands for “carriage return line feed” (new line).

The following table explains the possible values for the variables. Examples are given below.

  • The following explanations refer to version 1.2 of the protocol (see first line of the HTTP response).

  • You can also use HTTPS to retrieve the data from the message server. To do this, the message server has to be configured for HTTPS. See the documentation links at the end of the document for further information.

You get the application server list from the message server (release 6.40 onwards) with the following HTTP request:

http://<msg_server_host>: <msg_server_port>/msgserver/text/logon?version=1.2

The list is in plain text format. The following table describes the response in detail.





two numbers separated by a period

Typical version description: the first number denotes the major version, the second number the minor version.

We use version 1.2 in the following.


character string

Instance name.

  • AS ABAP or dual-stack instances: <host>_<SID>_<>

  • AS Java instances: J2EE<node_id>


Don't use these strings to get information about the server, the information is contained in the lines below.

The instance name can be an opaque sting, if hash-encryption is configured with the profile parameter is/instname_encoding in the system profile DEFAULT.PFL. In the default setting, the parameter has the value none, which means instance names are transferred in clear text.

<protocol- type>



Server has an HTTP port configured in the ICM.


Server has an HTTPS port configured in the ICM.


Server has dialog work processes; this line contains the LB capacity of the AS ABAP.


Other values may be listed here: RFC, RFCS, SMTP among others. These protocols are not relevant for load balancing.

AS Java


AS Java is active and HTTP port is configured.


AS Java is active and SSL-anabled. HTTPS port is configured.


Other values may be listed here: P4, P4S, IIOP, IIOPS among others. These protocols are not relevant for load balancing.


character string

host name



port number


character string

The following strings are possible:

  • LB=<n> denotes the capacity of the application server for load balancing; applicable for DIAG and all AS Java protocols.


    For DIAG, the capacity is denoted with DIA=<n> in AS ABAP Release 6.40 (SAP NetWeaver 04)

  • SNC string (applicable for DIAGS and RFCS, see example below)

  • Virtual host index VHOST=<n> (applicable for version 1.2 only)


    The virtual host string is only used for AS ABAP. For every virtual host configured in the application server (parameter is/<prot>/virt_host_<n> in the instance profile), the corresponding ports are listed.


Java System

The following example shows the application server list of a Java-only system with two instances.

The HTTP request http://ld8060: 8081/msgserver/text/logon?version=1.2 to the message server with HTTP port 8081 could get a response like this:

version 1.2
J2EE 51800 LB=2
J2EES 51801 LB=2
P4 51804 LB=2
P4S 51805 LB=2
IIOP 51806 LB=2
IIOPS 51807 LB=2
TELNET 51808 LB=2

J2EE 55000 LB=1
P4 55004 LB=1
IIOP 55007 LB=1
TELNET 55008 LB=1

Here, two AS Java instances are configured on one physical host. One of them is SSL-enabled and offers ports for all protocols. The instance J2EE187834720 has double capacity (two Java server processes active) and thus gets twice as many requests (as far as the requests are stateless) from the Web Dispatcher as the other instance J2EE507834720.

ABAP System

version 1.2
DIAG WDFD00146517A 3253 LB=3
RFC WDFD00146517A 3353
HTTP WDFD00146517A 1080
SMTP WDFD00146517A 8025
HTTP WDFD00146517A 1080 VHOST=0
SMTP WDFD00146517A 8025 VHOST=0

DIAG 3212 LB=7
RFC 3312
HTTP 8888
SMTP 2500

DIAG 3253 LB=10
DIAGS 3253 p/secude:CN=BIN, O=SAP-AG, C=DE
RFC 3353
RFCS 4853 p/secude:CN=BIN, O=SAP-AG, C=DE
HTTP 8080
HTTPS 8443
SMTP 25053
SMTP 25053 VHOST=0

Here, three AS ABAP instances are configured on different hosts. They have different capacities and protocols.

The information needed for a load balancer is the capacity in the first line and the ports for HTTP and HTTPS..

Dual-Stack System

version 1.2
DIAG us4251 3227 LB=8
RFC us4251 3327
HTTP 50027
HTTPS 44327
SMTP 25027
J2EE 50027 LB=1
J2EES 44327 LB=1
P4 52704 LB=1
IIOP 52707 LB=1
TELNET 52708 LB=1
HTTP 52700 VHOST=0
SMTP 25027 VHOST=0

DIAG bcomain 3227 LB=20
RFC bcomain 3327
HTTP 52700
HTTPS 44327
SMTP 25027
J2EE 52700 LB=2
J2EES 44327 LB=2
P4 52704 LB=2
P4S 52705 LB=2
IIOP 52707 LB=2
TELNET 52708 LB=2
HTTP 52700 VHOST=0
SMTP 25027 VHOST=0

This system has two instances providing ABAP and Java. The first one has ABAP capacity 8, Java capacity 1, whereas the second one has 20 and 2. If you do load balancing for a dual-stack system, you can take one of the values as capacity or do a calculation.