To illustrate the Automaton and flow processor in the HTML environment, this example includes an entire use case for home banking, the statechart diagram for the business process obtained from the use case, extensions to the Automaton, and the external definitions of the flow processor and its parts.
The following use case describes a user purchases a mutual fund within a home banking system. To keep it brief, the use case assumes that no errors occur.
Actor
The user is a customer of the financial institution, who has a login ID and personal identification number (PIN) to use the system. The PIN is a personal access code assigned by the institution to perform authorization and authentication of the user. It also controls the specific operations that the user may perform.
Preconditions
▪ The user has successfully logged onto the system and the system has assigned a session to the user.
▪ The system has retrieved the user's identification information required for subsequent operations during the session.
Flow of events
1 The user selects the mutual fund purchase application from a home page, which presents the activities available to the user.
2 The system displays a list of available mutual funds, categorized by fund type in a view called Funds Catalog View (Page 1). The view has an OK button and a Cancel button.
3 The user selects a fund and selects OK.
4 The system displays the Product Details View (Page 2) containing detailed information for the selected product such as the minimum investment amount, product purchase agreement conditions, fees to be applied, and withdrawal conditions. The view has an Accept button and a Cancel button.
5 The user accepts the product.
6 The system displays the Funds Purchase View (Page 3) containing a list of the user's accounts. In this view, the user must provide additional information pertaining to the mutual fund purchase. In addition to a selectable list of user accounts, this user interface contains entry fields for the amount to invest, the currency, an OK button, a Cancel button, and a Back button, which redisplays the product details page.
7 From the account list, the user selects the account the system is to debit for the mutual fund purchase. The user also provides an investment amount and currency, and then selects OK.
8 The system displays a confirmation page (Page 4), which contains the operation to be performed (mutual fund purchase), the account from which the funds will be withdrawn, the amount of the investment, the debit amount (which may be different from the amount because it reflects the invested amount plus service fees), and an entry field for the personal access code of the user. The confirmation page also contains a Cancel button, which allows the user to revisit the available funds list page, and a Back button to return to the additional information input page.
9 The user reviews the information in the confirmation page, enters the correct PIN, and confirms the mutual funds purchase by selecting OK.
10 The system displays an Operation Summary view (Page 5) that informs the user that the mutual funds acquisition operation has been performed. This page displays the data that was used in the operation and also an OK button to close the page.
11 The user selects OK, which ends the flow and clears the process on the server. Note that if the user does not click the button, the inactivity timeout in the server would clear the process.
12 The system returns to the home page.
Post-conditions
▪ The user's selected account has been debited by the sum of the investment amount and any applicable fees.
▪ The system stores a new agreement for the customer with the asset information data (such as open date, last movements date, number of owned participations in the mutual fund.)
Purchase Mutual Funds process flow
The following flow diagram is an artifact of analyzing the Purchase Mutual Funds use case to understand the flow of the business process:
When you read the same diagram as a statechart diagram of the business process, you can use it to create a flow processor to handle the business process.
To support the application's HTML client requests on the server, the toolkit requires the following things:
▪ ProcessorOperation interface to provide a front-end layer between the request from the client workstation and the processor responsible for controlling the navigation dialog. The following diagram shows the role of the ProcessorOperation implementation:
▪ Definitions for the operations required to perform the main business transactions. These include definitions for toolkit entities such as contexts and formats.
▪ Definitions for the actions for executing operations. These actions must be able to signal an error event when the result of executing a business operation halts further user interaction. The processor can use this event to display an information message to the user. For example, the processor should display a message when an action retrieves a list of accounts but the operation cannot use them due to constraining business rules. Note that the toolkit provides a default action with this functionality, ExecuteOperationAct, in the com.ibm.btt.automaton.ext package.
▪ Input validation of the PIN number using a subclass of DSEGuardCondition. The subclass validates the PIN and returns true or false. For an incorrect PIN, the subclass should leave data in the process context so that the confirmation page can display an informative warning message for the user.
▪ JSP pages for rendering the views in a Web browser.
With the business process of Purchase Mutual Funds described as a statechart diagram, you can then define the process as a sequence of states guided by a flow processor. The following example is how you would define the flow processor as a self-defined processor in a file called FundAcquisition.xml.
To allow the externalizer to find the path to the fundAcquisition flow processor in the FundAcquisition.xml file, the toolkit configuration file has the following definition:
<kColl id="files"> ... <field id="processor" value="DSEPROC.XML" /> <!-- The processor definition is the entity definition file for Processors --> <kColl id="processors"> <! The processor is self-defined in a specific path. > <processorDef id="fundAcquisition" value="FundAcquisition.xml" path="c:\dse\server\procs" /> ... </kColl> </kColl> ... <kColl id="packages"> ... <kColl id="processors"> <field id="package1" value="com.ibm.btt.samples.html"> ... </kColl> </kColl> ... <kColl id="tags"> ... <kColl id="processors"> <field id="processor" value="com.ibm.btt.automaton.DSEProcessor" description="compound"> <field id="state" value="com.ibm.btt.automaton.DSEState" description="compound"> <field id="transition" value="com.ibm.btt.automaton.DSETransitionDescriptor" description="compound"> <!-- Actions --> <field id="executeOperationAct" value="com.ibm.btt.automaton.ext.ExecuteOperationAct" description="compound"> <!-- Conditions --> <field id="checkPINCode" value="com.xxx.yyy.CheckPINCode"> ... </kColl> </kColl>
The requester of the process (in this case, the ProcessorOperation implementation built for HTML client support) uses the externalizer to instantiate the processor using the following command:(Processor) DSEProcessorExternalizer.readObject("fundAcquisition");
