EP: Sessions Part 2 (RFC, GUI, HTTP Plugin) Common Ground & Issues
Background: From my perspective one of the most commonly encountered Enterprise Portal issues seems to be that which involve session management. Now the term “session management” covers a wide range of different angles across a wide spectrum. Session management issues can involve the retention of Portal sessions, a faulty logoff mechanism or inadequate browser cookie handling.
Overview: From a high level perspective any session management issue that we may encounter, follows the underlying concept depicted in the image below.
Some Common Issues (Across Multiple Scenarios):
- Session Retention – User A logs out and User B is presented with User A’s session upon logging in.
- RFC sessions are not terminated in the back-end even after the logoff is called within the Portal.
- The browser session does not get terminated when the user clicks “logoff” in the Portal.
- The application does not invalid the existing, authenticated session on the server upon user logout.
- Cookies may appear to get “cleaned” but when the user returns to the logon page the previous application session is still active.
Important Point To Remember:
When session expires or logoff is invoked or browser is closed, no matter what, the connection is not terminated but returned to the pool and kept open as defined in the Connection Lifetime property. In short, the connection stays open for the predefined amount of time by design and this is not an unexpected behavior. It remains in the pool, it is no longer used by another service e.g. the UWL and it is available for other clients.
How To Analyze a session issue:
Now taking what I have written above into account we know that the connection itself is not terminated but rather returned to the connection pool (The connection lifetime pool can be reset to a different value). So if you encounter a session issue the first thing to check is SM04 (transaction)
- When you use transaction SM04 to check sessions what are you seeing? In many cases when the portal is closed (via logoff) a reference is stored. From using the SM04 transaction it may appear that the sessions remain open but infact they will only be references. But you are seeing the transaction field remain filled?
- Are you closing the browser after user logoff? When a user logs off from your company Portal by choosing the Log Off button, a logoff action should be triggered on the SAP Portal Side (Portal & Connected back-end systems). Although the SAP Netweaver Portal comes with an out-of-the-box mechanism that terminates a session when the user closes the browser or navigates out of the SAP iFrame the mechanism itself does not handle logoff. Instead your company Portal must raise the terminating event when logging off from the SAP Portal.
Session Release Agent (SRA) & Distributed Session Manager (DSM) Terminator
When executing the ITS services that access a component system (R/3) in the portal, there is the question how to close the sessions in the component system when the user closes the browser (the HTTP protocol is considered to be stateless). When the user closes the browser window or navigates to another position, the browser sends a mass request to a dedicated portal component to end one or more open sessions (by default DSM.Terminator). This component distributes the corresponding termination commands to the component systems. The Termination command then closes the server session.
To close the sessions, a small additional window is generated in the browser outside the visible screen area. This window is automatically closed after two seconds if the Transmission command has been processed. Since ITS-based services cannot be used directly in session management, the Automatic Server Session Termination works with a wrapper technique. A main page consists of:
- An iFrame that displays the content coming from the ITS
- A special script called the Distributed Session Manager (DSM) that is responsible for handling the session management on the page
Each content page (page generated by the ITS) includes JavaScript code that is processed in the browser once the browser has loaded the page. This script creates a new JavaScript object called SessInfo with a unique identification of the ITS session and the callback URL to which the SISP command is returned. Once the content page has been loaded into the iFrame, the SessInfo object is transferred from the content page to the main page and is captured there by the Distributed Session Manager (DSM). The DSM stores the SessInfo object in its own storage. When the user leaves the browser, navigates to another page, or uses the Back button, the DSM is activated (by receiving the browser event onunload). The DSM then sends termination commands to all registered callback URLs, resulting in a termination of the ITS session on the server.
Logging On/Off
As stated above your company Portal must raise the terminating event when logging off from the SAP Portal. To setup such a configuration the following appendix can be followed, referenced or used as guidance.
Appendix: JavaScript Code for Session Termination:
https://help.sap.com/saphelp_nw73/helpdata/en/19/667bae77684887bea80129800fd701/content.htm
Now the appendix outlined above deals with the actual “Logoff” command button option. Here we can find an overview on logging both on/off into Portal sessions and also some information on factors that prevent session termination via the browsers “X” option.
Logging ON/OFF The Portal
http://help.sap.com/saphelp_nw73/helpdata/en/48/f1494c7092404de10000000a42189b/content.htm
Logging ON/OFF The Portal (ii)
https://help.sap.com/saphelp_nw73/helpdata/en/48/bebd8e8697307ce10000000a42189b/content.htm
In the logoff section outlined in the first link above we see the following “Do not simply close your browser. Closing the browser leaves your portal session still working, until it times out. When working in a browser that supports multiple tabs, such as Internet Explorer 7 or Mozilla Firefox, if you close a tab in which a portal is running, the portal session is saved. If you then open the portal in a new tab, you are already logged on and need to first log off if you wish to log on with different credentials.”
In my next blog posting in this series I will outline the full set of relevant solution documentation for session issues & the Enterprise Portal.
Note: This blog posting is part 2/3 in a series involving Portal sessions, Checkout the first part below:
Part 3 coming soon…..
Thanks Troy - excellent!
Cheers - Jeff
Hey Jeff
No problem at all hope it provides you with some guidance, any issues let me know 🙂
All the best
Troy
Hi Troy,
I chance upon this blog of yours as we are having the issue with our SAp portal of using ESS which launches into another IE Window. In our QA, when the new IE window is opened,
However, when I do the same in our Prod, upon closing of the browser, the entry in SM04 stays and so is the lock in SM12. The wendynpro app is the same in Q and P. The difference is in P we use a message server that is different for our app servers and we have multiple app servers. In Q, our message server and app server are in the same server. Doing an httpwatch trace shows that .DSMTerminator is executed but in P, it goes to the message server which then redirects to the app server. Would you know if there is anything to be set up when you are using multiple app server so that session management works properly in the backend?
I was looking for your part 3 hoping to see something there but could not find part 3 of your blog. Is it already available or still in the process of writing it?
Thanks
Shirley
Hi Shirley, for proper http session management in a multi app server scenario you will need a sap web dispatcher. The SWD as a single entrypoint for http requests does the load distribution and forwards a request related to an open session to the appropriate server.
Regards, Lutz
Hi Lutz,
Thank you for your response. I forgot to mention that we execute the ESS transaction via SAP Enterprise portal which then does an RFC logon(HTTP and PLUG IN) to the ECC system(that shows up in SM04 of ECC) via Single Sign On. I have played around with the HTTP security session management set up in the portal and the backend but no effect. GIven the above, is your reco of a SWD still needed? I was jut wondering given that for our T&E in Prod that is also access via the portal, it is working fine. And as mentioned in QA, the ESS is working fine as well (proper session management works).
Also, we use other things in the portal that connects to the backend and when the logoff in the portal happens or when to navigate to another, the logoff from the backend happens immediately. It seems to be the ESS is the only one that has the problem and only in Prod.
Kind Regards,
Shirley
Hi Shirley
I hope you are keeping well. I've just been reading back over your description and if my understanding is correct this issue that you are encountering relates to the following:
Ok firstly would you be able to provide me with a snippet of the SM12 screen to show me what you are seeing?
I've come across some ESS Scenarios in which session management was not operating correctly and in some cases this was resolved via:
From our perspective there was a recent issue in this area please see and test test 1644347 to see if you get a re-occurance during normal operations - i.e user goes into ESS and edits data then logs off but session remains
Now as per your observations you mentioned you can see the DSM/Terminator requests which means in true essence session management should be working perfectly.
Also you can find part 3 here sometimes the blog content searches is not the easiest to follow 😆
http://scn.sap.com/community/enterprise-portal/blog/2015/08/17/ep-sessions-part-3-frequent-issues-solutions
Kindly update me as per your findings.
Cheers
Troy
Hi Troy,
Thank you very much for your detailed explanation and for
pointing me to the OSS Note and the Part 3 blog of yours. The OSS Note is
not applicable to us based on our version. We are also using Webdynpro
ABAP. I looked further closely at the http trace and this is what is
happening. When I execute the ESS in the SAP Enterprise Portal, it logs
into the ECC backend using the message server (since that is what is defined in
the System Landscape connection for ITS And Web AS Host Names). The message
server then redirects the session to one of the multiple applications servers
(example, the session gets created in server 1). When I close the ESS
browser, Portal again sends a session command of USR_ABORT which is correct to
the message server. The message server again redirects that session
termination command to one of the application servers (server 2). It
does not remember that the previous session it opened was in server 1.
Since there is no session to terminate in server 2, nothing happened and session in
server 1
remains open. We are using the message server to handle the load
balancing so that we don't hit always 1 specific backend
server.
When I temporarily changed the ITS and Web AS Host Names in the System
Landscape config in the portal to a specific server, closing the "ESS
browser for personal info" releases locks in SM12 and removes the session
in SM04 and so we are not having any locks. However, the session for the
ESS Menu somehow stays in SM04 and looking at the http trace did not show any
DSM.terminator command. In our Q system which we only have 1 server,
everything is working fine and all 3 sessions created in the backend by going
to ESS goes away when you close the ESS browser and then logoff but in the Prod
environment(after I did a temporary change to the System Landscape not to use
the message server), only 1 session gets removed from SM04 and lock goes away
when you close the browser. Logging off does not remove the other 2 sessions in
SM04.
Do you know if there is any document about using load
balancing and SAP portal so that we can make sure that the session created when
the login to the backend server be the same server when the session is being
terminated. Lutz has indicated we needed Web dispatcher but is there any other way to avoid having to deploy a web dispatcher? If Web dispatcher is a must, is there any step by step guide link you know of that I can look at?
Thank you very much for your time.
SM12 lock
Kind regards,
Shirley
Hi Shirley
Many thanks for the response and not at all my pleasure 🙂 also apologies for the short delay in response.
Now as you mentioned at present you are using WD ABAP and your analysis findings indicate that the USR_ABORT is being sent accordingly to firstly the message server.
Based upon your analysis can you see an evident icf/logoff or USR_logoff in the setup? As you would have observed these scenarios can become quite complex in occurrence with all the different parameters and properties at play 😐 .
Ordinarily as we are dealing with WD ABAP as a core point of interest here the first steps are to review and cross-reference the fundamental setup and configuration.
Kindly take a look at the documentation below which provides a comprehensive overview:
Activating HTTP Security Session Management on AS ABAP
Portal logoff does not terminate the backend session and user2 can see the details of user1 on portal
HTTP Session Security Protection
Core Troubleshooting Notes:
- SAP Note: Note 1306533 - Web Dynpro session is not closed when you log off.
- SAP note 1717945 Enabling ABAP HTTP Security Session Management.
Lastly to shed some light on your query regarding the Portal and Load Balancing there is indeed some useful points of reference documentation which I have outlined below for your convenience and cross-referencing:
Load Balancing the Portal
Load Balancing the Portal - Technical Operations Manual for SAP NetWeaver - SAP Library
Clustering & Load Balancing EP
Clustering and Load Balancing the Portal Platform - Portal - SAP Library
Server Selection & Load Balancing EP (Web Disapatcher)
Server Selection and Load Balancing Using the SAP Web Dispatcher - SAP Web Dispatcher - SAP Library
Kindly update me as per your findings.
Cheers
Troy 🙂
Hi Troy,
Thank you very much for all the links and reference materials. the first check I did when the issue happened was the HTTP security session management on AS ABAP and they are both active in the portal and the backend system both for QA and Prod. The load balancing is happening on the Backend side(ECC) and not the portal(as we only have 1 portal server), where session gets created in 1 server ECC but when Portal sends a termination session request, the load balancing(handled by the message server) redirects the session termination to another ECC server without realizing that session was created in a different server.
Due to the upcoming holiday season and with other activities happening in the company and given that the issue is not very critical yet since the lock/RFC session goes away after the 30 minute timeout set up and ESS was just rolled out, we will be revisiting the issue in January and whether we will have to change our portal connection to just connect to 1 backend server or deploy a web dispatcher, unless you have other options that you can suggest apart from the 2 I mentioned. I will also continue to look at the reference materials/links you have provided come January.
Again, thank you so much for all your guidance on this matter and wishing you a happy holidays!
Kind regards,
Shirley