Possible duplicate emission (PDE)

If a counterpart encounters a problem during an attempt to send a message or file, the counterpart can choose to send the message or file again with a PDE indication in the end-to-end control fields. When an MSIF transfer service receives such a message or file, it creates a scenario for it, and uses this information in the end-to-end control fields to determine whether the message or file was already received. To correlate a request primitive with previous primitives, it uses the SWIFT message ID (Sw:MsgId). This is not the MQMD.MsgId of the received message, but instead is a unique ID provided by the sending application.

You can specify, for each receive option-set CO (that is, each CO of type DnfEfaMsgReceiveOptionSet or DnfEfaFileReceiveOptionSet), whether duplicate transfers are to be allowed for the scenarios that use that CO:
Duplicate transfers are allowed for PDEs
All inbound transfers are accepted and a reason code indicating that the transfer is a possible duplicate is passed to the receiving application:
  • For a message transfer, the MSIF transfer service includes message DNFO2612E in the MsgReceived notification.
  • For a file transfer, the MSIF transfer service includes message DNFO1210I in the FileReceived notification.
Duplicate transfers are not allowed for PDEs
If the MSIF transfer service determines that a transfer is a duplicate:
  • For a message transfer:
    • If automatic response mode is used, the MSIF transfer service accepts the duplicate message, but does not deliver it to the application. The MSIF transfer service issues event message DNFO2611I.
    • If flexible response mode is used, the message is delivered to the application in a MsgReceived request with a possible duplicate indication. The MSIF transfer service includes message DNFO2612E in the MsgReceived request. The application must handle the duplicate message and send the appropriate response to the MSIF transfer service, which passes it to the SIPN via the SAG.
  • For a file transfer, its reaction and the value it assigns to the Sw:TransferAnswer field in its response depend on the state of the original transfer, as shown in Table 1. The file transfer states for a FileReceived scenario are described in Table 1.
When an MSIF transfer service receives a PDE that it cannot confirm is a duplicate:
  • For a message transfer, it includes message DNFO2625I in the MsgReceived notification or request.
  • For a file transfer, it includes message DNFO1210I in the FileReceived notification.
Table 1. Possible reactions to a duplicate file transfer when duplicate transfers are not allowed
State of original file transfer scenario Sw:TransferAnswer Reaction
TransferComplete
DelivComplete
DelivWarning
DelivFileInError
Duplicate
 Duplicated Because the receiving application already received the file, the MSIF transfer service rejects the new FileAct message, and does not notify any application.
Accepted
CancelRequested
CancelAbortRequested
CancelInProgress
Canceled
Failed
FetchRequested
FileReceived
Initial
Invalid
Rejected
Responded
Error
Aborted
 Accepted Because the original file transfer attempt will never result in the receiving application receiving the file, the MSIF transfer service accepts the new FileAct message, and specifies the following in the FileReceived notification that it sends to the receiving application:
  • The completion code PartialOk
  • A reason code indicating that the transfer is a possible duplicate