Distribution session management fails with Webdispatcher

[Vladimir73]

Hello,

We use Webdispatcher ver. 7.20 patch 321 for load balancing and SSL termination. Users login via the WebDispatcher into Enterprise Portal

ver. 7.30 and navigate to iViews, linked to PBF iViews in a CE 7.30 system. The back-end system for the iViews is BW 7.30.

There is a SSO configured between the BW, CE and EP systems. The CE system is defined in the EP System Landscape and under WAS ICM host we

have entered the Webdispatcher URL and port 8443. An URL rewriting rule on the Webdispatcher points to the SCS of the CE system, when port 8443

is used. The redirection works and all systems BW, CE and EP are defined in the Webdispatcher for load-balancing purposes.

The CE iViews create RFC connections to the BW system and table locks in SM12. If the EP users navigate away/log off/close browser the locks

stay until the session timeout. This causes major issues with users locking forms and unable to use the PBF solution. When the users login directly

into the CE system, the locking issue does not exist and the sessions are released properly.

When we change the ICM host in the CE system definition in the EP system landscape to point to the CE PAS URL:port, the locking issue does not

exist as well, but security warning appear as our SSL certificate is registered for the Webdispatcher's DNS hostname.

In OSS notes 1029194 and 1040325 SAP recommends using the SAP Webdispatcher for load-balancing and proper distributed session

management. The use of Webdispatcher causes the locking issues and hanging sessions in the CE and SM12 table locks in the BW system.

I have attached the Webdispatcher profile. Any ideas how to resolve the issue?

Regards,

Vladimir

WQ1_Webdispatcher_profile.txt.zip

[Vladimir73 · Accepted solution]

Hello,

Here is some additional information, I checked in the Portal under System Administration ->

Support -> App. Integration Tools - DSM Sessiosn.

I can see the different URLs (Log Off, Suspend, etc) for my session.

If I overwrite the portal URL with the Logoff URL from the DSM tool it logs off the CE sessions and

releases the BW locks. Why is this URL not loaded by the browser when using the Webdispatcher?

It should happen right after after the dms.terminator and before the LogOutComponent.

So far nothing useful from SAP and our PBF go-live is in jeopardy. The users are locking each other

Regards,

Vladimir

[Former Member · Accepted solution]

Can you share your Web Dispatcher configuration? Can you test with the latest patch level, 427?

[Vladimir73 · Accepted solution]

Hi Samuli,

The Webdispatcher configuration is zipped and attached to my first message. I have updated the Webdispatcher to the latest patch 427 and the issue still exist.

The OSS message with SAP has been re-assigned several times and is currently with the EP-PIN Session Release Agent support. According to SAP the Webdispatcher is working fine and they don't see issues with it's configuration. They suggested an OSS note related to the http Security Session Management (1717945), which we do not use as far as I know. We use SAP logon tickets, and this note does not explain why the use of Webdispatcher to access the CE system causes the locks.

I think there may be an issue with using the Webdispatcher, because it appears as a second reverse proxy in the sequence, e.g.

WD - EP - WD - CE - BW, instead of WD - EP - CE - BW, which may be causing issues with the saplb_ session cookies, containing the server node of the sessions. I am planning to test and set the server nodes to 1 for both EP and CE, to see if this will resolve the issue.

The HTTPWatch trace show that the dsm.terminator does not trigger the session logoff event, which could be due to the session information being on the wrong server node. However the information is available on the server node where the user session was created under System Administration - > Support -> Appl. Integration and Session Management -> DSM: MonitorStoreGroups. I can see the logoffURL, suspendURL, etc. If I copy the logoffURL of the session from there and paste it in the other browser window of the end user it closes the CE sessions and the BW table locks are released:

https://qaportal.domain.ca:8443/webdynpro/dispatcher/sap.com/pb/PageBuilder;jsessionid=IXLlQtULgW43E...

Regards,

Vladimir

[Former Member · Accepted solution]

Sorry, I missed the configuration. I don't see a problem with it, I do however recommend to use modification headers to route to the correct system instead of having static SRCURL definitions. Your landscape is according to SAP recommendations however there should also be a WD between CE and BW or are you using only RFCs between CE and BW? Another thing you can try is to use WD URLs all the way meaning there are no internal URLs anywhere in the landscape. Since you are terminating HTTPS in WD, that might also be a problem if there is a HTTP URL somewhere.

[Former Member · Accepted solution]

Another comment, you are not actually cascading WDs since you are using one WD. You will have cascading WDs only in case where you have defined another WD in a WD. The integration point, for a better lack of word, is the client. All accesses from the client go to WD and from WD to the backend systems (EP and CE). The fact that BW is connected to CE doesn't make any difference if only RFCs are used because the client is not directly connected to CE. That changes if HTTP(S) is used to access BW (for example WADs), then you should configure also BW as a backend system in WD and reference in CE accordingly.

[Former Member · Accepted solution]

And while you are at it, remove all redirects, rewrites, etc. just to rule out a problem with them.

[Vladimir73 · Accepted solution]

Hi Samuli,

We are using RFCs between the CE and BW, no http(s) is used to access BW. The sessions are not closed in the CE when using the Webdispatcher, that is why the BW locks/RFC sessions are not released. Your explanation about cascading the WDs makes sense, however somehow adding the Webdispatcher for accessing the CE causes the sessions issue.

I don't see how can we remove all redirects, rewrites and keep the same functionality.

SAP's response is basically to update all Portal/Java components to the latest patch level, however no specific note has been provided which addresses the issue. We are under a lot of pressure to resolve the issue ASAP. Thanks for your help.

Regards,

Vladimir

[Former Member · Accepted solution]

You need to remove the redirects and rewrites temporarily for troubleshooting purposes in order to find out the root cause of the problem. As I mentioned you should try to use only WD URLs and see if it makes a difference. If it doesn't then check using HTTPS all the way or HTTP if it's easier to setup.

[Vladimir73 · Accepted solution]

The issue is also happening in our DEV environment, where HTTP is used all the way. I am planning to test using only 1 server node on both CE and EP and removing the redirects and rewrites.

SAP think that the Webdispatcher is not causing the issue. The Session Release Agent (SRA) is behaving badly, and more specifically the Portal is not notifying the WebDynpro for the page unload. They don't know why it is happening when using the Webdispatcher to access the CE system.

From OSS Note 596698 the second steps is not happening:

How Session Release Agent works:

Session Release Agent (SRA) feature is used to notify content servers when the user leaves the application in the browser. This allows to release sessions and database locks related to the application as soon as possible. The Feature works in following steps:

1. The SRA receives and registeres the Session Data. This happens either in advance through SAP application launcher (yet before content is loaded) or by passing of script snippet in the content responses. The session data contains one of more "Notification URLs".

2. Portal observes the page/frame unload. When this happens the collected sessions are sends "Notification URLs" previously registered.

3. When the Content Server receives the "Notification URL", it takes corresponding actions to release allocated resources and locks.

Regards,

Vladimir

[Former Member · Accepted solution]

See if the problem occurs if you access CE directly through WD, without having the portal in between. If it doesn't, I would have to agree with SAP that WD is not to blame. What usage types do you have installed on the CE?

[Vladimir73 · Accepted solution]

The issue does not exist if I access the CE directly through the Webdispatcher, eliminating the Enterprise Portal completely and accessing the WebDynpro in the CE Portal Content. As soon I close the form's browser tab, the BW locks are released at the back-end.

The iViews in the Enterprise portal are links to the remote WebDynpro, located in the CE system. These are accessed via a system alias CE defined in the iView properties on the Enterprise portal. We do not have Enterprise Portal usage type in the CE system, only EP Core - Application Portal.

When we change the CE system properties in the Enterprise portal and set the ICM host to use the Webdispatcher we experience the issue. Accessing the CE system directly using the primary application instance works, but the users are getting mixed content browser warnings and we can not use load balancing since we bypass the Webdispatcher.

Unfortunately, setting the server nodes to just one node on both CE and EP systems did not resolve the issue.

Regards,

Vladimir

[Former Member · Accepted solution]

One more test: access the portal bypassing the WD meaning using the portals internal hostname. Does the issue occur then?

[Vladimir73 · Accepted solution]

Hi Samuli,

Your questions were very helpful, because they guided me to reach a solution. Basically, the issue was that once we use the web dispatcher to login to the portal, the CE system has to be in the same domain due to Java standard limitations (same origin policy). The web dispatcher alias used by the users is qaportal.domain.com (SSL certificate issued for this host name). The Portal and CE system host names are in the corp.domain.com domain. This creates issues with the SRA and causes the session issues.

I have tested with login via the WD (qaportal.domain.com) to the portal (paspq1-sap.corp.domain.com), then access the CE system (pascq1-sap.corp.domain.com) via the WD real host name in the same domain as the Portal and CE systems - wq1pq1-sap.corp.domain.com:8443. The WD redirect rule for *:8443 points to the SCS of the CE system. This works fine and all lock are released properly, however we have to ensure that the SSL certificate covers both qaportal.domain.com and wq1pq1-sap.corp.domain.com as the users get certificate mismatch error.

Thanks a lot for your help.

Regards,

Vladimir

[Former Member · Accepted solution]

That makes sense. Since you are already using WD for portal and CE you could just configure external aliases for portal and CE in domain.com and configure the landscape accordingly.

[Former Member]

See SAP note 1799709 on the Session Release Agent and DSM Terminator. Are you using ABAP HTTP Security Sessions? In case you are, see if SAP note 1717945 is relevant to you.

http://service.sap.com/sap/support/notes/1799709

http://service.sap.com/sap/support/notes/1717945

[Vladimir73]

Hello,

I analyzed the HTTPWatch traces in two cases - using the WebDispatcher to access the back-end CE portal and using the CE PAS instance. Per note 1660720 - Session remains open after the logoff on enterprise portal, it does look like when using the Webdispatcher the navigation/logoff/browser close event is not passed to the CE back-end portal. I can see passing of the event if using the PAS instance to access the CE system from the Enterprise Portal:

https://qaportal.domain.ca/irj/servlet/prt/portal/prtroot/com.sap.portal.dsm.Terminator

http://pascq1-sap.corp.domain.ca:51100/webdynpro/dispatcher/sap.com/pb/PageBuilder;jsessionid=SbWkYe...

https://qaportal.domain.ca/irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.masthead.LogOutC...

The second URL passing the USR_LOGOFF event is missing when using the Webdispatcher to access the CE system.

I have an OSS message opened with SAP, but if anyone has any idea how to resolve this issue, please let me know.

Regards,

Vladimir