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
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.
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.
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