FileReceived: Receiving a file sent by a counterpart

Figure 1. FileReceived SnF scenario
Figure showing FileReceived SnF scenario

When a counterpart passes to the SIPN a FileAct request primitive that is addressed to your location:

  • For a real time (RT) file transfer (see Figure 1):
    1. The receiving SAG puts a SAG message into the input 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 in the queue the longest. (Currently, the priority of an SAG message is always 0.)
    3. If the message contains a FileAct request primitive, the MSIF transfer service:
      1. Uses the contents of the primitive to create an entry for a corresponding FileReceived scenario in the FTM SWIFT database. It sets the MSIF reference of the scenario to the value of the MQMD.MsgId.
      2. Uses the name of the receiving message partner to identify a CO of type DnfEfaMPMap, which identifies the receiving OU.
      3. Stores a copy of the FileAct request primitive in the audit log (if recording of audit data is enabled for this audit point).
      4. Uses the RequestorDN, ResponderDN, Service, and RequestType specified in the primitive to determine which transfer option-set CO is to be used. The RequestorDN in the primitive is matched with a RemoteDN; similarly, the ResponderDN is matched with a LocalDN.
      5. Uses the transfer option-set CO to determine which file-receive option-set CO, SAG MP option set, and file option-set CO are to be used. If the transfer option-set CO specifies the name of a file-receive option-set group, the TransferInfo, FileInfo, and HeaderInfo fields in the message are used to determine which of the COs in the group is to be used (see File-receive option-set groups). If the transfer option-set CO specifies the name of an SAG MP option-set group, the MP and SNL ID fields in the message are used to determine which of the COs in the group is to be used (see Traffic distribution).
      6. Uses the SNL ID to determine which SAG communication option-set CO is to be used.
      7. Checks whether the SNL ID and message partner determined in this way match the SNL ID and message partner specified in the request. If not, it discontinues processing the request.
      8. Checks whether other constraints are satisfied, for example, that the size of the file does not exceed the configured maximum size. If not, it rejects the request primitive.
      9. Checks whether the configuration data and the data contained in the FileAct request primitive are valid and complete. If not, it rejects the request primitive.
      10. Checks whether the ASP of the SWIFT service contains elements that the MSIF transfer service does not recognize. If so, it issues an event and includes a response message and a PartialOk code in the FileReceived notification. For more information, see Validation based on ASP data.
      11. Checks whether the MSIF transfer service is started for the OU. If not, it sets the transfer condition of the FileReceived 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.
      12. Checks whether the MSIF transfer service is subscribed to receive FileAct events from the SAG from which it received the FileAct request.
      13. Checks whether the FileAct request is a duplicate. If so, the reaction of the MSIF transfer service depends on the AllowDuplicates option of the file receive option set, as described in Possible duplicate handling.
      14. Checks whether RMA is used by the SWIFT service and, if so, whether the local RMDS contains a corresponding authorisation to receive (see ASPs and RMA traffic filtering).
      15. Creates an entry in the message warehouse (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all FileReceived scenarios).
      16. Creates a response primitive that indicates to the sending SAG that it accepts the file transfer and that the sending SAG can transfer the file data. This response primitive specifies the MSIF reference of the corresponding request.
      17. Uses the SNL ID specified in the SAG message to determine which SAG communication option-set CO to use.
  • For a store-and-forward (SnF) file transfer (see Figure 1):
    1. When a user opens an output channel to (or acquires) an SnF queue, the configuration data for that channel (or queue) specifies which SAG MP option set is to be used. The SAG MP option set, in turn, specifies:
      • Which SNL endpoint is used
      • Which SNLID (and hence which SAG communication option-set CO) is used
      Each SnF session is identified by a session ID, which is assigned by SWIFT and is specified in the response to the open or acquire command.
    2. The receiving SAG passes the SAG messages in the SnF queue to the input queue of the MSIF transfer service.
    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 in the queue the longest. (Currently, the priority of an SAG message is always 0.)
    4. If the message contains a FileAct request primitive, the MSIF transfer service:
      1. Uses the contents of the primitive to create an entry for a corresponding FileReceived scenario in the FTM SWIFT database. It sets the MSIF reference of the scenario to the value of the MQMD.MsgId.
      2. Uses the session ID to:
        • Identify on behalf of which OU the output channel was opened or the SnF queue was acquired (this is the receiving OU).
        • Determine which SAG MP option-set CO is to be used. The SNL ID specified by this CO determines which SAG communication option-set CO is to be used.
      3. Stores a copy of the FileAct request primitive in the audit log (if recording of audit data is enabled for this audit point).
      4. Uses the RequestorDN, ResponderDN, Service, and RequestType specified in the primitive to determine which transfer option-set CO is to be used. The RequestorDN in the primitive is matched with a RemoteDN; similarly, the ResponderDN is matched with a LocalDN.
      5. Uses the transfer option-set CO to determine which file-receive option-set CO and file option-set CO are to be used. If the transfer option-set CO specifies the name of a file-receive option-set group, the TransferInfo, FileInfo, and HeaderInfo fields in the message are used to determine which of the COs in the group is to be used (see File-receive option-set groups).
      6. Checks whether certain constraints are satisfied, for example, that the size of the file does not exceed the configured maximum size. If not, it rejects the request primitive.
      7. Checks whether the configuration data and the data contained in the FileAct request primitive are valid and complete. If not, it rejects the request primitive.
      8. Checks whether the ASP of the SWIFT service contains elements that the MSIF transfer service does not recognize. If so, it issues an event and includes a response message and a PartialOk code in the FileReceived notification. For more information, see Validation based on ASP data.
      9. Checks whether the MSIF transfer service is started for the OU. If not, it sets the transfer condition of the FileReceived 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.
      10. Checks whether the MSIF transfer service is subscribed to receive FileAct events from the SAG from which it received the FileAct request.
      11. Checks whether the FileAct request is a duplicate. If so, the reaction of the MSIF transfer service depends on the AllowDuplicates option of the file receive option set, as described in Possible duplicate handling.
      12. Checks whether RMA is used by the SWIFT service and, if so, whether the local RMDS contains a corresponding authorisation to receive (see ASPs and RMA traffic filtering).
      13. Creates an entry in the message warehouse (if recording of message warehouse data is enabled for the SWIFT service that is used, or for all FileReceived scenarios).
      14. Creates a response primitive that indicates to SWIFT that it accepts the file transfer. This response primitive specifies the MSIF reference of the corresponding request.
      15. Uses the SNL ID specified in the SAG message to determine which SAG communication option-set CO to use.
      16. Creates a fetch request.

The following steps are carried out by the MSIF transfer service regardless of the delivery mode (real-time or SnF) of the file transfer:

  1. Stores a copy of the fetch request in the audit log (if recording of audit data is enabled for this audit point).
  2. Issues the fetch request to the SAG and changes the state of the scenario to FetchRequested. The SAG gets the file from the SIPN and stores it in a subdirectory on the SAG workstation.
  3. If CommType is set to MQHA, it creates an LFT request to copy the file to the MSIF transfer directory on the host. If CommType is set to LOCAL, the file on the SAG workstation is identical to the file in the MSIF transfer directory on the host.
  4. For a real-time file transfer, if the counterpart that sent the file requested a delivery notification, it sends one. For an SnF file transfer, it sends an SnFAck primitive to the SIPN. After sending a delivery notification or SnFAck primitive, it changes the state of the scenario to DelNotifSent. If the corresponding response indicates a recoverable error or timeout, it automatically retries to send the delivery notification or SnFAck primitive until either the attempt is successful, an unrecoverable error occurs, or the number of retry attempts is exhausted. It then changes the state of the scenario to TransferComplete.
  5. Verifies the received file by comparing the digest that accompanied the file with the digest that was calculated by the receiving SAG.
  6. Marks the file on the SAG workstation as being ready for deletion. The file is deleted later during the automatic housekeeping process.
  7. If so configured, it decompresses the received file, converts the code page of its contents, or both.
  8. Takes one of the following actions:
    • If the receive option set specifies a TargetDirectory option, it copies or moves the contents of the received file into a file with the same name as the transfer reference (TransferRef), which is an ID that the SIPN assigns to each file transfer. It then puts, into the queue specified in the receive option set, a FileReceived notification message that specifies the name of the file.
    • If the receive option set does not specify the TargetDirectory option, it copies the contents of the received file into the body of a FileReceived notification message, and puts this message into the queue specified in the receive option set.
    The value of the MQMD.Expiry field of the notification is set to MQEI_UNLIMITED, so that the notification never expires.
  9. Marks the copy of the received file in the working directory as being ready for deletion. The file is deleted later during the automatic housekeeping process.