Is it possible to set an output queue delay?

[Gregory A White]

I have a client that is asking that I hold each HL7 result message in queue until it has aged for 1 hour to build in sufficient time for the image sets associated to the exam to arrive and profile in PACS before my result arrives which would normally mark the image set complete if they were there.

Docs are just too fast on confirming these studies, go figure.

Topic

[Jim Kosloskey]

Greg,

Ask the client to hold his acknowledgment for 1 hour and set your wait time for response to 3600 or greater (assuming TCP/IP).

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Gregory A White]

That’s a good thought Jim, but I’m not sure its that simple in this case because they don’t want to build a 1 hour lag in between each message passed. They do want a 1 hour lag from message creation time to releasing from our queue for transmission.

For example, if I confirm a study (creating the result) at 12:00 and another at 12:05, I want the first one to release from queue at 13:00 and the next to release at 13:05. If the receiver didn’t send the ACK for an hour that would mean the second message can’t go out until 14:00.

[Jim Kosloskey]

Greg,

I am sorry I was trying to be a little facetious and I guess I did not pull it off.

Typically I would expect the receiving system to do any delayed message processing.

I have never done what you are asking within an Integration Engine but here are a couple of thoughts off the top of my head:

First off make sure you understand the responsibility you are accepting.

I expect you could have the messages delivered to a Fileset Protocl with a Tcl proc to emulate the num file protocol. That would place one message per file. The file name should include the Date/Time Stamp of the message and ideally be granular below one second. If the time cannot be granular below a second, then you will probably need to devise a tie breaker to include in the file name (I’ll bet your arrival rate potential is more than one message per second).

Then you can have another thread (I would probably place this in its own process or site) which is Fileset/Local protocol and you will probably need a Tcl proc for the dir parse routine to select the appropriate file(s) to go next (you might also need a ib_filedel proc).

Then route the selected messages to the ‘real time’ TCP/IP thread to the receiving system.

—- OR —-

I guess you could maintain your own suspend DB and manage that at the Outbound Thread wherein you store the current message and pop off he next one eligible, etc.

—- OR — probably at least one other mechanism that MIGHT work.

In all cases, you will certainly need to provide ample logging, backup, archival, access tools, etc. for troubleshooting, controlled resend, analysis, etc.

Again, are you sure this is something you feel your organization wants to be responsible for and something that should be done inside an Integration Engine?

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Michael Lacriola]

I’ll throw out this idea because we had to do sommething similiar. It’s a little involved, but a decent solid solution. Write each outbound message to a unique file name. Then you want to use an inbound directory with a tps parse to only read the files that have aged at least 60 minutes (3600 secs) based on when the file was written.

Hope this gets you going.

[Chris Blair]

I’m not sure of the exact coding required but I would be inclined to try the following approach.

1. When a message comes in, make sure it has an accurate start timestamp.

2. On the outbound TPS, calculate the difference between the current time and the start timestamp. Then sleep/wait for 3600 minus that many seconds.

That seems the simplest to me.

You might also want to consider putting this outbound thread in a process that’s seperate from your other mission critical threads. So that message build-up won’t compromise your other interfaces.

[Richard Hart]

It is possible to set a thread to fileset and get it to create a message every time it ‘runs’ (scan interval).  This message can then  be used as a timer to check on processing in other threads.

We use this technique for load testing in A NON-PRODUCTION environment. Messages are communicated to downstream applications at the same (within reason!) time that the messages were communicated in production.

This is quite complex, but a ‘sleep’ in a thread will sleep the complete process.

[Author]

Replies