Cascade of Web dispatchers

[Former Member]

Hello, 

Need some help implementing cascade of web dispatchers as per note 740234 - Cascade of SAP Web dispatchers

This note was still in unreleased state, got that resolved.

Anyway, my scenario is to setup communication between a system at external vendor and our back end system. We have a web dispatcher in the dmz to receive an initial request and pass that on to the backend system via another web dispatcher sitting on the same host as the backend system. This was in place for load balancing....

I found this note and followed it as its close to what I was doing. But this note says under example for the internal web dispatcher sitting in front of the backend system-

An SAP Web dispatcher with the following profile is placed in front of the BIN system:

           SAPSYSTEMNAME = BIN

           SAPSYSTEM = 66

           rdisp/mshost = binmain

           ms/http_port = 8081

           icm/server_port_0 = PROT=HTTP,PORT=8083

Not sure if I am reading this right - are they saying the webdispatcher's profile would have the system name and system number of the backend system in its profile???

If anybody implemented this scenario using this note or in general, then please share your knowledge.

Thanks

[tobias_winterhalter]

Hi

The example in the note is misleading. In fact, it is possible to use the same system name as the backend system, but the system number definitely needs to be unique. In this case, the Web Dispatcher would be like another instance of the backend system. But in general, it is better to keep the Web Dispatcher separate with its own system name.

If you already have a running Web Dispatcher installation in front of the backend, there is no need to change anything for the cascade. All the work needs to be done on the Web Dispatcher in the DMZ.

Regards

[Former Member]

Thanks Tobias. Yes that name and number threw me off....

Anyway, when you say all setup needs to be on the dmz side are you still referencing the same note....with those three files....they do reference backend SIDs there as well....OR you are saying through other parameters referencing sapssls.pse and sapsslc.pse etc....if you have used any link or know of, kindly pass it on....

Raj

[tobias_winterhalter]

Hi Raj

The point is that the Web Dispatcher in the DMZ cannot get the backend information the usual way by contacting the message server of the backend. For this reason, the configuration has to be done manually with the use of the three files. The example in the note is actually more complex than you need, because it was meant to show how one Web Dispatcher can service multiple systems. In your case, you only have one system and you should be able to skip all the stuff related to logon groups.

Here's an example (not tested). Let's say, your backend Web Dispatcher has the following profile and is running on server beserver1.example.com:

SAPSYSTEMNAME = WDP
SAPSYSTEM = 01
icm/server_port_0 = PROT=HTTP,PORT=8000

Now, from the DMZ WD's point of view, WDP is the backend system and beserver1 is the only app server of this system, listening on HTTP port 8000. This has to be defined in the server info file (the note calls it info.icr):

version 1.0
beserver1_WDP_01
HTTP beserver1.example.com 8000
DIAG beserver1.example.com 8000 DIA=2

As I mentioned, logon groups should not be required for your scenario, but the file should still be there and define the available servers (icrgroups.txt in the note):

version 1.0
beserver1_WDP_01

Finally, you need an URL prefix table to forward all incoming requests to the "fake" ABAP backend (urlinfo.txt in the note):

version 1.0
PREFIX=/sap/&GROUP=

If anything goes wrong, check the dev_webdisp for WARNING or ERROR. Better add rdisp/TRACE=2 to the profile during the testing phase, then you will not miss stuff that is going on during WD startup.

Please note that this example is for ABAP only. If you have J2EE or even a dul stack, it's getting a bit more complicated. Also, if you are using HTTPS between the two WDs, trust relationship has to be setup accordingly.

Regards

[Former Member]

Hey Tobias,

Really appreciate your response. Yeah I did try like you mentioned with just one system information in all 3 files but was getting errors in dev_webdisp.....but your last paragraph - my backend system is PI java only....and I am using (supposed to) https all the way, with a termination at dmz and reencryption to the second web dispatcher.....so I have all the complications possible I guess.

[tobias_winterhalter]

Let me see. In the info.icr, you have to specify the J2EE ports (and skip the DIAG which is for ABAP):

version 1.0
beserver1_WDP_01
HTTP beserver1.example.com 8000 LB=1
HTTPS beserver1.example.com 8001 LB=1
J2EE beserver1.example.com 8000 LB=1
J2EES beserver1.example.com 8001 LB=1

If you have HTTPS only, you can of course skip HTTP/J2EE.

The icrgroups.txt file remains unchanged. But the urlinfo.txt needs to specify the stack:

version 1.0
PREFIX=/&GROUP=&STACK=J2EE

For HTTPS, it might be sufficient to export the backend WD's server certificate from its SAPSSLS.pse and import it into the SAPSSLC.pse on the DMZ side. If you have wdisp/ssl_auth=2 on the backend WD, you need a client certificate for the DMZ WD.

Are you using X.509 client certifcate based logon for your users? This would make things maximum complicated 😉

You might consider using end-to-end SSL on the DMZ side. In this case, the clients would see the server certificate of the backend WD (there are no PSE files for the DMZ WD in an end-to-end SSL scenario.) But you would not be able to do anything with the requests on DMZ side (except forwarding), e.g. no logging, caching, URL filtering, etc.

Regards

[Former Member]

Hi Tobias,

I tried with only one entry for info.icr - HTTPS, didn't have the LB=1.

I just added stack to urlinfo just now along with LB=1 and didn't make any difference.

I had built SAPSSLC.pse on the dmz side from an export of SAPSSLS.pse on the internal side but no where in my current profile am I referencing that

In another version without these 3 files I have the following parameters

wdisp/ssl_encrypt = 1

wdisp/ssl_auth = 2

wdisp/ssl_cred = $(DIR_INSTANCE)\sec\SAPSSLC.pse

This is the error I have been getting

ERROR => no valid destination server available for '!J2EE' rc=13 {00000005} [http_route.c 3412]

Reviewing that error, I found a link of talking about creating logon groups and url mapping on the backend java system and defining the following in external webdisp profile

wdisp/j2ee/server_info_location

wdisp/j2ee/url_map_location

Yes I am using X509 certificates. I don't know about end to end...for the reasons you mentioned. I need to set up url filtering and also authentication....

[tobias_winterhalter]

Ok, I did some research:
You don't need the HTTP lines in the server.info. These are for the ABAP stack. You need to specify LB for the J2EE lines, otherwise they are ignored. Since there is not much load balancing involved, you can use LB=1.

In summary, the server.info should look like this:

version 1.0
beserver1_WDP_01
J2EE beserver1.example.com 8000 LB=1
J2EES beserver1.example.com 8001 LB=1

The other files remain as I mentioned before (STACK in the URL map file is important). It is not necessary to use parameters wdisp/j2ee/server_info_location and wdisp/j2ee/url_map_location.

If possible, I recommend to get the cascade running with HTTP first, then add HTTPS in a second step. I managed to get the cascade running with HTTP with the three files as described.

To get x.509 client certificates transported from the browser all the way to the back-end is quite tricky. I will look into this in the coming days.

[Former Member]

Hi Tobias,

I tried your suggestion and still same result....I have a message opened with SAP as well and provided logs, traces, etc.

I have requested http access, I can try that once they approve and open ports.

[Former Member]

I got it to work from the browser......still reviewing that destination error and yet to test from vendor site with actual message posting. Now to surround this configuration with uri mapping, acl, and
authentication...

So the extra parameters added were those under ssl reencryption - i had those parameters in my other profile with an attempt to bypass internal webdisp (as an alternate option). so kind of combined both profiles...