SendMsg scenario using SnF delivery mode

Figure 1 illustrates how a message is sent to a counterpart using SnF delivery mode:

1. The sending application puts the business message into the body of a SendMsg request, specifies the priority of the message in the Priority field of the MQMD header of the request, and puts the request into the interface queue of the MSIF transfer service.
2. The MSIF transfer service:
   1. Continually scans its input queue for messages that it is to process.
   2. Retrieves, from its input queue, the message with the highest priority. If more than one message has the highest priority, it retrieves the one that was submitted first.
3. If the message is a SendMsg request, the MSIF transfer service:
   1. Creates an entry for a SendMsg scenario in the FTM SWIFT database. It sets the MSIF reference of the scenario to the value of the MQMD.MsgId.
   2. Stores a copy of the SendMsg request in the audit log (if recording of audit data is enabled for this audit point).
   3. Augments the contents of SendMsg request with options specified by means of option-set COs or system defaults, as described in Value hierarchy.
   4. Checks whether the options are valid, for example, that all mandatory options are specified and that no mutually exclusive options are specified.
   5. Checks whether the options are compatible with the application service profile (ASP) of the SWIFT service that is to be used, as described in Validation based on ASP data.
   6. Sets the transfer state of the scenario to Requested.
   7. Creates an entry for the SendMsg scenario in the message warehouse (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all SendMsg scenarios).
   8. If the business message contained in the message body is not already encoded using UTF-8, converts the message payload to UTF-8.
4. If the MSIF transfer service is not started for the OU, it sets the transfer condition of the SendMsg scenario to stopped and discontinues processing the scenario until it is started for the OU. If the MSIF transfer service is started for the OU, it continues processing the scenario.
5. The MSIF transfer service:
   1. Creates an SAG message that contains an InterAct SwInt:ExchangeRequest primitive.
   2. Stores a copy of the SAG message in the audit log (if recording of audit data is enabled for this audit point).
   3. Sets the transfer state of the SendMsg scenario to Initiated.
   4. Updates the entry in the message warehouse with data from the SNL request primitive (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all SendMsg scenarios).
6. If the SendMsg request specifies that:
   • An input channel is to be used, and if that input channel is not open, the MSIF transfer service does not change the transfer state of the SendMsg scenario; the state remains Requested until the channel is opened.
   • An input channel is to be used, and if that input channel is open, the MSIF transfer service:
     1. Replaces the values of the SAG message partner options, which were taken from the SAG MP option set that was specified by the SendMsg request, with the values of the SAG MP option set that is configured for the input channel
     2. Checks whether the options, including the newly added SAG message partner options, are valid
     3. Obtains the next free sequence number in the transfer window
     4. Checks whether RMA is used by the SWIFT service and, if so, whether the local RMDS contains a corresponding authorisation to send (see ASPs and RMA traffic filtering)
     5. Passes the SAG message to the SAG that is specified by the SAG MP option set that is configured for the input channel
   • An input channel is not to be used, the MSIF transfer service:
     1. Checks whether RMA is used by the SWIFT service and, if so, whether the local RMDS contains a corresponding authorisation to send (see ASPs and RMA traffic filtering)
     2. Passes the SAG message to the SAG that is specified by the SAG MP option set that is specified by the SendMsg request, either directly or by means of a transfer option set.
7. The MSIF transfer service:
   1. Sets the transfer state of the SendMsg scenario to Initiated
8. The SAG initiates the message transfer to the SnF queue in the SIPN.
   Note: If the attempt to pass the message to the SAG or to initiate the message transfer results in:

   An unrecoverable error

   The MSIF transfer service creates a response that contains information about the error and the payload of the original request, and passes this response to the application. If the application wants to reattempt the message transfer, it must issue a new SendMsg request.

   A recoverable error

   The MSIF transfer service issues an event that contains information about the error. If automatic recovery is enabled (see Automatic recovery) it automatically reattempts the transfer. If automatic recovery is not enabled, or if the automatic recovery attempts are exhausted, and if an SAG MP option-set group was specified, it switches to a new SAG MP option set and reattempts the transfer using the new SAG MP options (see Switching SAG MP option-set COs). If the MSIF transfer service exhausts all automatic recovery attempts for all SAG MP option sets, an operator can reattempt the message transfer manually by issuing the recover command for the scenario.

9. SWIFT Message Request Routing (MRR) uses the RequestorDN, ResponderDN, Service, and RequestType in the primitive to determine the SnF queue (see Figure 2). SWIFT places the SwInt:ExchangeRequest primitive into the SnF queue of the receiving counterpart and generates an InterAct SwInt:ExchangeResponse primitive, which it passes back to the sending SAG.
10. The SAG passes an SAG message containing the SwInt:ExchangeResponse primitive to the MSIF transfer service.
11. The MSIF transfer service:
    1. Stores a copy of the SAG message in the audit log (if recording of audit data is enabled for this audit point).
    2. Correlates the SwInt:ExchangeResponse primitive with the corresponding SendMsg request.
    3. Sets the transfer state of the SendMsg scenario to Completed.
    4. Generates an application message containing a SendMsg response. The value of the SnFReturnBusMsg option determines whether the body of this message is to contain the business message that was contained in the request.
    5. Passes the application message to the reply-to queue specified in the request.
    6. Stores a copy of the application message in the audit log (if recording of audit data is enabled for this audit point).
    7. Updates the entry for the SendMsg scenario in the message warehouse with data from the SendMsg response (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all SendMsg scenarios).
    8. Records accounting data.
    9. Sets the transfer state of the SendMsg scenario to Completed_Notif.
    10. Updates the entry in the message warehouse with the new transfer state (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all SendMsg scenarios).
12. Each response primitive sent by the SIPN indicates the last replication time of the SnF database. A scenario with an SnF input time that is later than the last replication time specified in the most recently received response is assigned the condition waitForReplication. The completed scenario retains this condition until the MSIF transfer service receives a response for a subsequent scenario that uses the same SnF database and that contains a last replication time that is after the SnF input time of the completed scenario. After the MSIF transfer service receives such a response, it changes the condition of the completed scenario to finished.
    Note: The MSIF transfer service is not notified of the current last replication time until it receives a response for a subsequent transfer. For this reason, a scenario might retain the condition waitForReplication long after the replication of the SnF database has finished.
13. If the request message requested a delivery notification, the SIPN uses the information contained in the response from the receiver to generate a delivery notification. The SIPN puts the delivery notification into the notification SnF queue that was specified in the original SendMsg request. When an output channel to that SnF queue is opened (or when that SnF queue is acquired), the MSIF transfer service receives the delivery notification and initiates a NotifReceived scenario (see NotifReceived scenarios). The action it takes depends on the type of the delivery notification (SuccessDelivNotifAction or FailedDelivNotifAction) and the notification action specified in the corresponding SendMsg request (see Notification actions).