FTM SWIFT routing nodes

FTM SWIFT provides nodes that can be used in custom message flows that route FIN and MX messages. These nodes are called FTM SWIFT routing nodes, and can be of either of the following types:
MER routing nodes
MER routing nodes can be used only by MER routing message flows, which use them to route messages to and from queues:
DnqErFinInput and DnqErFinOutput
The DnqErFinInput node retrieves FIN messages from an input queue and, if necessary, converts the format of each message to MTXML, which is the internal format used by the MER Facility. It can also be set to validate each message.

The DnqErFinOutput node converts a FIN message from MTXML to MTFIN format. It fills the headers required by the interface layer (IL) of the SIPN FIN service, and sends the message to the IL input queue.

DnqErMsifInput and DnqErMsifOutput
The DnqErMsifInput node retrieves messages from an input queue and stores them in an MER queue. It also can validate messages to ensure that they conform to the SWIFTNet specifications.

The DnqErMsifOutput node prepares an MX message for the MSIF transfer service. It fills the headers required by the MSIF transfer service and sends the message to its input queue.

DnqErQueueInput and DnqErQueueOutput
The DnqErQueueInput node retrieves messages from an MER queue and routes them in FIFO sequence to subsequent nodes.

The DnqErQueueOutput node updates a message in an MER queue to reflect the changes that were made to the message during its processing, for example, the new queue value, the new next processing type, the updated message history, and any changed or new application information.

DnqSetTarget
The DnqSetTarget node updates the header of a message with information about the routing target. This information is specified in the node properties.

Output nodes that process messages that are to be sent (that is, ISN messages or SendMsg requests) set the CCSID of the message body to 1208.

General purpose (GP) routing nodes
GP routing nodes can be used by all types of routing message flows and are not limited to MER routing message flows:
DnqCatch
When an error occurs during message processing, an exception list is added to the message. The DnqCatch node processes a message that contains an exception list, generates an event that corresponds to the exception, and forces a roll-back of the transaction.
DnqFinApplicationOutput
The DnqFinApplicationOutput node prepares a message to be sent to a receiving FIN application, uses a destination list or configured values to determine the address of the target queue, and puts the message into the target queue.
DnqFinExtractFromMT021
The DnqFinExtractFromMT021 node can be used to extract a nested APDU from a FIN MT 021 Retrieved Message (Text and History).
DnqFinInput
The DnqFinInput node retrieves a message from a sending FIN application and prepares the message to be routed by means of XPATH conditions.
DnqFinServiceOutput
The DnqFinServiceOutput node prepares a message to be sent to the SIPN FIN service.
DnqGenericMqOutput
The DnqGenericMqOutput node performs integration tasks for external interfaces. It writes a record to the message warehouse, if configured to do so.
DnqMessageCopy
The DnqMessageCopy node duplicates a message that it receives at its input terminal and sends the original message to its output terminal. The copy is enriched using the parent message ID and is sent to its copy terminal.
DnqMsifInput
The DnqMsifInput node prepares an MSIF message for subsequent routing.
DnqMsifServiceOutput
The DnqMsifServiceOutput node prepares a message to be sent either to the MSIF transfer service or to an application that processes MSIF messages.
DnqPrintInputAdapter
The DnqPrintInputAdapter node stores messages that are to be processed by the Print Service. The messages must already be in MTXML or MX format.
These nodes can be used to process the following types of messages:
  • Messages that employ message structures used by the SIPN FIN and FMT FIN services:
    • ISN messages, except ISN messages that contain a stand-alone FIN acknowledgment
    • OSN messages
  • Messages that employ message structures used by the MSIF transfer service:
    • SendMsg requests and SendMsg responses that contain an InterAct payload
    • MsgReceived requests, responses, and notifications
These nodes process the contents of such messages, for example, they extract elements from an OSN message or a MsgReceived notification and add them to the ComIbmDni/Dnq/Properties folder of the Environment tree. These nodes tolerate messages that employ other message structures (for example, FIN ISN messages that contain a stand-alone FIN acknowledgment or MSIF DeliveryAck notifications); however, they do not process the content of such messages.

The FTM SWIFT routing nodes that process MT messages require that those messages be in MTXML format. If a message is not already in this format, it can be transformed by an input routing node (DnqErFinInput or DnqFinInput), or by the standards processing node (DniStandardsProcessing).

During transformation, the original FIN message, in MTFIN format, is retained in the ComIbmDni folder. As long as the contents of the FIN message remain unchanged, this version of the message is used whenever a component requires the message in MTFIN format. If the message in MTXML format is never changed, the output node passes this version of the message to the output queue, rather than waste time and effort by converting the unchanged message from MTXML back to MTFIN format. However, if an application modifies the contents of the FIN message, it must remove the original FIN message from the ComIbmDni folder. This indicates to the output node that it is to transform the changed FIN message from MTXML to MTFIN format, then pass the converted message to the output queue.