Support for Multiple Sessions
Concepts
– HTTP sessions and form sessions
Calling
a Verj.io form from an external application
Calling
an external application from a Verj.io form
Debugging
problems with form sessions
The Verj.io 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 Verj.io forms in each one. This support is not dependent on browser type.
This
document describes how the Verj.io multi-session support works and is designed
to be read by technical staff who need to include the
Verj.io system within the context of a larger system including, for example,
calling a Verj.io form from an external application, or calling external
applications from a Verj.io 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 Verj.io 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 Verj.io
system. Each HTTP session can contain any number of form sessions. The Verj.io
system maintains a form session context for each session. The Verj.io
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 Verj.io 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
Verj.io 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 a Verj.io
form from an external application
This
section addresses the question of how to pass in information to a Verj.io 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 Verj.io 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 a Verj.io form using the FPL getformsessionvariable() function or API client.formSession.getFormSessionAttribute() method as described earlier.
Calling an
external application from a Verj.io 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 Verj.io 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 Verj.io
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