Introduction
We have all on different occasions encountering notification popups when utilizing the Enterprise Portal. These can vary from notification popups such as logoff prompts and Work Protect Modes or may highlight something more sinister i.e. error exceptions. If you encounter a Popup which you are not familiar with underlying the root source and meaning behind it before hitting the panic button is essential. On some occasions new system changes such as SP implementations or upgrades may cause different visual popups to come to the forefront and here we will address one of these.
Session Management will not work! Please check the DSM log file for details.
From an end users perspective utilizing the enterprise Portal is a straightforward process. We simply logon, fulfill our work obligations and logoff. As an end user we are only concerned with the graphical representation of the Portal that we are delivered with through our monitors representation and we are not truly troubled by what underlying functionality is taking place.
As we know the Enterprise Portal (EP) from a high level perspective can become quite a complex session environment for users over a time-period due to increased utilization of resources such as applications, data management provisions and documents. With each-user session enacted on the Portal comes a set of different connection requests which are handled by the Portal's session management mechanisms.
Why would such a popup occur?
This popup can arise as a direct result of different changes which may have subsequent effects on the domain. If a recent system copy, migration or upgrade has taken place this would in theory become the primary point of interest in the investigation. For the case of a working example let us imagine that you have completed a system copy which went through success however afterwards on each occasion that a User logs on to the Portal they encounter the full popup "Session Management will not work! Please check the DSM log file for details".
What do I need to check?
If a system copy has taken place you need to determine whether or not the Portal domain has changed as a result of this. Session Management itself does not work for different domains. For example if AI iViews are involved here we need to determine their source and where the message is coming from. 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 a 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 J2EE Engine uses hierarchical security policy domains and requesting an application or source (residing in a different domain or sub-domain) will require the user to re-authenticate.
- This would obviously create a new "security session" if we take the working example above.
From the perspective of the DSM Terminator which is the reference you are seeing. This is a special script called the Distributed Session Manager that is responsible for handling the session management on the page.
- SAP Managed Tags:
