FTM Finite State Machine State Diagrams

Figure 1. Inbound transaction finite state machine
In the FSM diagram for the Inbound Transaction, the following process occurs:
  • After the payment message is mapped (handled by the Generic Model), the Inbound Transaction for the payment message enters the S_TxnMapped state.
  • Subsequently, the action that checks the processing date of the Service Participant against the payment message's value date is run and determines whether the payment message will be put into a holding state or be forwarded to the Payment Gateway immediately. At this point, the FSM is in the S_CheckingTxnSend state. Once the comparison of dates has occurred, the event, E_TxnChecked, is raised with context by the action.
  • If the context in the E_TxnChecked event is set to 'SEND_TXN', the action A_SendTxn is run and the FSM moves into the S_SendingTxn state. The A_SendTxn action will create the necessary Outbound Transmission and Outbound Transaction objects required to output the payment message out of FTM and to the Payment Gateway.
  • If the context in the E_TxnChecked event is set to 'HOLD_TXN', the FSM is transitioned into the S_HoldTxn state. From this state, there are three possible transitions. The E_ReleaseTxn event can be raised by the Payment Release Service when the scheduled time occurs. The state S_HoldTxn is also an OpsControl state. This means that an Operator can apply resolutions through the FTM OAC when the FSM is in this state. The S_HoldTxn state has two resolutions – 'Release' and 'Cancel'. If the Operator chooses to release the payment message, the event context of E_OperatorCmd will be 'RELEASE'. Otherwise, if the Operator chooses to cancel the payment message, the event context of E_OperatorCmd will be 'CANCEL'. In this instance, the action from the Generic Model, A_RaiseInTxnFailed, is executed to finalize the Inbound Transmission object and FSM associated with this Inbound Transaction object and the FSM is transition to a final state of S_InTxnFailed. In situations where the E_ReleaseTxn or E_OperatorCmd with a context of 'RELEASE' is raised, the A_SendTxn will be executed to start the process of forwarding the payment message to the Payment Gateway.
  • Once the A_SendTxn action has completed and the payment message has been sent, the Generic Action, A_RaiseInTxnComplete is executed to tidy up the Inbound Transmission object and FSM associated with this Inbound Transaction object. The FSM is then transitioned to its final state of S_InTxnComplete.
Figure 2. Scheduler task finite state machine
In the FSM diagram for the Scheduler Task, the following process occurs:
  • Upon the startup of the sample application, the E_HeartbeatStart event is raised in FTM. This executes the A_InitPaymentReleaseService action which determines and updates the correct processing date for the Service Participant. This is the date that is compared to the value date of the payment messages. Then the action will attempt to release eligible payment messages that were being held when the sample application started up. Finally, the action will determine the next Schedule Entry (either changing the business day or releasing payments) and the time stamp at which that next Schedule Entry will occur. The Scheduler Task's CURRENT_SCHEDULE_ENTRY and TIMEOUT values are subsequently updated.
  • The E_Heartbeat event is raised every minute by FTM, however, the action, A_PaymentReleaseService, will only execute when the current time is greater than the Scheduler Task's timeout value. In the A_PaymentReleaseService action, either the business day is updated to the next day, held payments are released, or both, depending on the Scheduler Task's current scheduler entry value. Finally, the Scheduler Task's current scheduler entry and timeout are updated to reflect the next Schedule Entry to occur.
  • The S_Available state is also an OpsControl state and allows for the Operator to reset the sample application during runtime. In the OAC, the Operator can supply a time in the format of 'hh:mm' which will be parsed during the A_ResetPaymentReleaseService action to become the new OPEN_TIME for the change business day Schedule Entry. The release payments Schedule Entry will be set for five minutes after this time. Subsequently, the initialization code in the A_InitPaymentReleaseService action is re-run.
    Note: This feature is for demonstration purposes only and is not necessarily advised for a production application.