Becoming a Real-Time Payments (RTP) “participant” has numerous challenges. For many financial entities, this is their first exposure to IBM MQ as a messaging system, which is a requirement to join the network.
The Clearing House’s RTP represents the next evolution of payments innovation for instant transfer of funds and confirmation. Financial institutions, big and small, are offering Real-Time Payments to their customers to stay competitive.
This article provides basic scenarios and explanations in regards to expiry messages, and the IBM MQ generated reports identifying expired messages.
IBM MQ MESSAGE EXPIRY WITH RTP
At its fundamentals, the RTP network is built upon the concept of MQ request/reply. For example, a participant sends a request message following the ISO 20022 XML standard. These request/reply messages have a short lifespan, and if the message isn’t consumed by the expiry time set, an MQ Expiry Report is generated on the queue property and returned to the participant’s response queue.
For example, when generating a request, it is the participant app’s responsibility to set the message expiry duration and indicate if an expiry report should be generated to be seen on the queue property. Also, the reply-to queue and queue manager would be set by the participant app’s request message, to complete the request/reply round trip.
SCENARIO 1: HAPPY PATH
The overall lifespan of the “transaction” is fifteen (15) seconds, but the “hops” between the participant to RTP to participant and back are two (2) seconds each between its respective queue manager. The Clearing House’s RTP documentation provides a chart to explain further and is outside the narrative of this article.
When everything works through “happy path”, it’ll be as shown above: the participant app sends a request message and awaits a response within the 15-second window.
SCENARIO 2: TCH-RTP APP DOES NOT READ MESSAGE
When the message is delivered to RTP and isn’t read off the queue in time, it’s considered “expired.” An internal IBM MQ process detects this the next time an app opens the queue for input, then generates a report expiry message, and sends it back to your queue manager. The message payload is the xml request message that the original participant app sent.
When you get the message, the way you can tell which queue manager generated the expiry message is in the Put Application Name within the MQMD. In this case above, it’s from RTP.
SCENARIO 3: MESSAGE STUCK IN THE PARTICIPANT XMIT QUEUE
It is possible for your request message to get stuck on your XMIT queue. This is due to the sender channel being unable to communicate with its companion receiver channel. When the message is considered “expired,” an internal IBM MQ process detects this and generates the expiry report as shown above.
When you get the message, the way you can tell which queue manager generated the expiry message is in the Put Application Name within the MQMD. In this case above, it’s from your qmgr.
CONCLUSION
Setting message expiry is another hallmark of IBM MQ to ensure messages are consumed within a prescribed amount of time. Expiry reports are a type of report generated by the queue manager if the message is discarded before delivery to an application.
The concepts within this article are not limited to MQ messages between participants on the RTP network; they can be used between any IBM MQ-enabled applications.
WANT TO LEARN MORE?
TxMQ delivers an RTP Starter Pack to accelerate participant onboarding. You can learn more about our starter pack here: https://www.txmq.com/RTP/
Our deep industry experience and subject matter experts are available to solve your most complex challenges. We deliver solutions and innovations to do business in an ever-changing world, to guide & support your organization through the digital transformation journey.
This post was authored by John Carr, Principle Integration Architect at TxMQ. You can follow John on LinkedIn here.
