Message processing example
Figure 1 illustrates how MER users and the underlying MER message flows process messages and move them from queue to queue.
- An MER routing flow that contains a single input node (DnqErFinInput for FIN messages or DnqErMsifInput for MX messages) retrieves a message from its source queue 1 , which is an IBM MQ queue. If the message is a FIN message, the input node converts the format of the message from MTFIN to MTXML. If validation is enabled for the node, it validates the message. The node then puts the message into its target queue 2 , which is an MER queue. This target queue then serves as the source queue for the next processing step. The message now contains an indication that it is waiting for a MER user to take the action that is associated with the purpose of the queue.
- A user requests a list of all of the messages in the MER queue. The MER enterprise application reads the contents of the queue 3 and displays a list of the messages it contains to the MER user 4 .
- The MER user selects the message and takes the appropriate action 5 . The message remains in the queue, but the MER enterprise application updates the message to reflect which action was taken 6 . This indicates to an MER message flow that the message is now ready for further processing.
- The DnqErQueueInput node of an MER message flow recognizes that the queue now contains a message that its message flow is to process. It retrieves the message 7 and passes it to the message flow for processing. After the message flow processes the message, its DnqErQueueOutput node updates the purpose and type of the queue specified in the message, thereby moving the message to a new MER queue 8 . This target queue then serves as the source queue for the next processing step.
- A different MER user requests a list of all of the messages in the MER queue. The MER enterprise application reads the contents of the queue 9 and displays a list of the messages it contains to the MER user 10 .
- The MER user selects the message and takes the appropriate action 11 . The message remains in the queue, but the MER enterprise application updates the message to reflect which action was taken 12 . This indicates to an MER message flow that the message is now ready for further processing.
- The DnqErQueueInput node of an MER message flow recognizes that the queue now contains a message that it is to process. It retrieves the message 13 and passes it to the message flow for processing. After the message flow processes the message, its DnqErQueueOutput node deletes the file from the MER queue. If the message is a FIN message, the output node (DnqErFinOutput) converts the format of the message from MTXML back to MTFIN. The output node (DnqErFinOutput for FIN messages or DnqErMsifOutput for MX messages) then puts the message into its target queue 14 , which is an IBM MQ queue.
Each MER message flow must use the following input and output nodes,
which are provided by FTM SWIFT:
- DnqERQueueInput
- This node retrieves messages from the MER message database and routes each message, in FIFO sequence, to subsequent nodes in an MER message flow.
- DnqERQueueOutput
- This node updates a message in the MER Facility message database 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.
These nodes enforce the following rules:
- The message was retrieved by a DnqErQueueInput node.
- Each path through the message flow contains exactly one DnqErQueueOutput node.
- The input and output queues either must be different or, if they are the same, have different processing types. This prevents looping.
- The message is not processed more than a certain number of times (this number can be configured). This prevents recursions.
- The target queue does not have the purpose Create and the type Main.