Summary events

The sample application raises a summary event at regular time intervals. It provides summary information on business transactions, such as the quantity and value of pending and completed transactions.

FTM provides a SCHEDULER_TASK object to facilitate event generation. This object includes monitored interfaces and runtime behavior. It contains two types of data:
  • Configuration data that defines the set of monitored interfaces. For more information, see Scheduler tasks and calendar groups.
  • Operational data that has a lifecycle and a related finite state machine (FSM) model for runtime behavior. It defines scheduled activity to collect data and raise events.
The operational data type has separate finite state machine (FSM) models for hosted and invoked services:
For hosted services
The FSM for hosted service monitor defines the lifecycle for objects of type SCHEDULER_TASK and subtype HOSTED_SERVICE_MONITOR (see Figure 1). It fires upon events from the heartbeat service.
  • When the heartbeat service (E_HeartbeatStart) starts, it sets up a timeout condition based on the monitoring interval that is configured for the particular object.
  • When the regular heartbeat event, E_Heartbeat, determines a timeout condition, the A_ProcessHostedServiceSummary action determines the transfer information that is to be monitored and triggers the internal E_HostedServiceSummaryStart and E_HostedServiceSummaryEnd events. These events trigger the emitter flow that creates the actual external monitor events to be published.
For invoked services
The FSM for invoked service monitor defines the lifecycle for objects of type SCHEDULER_TASK and subtype INVOKED_SERVICE_MONITOR (see Figure 2). It fires upon events from the heartbeat service.
  • When the heartbeat service (E_HeartbeatStart) starts, it sets up a timeout condition based on the monitoring interval that is configured for the particular object.
  • When the regular heartbeat event, E_Heartbeat, determines a timeout condition, the A_ProcessInvokedServiceSummary action determines the transfer information that is to be monitored and triggers the internal E_InvokedServiceSummary event. This event triggers the emitter flow that creates the actual external monitor event to be published.
Figure 1. FSM for hosted service monitor
Figure 2. FSM for invoked service monitor

The design objective of this approach is that the implementation is configurable, so it can be used in other FTM applications. Therefore, some of the model entities are defined in a separate model that can be imported into other models, similar to the Generic Model.

The sample application services summary events for the interfaces that are shown in the following list.
  • The interfaces for invoked services are shown in the following list.
    • Liquidity Service
    • Repair Service
    • Payments Gateways
    If a summary event is to be raised for any of these interfaces, the FTM sample application triggers an E_InvokedServiceSummary event.
  • The interfaces for hosted services are shown in the following list.
    • Payment Originator
    • Batch Payment Originator
    If a summary event is to be raised for either of these interfaces, the FTM sample application triggers an E_HostedServiceBeginSummary or E_HostedServiceEndSummary event.