Purpose
Clarify how the Multiple Systems settings of the Web Dispatcher work, including examples on how to configure each system involved.
Overview
This page will discuss the parameters involved on the Multiple Systems configuration of the Web Dispatcher, as well as showing examples of such configuration.
1. Background
The idea is to combine multiple backend systems of same or different type behind a single web address or web origin. An origin is the combination of protocol, host and port.
There are two variants of this scenario:
First scenario: Use additional URL prefixes to address multiple backend systems
For each system, an URL prefix would be added in front of the path to identify the system. The prefix could be either removed by the Web Dispatcher or tolerated by the backend system
Example:
The Web Dispatcher would run on "https://www.example.com". The backend systems would be addressed with the following URLs:
- Path prefix "/erp1" should reach an SAP ERP system;
- Path prefix "/erp2" should reach another SAP ERP system;
- Path prefix "/pi" would reach an SAP PI system;
- Path prefix "/ep" should reach an SAP Enterprise Portal system.
Unfortunately, the general answer is No. There are two major reasons:
- When backend systems generate URLs, they are not prepared to generate such a variable prefix;
- Cookies issued to path "/" would clash.
Therefore, SAP does not support adding a prefix in front of system paths to identify multiple backend systems. Instead, each backend system should be addressed by a different hostname or by using one of the system selection techniques that will be discussed later on this WIKI.
Second scenario: Partition the path tree of all backend systems and route the request accordingly
Differentiate backend systems by different paths to the applications.
Example:
The Web Dispatcher would run on "https://www.example.com". The backend systems would be addressed with the following URLs:
- All path prefixes "/sap/hba", "/hana", "/sap/hana" and "/sap/ui5" should be routed to an SAP HANA XS system;
- The path "/sap/es/ina" should be routed to an SAP ERP system;
- All remaining paths should be routed to an SAP NetWeaver Gateway 2.0 system.
Such a setup is possible, and is actually required for SAP Fiori to overcome the restrictions of the Same-origin policy. However, only specific combinations of systems are possible, because:
- Cookies issued to path "/" would clash;
- Overlapping resources must be avoided.
The next sections will discuss in detail all the possibilities to configure multiple backend systems at a single Web Dispatcher.
2. The parameter wdisp/system_<xx>
The starting point of the setup is the parameter wdisp/system_<xx>. Notice that this parameter uses comma (",") to distinguish the different arguments, in the same way the parameter "icm/server_port_<xx>" does.
The usage of this parameter is recommended even if a single backend system will be configured at the Web Dispatcher, as the old parameters ("rdisp/mshost", "ms/http_port" and "ms/https_port") are being discontinued.
Each backend system should be defined only once. Defining the same backend more than once can cause random issues (timeouts, "session does not exist", blank pages, …) because of how the internal load balancing mechanism of the Web Dispatcher works. For example, configuring:
wdisp/system_0 = SID=ABC, MSHOST=abc-ascs, MSPORT=8100, SRCURL=/sap/ wdisp/system_1 = SID=ABC, MSHOST=abc-ascs, MSPORT=8100, SRCURL=/nwbc/
is incorrect. The parameter "wdisp/system_1" should be removed and both parameters should be merged to
wdisp/system_0 = SID=ABC, MSHOST=abc-ascs, MSPORT=8100, SRCURL=/sap/;/nwbc/
3. System selection criteria
The parameter wdisp/system_<xx> provides three selection criteria: the SRCURL, the SRCSRV and the SRCVHOST arguments. The SRCVHOST option was introduced by the SAP note 2010948 and it is the recommended mechanism.
The selection criterion SRCURL can be used individually or combined with any of the other two criteria.
It does not make sense to use both SRCSRV and SRCVHOST combined.
3.1 SRCURL
Can be used to define the backend system to forward the request based on the URI path (the URL) accessed by the end user. For example, the Web Dispatcher is used in front of two systems: an ABAP and a Java.
wdisp/system_0 = SID=ABA, MSHOST=abap-srv, MSPORT=8100, SRCURL=/sap/;/nwbc/ wdisp/system_1 = SID=JAV, MSHOST=java-srv, MSPORT=8101, SRCURL=/
Because all ABAP URLs start with "/sap" or "/nwbc", all ABAP related requests will be sent to the ABA system.
If the accessed URL does not start with either criteria defined for the ABA system (/sap or /nwbc), the Web Dispatcher will send the request to the JAV system (“/irj/portal”, for example).
Notice that what we define at the SRCURL are "URL prefixes". This means that "/sap" is equivalent to "/sap*" and that "/" is equivalent to "/*".
Therefore, even though there is no apparent conflict in the URLs, the example above will cause the Web Dispatcher to not start as it will consider this setup to be ambiguous. Thus, even in this example, the parameter "wdisp/system_conflict_resolution" has to be set to one.
If the parameters were inverted (wdisp/system_1 renamed to 0, and wdisp/system_0 renamed to 1), all requests would be sent to the JAV system, always. No request would ever be sent to the ABA system (considering that "wdisp/system_conflict_resolution = 1" is set). Thus, the order of the wdisp/system_<xx> parameters is relevant in this scenario.
3.2 SRCSRV
Can be used to determine the backend system to which the request will be forwarded based on the HTTP(S) port used at the Web Dispatcher, the hostname used by the end user to reach the Web Dispatcher, or a combination of both.
EXAMPLE 1: port as the selection criteria
The Web Dispatcher has the HTTP ports 8000 and 8100 configured.
You have two ABAP backend systems, and want to determine which is to be used based on the HTTP port used to perform the access.
All requests made to the port 8000 are to be forwarded to the AB1 system, while all requests to port 8100 to the AB2 system. The parameters would be:
icm/server_port_0 = PROT=HTTP, PORT=8000 icm/server_port_1 = PROT=HTTP, PORT=8100 wdisp/system_0 = SID=AB1, MSHOST=abap1-srv, MSPORT=8100, SRCSRV=*:8000 wdisp/system_1 = SID=AB2, MSHOST=abap2-srv, MSPORT=8101, SRCSRV=*:8100
The hostname used to reach the Web Dispatcher is not relevant as the hostname part of the SRCSRV argument is defined as “*”.
EXAMPLE 2: hostname as the selection criteria
The following DNS aliases were created and are pointing to IP addresses of the server where the Web Dispatcher is installed (each DNS entry pointing to a different IP address).
ecc.example.com
portal.example.com
All requests made to "ecc.example.com" are to be forwarded to the ABA system, while the requests made to "portal.example.com" to the JAV system. These are the corresponding parameters:
wdisp/system_0 = SID=ABA, MSHOST=abap-srv, MSPORT=8100, SRCSRV=ecc.example.com:* wdisp/system_1 = SID=JAV, MSHOST=java-srv, MSPORT=8101, SRCSRV=portal.example.com:*
The Web Dispatcher will use the HTTP header "host" that is defined by the client (internet browser) to determine which was the hostname used by the end user to reach it.
The port used to reach the Web Dispatcher is not relevant as the port part of the SRCSRV argument is defined as "*".
EXAMPLE 3: hostname and port combined
The following parameters will be considered at this example:
icm/server_port_0 = PROT=HTTP, PORT=8000 icm/server_port_1 = PROT=HTTP, PORT=8100 wdisp/system_0 = SID=ABA, MSHOST=abap-srv, MSPORT=8100, SRCSRV=ecc.example.com:8000 wdisp/system_1 = SID=JAV, MSHOST=java-srv, MSPORT=8101, SRCSRV=portal.example.com:8100
All requests that reach the Web Dispatcher through the host "ecc.example.com" AND the port 8000 will be sent to the ABA system.
In the same way, all requests that reach the Web Dispatcher through the host "portal.example.com" AND the port 8100 will be sent to the JAV system.
If a request reaches the Web Dispatcher through "ecc.example.com" and the port 8100, for example, the result may vary.
This is because the Web Dispatcher will use the IP address associated to the hostname to perform the system selection. Therefore, if both hostnames ("ecc.example.com" and "portal.example.com") point to the same IP address, the result is the same as in example 1 (only the port will be used for the selection criteria). Thus, a request to "ecc.example.com:8100" will be forwarded to the JAV system.
However, if the IP address mapped to each hostname is different, the Web Dispatcher will not be able to match the request to the systems definitions. Thus, a "503 Service Unavailable" error is returned to the end user. The request is not forwarded to any backend, but is discarded.
In order to handle DNS aliases pointing to the same IP address, use SRCVHOST instead (read the next section).
3.3 SRCVHOST (recommended mechanism)
This argument works in the same way as SRCSRV (read the previous section), with only one difference: the IP address associated to the hostname used to reach the Web Dispatcher is not taken into account.
The SRCVHOST argument verifies the content of the HTTP header "host" itself, and only this value. A DNS lookup is not performed, as in SRCSRV.
Consider the parameters below for the following examples:
icm/server_port_0 = PROT=HTTP, PORT=8000 icm/server_port_1 = PROT=HTTP, PORT=8100 wdisp/system_0 = SID=ABA, MSHOST=abap-srv, MSPORT=8100, SRCVHOST=ecc.example.com:8000 wdisp/system_1 = SID=JAV, MSHOST=java-srv, MSPORT=8101, SRCVHOST=portal.example.com:8100
- If the user accesses "ecc.example.com:8000", the request will be sent to the ABA system - as in the SRCSRV case;
- If the user accesses "portal.example.com:8100", the request will be sent to the JAV system - as in the SRCSRV case;
- If the user accesses any other combination, like "portal.example.com:8000", no system will match the request.
Thus, a "503 Service Unavailable" error is returned to the end user. The request is not forwarded to any backend, but is discarded.
4. SSL (HTTPS) and multiple systems
The latest versions of the Web Dispatcher allow the definition of multiple SSL Server credentials. This enables the usage of a single Web Dispatcher for multiple backend systems even if SSL is used.
The Web Dispatcher release 7.53 is the recommended version for S/4 HANA 1709 backend systems and for NetWeaver 7.52 based backend systems.
The Web Dispatcher release 7.49 is the recommended version for all other backend systems.
There is no need to update the backend system(s) as well. You can read more about the Web Dispatcher releases and backend compatibility at the SAP note 908097.
The argument SSLCONFIG of the parameter icm/server_port_<xx> can be used to define the SSL server credential of that HTTPS port. A corresponding icm/ssl_config_<xx> parameter has to be defined.
For example, the following parameter configures the HTTPS port 443 to be opened with the SSL server credential 0:
icm/server_port_1 = PROT=HTTPS, PORT=443, SSLCONFIG=ssl_config_0
The corresponding icm/ssl_config_<xx> parameter would be:
icm/ssl_config_0 = CRED=ecc.pse
For assistance with the PSE / SSL certificates management, read this WIKI page.
4.1 Using SNI - Server Name Indication (recommended procedure)
It is possible to open a single HTTPS port that can use multiple PSE files.
This procedure aligns very well with the recommended selection criterion (SRCVHOST from section 3.3, above).
After creating the PSE files with the SSL server certificates for the different virtual hostnames pointing to the Web Dispatcher, the argument "SNI_CREDS" can be added to the icm/ssl_config_<xx> parameter to include the additional PSE files.
For example:
icm/server_port_1 = PROT=HTTPS, PORT=443, SSLCONFIG=ssl_config_0
icm/ssl_config_0 = CRED=Main_Cert.pse, SNI_CREDS=SNI1.pse;SNI2.pse
Each of the PSE files mentioned above (Main_Cert.pse, SNI1.pse and SNI2.pse) have an SSL server certificate for a different hostname.
If wildcard certificates (like "*.example.com") are being used at the PSE files provided through the argument "SNI_CREDS", read the SAP KBA 2527968 for assistance on how to perform the correct configuration of this scenario.
4.2 Using multiple HTTPS ports or hostnames (old, not recommended procedure)
To use multiple HTTPS ports, the following parameters would be configured:
icm/server_port_1 = PROT=HTTPS, PORT=443, SSLCONFIG=ssl_config_0 icm/server_port_2 = PROT=HTTPS, PORT=444, SSLCONFIG=ssl_config_1 icm/ssl_config_0 = CRED=ecc.pse icm/ssl_config_1 = CRED=portal.pse
To use multiple hostnames, multiple IP addresses have to be configured at the Web Dispatcher server. For example, instead of creating the DNS aliases mentioned earlier in this page, the server where the Web Dispatcher is installed has two IP addresses configured:
ecc.example.com - local IP address at the Web Dispatcher server: 10.10.10.10
portal.example.com - local IP address at the Web Dispatcher server: 10.10.10.20
The Web Dispatcher parameters would be:
icm/server_port_1 = PROT=HTTPS, HOST=10.10.10.10, PORT=443, SSLCONFIG=ssl_config_0 icm/server_port_2 = PROT=HTTPS, HOST=10.10.10.20, PORT=443, SSLCONFIG=ssl_config_1 icm/ssl_config_0 = CRED=ecc.pse icm/ssl_config_1 = CRED=portal.pse
The hostnames can be used as well, at the HOST argument, instead of the IP addresses:
icm/server_port_1 = PROT=HTTPS, HOST=ecc.example.com, PORT=443, SSLCONFIG=ssl_config_0 icm/server_port_2 = PROT=HTTPS, HOST=portal.example.com, PORT=443, SSLCONFIG=ssl_config_1
5. Putting all together at more realistic examples
The Web Dispatcher will be in front of two systems: an ECC (ABAP) system and an Enterprise Portal (Java) system.
The users will access the Portal, initially, and they will access Portal iViews that are pointing to the ECC (so the users can run a transaction at the ECC through web access, for example).
Observation: the single sign on (SSO) configuration between the ECC and Portal systems will not be covered at this page.
EXAMPLE 1: ACCESS THROUGH A SINGLE HOSTNAME
All access will be performed through a single hostname.
The Web Dispatcher hostname is "wdp.example.com".
SETTINGS AT THE WEB DISPATCHER
The following parameters are defined at the Web Dispatcher profile.
icm/server_port_0 = PROT=HTTP, PORT=80 wdisp/system_0 = SID=ECC, MSHOST=ecc-srv, MSPORT=8100, SRCURL=/sap/;/nwbc/ wdisp/system_1 = SID=EPP, MSHOST=portal-srv, MSPORT=8101, SRCURL=/
SETTINGS AT THE ECC SYSTEM
Usually, no changes are required at ABAP systems. The usage of a Web Dispatcher should be completely transparent to the ABAP system.
In rare occasions, the HTPURLLOC table has to be maintained so the URL generation of the ABAP system uses the Web Dispatcher hostname instead of the hostname of the local ABAP instance.
SETTINGS AT THE PORTAL SYSTEM
No changes are required at the Java system itself. However, since the Web Dispatcher is the end user entry point, the System Objects involved should have their "Web AS" and "ITS" properties pointing to the Web Dispatcher host/port instead of the ECC host/port.
The System Objects are defined under the "System administration" -> "System landscape" menu.
Example of System Object _before_ the Web Dispatcher implementation:
Example of System Object _after_ the Web Dispatcher implementation:
It is not necessary to define the port number as the Web Dispatcher is configured with the standard port number (80 for HTTP). If a non-standard port was in use at the Web Dispatcher (e.g., HTTP port 8080), the port should be defined in the same way seen at the picture related to the settings before the Web Dispatcher implementation.
EXAMPLE 2: ACCESS THROUGH MULTIPLE HOSTNAMES
Access through HTTPS is to be enforced.
Thus, the Web Dispatcher server has two IP addresses configured, each mapped to a different hostname:
ecc.example.com - local IP address at the Web Dispatcher server: 10.10.10.10
portal.example.com - local IP address at the Web Dispatcher server: 10.10.10.20
End users will use "portal.example.com" as the entry point.
SETTINGS AT THE WEB DISPATCHER
The following parameters are defined at the Web Dispatcher profile.
icm/server_port_0 = PROT=HTTP, PORT=80 icm/server_port_1 = PROT=HTTPS, HOST=ecc.example.com, PORT=443, SSLCONFIG=ssl_config_0 icm/server_port_2 = PROT=HTTPS, HOST=portal.example.com, PORT=443, SSLCONFIG=ssl_config_1 icm/ssl_config_0 = CRED=ecc.pse icm/ssl_config_1 = CRED=portal.pse wdisp/system_0 = SID=ECC, MSHOST=ecc-srv, MSPORT=8100, SRCSRV=ecc.example.com:* wdisp/system_1 = SID=EPP, MSHOST=portal-srv, MSPORT=8101, SRCSRV=portal.example.com:*
The "ecc.pse" file has the server certificate signed for the ECC related address (ecc.example.com), while the "portal.pse" file has the server certificate for the Portal address (portal.example.com).
In order to enforce HTTPS usage, the parameter icm/HTTP/redirect_<xx> can be used:
icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, PROT=https, FOR=portal.example.com:*, HOST=portal.example.com icm/HTTP/redirect_1 = PREFIX=/, FROM=*, FROMPROT=http, PROT=https, FOR=ecc.example.com:*, HOST=ecc.example.com
It is also recommended to set the following parameters:
wdisp/add_client_protocol_header = true
This is for the backend systems to be "aware" that the end user is using HTTPS, and there is "something" between the end user and the system that is handling the SSL communication with the end user.
icm/HTTPS/forward_ccert_as_header = true
In case X.509 certificate based single sign on is used, the Web Dispatcher will forward the end user certificate to the backend system as an HTTP header.
SETTINGS AT THE ECC SYSTEM
Refer to the example above. The same settings / observations apply to this example.
SETTINGS AT THE PORTAL SYSTEM
Refer to the example above. The same settings / observations apply to this example, with the only remark that the "Web AS" and "ITS" properties of the System Object should point to "ecc.example.com".
Related Content
Related Documents
Parameter wdisp/system_conflict_resolution
Parameter icm/server_port_<xx>
Parameter icm/HTTP/redirect_<xx>
Managing PSE files at the Web Dispatcher
Using multiple SSL server certificates at the Web Dispatcher
Related SAP Notes/KBAs
SAP note 908097: SAP Web Dispatcher: Release, Installation, Patches, Documentation
SAP note 2010948: SAP Web Dispatcher support of virtual hosts
SAP KBA 2527968: SSL WildCard Certificates for SNI
26 Comments
Former Member
Hi
A good and concise WIKI. I would also recommend that you look at also using the MOD rules to handle the distribution to multiple systems.
This gets over the limitation that you have with SRCURL in that you can have multiple ABAP / JAVA systems connected, without having to separate it by port number. You create multiple CNAME aliases to the Webdispatcher server and have 1 wildcard or SAN certificate on the 1 SSL port (*.fqdn)
An example would be that if your webdispatcher is on host wd-srv.fqdn / 10.10.10.50 then in your corporate DNS you would create the following CNAME records
CNAME ecc-alias wd-srv.fqdn
CNAME ep-alias wd-srv.fqdn
This would mean that if you ping ep-alias.fqdn or ecc-alias.fqdn you would get 10.10.10.50 returned.
In the Webdispatcher Instance Profile you need to add the following
icm/server_port_0 = PROT=HTTP,PORT=80,EXTBIND=1,TIMEOUT=900,PROCTIMEOUT=600
icm/server_port_1 = PROT=HTTPS,PORT=443,EXTBIND=1,TIMEOUT=900,PROCTIMEOUT=600
wdisp/system_0 = SID=ERP, MSHOST=ecc-srv, MSPORT=8101
wdisp/system_1 = SID=PRT, MSHOST=ep-srv, MSPORT=8101
icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_PROFILE)/icm_mod_rules.pfl
And then create a Modification Rule file in the Webdispatcher profile directory (icm_mod_rules.pfl)
#-----------------------------------------------------------------------
# Set Web Dispatcher Headers
#-----------------------------------------------------------------------
SetHeader "ClientProtocol" %{SERVER_PROTOCOL}
SetHeader "X-SAP-WEBDISP-AP" "http=80,https=443"
SetHeader "X-Forwarded-For" %{REMOTE_ADDR}
#-----------------------------------------------------------------------
# Redirect to SAP Environment based on CNAME Convention
#----------------------------------------------------------------------
if %{HTTP_HOST} regimatch "ecc-alias.fqdn"
SetHeader x-sap-webdisp-target-sid ERP [break]
if %{HTTP_HOST} regimatch "ep-alias.fqdn"
SetHeader x-sap-webdisp-target-sid PRT [break]
You than also need to maintain HTTPURLLOC with the correct host name of ecc-alais.fqdn and update the portal connectors with the correct hostname of ecc-alais.fqdn
This would then redirect HTTP(S) requests to https://ecc-alias.fqdn to the ERP environment and requests to https://ep-alias.fqdn to the EP environment. As you are using host names to do the matching, then you can have the same URI (i.e /sap/bc/public) and not have any issues, therefore allowing ERP / NW Gateway scenarios.
This approach also supports the further redirect configuration required for S/4HANA, Fiori, Enterprise Search, HANA XS etc and gets around the limitations documented in the following SAP Notes.
SAP Note 2477189 - SAP NetWeaver Gateway, ICM, Web Dispatcher, S/4HANA and Kernel compatibility info
SAP Note 2395328 - Can I operate multiple backend systems behind a single web origin?
Hope this helps
Damian
Isaias Freitas
Hello Damian,
Thank you for your comment!
Wouldn't using SRCVHOST (chapter 3.3) achieve the same functionality without the need to use MOD rules?
Best regards,
Isaías
Former Member
Hi Isaias.
It would do, but you would have to then have multiple ports (HTTP / HTTPS) configured for each hostname you want to use for backend access. It does however give the advantage of allowing individual SSL certificates for each system, rather than having to use a wildcard or SAN cert.
So in the example above you would need 4 ports (HTTP / HTTPS) on the Webdispatcher for ecc-alias.fqdn and ep-alias.fqdn (Assuming you wanted both HTTP and HTTPS based access), Then for each additional system you wanted to connect to the Webdispatcher, you would then need a further 2 more ports allocated.
This then starts to make integration into other network functions such as Network Acceleration, Firewalls, QOS etc. more complicated as you have more Ports to deal with. Its also harder to remember the ports when deploying to end users or configuring system connections (Portal Landscape, SM59 etc.)
The advantage of using the MOD rule in this manor, is that you only ever need 1 IP and default ports for HTTP and HTTPS configured. Disadvantage is you need a wildcard or SAN cert for HTTPS as you are only using 443.
I have been using the MOD rule for a long time now, and I find it a very flexible way of doing most functions with the Webdispatcher.
Hope this helps
Damian
Isaias Freitas
Hello Damian,
There is no need to have a dedicated port.
You can define "SRCVHOST=ecc-alias.fqdn:*", so just the hostname is considered.
SRCVHOST works on the same way as SRCSRV. Maybe the example given at the SRCVHOST section is causing some confusion...?
Best regards,
Isaías
Oliver Broughton
Great wiki which clears up a few of the precedence rules in the webdisp profile which have been puzzling me.
Also, I have configured with a single IP and port (443) using a single server PSE and multiple common names. This does require multiple bound IP's and DNS names but seems to work well in the SAML configuration scenario.
In my experience all the above configuration should work for SAML, but have you tested any of the above configurations using SAML authentication?
It should not make a difference.....multiple PSE's seem to be 'cleaner' and easier to understand.... So will be using that config in future.
Regards
Justin
Isaias Freitas
Hello Justin,
I (personally) have never setup SAML.
But, as you said, it should not make any difference.
Regards,
Isaías
Daulet Ujurganov
Hi Isaias, thanks for share.
I have some trouble with ssl, can you help me with my problem?
https://answers.sap.com/questions/340046/web-dispatcher-https-for-bpc-nw-systems.html
Isaias Freitas
Hello Daulet,
I do not know whether you saw it, but I have replied the SAP Community question that you linked
.
Best regards,
Isaías
Christoph Ostrop
is this a valid splitting of URL-content ? dispatching with path-prefix to multiple targets,should this work fine ?
some of Webservice to PO, other webservice to PI, all other to ERP
SID:EOP = SAP-PO
SID:EXP = SAP-PI
SID:ERP = ECC-/ERP-6.0 EHP8
wdisp/system_conflict_resolution = 1
wdisp/system_0 = SID=EOP, MSHOST=host3, MSPORT=8101, SSL_ENCRYPT=0, SRCURL=/XISOAPAdapter/MessageServlet?send
erService=BC_WEBSERVICE&interface=BestellungAnlegen_IS;/XISOAPAdapter/MessageServlet?senderService=BC_WEBSERVICE&interf
ace=siRequest
wdisp/system_1 = SID=EXP, MSHOST=host2, MSPORT=8146, SSL_ENCRYPT=0, SRCURL=/XISOAPAdapter
wdisp/system_2 = SID=ERP, MSHOST=host1, MSPORT=8135, SSL_ENCRYPT=0, SRCURL=/
Isaias Freitas
Hello Christoph,
That would not work. The path-prefix ends at the question mark. Everything after the question mark is called "query string".
The easiest way would be to use port (SRCSRV) or virtual hosts (SRCVHOST) to decide the target system.
Another option would be to use modification rules, as you can test query string values with it.
You would need to:
if %{QUERY_STRING} stricmp "senderService=BC_WEBSERVICE&interface=BestellungAnlegen_IS"
SetHeader x-sap-webdisp-target-sid EOP [break]
if %{QUERY_STRING} stricmp "senderService=BC_WEBSERVICE&interface=siRequest"
SetHeader x-sap-webdisp-target-sid EOP [break]
<add more rules>
* Notice that you would need to test this to confirm that it works and that it does not cause conflicts with EXP
Regards,
Isaías
Christoph Ostrop
Hi, Isaias Freitas,
I had already suspected that, so thank you for your confirmation and thanks for the quick response and good help.
regards
Christoph
Isaias Freitas
You are welcome!
Christoph Ostrop
Hi,
we are using WebDisp-7.45 and trying to connect to HANA-XS Engine using the XSSRV= parm, - but it did not work,
wdisp/system_conflict_resolution = 1
wdisp/system_0 = SID=EOE, MSHOST=aaaaaaaaa, MSPORT=8101, SSL_ENCRYPT=0, SRCURL=/RESTAdapter;/XISOAPAdapter
wdisp/system_1 = SID=ECE, XSSRV=https://bbbbbbbbb:8000, SSL_ENCRYPT=0, SRCURL=/sap/is/retail/car/mcsa/odata;/sap/hba/;/sap/hana
wdisp/system_2 = SID=ECE, MSHOST=cccccccccc, MSPORT=8106, SSL_ENCRYPT=0, SRCURL=/sap/bc/ui2/flp
wdisp/system_3 = SID=ERE, MSHOST=ddddddddd, MSPORT=8105, SSL_ENCRYPT=0, SRCURL=/
Failed to read XS config from /sap/hana/xs/internal/topology.xscfunc. Error SSL
Refer to SAP note 1528396 + https://launchpad.support.sap.com/#/notes/2146931
we did set "false" to the internal HANA-webdisp. as in sapnote https://launchpad.support.sap.com/#/notes/2146931 , and restart HANA
but it still did not work
sapwebdisp pf=ppppppppp -checkconfig show this error
Retrieving server info from xsengine from bbbbbbbbb:/sap/hana/xs/internal/topology.xscfunc using http
ERROR: Connection to server bbbbbbbbb: failed
ERROR: retrieving server info from xsengine failed: Network error (NI)(-8)
??? any idea
Tobias Lejczyk
Hi Christoph,
apart from fixing the certificates, I would recommend to double check if the XS Classic is reachable on the HANA system. Which version of HANA are you using? Can you access the XS there directly?
I have seen quite a few installations now, especially newer ones, where the XS classic wasn't reachable via the hdbwebdispatcher.
Best regards,
Tobias
Christoph Ostrop
Hi, Tobias,
thanks for your quick reply,
we use HANA version 2.00.041.00.1560320256 (fa/hana2sp04) with SAP-CAR-AB 4.0
the URL directly to XS-Engine delivers a logon prompt (powered by XS-engine classic)
=====
additional info: there was an typing error - is should have to be the http protocol, not https
wdisp/system_1 = SID=ECE, XSSRV=https://bbbbbbbbb:8000, SSL_ENCRYPT=0,
this should be
wdisp/system_1 = SID=ECE, XSSRV=http://bbbbbbbbb:8000, SSL_ENCRYPT=0,
my fault, sorry. Thanks
Tobias Lejczyk
So is it working now? That would be great news
.
Christoph Ostrop
yes, thanks
Christoph Ostrop
Hi,
one more question - relating to this situation:
wdisp/system_conflict_resolution = 1
wdisp/system_0 = SID=EOE, MSHOST=aaaaaaaaa, MSPORT=8101, SSL_ENCRYPT=0, SRCURL=/RESTAdapter;/XISOAPAdapter
wdisp/system_1 = SID=ECE, XSSRV=http://bbbbbbbbb:8000, SSL_ENCRYPT=0, SRCURL=/sap/is/retail/car/mcsa/odata;/sap/hba/;/sap/hana
wdisp/system_2 = SID=ECE, MSHOST=bbbbbbbbb, MSPORT=8106, SSL_ENCRYPT=0, SRCURL=/sap/bc/ui2/flp
wdisp/system_3 = SID=ERE, MSHOST=ddddddddd, MSPORT=8105, SSL_ENCRYPT=0, SRCURL=/
========
wdisp_system_0 is a SAP-PO
wdisp_system_1 is a SAP-CARAB 4.0 with XS-Engine
wdisp_system_2 is a SAP-CARAB AS-ABAP ICM
all other => wdisp_system_3 is a SAP-ECC 6.0 EHP8 AS-ABAP with different usage as NWBC-Sessions and some more WebServices /HttpAdapter and some Fiori-Launchpad or WebDynproABAP
============
the problem is, that 2 systems will use FLP or WebDynpro, so if we config for the CARAB-System AS-ABAP,
but the NWBC-Sessions to ECC-System does not work anymore
we tried to split with different entry-port-no in webDisp, but is does not work.
============
wdisp/system_conflict_resolution = 1
wdisp/system_0 = SID=EOE, MSHOST=aaaaaaaaa MSPORT=8101, SSL_ENCRYPT=0, SRCURL=/RESTAdapter SRCSRV=*:8443;/XISOAPAdapter SRCSRV=*:8443
wdisp/system_1 = SID=ECE, XSSRV=http://bbbbbbbbb:8000, SSL_ENCRYPT=0, SRCURL=/sap/is/retail/car/mcsa/odata SRCSRV=*:8444;/sap/hba SRCSRV=*:8444;/sap/hana SRCSRV=*:8444
wdisp/system_2 = SID=ECE, MSHOST=bbbbbbbbb, MSPORT=8106, SSL_ENCRYPT=0, SRCURL=/sap/bc SRCSRV=*:8444;/sap/opu SRCSRV=*:8444;/sap/es SRCSRV=*:8444;/sap/es/ina SRCSRV=*:8444;/sap/public SRCSRV=*:8444;/ENTERPRISE_SEARCH SRCSRV=*:8444
wdisp/system_3 = SID=ERE, MSHOST=ddddddddd, MSPORT=8105, SSL_ENCRYPT=0, SRCURL=/ SRCSRV=*:8443;SRCURL=/sap/bc/ui2/nwbc SRCSRV=*:8443
============
How to resolve this ? how to separate AS-ABAP CARAB, and AS-ABAP ECC ?
Tobias Lejczyk
Hi Cristoph,
you have basically five options for routing traffic:
and basically any combination of those.
If you have Paths, that are called from different systems (in your case the fiori interface), you have to move over to portbased or hostname based routing. Or you need to implement some elaborate ruleset, which I would try to avoid.
You are on the right track with port based routing.
So what were you trying to achive? Basically: Reach EOE and ERE via Port 8443 and ECE via port 8444? Or something else?
For that scenario the right config would be:
wdisp/system_0 = SID=EOE, MSHOST=aaaaaaaaa MSPORT=8101, SSL_ENCRYPT=0, SRCURL=/RESTAdapter;/XISOAPAdapter, SRCSRV=*:8443
wdisp/system_1 = SID=ECE, XSSRV=http://bbbbbbbbb:8000, SSL_ENCRYPT=0, SRCURL=/sap/is/retail/car/mcsa/odata;/sap/hba;/sap/hana, SRCSRV=*:8444
wdisp/system_2 = SID=ECE, MSHOST=bbbbbbbbb, MSPORT=8106, SSL_ENCRYPT=0, SRCURL=/sap/bc;/sap/opu;/sap/es;/sap/es/ina;/sap/public;/ENTERPRISE_SEARCH, SRCSRV=*:8444
wdisp/system_3 = SID=ERE, MSHOST=ddddddddd, MSPORT=8105, SSL_ENCRYPT=0, SRCURL=/;SRCURL=/sap/bc/ui2/nwbc, SRCSRV=*:8443
I would shorten it to:
wdisp/system_0 = SID=EOE, MSHOST=aaaaaaaaa MSPORT=8101, SSL_ENCRYPT=0, SRCURL=/RESTAdapter;/XISOAPAdapter, SRCSRV=*:8443
wdisp/system_3 = SID=ERE, MSHOST=ddddddddd, MSPORT=8105, SSL_ENCRYPT=0, SRCURL=/, SRCSRV=*:8443
wdisp/system_1 = SID=ECE, XSSRV=http://bbbbbbbbb:8000, SSL_ENCRYPT=0, SRCURL=/sap/is/retail/car/mcsa/odata;/sap/hba;/sap/hana, SRCSRV=*:8444
wdisp/system_2 = SID=ECE, MSHOST=bbbbbbbbb, MSPORT=8106, SSL_ENCRYPT=0, SRCURL=/, SRCSRV=*:8444
This basically routes traffic on Port 8443 to EOE and ERE. Based on the Path, some traffic is routed to the EOE, the rest is routet to the ERE.
Same goes for ECE. Traffic coming in on 8444 is routet to ECE: some traffic is routet to the XS, the rest is routet to the AS ABAP.
Hope this helps
.
Best regards,
Tobias
Christoph Ostrop
Oh thank you very much, - now I also realized what I did wrong,
(please see attached hardcopys)
maybe this should be explicitly mentioned again in your blog-content, so that other customers do not make the same mistakes,
et al the comma separation between the parameters is obviously extremely important for recognizing the port-no within the web-disp configuration.
my mistake: the missing comma between e.g. ( SRCURL=/, SRCSRV=*:8443 )
otherwise the configuration leads to such erroneous results and it does not work.
many thanks, that helped me really a lot.
Christoph
==================================
https://ibb.co/7pbwqqp
https://ibb.co/RHz80TT
Isaias Freitas
Hello Christoph,
Thank you for the suggestion! I have added a comment about the usage of comma at the beginning of section 2.
Best regards,
Isaías
Asif Rahmetulla
Hello Tobias,
In your example 2 with one web dispatcher accessing multiple systems using hostnames, what would the web dispatcher configuration be if the backed systems have SSL enabled
for example, ecc has ssl with CN=sapecc.example.com and portal has ssl with CN=sapportal.example.com
In your example, the web dispatcher is listening on two different ip-addresses with ssl certificates for CN=ecc.example.com (referenced by CRED=ecc.pse) and CN=portal.example.com (referenced by CRED=portal.pse). Where would you specify the SSL certificate corresponding to the backend systems to achieve SSL re-encryption between WDP and backend systems?
Regards,
Asif
Tobias Lejczyk
Hi Asif,
I am not quite sure, if I understand the question correct. For the encryption of the connection between the Web Dispatcher and the backend system, the SAPSSLC.pse is always used. So there, the root CA of the backend needs to be trusted. And if you need some certificate forwarding, the Web Dispatcher has to be trusted by the backends to forward certificates (accept WD client certificate from SAPSSLC.pse and trust via parameter icm/trusted_reverse_proxy_<nn>).
Regarding the HTTPS Ports of the WD: You can go for different IP addresses or use Subject Alternative Names (one certificate that is issued to all server names) or Server Name Indication (one certificate per hostname, but on the same IP and Port).
Does this help in answering your question?
Tobias Lejczyk
Hi Asif,
I am not quite sure, if I understand the question correct. For the encryption of the connection between the Web Dispatcher and the backend system, the SAPSSLC.pse is always used. So there, the root CA of the backend needs to be trusted. And if you need some certificate forwarding, the Web Dispatcher has to be trusted by the backends to forward certificates (accept WD client certificate from SAPSSLC.pse and trust via parameter icm/trusted_reverse_proxy_<nn>).
Regarding the HTTPS Ports of the WD: You can go for different IP addresses or use Subject Alternative Names (one certificate that is issued to all server names) or Server Name Indication (one certificate per hostname, but on the same IP and Port).
Does this help in answering your question?
Asif Rahmetulla
Hello Tobias,
Thank you for your prompt response! And I am good with the WD certificates for HTTPS ports and ip-addresses etc.,
My question was around SSL re-encryption ([client] ---- https ---- [WebDispatcher] ----- https ----- [ECC]), where client connects to WD which is listening on HTTPS port with server certificate ("ecc.pse") for address "ecc.example.com" and then WD re-encrypts and connects to ECC system which has SSL certificate under different name "sapecc.example.com". In this setup, the web dispatcher profile parameter icm/ssl_config_xx will point to the CREDential files ecc.pse and portal.pse (as you had mentioned). However, what setup is needed on Web dispatcher to perform the SSL re-encryption to connect to the backend system running with different SSL certificate? You mentioned SAPSSLC.pse on WD side to contain the root CA of the backend. What else? Can you share an example for the HTTPS-HTTPS setup with SSL re-encryption?
Regards,
Asif
Tobias Lejczyk
Hi Asif,
this is done via the parameter "wdisp/ssl_encrypt". Basically, you set it up as follows:
icm/server_port_0 = PROT=HTTPS, PORT=443, HOST=ecc.example.com, SSLCONFIG=ssl_config_0
icm/ssl_config_0 = CRED=ecc.pse
icm/server_port_1 = PROT=HTTPS, PORT=443, HOST=portal.example.com, SSLCONFIG=ssl_config_1
icm/ssl_config_1 = CRED=portal.pse
wdisp/system_0 = SID=ECC, MSHOST=..., MSPORT=..., SRCVHOST=ecc.example.com
wdisp/system_1 = SID=POR, MSHOST=..., MSPROT=..., SRCVHOST=portal.example.com
wdisp/ssl_encrypt = 2
=> The Traffic between WD and backends is encrypted (except for Ping, GroupInfo and Messageserver Traffic, which have to be enabled seperately).
The Web Dispatcher is using the SAPSSLC.pse to validate the certificates of the backend servers and, if necessary, to authenticate towards the backends.
It's really that simple. At least, when you have your backend certificates in order
. They obviously have to be issued to the right hostname (SAPLOCALHOSTFULL of the application-Server).
Best regards,
Tobias