An HTML client user enters into a dialog with the toolkit. This dialog consists of navigating through Web pages that are presented according to the business process that is being carried out. Business processes are expressed as toolkit Single Action EJB, BPEL, Operation Step or as state machines that follow the application's business logic.
The simplest dialog and navigation is to request static informational pages using HTML hyperlinks. Dialogs that require dynamically generated Web pages use more sophisticated navigational control. You have the following navigation options:
▪ HTML hyperlinks
▪ Simple toolkit operations with Single Action EJB
▪ Flow Processor processes
HTML hyperlinks support linking one HTML page to another. This is suitable for informational pages that do not need to be dynamically generated.
Simple toolkit operations with Single Action EJB are suitable for simple transactions that do not require the persistence of an intermediate state. For example, a transfer of funds between accounts could be done with a form request page that runs an operation, which in turn causes a confirmation page to be returned to the client. No dialog control is needed in this case. See Single action EJB.
When a process requires the submission of several form pages from the HTML client to gather the required data, a flow processor can be used to keep track of the state of the user's interaction with the toolkit. Each time the user interacts with the toolkit, the flow processor is called and, according to its current state, it invokes the process for creating the response page to send back to the client. As the user interacts with the toolkit, the flow processor changes states according to its definition. The user experiences this process as a navigation through a series of Web pages.
The toolkit provides an implementation of a specialized Automaton for supporting HTML client requests on the server. The specialized Automaton is a state machine that can handle multiple execution hits and reply to each hit according to a defined flow. It provides a flow processor (DSEHtmlProcessor) that controls navigation within the client by performing different actions depending what the user selects in a dialog. The navigation process represents each dialog as a state in the navigation process.
The DSEHtmlProcessor extends the DSEProcessor class and adds the following functionality to the generic flow processor:
▪ The HTML flow processor can be asynchronous in that it can delegate the responsibility of the flow outside the state machine. That is, the HTML flow processor can release control of the flow before it finishes. The toolkit stores the state of the processor so that it can re-establish the processor later. The generic flow processor is only synchronous.
▪ The HTML flow processor has two special kinds of state: page and subFlow. These states determine how the HTML flow processor handles events. When the processor reaches one of them, it releases control of the flow. The DSEHtmlProcessorOperation assumes control of the flow at that point. When the processor achieves one of these states, the only event that causes it to resume the flow is an external event.
When the HTML flow processor is in the page state, it resumes control of the flow when it receives an event from an HTML page containing a field in which the user has done something. The value for the field determines the name of the event (dse_nextEventName) raised by the page.
When the HTML flow processor is in the subFlow state, it raises a subflow running in a child processor. The processor resumes control of the flow when it receives an event from the child processor. The name of the event is the value of the typeIdInfo attribute of the final state of the child processor.
During a flow, the HTML flow processor enters the page and subflow states twice. The first time occurs before the processor releases control and the second time occurs when it resumes control. During the first state entry, the toolkit executes the entry actions without triggering the event listeners. During the second state change, the toolkit processes the event normally. Once the processor loses control, the toolkit stores relevant processor information such as the processor's context and then deletes the processor instance from memory. When it is time for the processor to regain control, the toolkit recovers the processor instance using the stored information. Before the toolkit stores the processor context, the toolkit unchains it from its parent, which is the session context. This means that the HTML flow processor's context must not have a defined parent.
▪ The HTML Channel uses the HTML Processor Manager to manage the instances of processors if the processors cache is enabled. In the cache, the HTML Processor Manager stores the processor instances. This feature is particularly useful for HTML flow processors because the toolkit frequently unloads and re-instantiates them when they reach one of their special states.
▪ Process Context is local context only.
The following two HTML flow processor examples are provided:
Each time the user interacts with the toolkit, the flow processor is called and, based on its current state, it invokes the process for creating the response page to send back to the client. As the user interacts with the toolkit, the flow processor changes states according to its definition. The user experiences this process as a navigation through a series of Web pages.
The navigation through the flow uses the dse_nextEventName parameter. This parameter represents the event to which the flow responds. It has two elements, the event name and the notifier. Usually an application needs to specify the name of the event (in some cases the toolkit can automatically build it) and does not need to specify the name of the notifier (because the system knows the current state of the processor). Note that the name of the event must be configured for every concrete action performed in a form. When a JSP tag is added for a button, a link, or a form, the event name is set by the JSP tag, but the attribute must be configured in the list of attributes for the tag.
Following is the sample code for Main process flow:
<htmlProcessor context="creditCardsCtx" id="creditCardsProc"> <htmlState id="initial" type="initial"> <transitions> <htmlTransition id="initial.start" targetState="creditCardsWellcome"/> </transitions> </htmlState> <htmlState id="creditCardsWellcome" type="page" context="selectCardsOpCtx" typeIdInfo="creditCardsWellcome.jsp"> <transitions> <htmlTransition context="creditCardsWellcome_history_Ctx" delegateValAssessment="true" id="creditCardsWellcome.history" targetState="creditCardsPage"/> </transitions> </htmlState> <!-- Operation state. The operation is executed by the specialized state. The operation is firing the exit events --> <operationState id="creditHistoryOpState" type="operation" typeIdInfo="creditHistoryOp"> <!-- refFormat name="inputMapFmt" value=""/--> <!-- refFormat name="outputMapFmt" value=""/--> <transitions> <transition id="creditHistoryOpState.accountExists" targetState="creditCardsPage"/> <transition id="creditHistoryOpState.newAccount" targetState="creditCardsPage"/> <transition id="creditHistoryOpState.error" targetState="finalNotOK"/> </transitions> </operationState>
The flow processor can transition to a state that is defined as an entry to a subflow that has its own separately defined flow processor. A subflow has its own context, which is isolated from the context of the parent flow. The toolkit allows you to define data mappers from the parent to the child context, thus enabling separate namespaces and the ability to reuse the subflows from different parent flows. When the navigation of this subflow is complete, the specified data mapper copies the reply data to the parent context and the control of the flow returns to the parent flow.
While in one navigation flow, it is possible to start another completely separate and independent flow. Flows that are running in parallel cannot share data. A user can start a parallel process by starting a secondary browser window using the same session already started in the first browser window.
When a processor finishes, the exit event name specified in the typeIdInfo attribute of the final state is passed to the parent processor to move the flow further on. However, if the processor has no parent, then it displays the final state page. This page can be the home page of the application, the home page of the session, or it can be the generic home page. The final page is determined by the following process:
1 When a processor finishes, it displays the HTML page defined in the finalPage attribute, which looks as follows:
2 If this attribute is not defined, the toolkit displays the HTML page defined in the finalStatePage setting in the HTMLClient section of the toolkit definition (btt.xml) file, which looks as follows:
HTML toolkit applications usually manage both the presentation and the business logic through HTML flow processors. The HTML flow processors are asynchronous processors, which means that their execution can stop before the processor has reached a final state. If this occurs, the execution can resume from the point where it was stopped. For example, when an HTML flow processor reaches a page state, its flow execution stops and the control passes to the HtmlRequestHandler. The HtmlRequestHandler passes the request to the HtmlPresentationHandler, which runs and displays the JSP. The toolkit must store information about the flow processor, because the user might send another request to the processor, expecting to find the processor in the same state as it was before the flow execution stopped.
To store the information needed to rebuild the processor, including the processor's context, the session context keeps a table of processors. The following is the toolkit information stored in the session context (the bold fields are storing the processors table and the contexts table):
The following diagram shows a context and its entry in the session table, as well as an HTML processor and context information:
The processor contexts remain unchained while the flow is on the user side. When the user sends a request to the HTML processor, the toolkit rebuilds the processor instance, attaches the processor context to it, and chains the processor context to the session context. Additionally, the toolkit removes the processor and context from the session context and does not store the HTML processor and context in the session context until the processor again reaches a page or subFlow state.
It can be very time-consuming and use a lot of resources to rebuild a processor that was stored without finishing its flow each time a user sends a request to the server. Each time the toolkit receives one of these requests, it instantiates the processor using the processor externalizer and then modifies the instance with the information stored in the session context to make this instance exactly the same as the processor that the user left, including the same state, attribute values, and context. The toolkit also instantiates the processor context when instantiating the processor with the processor externalizer. This becomes expensive in terms of performance if the context contains large amounts of data, and it is inefficient because the processor context is replaced by the one stored in the session context. The HTML processors cache helps relieve this situation by allowing the toolkit to use the cached processor instead of rebuilding it. Note that the cache is only available for the session. For example, if the flow processor named myProc is in use by user1, it will exist in the cache while this user is navigating. If user2 runs a new instance of myProc, the toolkit creates a new entry in the cache for myProc instead of using the existing one.
As long as the cache is enabled (See Configuring the HTML Channel), the toolkit stores the flow processor instances in the cache whenever a page is displayed, and deletes the processor instances from cache when they are recovered by the user. When the processor attains its final state, the toolkit does not store it in the cache. Processors that do not reach a final state are kept in cache and the application must clean up these instances. For example, each time a page is displayed for user1, the toolkit stores myProc in the cache, and each time user1 sends a request from the browser, the toolkit restores the instance of myProc from the cache and then removes it from the cache. The same process occurs for user2. When user1's processor attains its final state, the toolkit does not store myProc in the cache, thus preventing a memory leak. If a page is displayed to user2, the toolkit stores myProc in the cache. If user2 then stops the process (by closing the browser for example), user2's instance of myProc remains in the cache. If user3 runs a new instance of myProc, the toolkit does not use the myProc stored in the cache. Instead, the toolkit creates a myProc instance and eventually stores it in the cache. This means that there will be two instances of myProc stored in the cache but the toolkit will only reuse one of them. The application must clean up the cache by removing user2's instance of myProc.
