Skip to Content
SAP Cloud for Customer add-ins

Installing SAP Web Dispatcher for HCI and multiple On Premise backend systems

Installing SAP Web Dispatcher for HCI and multiple On Premise backend systems


Author: Berthold Wocher                                                                                            Date: 09.03.2015

Motivation

For Integration between Cloud for Customer via HCI to SAP backend systems we typically have the situation that we have to consider test and production systems. So a typical landscape could look like this one below:

Therefore one general question is on how to distinguish incoming calls on SAP WD from different HCI tenants and route them to the correct ERP instance (test or prod). Since both HCI systems are hidden behind a proxy – it is not possible for the WD to distinguish incoming calls via the sending hostname. Therefore we have to identify other ways of solving this issue. Of course it is always possible to use dedicated Web Dispatchers for test and prod with dedicated FQDN’s– but this causes more effort during setup.Therefore we will describe here possible options by using the same WD for test and prod.

The general options for this scenario are described within the official WD documentation, which can be found here:

https://help.sap.com/saphelp_nw74/helpdata/en/c5/ec466f5544409982c7d3ca29ce1ad3/content.htm

However due to our specific setup not all of these options can be used in practice. Therefore we have to go in detail through these options.


Please consider also the general recommendation for Release/Version of the Web Dispatcher which you can read in SAP note: 908097

1.    Control Using Ports

The easiest solution might be to use two separate SSL ports on Web Dispatcher and to call from HCI1 a different port then from HCI2.

You can assign the incoming requests to the connected systems by the port where they arrive in the Web Dispatcher.


You configure two HTTPS ports in the Web Dispatcher:


icm/server_port_0 = PROT=HTTPS, PORT=44300

icm/server_port_1 = PROT=HTTPS, PORT=44301

In addition, you define the system assignments, as follows:

wdisp/system_0 = SID=ERP1, MSHOST=ms_erp1, MSPORT=8082, SRCSRV=*:44300

wdisp/system_1 = SID=ERP2, MSHOST=ms_erp2, MSPORT=8127, SRCSRV=*:44301

Then all requests that enter through port 44300 go to the ERP1 system, and requests entering through port 44301 go to the ERP2 system.

Keep in mind that you can’t use an expression like this:

wdisp/system_0 = SID=ERP1, MSHOST=ms_erp1, MSPORT=8082, SRCSRV=ifltestmap:44300

Since the HCI hostname is hidden by the proxy and therefore not available for routing purpose.

This solution using two different ports on Web Dispatcher is pretty easy to achieve. However there are certain things to consider:

-> Both SSL ports must be allowed from the Proxy Server. This is the case in our landscape if you are using e.g. 44300 and 44301

-> For browser based scenarios this solution is not good since it is cumbersome to enter different ports in all URL’s

-> Cookies will not work properly since they arenot port specific

However in our pure system to system integration those problems will not be relevant

2.    Control Using URL Prefixes

WD supports also routing via URL prefixes. This would require that HCI1 is using a different prefix then HCI2. As an example we can look at IDOC Service. So HCI1 would call for example

https://wdisp.cust.com:443/hc1/sap/bc/srt/idoc

Whereas HCI2 would use

https://wdisp.cust.com:443/hc2/sap/bc/srt/idoc

You specify the assignment to the systems:

wdisp/system_0 = SID=ERP1, MSHOST=ms_erp1, MSPORT=8082, SRCURL=/hc1/

wdisp/system_1 = SID=ERP2, MSHOST=ms_erp2, MSPORT=8127, SRCURL=/hc2/


You can use the following parameter to define that ambiguity will be resolved by selecting the first matching system:


wdisp/system_conflict_resolution = 1


Finally the URL must be modified before calling ERP1 or ERP2 since the added prefix must be deleted again. This happens via modification handler.


The reason why we do not recommend this solution is that it is not possible to create the prefix in HCI Web Configuration. So this would require eclipse tooling. In addition the modification handler must be used to cut out the prefix before the request is sent to the ERP backend.

3.    Control Using Virtual Hosts

This technique you can apply from Web Dispatcher 7.40. In addition you have to provide several hostnames (alias) for your Web Dispatcher. As an example you might have wdisp.custom.com and wdisp1.custom.com. Both hostnames are mapped to the same IP address (also in DNS!).


So you assign

  • requests with host header wdisp.custom.com to the ERP1 system
  • requests with host header wdisp1.custom.com to the ERP2 system

Requests with a different host header are forbidden.

You then need a port in the Web Dispatcher:

icm/server_port_0 = PROT=HTTPS, PORT=443

wdisp/system_0 = SID=ERP1, ..., SRCVHOST= wdisp.custom.com:443

wdisp/system_1 = SID=ERP2, ..., SRCVHOST= wdisp1.custom.com:443


For details of this solution and the syntax of this new parameter please check also SAP note 2010948

This solution is very powerful and is recommended to use in case multiple virtual hosts can be provided. In addition the certificate mismatch has to be considered. Since we have only one Server PSE in this example the distinguished name of the server certificate must cover both hostnames. A wildcard certificate like this CN=*.custom.com would be fine whereas a certificate like this CN=wdisp.custom.com would cause a  certificate mismatch when calling the URL https://wdisp1.custom.com:443/sap/bc/srt/idoc from a Web Service client (HCI)