Skip to Content

Background: This final piece of my session blog series will outline in summary some of the most commonly reported session issues with the Enterprise Portal and also provide an overview on the resolution documentation and steps which exist to resolve such occurences.

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.

BLOG9 session.PNG

One user logs out, another logs in and its the same session what do we do?

Let us revert back to the points we discussed in the earlier blog postings and what we mentioned about sessions and how they are handled. Let us begin by reaffirming the point that when a session expires or a 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. The connection lifetime pool can be reset to a different value.

Initial Troubleshooting!

With any issue regarding sessions you should firstly try and simplify it. Beginning with a simple analysis approach i.e. check if the issue occurs for all users (various roles) and within all web browser platforms, is this a recent issue? Has something played a role in this issue arising?

Next..

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 remaining filled?

Note Fixes…Plentiful and effective.

Some of the most commonly reported session issues are resolved via the following notes:

  • SAP Note: 1903478 – Session remains open after the logoff on enterprise portal from enterprise portal.
  • SAP Note: 1660720 – Session remains open after the logoff on enterprise portal.
  • SAP Note: 1717945 – Portal Logoff Does Not Logoff the Backend When Using HTTP Session Management.

WIKI describes the SM04 transaction screen and the retention of RFC Connections

RFC Connections remain in SM04

http://wiki.scn.sap.com/wiki/display/ABAPConn/RFC+Connections+remain+in+SM04

SM04 viewing, does it indicate more than a reference? Is the session incorrectly kept open?

  • SAP Note: 1261669 – RFC connections are not closed
  • SAP Note: 1322944 – ABAP: HTTP security session management

Backend sessions are the culprit

http://scn.sap.com/docs/DOC-55337

Remember

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 and connected back-end systems). Although 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 does not handle logoff. Instead, your company portal must raise the terminating event when logging off from the SAP portal.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Ruth Jones

    Very helpful.  My situation is a little different,  A frontend .net portal, with link to Enterprise Portal (using SSO via a Siteminder agent), and a interop framework page (meaning no EP headings, to a backend webdynpro URL (SCM system). 

    The SAP EP does not show, but its java accepted the Siteminder login, and created the MYSAPOSS2 cookie for the backend  SCM system.  This is all displayed within an iframe of the .net portal.

    Users log off the .net portal, and are getting logged out of web dynpro system, but left in EP.  A different user logs back in to .net, and does get EP / SNC of first user.

    I think you are saying the .net log off needs to log them off the SAP portal as well.  Would that be via the java script your second article linked to.

    (0) 
    1. Troy Cronin Post author

      Hi Ruth

      I hope you are keeping well and many thanks for the posting 😎 .

      In relation to the scenario and the description that you provided you mentioned the following:

      Q: A frontend .net portal, with link to Enterprise Portal (using SSO via a Siteminder agent), and a interop framework page (meaning no EP headings, to a backend webdynpro URL (SCM system). The SAP EP does not show, but its java accepted the Siteminder login, and created the MYSAPOSS2 cookie for the backend  SCM system.  This is all displayed within an iframe of the .net portal.

      Now regarding the description you provided the first point to highlight here is the utilization of Siteminder within the setup itself. Siteminder is not a SAP delivered software therefore we cannot offer consultation guidance or troubleshooting recommendations here. In terms of a concrete solution regarding Siteminder I cannot provide this as we are dealing with a third party. However what I can tell you is that the modification of the SAP HTTP request by a third party provided software is not under our support spectrum and therefore we cannot recognize this issue regarding the URL encoding as a bug. From reviewing your scenario it looks like a third party product configuration.

      As the modification of the SAP HTTP request is not occurring this would describe why the EP is not displaying and shown.

      Secondly you mentioned:

      1. Users log off the .net portal, and are getting logged out of web dynpro system.
      2. But left in EP.
      3. A different user logs back in to .net, and gets the EP / SNC of first user.

      This description is a classic occurrence and one which SAP Note: 1717945 – Portal Logoff Does Not Logoff the Backend When Using HTTP Security Session Management deals with.

      Alternatively as you have obsered this “Javascript” can be used as a means of triggering the closure of an SAP session when a user logs off the company portal.


      So once configured correctly the following behavior should be achieved.


      1. User A login, performs some actions and logs out.
      2. The session terminates.
      3. User B login, and is presented with a clean session (no prior user data).

      Let me know how you get on.

      Talk Soon 🙂

      Kind Regards

      Troy

      (0) 
  2. Karthik S

    Hi Troy,

    The information is very useful.

    We are having a issue like portal sessions remains active after closing the browser without logging off the portal.

    We know that recommended way of closing the portal is log off. From client perspective, they don’t care about this logic. They simply close the browser. After some time,if they try to run the same portal URL, they easily get into the portal because of the active portal session.

    Our requirement is to kill the session after closing the browser. So that user will be restricted if he  try to run the same URL again.

    (0) 
    1. Troy Cronin Post author

      Hey Karthik

      Thanks for checking out the blog and I’m glad that you found it informative and useful 🙂 .

      Q:

      You have a Portal session issue remaining after closing the browser without logging off.

      A:

      Now firstly as you highlighted as you are aware the recommended procedure is to “click logoff” and then subsequently “close the browser” this is indeed the proper means of closing a session.

      Such an occurrence is similar to that resolved in SAP Note: 1599643 although the behavioral symptom is not the same the underlying root cause is. In your case you logon to the Portal, perform activity and then close the browser so there is no direct “CLOSE” session or “TERMINATE” session command sent.

      Now as per your business requirements simply closing the browser is the preferred means of ending the session and this is indeed a common preference.

      What I will say here is that when you are closing an application window or the entire browser window session termination notifications to the backend are sent via a hidden popup window. Therefore the first point of analysis is to ensure that either popup blockers are deactivated, or that the portal URL is added to the whitelist of allowed sites for popups. For more information, please refer to Note 1331353 ‘Session Release Agent

      Pop-Up Blockers.

      Kindly let me know how you get on.

      Cheers

      Troy Cronin – Enterprise Portal Support Engineer

      (0) 
      1. Karthik S

        Hi Troy,

        Thanks for your information.

        I have checked in my IE browser. This is the default browser we are using in Citrix desktop. The popup blocker is activated in our IE browser. And there is no URL added in “allowed sites” field in pop up.

        From your suggestion, I have tested the portal by deactivating the pop up blocker. And also I added the portal URL in the allowed sites field.

        But still I am facing the same issue.

        (0) 

Leave a Reply