A flow processor performs a specific business process based on a defined flow of states. A flow processor contains an initial state, one or more final states and any number of other states through which it might go. The toolkit definition file may contain flow processor definitions or, for self-defined processors, there are separate XML files. Each flow processor definition includes XML representations of all the parts and features that would be included in the statechart diagram of the flow.
A flow processor realizes the Automaton by implementing the Processor interface. The toolkit provides the DSEProcessor for Java clients and as a parent class for other flow processor classes. The DSEHtmlProcessor is an example of a flow processor implementation for HTML clients and is a subclass of DSEProcessor.
A processor contains an instance of a context for data and services management. All actions that the processor executes during its lifetime can access the processor context or use their own context. If the action does not have a defined context, the action uses the processor context. If the action does have a defined context, the toolkit chains the action context to the processor context. A processor can also have associated formats.
To enable a flow processor to represent the parts of a statechart diagram, the Automaton provides the following set of interfaces: Action, GuardCondition, Processor, State, and Transition. In addition, the Automaton uses the concepts of entry actions, exit actions, and events. The following diagram shows the relationships between these entities:
A flow processor has a status as well as a set of states. The status identifies the state of the processor's execution so that the toolkit can monitor it. This allows the toolkit to determine, for example, whether a processor requester can restart the flow processor. The status can be one of the following values:
▪ not_initialized - The toolkit has created the instance but not initialized it.
▪ initialized - The toolkit has initialized the instance but not started (executed) it.
▪ running - The toolkit has started the instance.
▪ aborted - The toolkit has stopped the instance before it reached a final state. The toolkit cannot restart the processor.
▪ suspended - The toolkit has stopped the instance before it reached a final state. The toolkit can restart the processor.
▪ completed - The processor has completed its flow. When the processor makes a transition to a final state, it performs its entry actions and changes its status to completed. From this point on, no more transitions are allowed for the Processor. By definition, a final state has no associated transitions to other states.
▪ consequential - The processor restricts the states it accepts when requests come from pages displayed using the browser's back button. This is specific to the HTML client. For further information, see the Struts Extensions documentation.
The toolkit creates and initializes a flow processor instance before it executes the instance. Upon execution, the instance has a running status and enters in the initial state of the process. The toolkit may execute processor instances asynchronously in separate threads if desired. This allows the requester (the application using the processor) to be listening for events fired by one processor and use another processor to perform some actions on the first processor such as suspending, resuming, or aborting its execution.
The requester of a processor can abort its processor instance explicitly or implicitly through the use of a flow modifier associated with a guard condition within the flow definition. Aborting a processor prevents it from perform any further actions. If the processor is performing an action when the requester aborts it, the processor completes the action but does not handle any events. It then terminates with an aborted status. The system garbage collects the processor when the requester no longer references it. If the requester does not abort a processor, the processor only ends when it reaches a final state. When it reaches one, the processor changes its status to completed.
The requester can also suspend a processor. A suspended processor does not handle any events for its current state although the events remain in the event queue. The queue contains both events that exist at the moment of suspension and any new events fired while the processor has a suspended status. When the requester resumes the processor, the processor handles all of the events in the queue and resumes its normal flow.
When a requester wants to manipulate the status of a particular processor, it can use the Processor Manager as an intermediary. The Processor Manager creates an instance of the processor, initializes it, adds it to its internal registry of processors, and executes it on behalf of the requester. The requester can also directly deal with a processor without using the Processor Manager by listening for events fired by the processor whenever its internal status changes.
