Handling asynchronous ACK in Mirth

Question

I've developed a channel in Mirth that sends an ORU message. The ACK will be then sent back asynchronously to a different channel on a specific port.

In order to be able to resend the ORU message in case an AR or AE is received back in the ACK I need to store this ORU somewhere to get access to it later when the ACK is received (remember it is asynchronous).

I am figuring out how to achieve this. My idea looks like this:

• send ORU message and store it in a database
• in the other channel wait for incomming ACKs
• for an incomming ACK look for the related ORU in the database and depending if the ACK was positive or not, remove the ORU or resend it again

It would be nice if someone of you has some experience with it and can tell me if this is a proper way to do it and if not, how. Case the idea is good, how should I implement the third step? I have already tried with a single channel but I cannot manage to resend the ORU.

Answer 1

I think your approach is reasonable. We tend to shy away from hard deletes and instead mark the message as "acknowledged" with the time the ACK (or NACK) message arrived. This gives you the ability to query for ACK/NACK/NULL and gives you a history of responses.

We keep track of our ORU by sampleId/timestamp and make note of the messageID. The messageID comes back in the ACK/NACK so it's easy to match up.

You probably don't want to resend (automatically) NACK'ed messages because what-ever caused the NACK in the first place (like a format issue) will not likely be resolved with a simple resend. Instead you may want a NACK to trigger an alert (like an email) to some group that can make the fix and resend manually.

You'll have to decide if you can safely resend missing "ACKs" and how long you should wait. Those are more business decisions than technical ones. For instance, you didn't receive an ACK/NACK, but was that because of network hiccup, an issue with Mirth, or did your original message actually not go through? If the receiving system is counting on 1 and only 1 message, then you'll need some way to reconcile before resending those messages that received no ACK.