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.