Supported configuration settings

Logging physical transmissions and transactions

Channel level properties were extended to specify whether the transmission and transaction objects are logged to the database.

The following two tables show the database logging settings for a channel. The options in the following list are available for both transmission and transaction objects.
  • Log the complete record, including data, to the database.
  • Log only the record.
  • Do not log anything.
Table 1. Channel settings for physical transmissions
CHANNEL.LOG_DATA Log transmission object Log transmission data
Y Yes Yes
N Yes No
X No No
Table 2. Channel settings for transactions
CHANNEL.LOG_TXN Log transaction object Log ISF data
Y Yes Yes
N Yes No
X No No

All master transmissions or transactions are logged, regardless of the configuration. If a failure occurs, either sending or receiving and correlating, the objects are logged regardless of the configuration.

Response correlation

FTM provides several mechanisms for correlating response transmissions with the original outbound request. You can define the correlation mechanism in the configuration at the service participant level. This mechanism allows the FTM core and generic actions to automate correlation, removing this burden from the application. In some cases, the FTM core and generic model can use this improved awareness to optimize the overall process. Response correlation uses the OUT_REQ_CORREL database table, which stores the correlation records. The Purge utility can be used to purge correlation data that is no longer needed.

Correlation scheme

The CORREL_SCHEME column in the SVC_PARTICIPANT_BASE table defines the correlation method. The documentation for the FTM data model for this version is provided in the entitled documentation fix pack for FTM. For more information about getting the fix pack, see FTM support links. The following table describes the possible values for the correlation scheme.

Table 3. CORREL_SCHEME values
Code Description
IN_TXN_ACK_MQ1 Correlate by using the CID of the request transmission.
IN_TXN_ACK_MQ2 Correlate by using the UID of the request transmission.
IN_TXN_ACK_CID Correlate by using the CID of the request transaction.
OUT_TXN_NOWAIT No correlation is needed.
Null Legacy-application-controlled correlation.

Starting with FTM V3.0.0, Fix Pack 5 and later, all values available are listed in the SP_CORREL_SCHEME Classification scheme in the FTM Generic Model in Rational® Software Architect. They can be selected within a Service Participant, along with End Mapper correlation. The values that are supported are a direct match to the correlation mechanisms historically supported by the generic action A_CorrelateAndUpdateRel. If the correlation scheme is configured for a request channel, the core and generic actions populate the database table OUT_REQ_CORREL with values according to the correlation scheme and logged objects. The CORRELATION_KEY field in this table holds the value that is used when the response is correlated with the request. Depending on the correlation scheme, the field holds either OBJ_ID, CID, or UID.

The documentation for the FTM data model for this version is provided in the entitled documentation fix pack for FTM. For more information about getting the fix pack, see FTM support links.

End mapper correlation

In addition to the correlation scheme codes previously defined, the correlation scheme code can be extended to request that EndMapper handle the correlation instead of running the generic inbound acknowledgment FSM. To have EndMapper do correlation, append /EM to the correlation scheme code. If EndMapper is handling the correlation, it suppresses the usual mapped events and raises alternative events to notify relevant objects of the acknowledgment.

Scenarios for optimal performance

The introduction of these configuration settings means that a considerable number of permutations are now possible for any outbound channel. The following table shows the supported permutations:

Table 4. Supported permutations.

(S_xxx) is the state in which the object is created.
Scenario # EndMapper correlation Correlation location EndMapper event Correlation scheme Outbound channel Inbound channel
Log transaction Log transmission Log transmission Log transaction
1 N/A N/A N/A OUT_TXN_NOWAIT No No N/A N/A
2 5 N/A N/A N/A OUT_TXN_NOWAIT Yes (S_OutTxnComplete)1 No N/A N/A
3 N/A N/A N/A OUT_TXN_NOWAIT No Yes (S_OutPTSent) N/A N/A
4 5 N/A N/A N/A OUT_TXN_NOWAIT Yes (S_OutTxnComplete)1 Yes (S_OutPTSent) N/A N/A
5 No Ack Txn FSM E_MpInTxnMapped NULL Yes (S_OutTxnCreated) No No Yes (S_InTxnMapped)
6 No Ack Txn FSM E_MpInTxnMapped NULL Yes (S_OutTxnCreated) No Yes (S_InPTArrived) Yes (S_InTxnMapped)
7 No Ack Txn FSM E_MpInTxnMapped NULL Yes (S_OutTxnCreated) Yes (S_OutPTSent) No Yes (S_InTxnMapped)
8 No Ack Txn FSM E_MpInTxnMapped NULL Yes (S_OutTxnCreated) Yes (S_OutPTSent) Yes (S_InPTArrived) Yes (S_InTxnMapped)
9 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX Yes (S_WaitingForAck)1 No No Yes (S_InTxnMapped)
10 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX Yes (S_WaitingForAck)1 No Yes (S_InPTArrived) Yes (S_InTxnMapped)
11 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX Yes (S_WaitingForAck)1 Yes (S_OutPTSent) No Yes (S_InTxnMapped)
12 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX Yes (S_WaitingForAck)1 Yes (S_OutPTSent) Yes (S_InPTArrived) Yes (S_InTxnMapped)
13 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX No No No Yes (S_InTxnMapped)
14 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX No Yes (S_OutPTSent) No Yes (S_InTxnMapped)
15 No Ack Txn FSM E_MpInTxnMapped IN_TXN_ACK_XXXXX No Yes (S_OutPTSent) Yes (S_InPTArrived) Yes (S_InTxnMapped)
16 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 No No No
17 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 No No Yes (S_InTxnComplete)
18 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 No Yes (S_InPTComplete)2 No
19 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 No Yes (S_InPTComplete)2 Yes (S_InTxnComplete)
20 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 Yes (S_OutPTSent) No No
21 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 Yes (S_OutPTSent) No Yes (S_InTxnComplete)
22 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 Yes (S_OutPTSent) Yes (S_InPTComplete)2 No
23 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_OutTxnCreated)3 Yes (S_OutPTSent) Yes (S_InPTComplete)2 Yes (S_InTxnComplete)
24 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 No No No
25 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 No No Yes (S_InTxnComplete)
26 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 No Yes (S_InPTComplete)2 No
27 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 No Yes (S_InPTComplete)2 Yes (S_InTxnComplete)
28 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 Yes (S_OutPTSent) No No
29 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 Yes (S_OutPTSent) No Yes (S_InTxnComplete)
30 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 Yes (S_OutPTSent) Yes (S_InPTComplete)2 No
31 5 Yes EndMapper E_AckRcvd IN_TXN_ACK_XXXXX/EM Yes (S_WaitingForAck)1 Yes (S_OutPTSent) Yes (S_InPTComplete)2 Yes (S_InTxnComplete)
32 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No No No No
33 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No No No Yes (S_InTxnComplete)
34 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No No Yes (S_InPTComplete)2 No
35 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No No Yes (S_InPTComplete)2 Yes (S_InTxnComplete)
36 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No Yes (S_OutPTSent) No No
37 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No Yes (S_OutPTSent) No Yes (S_InTxnComplete)
38 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No Yes (S_OutPTSent) Yes (S_InPTComplete)2 No
39 Yes EndMapper E_TxnOutTxnComplete4 IN_TXN_ACK_XXXXX/EM No Yes (S_OutPTSent) Yes (S_InPTComplete)2 Yes (S_InTxnComplete)
Table notes:
  1. S_WaitingForAck and S_OutTxnComplete (Outbound Transaction) – In these scenarios, the database persistence API must convert S_OutTxnCreated to the correct state automatically. For more information, see Database Persistence.
  2. S_InPTComplete (Inbound Transaction) – In these scenarios, the core must convert S_InPTArrived to the correct state automatically.
  3. Optimized inbound scenarios 16 - 23 modify outbound create actions and all have essentially the same correlation behavior.
  4. Scenarios 32 - 39 support customization of the precise E_TxnOutTxnComplete event name.
  5. Scenarios 2, 4, and 24 - 31 are only supported when you use the database persistence API to create the outbound transactions. The database persistence API can do multiple row database inserts, automatically adjust the initial state of the transaction based on the channel settings, and handle transmission failures. For more information about the database persistence API, see Database Persistence.

Customizing the outbound transaction completion event

EndMapper can automatically adjust the name of the E_TxnOutTxnComplete event by using the mechanism that the generic actions support.

The event that is raised to indicate that an outbound transaction was completed can be defined by using VALUE table entries with a category of COMPLETION_EVENT_FOR_TXN_TYPES. These configuration values also have a key that contains only one of the following transaction types.
  • The outbound transaction type. For example, PAYMENT_ACK.
  • The inbound and outbound transaction types. The types are separated by an underscore. For example, LIQUIDITY_REQUEST_LIQUIDITY_RESPONSE.