Inbound commands

FTM needs to be able to process the arrival and lifecycle of inbound commands. Commands are usually sent from the FTM management console to verify, resolve or cancel processing of objects that encounter some kind of error or to manually trigger a business process. Typically an inbound command consists of:

1 Transmission object
1 Transaction

Two types of command may be received:

Commands requiring authorization
Commands not requiring authorization

A typical usage scenario is:

Receive, log, and map an inbound command transmission.
Validate the command transaction.
Wait for authorization, if required.
Locate the target object.
Invoke the command execution on the object.
Check that the command was successful.

The sequence diagram in the following figure shows the processing steps for a command that does not require authorization.

Figure 1. Commands not requiring authorization

The sequence diagram in the following figure shows the processing steps for a command that requires authorization.

Figure 2. Commands requiring authorization

The sequence diagram in the following figure shows a command that has failed.

Generic inbound command transaction lifecycle

The InPT lifeline is compatible with the existing generic inbound transmission. In the InTxn lifeline, the following states are identified:

S_TxnMapped
S_CheckingAuthorityValidating
S_AuthorizePending
S_ProcessingCommand
S_InTxnComplete
S_InTxnPartialComplete

Figure 4. Typical application interaction single transaction transmission

Figure 5. Simple generic inbound transmission lifecycle

For more information, see Process inbound transmission.

The following figure shows a simple state diagram that is derived from the sequence diagrams.

Figure 6. Simple generic command transaction lifecycle

A more extensive set of states is supplied in the full generic FSM to cover error scenarios. A simplified version is shown in the following figure.

Figure 7. Simple generic command transaction lifecycle with error paths

Differences in the full FSM

The full FSM is the same as the simple lifecycle diagram except for the addition of technical FTM information such as Event Filters, Object Filters, and so on.

Differences to legacy operator commands

The extensible style of operator command, which was introduced in FTM V3.0.0, has the following advantages over the legacy method:

Less configuration required. User defined events no longer need to be inserted into the VALUE table of the FTM database.
Standardized for every operator command. Every operator command now uses E_OperatorCmd and context data.
Feedback regarding command completion of commands.

Feedback mechanism

Along with the action raised when the targeted object transitions on the command, A_NotifyCmdProcessed must also be raised. This is used by the Inbound Command Transaction FSM to determine if the command has successfully acted on each of the valid objects. Using this information, the command transaction can transition into one of three final states:

S_InTxnComplete (if all valid targets notify that the command was acted upon).
S_InTxnPartialComplete (if some valid targets did not notify that the command was acted upon).
S_InTxnFailed (if none of the valid targets acted upon the command).

Usage

The use of the updated operator command style is demonstrated in Figure 8. Items of note are:

The FSM transitions on the "E_OperatorCmd" event.
The event guard must check that the TYPE context data in the operator command is equal to the text in the resolution constraint.
The Object Filter must check that the object ID is equal to the "TRGT_OBJ_ID" context data in the operator command.
Along with the usual action, "A_NotifyCmdProcessed" must also be raised, separated by a semicolon.