HTML toolkit applications typically run in a session environment. Each session (a channel session) is a memory area on the server side that can persist from one request to another. For an HTML client, which might not be able to store data on the client side, the concept of session is particularly useful. See Session management for details of sessions and how to use them. Only session information specific to the HTML Channel is included here.
The toolkit saves a reference to the session object that currently manages a session in the application session table. The session object is an HttpSession object actually. See Session management for more information.
Once an application session exists, the toolkit links any requests from a processor running in an application session to that application session. If the application has created a subsession (keep in mind that subsessions are optional and used in some cases only), then the toolkit links any requests from a processor running in an application subsession to that application subsession.
To do this, the toolkit uses hidden fields, which every JSP must have, that contain internal toolkit information. Two of these hidden fields identify the session and subsession (if any) in which the toolkit must execute the application request, as in the following example:
For information on how to add these fields, see Populating the response page with the required fields.
The toolkit can run a subprocessor from a flow processor linked to an application session, as follows:
1 Flow Processor 1 is the main flow running under a session.
2 Flow Processor 1 invokes Flow Processor 2 as a subflow.
3 Flow Processor 2 creates an application subsession and chains itself to it.
4 Flow Processor 2 runs under the application subsession and finishes.
5 The toolkit is able to find and load the parent processor using the following two attributes in the DSEHtmlProcessor class:
▪ protected String parentSessionId = null;
▪ protected String parentAppSessionId = null;
These attributes enable the toolkit to find the parent processor once the child processor finishes execution.
To persist these two attributes when the processor is stored, the com.ibm.btt.automaton.html.HtmlProcessorInfo (which encapsulates processor information when a page is displayed) also has these attributes.
To enable a flow processor to change its linking dynamically, the flow processor updates the appSession attribute of the DSEHtmlProcessorOperation when it finishes execution because of reaching a page, a subflow state, or a final state. This allows the toolkit to be aware of the change in linking.
Within an application, an operation or an action (within a flow processor) creates an application subsession and its associated context and links it to the session context. A new operation or flow processor must be chained to the application subsession by chaining the operation or processor context to the application session context.
When an application subsession expires, the toolkit should release all of the session's resources and information. For information on how to do this, see Handling application subsession timeout in the Client/Server connectivity documentation.