Identifying transitions and events
The next step is to identify every possible transition between states and, for each transition, the event that triggers that transition.
A transition can have an associated action that is called after the object has been moved into the target state. Actions provide the means to perform business logic that is related to one or more state transitions. Often, this business logic raises further events. For more information, see Actions. For each event that causes a transition, think about what action, if any, should be carried out.
Simple state diagram shows the simple state diagram for the payment transaction from the sample application. The diagram shows the states, transitions, and events that trigger the transitions.
- Rename all states so that they begin with S_. For example, change Transaction Validating to S_Transaction Validating.
- Rename all transition events so that they begin with E_.
- Rename all actions so that they begin with A_.
- Transition event names are enhanced to indicate in/out, txn/bat, and so on. For example: event E_OutTxnComplete is raised to indicate successful completion of an outbound transaction.
- Define all event filters (also called transition guard conditions) in the FTM syntax. For more information, see Transition Properties.
- Specify all object filters. For more information, see Defining the object filter.
When events occur in an FTM application, FTM must locate the FSM transitions that the event can trigger. For each of these transitions, FTM must locate, in the database, objects that meet the criteria for the transition. To allow FTM to locate objects for a transition, there must be an object selector for each transition. For each FSM, define an object selector - referred to as the master object selector. For any transition in an FSM, you can provide an object selector to override the master object selector - referred to as the override selector.