Runtime components : Core components : Flows : Tasks : Customizing a processor
  
Customizing a processor
There are two ways to customize a processor: by configuring the parameters defined in the external processor file or by implementing extensions to the toolkit.
To customize a processor by configuring the external parameters, change the attribute values in its externalized data. The following table lists the ways you can customize a processor and the tags you use to do so. For information on specific tags, see Flow processor external definitions.
Customizing the service tasks
 
Customization
Attribute to use
Adding a parameter to a transition
Add an attribute and its value to the <transition> tag
Adding a parameter to an action
Add an attribute and its value to the action's tag
Chaining a context to another context
linkContextTo in the <openView> tag
Changing the action's context
context in the action's tag
Changing the processor's context
context in the <processor> tag
Changing the implementation class for the processor
implClass in the <processor> tag
Preserving events in the queue
cleanEventsQueueOnSwitch in the <processor> tag
Preventing a state from performing entry actions more than once
ignoreEntryActions in the <transition> tag
Preventing an event from going to the next handler
propagateEvent in the <transition> tag
Removing all events from the queue
cleanEventsQueueOnSwitch in the <processor> tag
Sending the event to the next handler
propagateEvent in the <transition> tag
Setting the formatter for inputting data into a context
inputMapFmt in the <executeOperationAct>, <openView>, or <executeSubflowAct> tags
Setting the formatter for outputting data from a context
outputMapFmt in the <executeOperationAct>, <closeView>, or <executeSubflowAct> tags
Setting the location of the view definition
viewSource in the <openView> tag
Setting the state as the initial state of a process
type and possibly typeIdInfo in the <state> tag
Setting the state as a final state of a process
type and possibly typeIdInfo in the <state> tag
Setting the target for a transition
targetState in the <transition> tag
Setting what happens when a user cancels a view
navigation in the <openView> tag
Using a flow defined elsewhere
refFlow in the <processor> tag
For examples of processor definitions, see the example definitions.
The toolkit provides a generic flow processor and two concrete implementations, one for Java clients and another for HTML clients. The functionality is extensive and is not likely to require significant modification to add behavior to meet the requirements of a particular project. Nevertheless, to change the internal behavior of an Automaton to suit the requirements of a particular project, create specialized FlowProcessors and States by subclassing from DSEProcessor or DSEState, and set the relationships between the tag names and the classes actually implementing the behavior in the framework configuration files (dse.ini).
In addition, Actions and GuardConditions are very likely to require specific implementations. The framework provides a set of generic Actions, which are intended to be extended. These Action classes are located in the com.ibm.dse.automaton.ext package. See Actions for more information.
See
Making an action conditional
See also
Tasks
Making an action conditional
To make an action occur only if a specified condition applies, add a set of guard conditions. Within each guard condition, use the onTrue and onFalse attributes to determine what happens when the passes or fails the evaluation of the condition. The values of the attributes are one of the flow modifiers:
▪ continue - (default) The flow resumes by evaluating the next condition associated with the action.
▪ skipConditions - The flow resumes by skipping all the conditions associated with the action and executes the action.
▪ skipAction - The flow resumes by skipping the action and processing the next action.
▪ skipAllActions - The flow resumes by skipping all the actions and moving to the target state that is defined for configured to the transition.
▪ changeState("targetStateName") - The Processor exits the current state and moves into the given targetStateName without executing the action.
▪ execAndChangeState("targetStateName") - The Processor executes the action, exits the current state, and moves to the given targetStateName.
▪ abortProcess - The current state and the processor are aborted. This should only be used in very seldom cases when an exceptional event happens.
The following example demonstrates how to apply these conditions:
<conditions>
  <checkPINCode onTrue="continue"
                onFalse="changeState(confirmationPage)">
</conditions>
After completing this task: If the PIN contained in the context hierarchy for the action passes the checkPINCode evaluation, the validating class returns true and the processor performs the action containing this condition. If the validating class returns false, the processor transitions to the confirmation page state instead of performing the action.
See also
Customizing a processor