Skip to Content
Author's profile photo Troy Cronin

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.


BLOG7 session.PNG

Some Common Issues (Across Multiple Scenarios):

  1. Session Retention – User A logs out and User B is presented with User A’s session upon logging in.
  2. RFC sessions are not terminated in the back-end even after the logoff is called within the Portal.
  3. The browser session does not get terminated when the user clicks “logoff” in the Portal.
  4. The application does not invalid the existing, authenticated session on the server upon user logout.
  5. 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)


  1. 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?
  2. 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:

http://scn.sap.com/community/enterprise-portal/blog/2015/07/24/ep-sessions-part-1-rfc-gui-http-plugin-a-brief-overview

Part 3 coming soon…..

Assigned Tags

      9 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jeff McDonald
      Jeff McDonald

      Thanks Troy - excellent!

      Cheers - Jeff

      Author's profile photo Troy Cronin
      Troy Cronin
      Blog Post Author

      Hey Jeff

      No problem at all hope it provides you with some guidance, any issues let me know 🙂

      All the best

      Troy

      Author's profile photo Shirley Te
      Shirley Te

      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,

      1. another entry in SM04 shows up as expected.
      2. When I close that browser, the said entry in SM04 goes away as expected and so is the lock created in SM12.  This means that the session management is working fine in the backend.

      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

      Author's profile photo Lutz Rottmann
      Lutz Rottmann

      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

      Author's profile photo Shirley Te
      Shirley Te

      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

      Author's profile photo Troy Cronin
      Troy Cronin
      Blog Post Author

      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:

      • You are using ESS through IE and the ESS Application opens up within a new browser window. SM04 and locking works as required once the browser is closed (QA Portal). But in your Production Setup when you close the browser SM04 retains the user session and you get locking in SM12.

      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:

      • SAP Note:1644347 - HttpClientSessionListener failed to destroy client session

      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

      Author's profile photo Shirley Te
      Shirley Te

      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

      SM12 Lock.JPG

      Kind regards,

      Shirley

      Author's profile photo Troy Cronin
      Troy Cronin
      Blog Post Author

      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.

      • The message server then redirects that session termination command to one of the application servers (server2).  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. You are using the message server to handle the load balancing so that we don't hit always 1 specific backend 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 🙂

      Author's profile photo Shirley Te
      Shirley Te

      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