Transaction Server Messaging API configuration

The Transaction Server and the Distribution engine use the Messaging API protocol to send and receive messages using WebSphere® MQ queues. For more information, see Setting Up a Messaging API Event Handler.

The diagram in the following figure illustrates a typical notification interaction between a Transaction Server and a Distribution engine:
Figure 1. Notification interaction
gpy_izgd_PresentmentFlow.jpg
The types of event notifications in the above diagram are:
  • PresentmentStateChange (presentment state change event)
  • paymentReady (Image Compliance Reviewed, Duplicate Reviewed)
The PresentmentStateChange message is a guaranteed delivery message to ensure that the Distribution engine receives these notifications.

A Work-in-Progress (WIP) record is built to enable the Control Center to track the message. When the Transaction Server receives a response from the Distribution engine, it posts the WIP record as complete. If the response is not returned as expected, the WIP record is left as incomplete. Incomplete WIP records can be picked up by the Control Center and reissued, ensuring that the PresentmentStateChange is delivered and the associated work is performed.

The PresentmentStateChange notification is first issued when a requisite set of states is reached in the Transaction Server as defined in the event configuration. Subsequent notifications are sent as other states are reached. All PresentmentStateChange messages are synchronous and require a response from the Distribution engine. A time out is used to ensure that the Transaction Server does not wait indefinitely for the response.

paymentReady notifications are posted for every transaction as the Suspect Image Review or Duplicate Detect engine completes a review for that transaction. There can be many of these, depending on the size of the batch (ICL) and the percentage of exception transactions. These messages are asynchronous and are not guaranteed for delivery. The Distribution engine needs only a single PresentmentStateChange message to account for any paymentReady messages that might have been missed earlier. The last PresentmentStateChange notification causes any outstanding paymentReady messages to be processed, which guarantees that all work is posted to Distribution.

The following additional notifications are required by the target application:
  • endOfDayCheck
  • purgeBusinessDay