Support for Multiple Sessions
Concepts –
HTTP sessions and form sessions
Calling an
Ebase form from an external application
Calling an
external application from an Ebase form
Debugging
problems with form sessions
See also:
The Ebase
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 a form using the supplied functions getsessionvariable()
and setsessionvariable(), or from custom functions and custom resources implemented in
Java.
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 a form using the supplied functions getformsessionvariable()
and setformsessionvariable(), or from custom functions and custom resources implemented in
Java.
The form
session mechanism is implemented by adding an additional parameter esessionid
to all URLs. The Ebase 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 esessionid parameter. The esessionid consists of the http session
id plus an underscore plus a numeric form session id e.g. DF5023C82F8475CDC2909CF739B162AF_5;
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 esessionid parameter is
not present on the invoking URL. The esessionid
representing the form session can be preserved or passed on a URL by
calling com.ebasetech.ufs.utility.HttpUtil.encodeURL().
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 getformsessionvariable()
function 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. It
is not possible to return to the form after goto
url, therefore maintaining the esessionid
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 esessionid
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 esessionid
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