Technical Background – Connection Strings

Connection string is a technical term used within SAPGUI for the Java Environment configuration. A connection string describes a connection address for a destination, for example, an SAP system application server, rather like an Internet URL describes a location for a web page.

Simple Connection Strings

In its simplest form, a connection string contains an IP address and a port number. This information is sufficient for SAPGUI for the Java Environment to open a direct TCP connection to a destination, for example, an application server. IP address and port number are marked with the prefixes ‘/H/‘ (for host) and ‘/S/‘ (for service). Note that the portnumber for an SAP application server is by convention 3200 plus the two-digit SAP system number.

Example for a simple connection string with an application server’s IP address (172.16.64.17) and portnumber (3200):

/H/172.16.64.17/S/3200

If your network environment supports DNS (Domain Name Services), a hostname can be used instead of the IP address in all kinds of connection strings. (This requires a correct DNS configuration at the front-end computer, for example, using the /etc/hosts file).

Example with an application server’s hostname (iwdf8997.wdf.sap-ag.de) and portnumber (3200):

/H/iwdf8997.wdf.sap-ag.de/S/3200

If your network environment supports symbolic service names for well-known ports, the symbolic service name can be used instead of the port number in all kinds of connection strings (this requires a correct service configuration at the frontend computer, for example, in the /etc/services file). Note that SAP application server ports are named ‘sapdp<SID>’ by convention where <SID> is the SAP system ID.

Example with host name (iwdf8997.wdf.sap-ag.de) and symbolic service name (sapdpIWD):

/H/iwdf8997.wdf.sap-ag.de/S/sapdpIWD

Simple connection strings need not be resolved by the GUI application. Resolution of host names and symbolic service names is done by the operating system’s network layer.

SAP Routers

In a WAN (Wide Area Network) environment, SAP routers are used to make connections to remote SAP systems that cannot be reached with a direct TCP connection. Passwords may be used for each SAP router to control access.

In order to make a connection, the front-end computer is responsible for providing the complete route to the destination, possibly including a chain of several SAP routers. Path information is not provided by the routers. (Strictly speaking, an SAP router is actually better described as an application level proxy with password capabilities and strict source routing).

The address for each router is specified by a simple connection string (with the router’s host name and port number), optionally followed by ‘/P/‘ and the router password. The path from the current location to the destination is described by appending all router addresses together, followed by the address of the destination SAP system. Thus, a connection string with SAP routers generally has the form <router 1><router 2>…<router n><destination>.

Example with two routers (gate.acme.com, port 3299, and gate.sap.com, port 3298), the first using a password (secret), for a connection to the application server iwdf8997.sap.com, port 3200):

/H/gate.example.de/S/3299/P/secret/H/gate.sap.com/S/3298/H/iwdf8997.sap.com/S/3200

<——– 1st router ———-><—- 2nd router —-><—— app_server ——>

Connection strings including SAP routers are passed to the GUI’s communication layer and resolved step-by-step by the routers on the path. If host names and symbolic service names are used, each router must have access to correct network configuration information to resolve them.

Message Servers and Logon Groups

For load balancing purposes, application servers from an SAP system are usually configured in logon groups, where each group serves a particular kind of user. The application servers in each group are assigned to users using a ‘least-heavily-loaded strategy’. This load balancing is done by message servers. Each SAP system has exactly one message server, which can be reached using TCP on a specific message server port.

Care should be taken that the application server’s port number is not confused with the message server’s port number. In smal installations the message server’s host name can often be identical to the hostname of an application server, the port number is however always different. Symbolic service names for message servers by convention have the form ‘sapms<SID>’, where <SID> is the SAP system ID.

Message server and group information can be used to address an SAP system in a connection string. The address of the message server is specified as a combination of message server host name, message server port and group name. This information is marked with the prefixes ‘/M/‘ (message server host name), ‘/S/‘ (message server port) and ‘/G/‘ (logon group).

Example with message server (hostname alrmain, port number 4253) and logon group (SPACE):

/M/alrmain.wdf.sap-ag.de/S/4253/G/SPACE

Connection strings with message servers are resolved by SAPGUI for the Java environment by contacting the message server and retrieving the (simple) connection string of an application server for the specified group. This requires network access to the message server at the time the address is resolved.

SAP router connection strings may be used in combination with message server connection strings simply by specifying the router address before the message server address. The router is then used for contacting the message server and the resolved application server.

Symbolic System Names

The most user-friendly form of connection string addresses an SAP system only by its symbolic name (by convention, the system ID) and the logon group name. This information is marked with the prefixes ‘/R/’ (for the symbolic SAP system name) and ‘/G/’ (for the logon group name).

Example with SAP system (ALR) and logon group (SPACE):

/R/ALR/G/SPACE

Connection strings with symbolic system names are resolved by SAPGUI for the Java Environment by looking up the symbolic SAP system name in the Message Server List (a text file containing a mapping between symbolic system names and message server addresses) and replacing the /R/ part of the connection string with the resulting message server address. The result is a complete message server connection string which is then further resolved as explained above.

Formal Syntax

For the technically interested reader, the following BNF grammar formally describes the syntax of connection strings:

<connection string> := [<router prefix>]<local>

<local>            := <simple>|<message server>|<symbolic>

<simple>            := “/H/”<host>”/S/”<service>

<host>            := <hostname>|<ipaddr>

<hostname>      := (any DNS hostname)

<ipaddr>        := (any IP address, in dotted decimal form)

<service>        := <servicename>|<port number>

<servicename>  := (any IP service name)

<port number>  := (any decimal number)

<messageserver>    := “/M/”<host>”/S/”<service>”/G/”<group>

<group>          := (any ASCII string not containing ‘/’)

<symbolic>          := “/R/”<system>”/G/”<group>

<system>          := (any ASCII string not containing ‘/’)

<router prefix>    := <router>*

<router>          := “/H/”<host>”/S/”<service>[“/P/”<password>]

<password>      := (any ASCII string not containing ‘/’)



(I found this document in the inet long time ago but don´t know where. It was very interisting for me, so I think it is interisting for you too.)

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply