SendFile: Sending a file to a counterpart

Figure 1 and Figure 2 illustrate how a file is sent to a counterpart:

1. The sending application prepares the data to be sent. This data can be stored in a file (an HFS file or a data set), or in the body of an IBM® MQ message containing a SendFile request.
2. The application constructs a SendFile request and puts this request into an interface queue of the MSIF transfer service. The Priority field of the MQMD header of this request specifies its priority.
3. 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.
4. If the message is a SendFile request, the MSIF transfer service:
   1. Creates an entry for a SendFile scenario in the FTM SWIFT database, and sets the MSIF reference of the scenario to the value of the MQMD.MsgId.
   2. Augments the contents of SendFile request with options specified by means of option-set COs or system defaults, as described in Value hierarchy.
   3. Checks whether the options are valid, for example, that all mandatory options are specified and that no mutually exclusive options are specified.
   4. Checks whether the user has the access rights needed to access the file.
   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. Stores a copy of the SendFile request in the audit log (if recording of audit data is enabled for this audit point).
   8. Checks whether the request has expired.
   9. Copies the data to be sent from the source file or data set, or from the body of the request message, to a temporary file. Depending on the properties of the file transfer, the MSIF transfer service either copies the file into the work directory or directly into the transfer directory. If requested, it performs character conversion and compresses the temporary file.
   10. Creates an entry for the SendFile scenario in the message warehouse (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all SendFile scenarios).
   11. If CommType is set to MQHA, it creates an LFT request to copy the file from the transfer directory to a subdirectory on the SAG workstation.
5. If the MSIF transfer service is not started for the OU, it sets the transfer condition of the SendFile 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:
   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. Creates an SAG message containing the SNL request primitive.
   3. Stores a copy of the SAG message in the audit log (if recording of audit data is enabled for this audit point).
   4. Sets the transfer state of the SendFile scenario to Initiated.
   5. 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 SendFile scenarios).
   6. Passes the SAG message to the SAG.
6. The SAG initiates the file transfer over the SIPN.
   Note: If the attempt to pass the SAG message to the SAG or to initiate the file 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 file transfer, it must issue a new SendFile 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.

7. The means by which the file data is sent depends on the type of SendFile scenario:

   For a real-time file transfer (see Figure 1):

   1. SWIFT Message Request Routing (MRR) uses the RequestorDN, ResponderDN, Service, and RequestType specified in the primitive to determine the SNL ID of the SAG and the name of the SNL endpoint (see Figure 1).
   2. The SAG uses the name of the SNL endpoint to determine the name of the receiving SI endpoint and message partner.
   3. The request primitive is sent to the receiving SAG, which puts the primitive into the input queue of the receiving transfer service.
   4. The receiver issues a response primitive that indicates to the sending SAG that it can transfer the file data. If the receiving transfer service is the MSIF transfer service, this response primitive specifies the MSIF reference of the corresponding request.
   5. The sending SAG transfers the file data to the receiving SAG.

   For an SnF file transfer (see Figure 2):

   1. The sending SAG sends the request primitive to the SIPN
   2. SWIFT Message Request Routing (MRR) uses the RequestorDN, ResponderDN, Service and RequestType in the primitive to determine the SnF queue (see Figure 2).
   3. The SIPN puts the request into the SnF queue.
   4. The SIPN issues a response primitive that indicates to the sending SAG that it can transfer the file data. This response primitive specifies the MSIF reference of the corresponding request.
   5. The sending SAG transfers the file data to an SnF queue, where the file data waits to be retrieved by the receiver.
8. When the file transfer is complete:
   • If CommType is set to MQHA, the MSIF transfer service deletes the file from the SAG workstation.
   • If CommType is set to LOCAL, the MSIF transfer service deletes the file from the transfer directory.
9. The MSIF transfer service uses the MSIF reference of the response primitive to correlate it with the corresponding SendFile request. The MSIF transfer service uses contents of the response primitive and the SendFile request to construct a SendFile response, and puts it into the reply-to queue specified in the MQMD folder of the SendFile request.
10. 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.
11. If a Y-Copy service is used for an SnF file transfer, and if authorisation was either requested by the sender or is mandatory for the Y-Copy service that is to be used, after the third party acquires its SnF queue and receives the file, it sends a system message to the SIPN. This system message indicates whether the third party accepted the transfer, determined the transfer to be a duplicate, or rejected the transfer. The SIPN generates a SwInt:HandleRequest primitive containing the system message and sends it to the sending SAG, which routes it to the MSIF transfer service. The MSIF transfer service updates its status information for the file transfer based on the contents of the system message.
12. If the sending application specified, in the original SendFile request, that it wished to receive a delivery notification:

    For a real-time file transfer

    When the counterpart receives the file, the receiving file transfer service creates a delivery notification primitive and sends it to the sender of the file. 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).

    Note: If SWIFT Message Request Routing (MRR) is configured in such a way that a delivery notification primitive might be received by an SAG or MP that is different from the one used to send the file, the corresponding SendFile request must specify, either explicitly or by means of its transfer option set, an SAG MP option-set group, and that group must contain a CO for the receiving SAG and MP. Otherwise, the MSIF transfer service is unable to process the delivery notification primitive.

    For an SnF file transfer

    After the counterpart retrieves the file from its SnF queue, it sends a response primitive to the SIPN. The SIPN generates a system message containing a delivery notification and puts it into the notification SnF queue specified in the original SendFile request. When this queue is acquired or an output channel to it is opened, 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).