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 and operates with
all supported browsers. (See Supported
Configurations for more information)
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