Channels, services, and service participants

The FTM data model defines the following entities:
  • Channel
  • Service
  • Service participant
These entities can be used to define various characteristics of the interfaces to an instance of FTM. In particular, they provide a structure to define the relationships between interfaces and the roles (such as payment source, payment gateway, administration, and others) of those interfaces. The entities also have other parameters that can be used to control the behavior of those interfaces.

The concept of a channel is used by FTM to model the characteristics of an interface between FTM and another system. Typically, two or more channels are used for a bidirectional interface.

The principal features of a channel are:
  • They are owned by an involved party; for example, a system with which FTM interacts.
  • They are unidirectional. Each defined channel can be used only to send data or only to receive data.
  • They are associated with a format. Only data in this format is expected on the channel.
  • They are associated with a mapper. This association tells FTM which mapper to use to convert data from the channel into ISF or to convert from ISF to the target format for the channel.
  • They have physical communication details, such as the name of a queue manager and a queue.

The service entity corresponds to a service that is provided by FTM, such as payment processing, remittance processing, and others. It provides a mechanism to group the interfaces that are involved in the provision of that service.

The service participant entity corresponds to an interface to FTM. The end points of the interface can be defined by using an input channel and an output channel. The properties of a service participant can be used to control many aspects of processing and routing options within the FTM process.
Role
Defines how this interface is used within the service (for example, payment source, payment gateway, and others). This role can be used to determine how transactions are processed, and form the basis for primary routing decisions.
Rank
The rank can be used to differentiate participants of the same role (for example, primary, secondary, and so on), to form the basis for secondary routing decisions.
State
The service participant is also an object, so it can have a state, and its lifecycle can be controlled by an FSM. For example, the state can be used to manage the opening and closing of interfaces based on a schedule or explicit open and close messages. Similarly, the state can be used to signal an alert and enable administration controls when a problem, such as an interface that is not available, occurs.

Model channels in the Rational® tools so that metadata that describes the channels can be installed into the database. The channel metadata in the database can also be reviewed and modified by using the FTM Operations and Administration Console. It is recommended that the Rational model is used as the single, original copy of all configuration data.