Wednesday, 6 April 2016

Mirth destinations not waiting for previous destination

The other day I had sent off a channel to one of the implementations guys and he installed it on the customers system.
It had three Web Server Sender destinations in a row that had to be executed in order.  AddPatient, AddVisit, and AddAppointment.   No problem I thought, "Wait for previous destination" was checked on all of them.

However I later received a report that the customer was getting errors of the sort that could only happen if the destinations had not been executed in the right order.  The appointment was being added without a visit, and sometimes without a patient.

I tried replicating the problem locally, but had no luck, so I gained remote access to the site. I first located an instance of the problem and checked that there wasn't an error in the first couple of destinations - there wasn't.

Sure enough though, when I look at the timing of the message, all the destinations trigger at more or less the same time, while the responses happen much later.

So I opened the channel and checked that the "Wait for previous destination" was checked.  Sure enough all looked good, but then I noticed the problem.  Someone had changed my pattern to queue the destinations.

Mirth Destination
I don't know if it was the implementation team, or the customer, but someone was making the mistake of thinking everything is more reliable if queued.  I checked the "Wait" and "Queue" tool-tips, and they don't mention that setting queuing overrides the wait, so they can't be blamed for missing this one really.  Maybe the Mirth guys might want to include this in their tool-tips.

No comments:

Post a Comment