Session Management 
Business applications use a stateful protocol with a dedicated client (GUI). This allows server sessions to be terminated correctly and all server resources (for example, memory) are released when the client closes the session, for example, by logging off from the Portal.
If an application runs on the Web, the connectionless HTTP protocol works in request/response cycles and does not check if the client has already terminated the session. In this scenario the server sessions and resources of the business application are usually released after a predefined timeout (about 5-10 minutes). This delay can cause the following situations:
· Servers can become overloaded and run out of resources by sessions that have already been terminated.
· Locks for the application are held until timeout. In some cases an application can be deadlocked even if there are many servers available.
The SAP Internet Session Protocol (SISP) included in the SAP Workplace 2.10 overcomes this problem.
How does Session Management Work?
For the explanation we consider a service based on the Internet Transaction Server (ITS). The service is started with a LaunchURL containing the ITS location, name of the service and a set of parameters (user, password, language and so on).
Example:
http://pgwp211a.wdf.sap-ag.de:1080/scripts/wgate/webgui/ !?~transaction=sm04&sapwp_active=1&~client=050&~login=wpdev&~ language=de&~passwd=blue
When we enter the LaunchURL directly on the client, the content page, that is generated by the ITS, is displayed. Because of the stateless connection, the responsible ITS is not informed whether the running ITS session is still valid or should be terminated. That is not a reliable session management. If the user closes the browser, navigates to another location or chooses the Back button in the browser, the ITS session is kept alive on the server until the predefined timeout occurs.
To overcome this problem, a main page is created that consists of an IFrame (displaying the content from the ITS) and a special JavaScript object called Distributed Session Manager (DSM). The DSM is responsible for session management handling in the page. Every content page includes a JavaScript code that is processed on the client after the page has been loaded. This JavaScript code creates a new JavaScript object called SessInfo with the unique identification of the ITS session SessInfo.GUSID and the callback URL SessInfo.SessURL. The callback URL is the address where the SISP commands will be sent to. See chapter SessInfo Object Properties for more details.
After the content page in the IFrame has been loaded, the SessInfo object is transferred from the content page to the main page and is saved by the DSM. If the user exits the browser, navigates to another location or chooses the Back button, the DSM is activated by receiving the browser event onunload. DSM sends the termination commands to all registered callback URLs and terminates the ITS sessions on the server.
Following restrictions apply:
· JavaScript origin policy
The SessInfo object and script can only be transfer over IFrameborders, if both pages (main page and content page) use the same document domain. The main page comes from the Enterprise Portal server, for example, http://epserver.mycomp.com, and the content page comes from the ITS server, for example, http://itsserver.mycomp.com. Both domains must be aligned to the same denominator, such as mycomp.com, to allow scripting. See JavaScript Origin Policy for more details.
· Browser event onunload
The transmission of a termination command from the DSM back to the ITS server must be triggered by a client event. If the DSM simply registers the onunload event and tries to send one or more HTTP requests from the JavaScript, there is no guarantee that all requests are transmitted. If the connection is slow, the browser can be terminated before all requests have been sent.
The browser event onbeforeunload solves this problem, but only the Microsoft Internet Explorer supports this event.
A browser independent solution is, to send the termination commands from a Java applet. Received SessInfo objects are collected directly by the applet and the termination commands are sent to the servers in the destroy()method of the applet. The applet runs in its own JVM and the destroy()method of the applet is executed independently of the browser JVM, so the applet is still executed, even if the browser is already terminated.
When the browser has no Java support, the commands can be sent from the External Window.
· Applet origin policy
A termination command is HTTP request from the client to the ITS. Since the applet can only connect to the server from which it is loaded, you must have the same applet on every ITS. To overcome this problem the applet code should be loaded from the Workplace Middleware Server. Instead of sending the termination commands from the DSM directly to the ITS, the commands are sent to the dedicated Portal component Terminator. The Terminator component finally distributes the commands to the ITS.
Components
Server: ITS server/ ITS services
No modifications are necessary for the ITS; the customer can use the existing ITS transactions in Workplace 2.10/Workplace 2.11 and integrate them into the new Portal by customizing the Launcher component
Server: Workplace server components/services
EPCM Object (Portal service)
The EPCM object is involved in the page assembly process. It generates page stubs into predefined page locations. It is responsible to place DSM interfaces, DSM applets and the EPCF infrastructure into the header and body of the page.
Launcher (Portal component)
The Launcher includes an IFrame, with the size of 100% by 100%, on the Portal page with the LaunchURL.
Terminator (Portal component)
The Terminator is invisible. It receives a list of termination commands from the client and sends them back to the ITS. Every page assembled by the EPCM Service includes one URL of the Terminator component as the parameter of the applet. See also chapter Terminator Component for more details.
DSM (Portal component)
The DSM is used for testing. If this component is included in the same page as the Launcher, the processed SessInfo object can be displayed easily and terminated manually.
Client: Scripts & Applet
DSM Interface
The DSM interface is JavaScript code that is fully integrated into the Workplace Client Manager EPCM and therefore automatically included in every Portal page generated by the EPCM Object. It provides methods to communicate with the DSM Applet and a definition of the function SAPWP_receiveSessInfo(), which collects the SessInfo objects coming from the content IFrame. See chapter DSM Interface for more details.
DSM Applet
The DSM applet is integrated with the applet com.sap.portal.epcf.EPCMfactory. It implements the saving of the SessInfo object in a hash table and a communication channel to the server using Client Data Channel. The methods can be accessed using the DSM Interface.
SISP Code generated by the ITS in the content page
The ITS server generates JavaScript code to create the SessInfo object and transfers it to the main page.
External Window
The External Window is an additional window to the regular Portal page that is used for browsers with no Java support.
Session Management Step by Step
Clients with Java Support
...
...
1. The EPCM Object includes the DSM Interface and DSM Applet in the Portal page.
2. The Launcher creates the LaunchURL for the ITS service and includes the IFrame in the Portal page. There is an instance of the Launcher in the Portal page for every IFrame that points to a different ITS service.
3. The page is processed in the browser. Every IFrame generated loads its contents from the ITS. The ITS returns the content page with the generated SISP Code as the response to LaunchURL. The SISP Code creates the SessInfo object and transfers it to the main page.
4. SessInfo objects are collected by the DSM Interface, transferred to the DSM Applet and stored in the applet.
5. If the user navigates to another location, closes the browser or chooses the Backbutton in the browser, the registered ITS sessions become invalid and must be terminated. The browser triggers the unload event and the DSM Applet starts to process its own destroy() method.
6. The destroy() method of the DSM Applet computes the URL to terminate the sessions on the ITS for every SessInfo object stored. All URLs are collected and placed into one single HTTP postrequest (parameter TermString) and sent to the Terminator component.
7. The Terminator component splits the TermString parameter from the HTTP request into single URLs and sends the URLs to the different ITS servers with a new URLConnection. The server sessions on the ITS are then terminated.
8. Every SessInfo object is reported by the EPCF to the DSM.
Clients without Java Support
...
...
1. The EPCM Object includes the DSM Interface on the Portal page. The event handler in the DSM Interface is attached to the onunload event.
2. The Launcher creates the LaunchURL for the ITS service and includes the IFrame into the Portal page. There is an instance of the Launcher in the Portal page for every IFrame that points to a different ITS service.
3. The page is processed in the browser. Every IFrame generated loads its contents from the ITS. The ITS returns the content page with the generated SISP Code as the response to the LaunchURL. The SISP Code creates the SessInfo object and transfers it to the main page.
4. SessInfo objects are collected by the DSM Interface and stored in a JavaScript array.
5. If the user navigates to another location, closes the browser or chooses the Backbutton in browser, the registered ITS sessions become invalid and must be terminated. The browser fires the unload event.
6. The onunload event handler creates an External Window, in addition to the existing Portal page, with the URL of the Terminator component. The browser sends a HTTP get request (parameter TermString) to the Terminator. After the request has been sent the External Window can be closed automatically using the JavaScript timeout function.
7. The Terminator component splits the TermString parameter from the HTTP request into single URLs and sends the URLs to the different ITS servers with a new URLConnection. This terminates the server sessions on the ITS.
8. Every SessInfo object is reported by the EPCF to DSM.
Scripts
Here are some scripts that are used for the session management. The different examples refer to the steps, for example Step 1, shown in the previous chapter Session Management Step by Step.
Client scripts
DSM Interface (Step 1)
<SCRIPT src= "/irj/portalapps/com.sap.portal.epcf.loader/script/standard/js13_epcf.js"> </SCRIPT>
<SCRIPT>
<!--
EPCM.init( 2, 2, '8a50298ad8156b33d0445ae7e4f9062e', 1, 5.5, 1 );
EPCM.DSM.init("http://p45462.wdf.sap-ag.de:8080/irj/servlet/prt/portal/prtroot/DSMTerminator.default"); function SAPWP_receiveSessInfo( sessInfo, frameRef ){
EPCM.DSM.processSession( sessInfo );
EPCM.DSM.notifyMonitor( sessInfo );
}
//-->
</SCRIPT>
DSM Applet as the Part of EPCM Object (Step 1)
<APPLET CODEBASE="/irj/services/epcfloader/applet"
CODE="com.sap.portal.epcf.EPCMfactory"
ID="_EPCMfactory_"
NAME="_EPCMfactory_"
STYLE="POSITION: absolute;"
WIDTH="0"
HEIGHT="0"
MAYSCRIPT>
<PARAM name="trace.level" value="2">
<PARAM name="DSM.serverUrl" value="http://p45462.wdf.sap-ag.de:8080/irj/servlet/prt/portal/prtroot/DSMTerminator.default">
<PARAM name="DSM.scope" value="8a50298ad8156b33d0445ae7e4f9062e">
</APPLET>
IFrame with Content (Step 2)
<IFRAME width="100%"height="100%"border="0"
src="http://pgtlsp4c.wdf.sap-g.de:1080/scripts/wgate/fielddump/!?
~client=001&~language=EN&
~logingroup=SPACE&sapwp_active=1&
~login=p80000001&passwd=welcome">
</IFRAME>
Function SAPWP_receiveSessInfo is the entry point for every SessInfo Object. The SessInfo object is transferred to the DSM Applet using the method EPCM.DSM.registerSession() from the DSM Interface. The applet parameter DSM.serverUrl specifies the URL of the Terminator component. The collected termination commands will be sent to this URL (Step 6).
SISP Code Example Generated by the ITS (Step 3)
<SCRIPT>
// ----------------------------------------------------------------------------
function SAPWF_sendSessInfo( cltSessInfo ) {
var lsDomain = "";
var liBehindFirstDot = location.hostname.indexOf( "." ) + 1;
if (liBehindFirstDot > 0) {
document.domain = location.hostname.substr( liBehindFirstDot );
}
var loCF = window; // current frame
var loPF = (loCF.opener != null)? loCF.opener: loCF.parent; // parent frame
while (loCF != loPF) { // while top frame not reached
if ("object" == typeof( loPF.document ) ) { // is parent frame scriptable?
if (loPF.SAPWP_receiveSessInfo != null) {
// workplace frame found, deliver sessinfo
loPF.SAPWP_receiveSessInfo( cltSessInfo, loCF );
return true;
} else {
// try upper frame
loCF = loPF;
loPF = (loPF.opener != null)? loPF.opener: loPF.parent;
}
} else {
// access to foreign frame denied, stop here
return false;
}
}
// top frame reached, but no workplace frame found
return false;
}
function SAPCLT_SessInfo() {
var prot = ( "off" == "on" ? "https://" : "http://" ) ;
this.protocolVersion = "1.0";
this.sessUrl = prot + "pgtlsp4c.wdf.sap-ag.de:1080" + "/scripts/wgate" + "/" + "fielddump" + "/?~session="+"QW2-A:pgwdf062:0000.0040.afa108fd";
this.GUSID = "QW2-A:pgwdf062:0000.0040.afa108fd";
this.lastSessCmd = "USR_OPEN";
this.redirectURL = "";
this.dTimeout = "120";
}
SAPWF_sendSessInfo( new SAPCLT_SessInfo());
</SCRIPT>
Testing the Session Management
The Portal has two components to test the session management:
· DSM TestLaunch.
Creates the docking IFrame for the ITS response.
· DSM Monitor
Allows you to check the Public API functionality and displays the SessInfo object list and other information.
Both components must be included on the same Portal page for the test. The DSMTestLaunch component properties must be configured to start an ITS service. As already shown in the chapter Session Management Step by Step the transfer of the SessInfo objects is processed in several steps. The DSM component can test Step 4, Step 5 and Step 6 even if the ITS is not available. The DSM component can be started in single component mode with the following URL:
<Portal_URL>/irj/
servlet/prt/portal/prtroot/com.sap.portal.dsm.Monitor
The test results of the session termination are displayed on the Java console of the browser (browsers with Java support) or on the External Window after the resize of the window is done (browsers with no Java support).
Test 1: DSM Displays SessInfo Objects
If the session management works correctly, all received SessInfo objects are displayed in the DSM and you can display all properties of the SessInfo objects. If there are no SessInfo objects displayed in the DSM following problems are possible:
...
1. ITS did not include the SISP coding stub into the response
Check if the service parameter SAPWP_ACTIVE is set in ITS. You can add to the LaunchURL following string: SAPWP_ACTIVE=1
2. The ITS server and Workplace server use different domains
The typical local test installations at SAP do not have a specific IP address. The Workplace Server can be accessed using localhost instead of a specific server name or IP address (for example, http://localhost:8080/irj/servlet/prt/portal) and the ITS server uses a server name like itsserver.wdf.sap-ag.de. This does not comply with the JavaScript origin policy and therefore the DSM can not display a SessInfo object.
To solve this problem, use a specific IP-address for the computer or define a synonym in the hostsfile of the computer (for example, Windows NT keeps that file at location C:\WINNT\system32\drivers\etc\hosts). The entries for the synonym look like that:
127.0.0.1 localhost
127.0.0.1 myhost.wdf.sap-ag.de
Now you can access your Portal runtime from your computer locally using the address:
http://myhost.mycomp.com/irj/servlet/prt/portal
The name myhost.wdf.sap-ag.de is only known on your local computer and can not be accessed from another computer.
Test 2: DSM Interface to DSMTerminator Component Connection
SessInfoobjects will be processed during the page unload event. The termination command is sent by the Java applet to DSMTerminator component. The transfer protocol can be displayed on the Java console of your browser. The Java console of the MS Internet Explorer can be enabled as follows:
Tools ® Internet Options ® Advanced ® Microsoft VM
If there is an error message in the Java console, you should first check if the proxy settings http.proxyHost, http.proxyPort and http.nonProxyHosts in your servlet environment are correct.
Test 3: Destroying of ITS Sessions
Every SessInfo object represents a session on the ITS. You can directly start the R/3 system to which the ITS server is connected and check with the transaction SU04 which sessions have been destroyed during the page unloadevent.