MQSeries.net :: View topic - Understanding the mechanics of mqsistopmsgflow

jrsetters · Posted: Tue Oct 23, 2012 5:43 am Post subject:

We have an outbound HL7 flow using the GenericHL7Out node to send patient demographics and orders to an external system at a satellite office. The vendor's software is not very stable and the office shuts down the inbound servers when they leave for the day. (We have no control over this).

Typically, we would not send them messages after this time frame, but on occasion something will be entered in the ordering system that generates an outbound message while the external system is down.

Part of our standard workflow is to incorporate email notifications into out outbound message flows. These are part of an eSQL loop that reads the local environmental variable 'RetryCount' and approximately every 15 times the message is retried sends an email to a support group. This variable is set in the properties of the GenericHL7Out node as maximum retry attempts.

One way we thought of dealing with the problem with this one system is to write a Unix job to use mqsistopmsgflow every day at 5pm for that particular outbound so if any messages do land in the queue, they will just stay in the topic the queue subscribes to until a second job starts it at 7am.

One odd thing that happens when we tested this is that if there is currently a message in the flow in a retry state (the external is down and it is counting through the maximum retries), when the flow shuts down, we will get 10-15 email alerts instantly as if it is trying to force its way through the total retry count. So lets say it is on retry attempt 40 out of a maximum of 300 and we stop it, we will get alerts for the next 4 or 5 retry increments (usually up to the 90th or 100th retry), however it won't go all the way up to 300.

It is as if the stop flow command forces the flow to process through some random number of retry attempts before it quits. This is not a huge deal, and we can always replay that message, but it makes me wonder what is happening and if there is some other way to make the flow handle an interruption.