MSIF transfer services

This section describes the syntax and message structures for the requests and responses that applications pass to the MSIF transfer services and the notifications and requests that the MSIF transfer services pass to applications.

When writing applications that use the MSIF transfer services, keep the following points in mind:
  • The interface queue of the MSIF transfer service has a name of the form: 
    instance.ou.DNF_O_FT
  • Depending on the MSIF transfer service you use the interface queue has a name of the form: 
    instance.ou.name
    where name depends on whether you send a request or a response message. If the message is:
    A request message
    name corresponds to the MSIF transfer service name in use:
    • DNF_O_FT
    • DNF_O_FT1
    • DNF_O_FT2
    • DNF_O_FT3
    A response message
    name is similar to the MSIF transfer service name that has issued the corresponding request message, extended by characters UMH:
    • DNF_O_FTUMH
    • DNF_O_FTUMH1
    • DNF_O_FTUMH2
    • DNF_O_FTUMH3
    Attributes MQMD.Reply2Q and MQMD.Reply2QM of the corresponding request message specify the queue name and queue manager to put the reply message in.
    Note: Although the MSIF transfer service names differ, the name of the FTM SWIFT service folder is DNF_O_FT for all services. That is the API message looks exactly the same for all services.
  • The attribute MQMD.Expiry is set to MQEI_UNLIMITED for all messages the application receives from the MSIF transfer, that is, those messages do not expire. Therefore, the reply queue specified in a request must be a local, remote, or alias queue.
  • Each file-transfer or message-transfer scenario is identified by a unique identifier (its MSIF reference). This reference is the value of the MQMD.MsgId of the request that initiates the scenario, for example, a SendFile, SendMsg, or ProvideFileForDownload request. Therefore, an application does not need to wait for a response in order to be able to identify a scenario. An administrator uses this reference to uniquely identify a scenario, for example, when canceling or recovering it.

    Because the MSIF reference is identical to the MQMD.MsgId of the request and is used to uniquely identify the request, an application must ensure that the MQMD.MsgId of each request is unique. Requests with duplicate MQMD.MsgIds are rejected.

  • The MessageGroup element of the ComIbmDni folder can be set by the application that generates the request. If it is not set by the application, the MSIF transfer service sets it when it processes the request. This MessageGroup element is repeated in each response or notification that corresponds to the original request.
  • A file that a business application passes to MSIF and that is processed in a file transfer scenario must be accessible and readable for the MSIF transfer services until the corresponding transfer scenario is finished.