Name-based virtual hosts and one SAP Web Dispatcher to access multiple SAP systems

September 9, 2014

SAP Note 2010948 obsoletes the scenario described in this article. Web Dispatcher 7.4 and higher has now built-in capabilities to serve multiple systems based on virtual host names. I recommend to use Web Dispatcher 7.41.

SAP Web Dispatcher 7.20 introduced the long awaited functionality of serving multiple SAP systems. In principle, this means that any SAP landscape – however complex – can be served by one single Web Dispatcher. In this article I want to show how this feature can be combined with name-based virtual hosts to access multiple SAP systems behind one Web Dispatcher in an elegant and fairly low maintenance fashion.

This is the example landscape I will use for the purpose of this article:

• the ERP system: ABAP system with SID “ECC”; HTTP should be accessed with “http://ecc.example.com“
• the CRM system: ABAP system with SID “CRM”; HTTP should be accessed with “http://crm.example.com“
• the Enterprise Portal system: J2EE system with “EP1”; HTTP should be accessed with “http://portal.example.com“

When running in front of multiple systems, Web Dispatcher has to apply a multi-stage routing decision for each request. For each request, it has to determine the target system first, and then dispatch the request to the appropriate application server in the selected target system. There are several methods to identify the target system:

• by access point (IP address and/or port)
• by URL prefix
• by a SAP specific HTTP header field called x-sap-webdisp-target-sid

IP-based virtual hosts

The first method can be used to identify the target system based on virtual hostnames, but it requires a physical access point for Web Dispatcher to listen on.

For our example landscape we would require:

• the Web Dispatcher host to have at least three network interfaces
• Web Dispatcher to listen on at least three different network interfaces (in this case, each time on port 80)
• the DNS to resolve each ecc.example.com, crm.example.com, and portal.example.com to the IP address of one of the network interfaces

The following picture shows this setup in more detail:

This is certainly a valid approach, but as the landscape gets more and more complex and as even more systems are to be served, the requirement to have a separate network interface for each system is becoming an increasing cost factor. This method of virtual host separation is IP-based since every virtual host requires a network interface, which in turn requires at least one IP address.

Name-based virtual hosts

Name-based virtual hosts offer a different approach. In this case, the DNS will resolve all virtual hostnames to one IP address, and Web Dispatcher only listens on the network interface that has this IP address (of course, having multiple interfaces and IP addresses is still an option, e.g. for high availability purposes).

Web Dispatcher then has to look at the hostname of the request to identify the target system. This can be achieved by using Web Dispatcher’s modification handler to insert the special header field x-sap-webdisp-target-sid into the request. The value of this header field has to be set to the system ID of the desired target system, based on some information in the request, such as the Host header field. Thanks to the order in which the request goes through the handlers (… > modification handler > … > routing handler), the routing handler will find the special header field previously inserted by the modification handler and use its value to identify the target system for the request.

The necessary configuration for our example landscape would look like this:

1. DNS must resolve all three hostnames to the IP address of the Web Dispatcher host.
2. All systems must be defined in the Web Dispatcher profile:
      wdisp/system_0 = SID=ECC, MSHOST=sapecc1, MSPORT=8100
      wdisp/system_1 = SID=CRM, MSHOST=sapcrm1, MSPORT=8100
      wdisp/system_2 = SID=EP1, MSHOST=sapepcs, MSPORT=8101
   
3. Modification handler must be added to the Web Dispatcher profile:
      icm/HTTP/mod_0 = PREFIX=/, FILE=mod_rules.txt
   
4. One rule must be added to the rule file (in this case, mod_rules.txt) for each virtual host (i.e., system):
      if %{HTTP_HOST} regimatch “ecc.example.com”
        SetHeader x-sap-webdisp-target-sid ECC [break]
      if %{HTTP_HOST} regimatch “crm.example.com”
        SetHeader x-sap-webdisp-target-sid CRM [break]
      if %{HTTP_HOST} regimatch “portal.example.com”
        SetHeader x-sap-webdisp-target-sid EP1 [break]

The following picture shows the name-based setup in more detail:

Requirements and possible issues

Web Dispatcher can identify the target system only if it knows the hostname. This information is available in HTTP/1.1 with the mandatory Host header field. Consequently, HTTP/1.1 is a requirement for the name-based virtual hosts solution described in this article. HTTP/1.1 is the standard for all common Web browsers supported by SAP, so this requirement should not be of much concern.

When using HTTPS, Web Dispatcher needs to see the decrypted request in order to evaluate the Host header. This is no problem when Web Dispatcher terminates or re-encrypts SSL. But the special ROUTER protocol (End-to-End SSL) cannot be used.

In case of DNS issues, users sometimes try to use IP addresses in the URL instead of the hostname, e.g. http://120.20.12.10/sap. This causes a problem because the IP address does not uniquely identify the target system, so Web Dispatcher cannot decide where to dispatch such a request.

There are several possible solutions for this issue:

1. Web Dispatcher rejects requests that were called with an IP address:
   With the rules in the above example, this would be the default behaviour. Since none of these rules match a hostname pattern, Web Dispatcher would respond to the request with a 500 Internal Server Error and the error detail No target SAP system for request.
   Different behaviours such as a custom error page, a redirect, or a Forbidden response can be achieved with additional rules, e.g.:
      if %{HTTP_HOST} regimatch “[0-9]*[.][0-9]*[.][0-9]*[.][0-9]*”
        RegIForbiddenUrl ^/.* –
   
2. Web Dispatcher forwards requests that were called with an IP address to a specific target system:
      if %{HTTP_HOST} regimatch “portal.example.com” [or]
      if %{HTTP_HOST} regimatch “120.20.12.10”
        SetHeader x-sap-webdisp-target-sid EP1 [break]
   
3. If possible, Web Dispatcher uses additional information to determine the correct target system:
   The most obvious source of information is the URL path. However, anything that can be evaluated by the modification handler, such as header fields or query parameters, is a possible criterion to determine the correct target system. Criteria can also be grouped together.
   Here is a very simple example which makes use of the URL path:
      if %{HTTP_HOST} regimatch “portal.example.com” [or]
      if %{PATH} regimatch “^/irj”
        SetHeader x-sap-webdisp-target-sid EP1 [break]

   This last option is only available if there is sufficient information that can uniquely identify the target system. For example, as soon as two systems serve a resource with the exact same name, it is no longer possible to use the URL path alone, e.g. http://host1/sap/public/logo.gif and http://host2/sap/public/logo.gif.

A completely missing hostname causes similar issues as the use of the IP address. This could happen if a browser uses HTTP/1.0 and does not send the Host header field. The same three solutions as above are also valid in this case, and a rule to reject such requests would look like this:

   if %{HTTP_HOST} regimatch “”
     RegIForbiddenUrl ^/.* –

Finally, one last issue should be mentioned. Even the official Web Dispatcher documentation currently contains the following erroneous example:

   if %{HTTP_HOST} regimatch wd_erp*
     SetHeader x-sap-webdisp-target-sid ERP [break]
   if %{HTTP_HOST} regimatch wd_ce1*
     SetHeader x-sap-webdisp-target-sid CE1 [break]
   RegForbiddenUrl ^/(.*) –

These rules do not work because of the way Web Dispatcher separates header rules from other rules. All header rules are executed first, followed by all other rules. The [break] statement in a header rule will only terminate the execution of the header rules, but the other rules will still be executed. In the example above, this will lead to a Forbidden response for all requests (that match the RegForbiddenUrl rule).

The correct solution to achieve the behaviour intended in the example looks a bit awkward and requires double maintenance of all known hostnames since Web Dispatcher does not support else clauses for its if conditions:

   if %{HTTP_HOST} !regimatch “ecc.example.com” [and]
   if %{HTTP_HOST} !regimatch “crm.example.com” [and]
   if %{HTTP_HOST} !regimatch “portal.example.com”
     RegForbiddenUrl ^/.* –

Conclusion

Name-based virtual hosts require fewer resources (e.g., IP addresses) when used as identification criteria in a Web Dispatcher for a Multiple Systems scenario and should, therefore, be preferred over IP-based virtual hosts. The modification handler offers sufficient flexibility and functionality to define rules that can identify the correct target system, even if users type in the IP address instead of the hostname, or if the hostname is missing entirely (e.g., browser uses HTTP/1.0).

 
Further reading

• Name-based virtual hosting (http://en.wikipedia.org/wiki/Virtual_hosting#Name-based)
• Hypertext Transfer Protocol — HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt)
• SAP Web Dispatcher for multiple systems (http://help.sap.com/saphelp_nw73/helpdata/en/b0/ebfa88e9164d26bdf1d21a7ef6fc25/frameset.htm)
• Modifications of HTTP requests (http://help.sap.com/saphelp_nw73/helpdata/en/48/9266acaa6b17cee10000000a421937/frameset.htm)