Support for Multiple Sessions

 

Documentation home

 

Overview.. 1

Concepts – HTTP sessions and form sessions. 1

How is this implemented?. 2

Guidance for developers. 2

Calling an Ebase form from an external application. 2

Calling an external application from an Ebase form.. 3

Debugging problems with form sessions. 3

 

 

Overview

The Ebase Xi system provides support for multiple browser sessions for each end-user. This means that an end-user can open any number of browser windows and run different Ebase forms in each one.  This support is not dependent on browser type and operates with all supported browsers.  (See Supported Configurations for more information)

 

This document describes how the Ebase multi-session support works and is designed to be read by technical staff who need to include the Ebase system within the context of a larger system including, for example, calling an Ebase form from an external application, or calling external applications from an Ebase form.

 

Concepts – HTTP sessions and form sessions

A HTTP session represents a logical connection between a client browser and a web server. This connection is maintained by both client and server, and is normally terminated by the server after an inactivity timeout period has expired. When an end-user opens multiple browser windows, it is unfortunately not easy to predict whether or not a new HTTP session is created. This is particularly true for MS Internet Explorer, which may or may not create a new session depending on how the window is opened.

 

J2EE application servers maintain an HTTP session context, which provides the ability for applications to store session related data. The Ebase system makes use of this facility to store the following information at session level:

 

·         Sign on information (if applicable)

·         Information about the browser, e.g. browser type, JavaScript, cookies enabled etc

·         One or more form session contexts (see below)

 

Form developers can also store data in the HTTP session context and access this information from an FPL script using the supplied functions getsessionvariable() and setsessionvariable(). API based language scripts access these session variables by using the HttpSession object e.g. client.httpSession.setAttribute("ATTR1", attrValue). Both custom functions and custom resources also have access to HTTP session variables.

 

A form session represents a single browser window and is created by the Ebase system. Each HTTP session can contain any number of form sessions. The Ebase system maintains a form session context for each session. The Ebase system stores the following information in this context:

 

·         State information for the current form being executed (this will be a stack of forms when the call form FPL command is used)

·         The language of the current form

 

As with the HTTP session context, form developers can also store data in the form session context and access this information from an FPL script using the supplied functions getformsessionvariable() and setformsessionvariable(). API based language scripts access these form session variables via the Client and FormSession objects e.g. client.formSession.getFormSessionAttribute(), client.formSession.setFormSessionAttribute(). Both custom functions and custom resources also have access to form session variables.

 

How is this implemented?

The form session mechanism is implemented by adding an additional parameter ebz to all URLs. The Ebase Xi system uses this to route control to the appropriate context when a URL is received. A new form session is created each time a URL is processed that does not contain the ebz parameter.

 

Guidance for developers

Developers who would like to use these contexts to pass information in to or out of Ebase forms need to understand the distinction between an Http session and a form session as described above. In particular, that the Http session has a wider scope that may encompass the concurrent execution of several forms by a single user.

 

Calling an Ebase form from an external application

This section addresses the question of how to pass in information to an Ebase form from a calling application running in the same web application, e.g. a JSP, another servlet etc. This can of course be achieved just by adding parameters to the calling URL, but  can also be done by creating a new form session context and adding the information to this. An external application generates a new form session context by including itself within the scope of the Ebase HTTP filter as defined in the web.xml file. For example, the following illustrates the addition of the MyFrontEnd servlet:

 

<servlet>

   <servlet-name>MyFrontEnd</servlet-name>

   <servlet-class>MyFrontEnd</servlet-class>

</servlet>

<servlet-mapping>

  <servlet-name>MyFrontEnd</servlet-name>

  <url-pattern>/MyFrontEnd</url-pattern>

</servlet-mapping>

<filter-mapping>

  <filter-name>EbaseFilter</filter-name>

  <url-pattern>/MyFrontEnd</url-pattern>

</filter-mapping>

 

This will result in the generation of a new form session each time the servlet is called and the ebz parameter is not present on the invoking URL. The ebz parameter representing the form session can be preserved or passed on a URL by calling com.ebasetech.ufs.utility.HttpUtil.encodeURL(myUrl).

 

State information can then be added to the form session context as illustrated in the following example.

 

include com.ebasetech.ufs.kernel.EbaseFormSession;

EbaseFormSession formSession = EbaseFormSession.getFormSession(request);

formSession.setAttribute(“MyAttr”, “MyAttrValue”);

 

This state information can be extracted in an Ebase form using the FPL getformsessionvariable() function or API client.formSession.getFormSessionAttribute() method as described earlier.

 

Calling an external application from an Ebase form

An external application can be called by a form by using one of the FPL commands call url or goto url or corresponding API methods WebForm.callUrl() or WebForm.gotoUrl().  It is not possible to return to the form after goto url, therefore maintaining the ebz parameter representing the form session is not applicable. However, when call url is used, the external application will eventually return control to the calling form. At this point, a potential problem exists as the Ebase system needs to identify the correct form session to return to. The $UFS_RETURN_URL system variable contains the ebz parameter and, if possible, this should be passed to the called application and then used to return control to the calling Ebase form.  If return is made from a called application and the returning URL does not contain the ebz parameter, the system will return control to the most recently active form session.

 

(See FPL Script command syntax for more information)

 

Debugging problems with form sessions

Adding the following parameter to the java command used to start the application server will cause the system to log informational messages about the assignment and use of form sessions.

 

-DsessionDebug=true