Delay Message to target system

[manoj thotakur]

Hello ,

Is there any way to delay the transaction to reach the target system?

I have the TCPip interface and I use the xlate for mapping.

Is there any way during the mapping or post mapping to delay the transaction for 30 seconds and release it to the target system.

Thanks for the help.

Englewood Hospital.

Topic

[Peter Heggie]

Putting a delay in an interface, especially in a translate, allows risk to normal internal engine processing. I’m very sorry I can’t give you specific examples – this is my intuition based on many previous discussions here on message flow through various queues.

You can minimize the risk by building a single pair of threads with one route detail.

Perhaps a simple alternative is to use a second pair of threads. The outbound thread of your first pair writes files to a directory and the inbound thread of the second pair reads files from the same directory. You would build a tcl tps proc that is used as a directory parse proc.

When the files are written to the directory, the file name consists of a timestamp that includes seconds. The directory parse proc would get the list of files in the directory, and determine which files, based on the timestamp, are old enough to process. The timestamp would have to be 30 seconds old.

Peter Heggie

[Rob Lindsey]

Another thing you could do is to setup on your inbound to write to a SQLite (assuming you have the proper version of CL to use SQLite) and put the data in the DB table by timestamp.  Then have another thread (there might be a way to do it on a single thread) read from that table and get everything that is older than 30 seconds previous to the current time.

Do NOT use sleep or wait or put in loops to make the xlate or TCL pause for 30 seconds.  That will really make things go weird.

Rob

[Mark Thompson]

Another solution is to set up a fileset-local thread to write the message to a file in the directory of your choice – we call them queue directories.  That same thread can read files from your chosen directory.  A directory parse proc allows you to only select files over 30 seconds old.

Pros:

– You can easily monitor what is in the “queue” by doing a directory listing from the operating system.  (More familiar to most folks than SQL commands)

Cons:

– Messages in the queue don’t show up in the recovery database – won’t be included in RDB alerts.  (Also true for the SQL database)

– Tcl coding required for the directory parse proc.

- Mark Thompson
HealthPartners

[David Coffey]

Putting a sleep or a wait in a thread (sorry we do our interface work in TCL, so I do not know the equivalent function in the GUI) will cause the entire process to sleep.  This is probably not an acceptable side affect.

You could drop the message in a database and use the MSH time value as the key.  Any messages where the delta between the key and the current time is greater than 30 seconds and these are forwarded to the end point.   Be sure to delete anything sent onward.

[Bob Schmid]

💡 this has been a somewhat frequently requested “fx” by cloverleafer’s…with perfectly acceptable methods given via clovertech to “simulate” the delay ie…using primarily a file protocol to write and than a delayed read …….which effectively addressed the need.

I (think) I understand the issue with sleep in the tcl interpreter within a site…and have witnessed it’s impact

[Peter Heggie]

right – so.. maybe something in the (outbound) thread IP protocol configuration. We already have a setting for Reopen Time, so that implies some kind of timer processing in between connections.. so maybe another timer could be implemented ‘during’ connections

Peter Heggie

[Jim Kosloskey]

Here is my .02.

The few times I have run into this I had a discussion with the receiving system.

I wanted to determine how modern software using real-time exchange needed to have lengthy delays between messages.

In some cases it was due to simply not sufficient horsepower on the receiving system.

In one case it was a design which had been file based but in order to market the product they changed it to real time protocol (tcp/ip) but did not address any of the message handling. Found out they could control the delay on their end by simply not acknowledging until they were ready to receive another message. Still ended up with a 30 second delay and the messages backed up in the Recovery DB. We put them in their own site so they did not impact anyone else. This system was always behind (as any system needed 30 seconds wait would be in a modern environment) so I always wondered just how useful this data was.

In another case, the system was configured to share the same file system for the Transaction queue and the Application DB. With normal message flow the file system filled up and stalled everything. In the conversation it was revealed that the 2 entities did not have to be on the same File System. Once they were split all was well.

So before making Cloverleaf adapt, perhaps a discussion with the receiving system could provide an answer.

The bottom line question for me is, if a system requires long delays between processing messages, what use are those stale messages to the receiving system? The rest of the hospital is already down the road.

Like I said at the beginning just my .02.

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

[Peter Heggie]

I agree – it is better to get the receiving system operating at nominal capacity.

We have a ‘problem child’ receiving system that refuses to modernize. I’ve set the Reopen Time and other parameters accordingly. Net Monitor shows it as down most of the time. We have learned to ignore it. Someday it will be replaced.

Peter Heggie

[Author]

Replies