The MERVA Bridge

The MERVA Bridge is a MERVA component that provides the connection between MERVA and FTM SWIFT. It is based on the MERVA MQI attachment, which is described in MERVA for ESA Version 4: Concepts and Components. Each MERVA Bridge carries out the following operations:
  • For each outbound message:
    • Adds FTM SWIFT header information to the message before putting it into an IBM MQ queue
    • Validates the message
  • For each inbound message, analyzes the FTM SWIFT header, extracts certain information, and puts this information into MERVA message fields

Each OU for which FIN messages are to be transferred requires at least one bridge of its own, because each OU has its own set of queues, and each bridge corresponds to one set of queues. A single OU can have any number of bridges. The more bridges an OU has, the higher its throughput, because the bridges work in parallel. The bridge send process uses a parameter to specify to which OU it belongs.

Figure 1 shows the queues involved in the processing. The creation of COA and COD reports is optional: however, if these reports are omitted, less information about the processing state of a message is available to MERVA.

Figure 1. Outbound message flow
Figure showing outbound message flow

The names of the MERVA queues shown in Figure 1 are those that are used in the sample DSLKPROC customization table that is delivered with MERVA. For each processing step, the message is moved from one MERVA queue to the next:

  1. An application puts a message into the MERVA send queue (DSLWFNIN).
  2. From there the bridge transfers the message to the input queue of the FTM SWIFT message flow for FIN input messages (DNF_ILC_FIN).
  3. The message is also stored in the MERVA "wait for COA" queue (DSLMRCA1).
  4. When the message arrives on the target queue manager, IBM MQ puts a COA into the Bridge reply queue.
  5. After the COA arrives in the reply queue, the COA is correlated and the message is moved to the "wait for COD" queue (DSLMRCD1). Usually, this step is completed quickly; however, if you use a remote queue connection, this might take longer, as the message must first be received by the target queue manager.
  6. DNF_ILC_FIN retrieves the message and begins its processing.
  7. After the message is processed by the service for SWIFTNet FIN messages, a COD is sent by the queue manager and put into the MERVA Bridge reply queue. When messages stay in this queue for a long time, this indicates a processing problem with the broker or the FTM SWIFT message flows.
  8. The message flow for FIN input messages stores the received messages in the table DNF_OAMS.
  9. Upon receipt of the COD, MERVA Bridge moves the message to the "wait for ACK" queue (DSLMRAW1). The message stays in this queue until the SWIFT ACK is received. How long this takes depends on whether a session to SWIFTNet FIN is currently open, and on the number of messages with higher priorities that are waiting in the DNF_OAMS table. The SWIFTNet FIN protocol enforces a sequential sending of messages controlled by input sequence numbers.
  10. The ILS_ACK flow receives the SWIFT ACK from the session. The ACK is correlated with the original input message from the OAMS, and is placed into the Bridge reply queue.
  11. After the ACK is placed into the Bridge reply queue, the message is moved to the "processed messages" queue (DSLMRRQ1).

If messages are moved very quickly from DSLMRAW1 to DSLMRRQ1, this might indicate a message flow problem. In this case, the message flow would generate a negative acknowledgment and complete the processing of the message immediately. The relevant error information is stored in the MERVA MSGACK field similar to the standard SWIFT Link processing used for the STN.

The use of COAs and CODs is optional and is customized in the MERVA Bridge by specifying the corresponding wait queues in the DSLKPROC table. For performance reasons, it is recommended not to use them; however, if you must use one, use CODs only.

The receiving side is much simpler, because there is only one receive queue, that is, only one queue in which the FTM SWIFT message flow for FIN output messages (DNF_ILS_FIN) puts messages, as shown in Figure 2.

Figure 2. Inbound message flow
Figure showing inbound message flow

The messages are transferred by the MERVA Bridge to the received messages queue (DSLMRRQ1).

To ensure the integrity of the messages, the bridge uses control queues located both within MERVA and within IBM MQ. The MERVA control queues are:
  • DSLMRC1Q for the send process
  • DSLMRCQ1 for the replies from the send process
  • DSLMRCQ4 for the receive process
A control queue is needed only for the send process.