Only process messages within a certain timeframe for LLP-Trans channel

I have a LLP-Trans channel that receives HL7 messages and makes HTTPS calls. I would like to limit the processing on this channel to a certain window of time, while also maintaining the LLP connection so that the vendor can continue to send messages, even outside of the processing window. I tried setting this up by using a function within the To Translator script to determine the required SleepTime, if any. The first HL7 message that is received by the channel after the processing window closes will set the util.sleep() so that the message is queued for 21 hours (the processing window is only three hours). This works great – the message is queued and any subsequent HL7 messages received are queued. The problem is that when the SleepTime expires (21 hours later) the message does not process. I’ve tried testing with smaller sleep times (10-15 minutes) and it works as expected. Is there an issue with using the util.sleep() function to delay processing for longer periods of time?

Additionally, is there a better way to handle this situation in Iguana without having to use multiple channels?

Thanks.

Iguana’s queue is not meant to archive messages, but to process them through as fast as possible.
Use SQLite, included with Iguana distribution, to create a local table and store all messages that require delay.
During processing window (of 3 hours) activate channel which will process all of the current, pending processing, table content.

Thanks, Lev. It sounds like the solution you are proposing would require a second channel, correct?

What is the mechanism for scheduling the activation and deactivation of a channel?

Is there any reason why the sleep function should behave differently when it is given a longer sleep time? If the channel would wake from the sleep after 21 hours, then the current config would work perfectly. I’ve also set the Timeout in the Translator script to 23 hours – iguana.setTimeout(82800) – but don’t think this is the cause.

The way you force it to act is not the way Iguana is meant to be used. A dead end from design perspective. Does it require a second channel? Not in necessary. Try it as a programming exercise, to combine all of required logic in single channel. How “mechanism for scheduling” works – we offer at least two examples in online Knowledge Base; one of them is exactly what your desired scheduling has to be built like.

Lev:

I would like to revisit this. Tsuacci works with me. I am wanting to delay the processing of messages also. I would like to implement a solution that delays a message for X number of seconds before processing.

Is the SQLlite db solution one that is still relevant for Iguana 6 or is there another method. I search for “delayed processing” and couldn’t find the examples that you mentioned are already out there. Can you point me to a few specific examples such that the work to do this may be minimized?

Yes, the SQLite solution is likely the easiest to implement without the acquisition and implementation of a 3rd party database solution.

Are you interested specifically in a fixed delay, or would a minimum delay work for each message? The latter might be implemented by having an inbound message trigger both its insertion into the SQLite database and a scan for (and subsequent delivery of) “suspended” messages that meet the minimum delay criteria. This could be accomplished entirely within a single channel. The downside is that, if no messages are received from the external system for an extended period, there may be some number of messages that were “suspended” with no opportunity for delivery.

A more robust solution would be to implement two channels; one that receives via LLP and inserts, via translator, all inbound messages to the SQLite table with an associated timestamp column. A second channel would be configured with an inbound translator that triggers periodically and scans the SQLite table for messages eligible for delivery. When found, it forwards them to their destination. The translator in the second channel would also be responsible for periodic purges of the suspense table to keep performance and storage at acceptable levels.

I’ve developed a similar facility for a customer that needed to suspend messages for patients that had not yet been assigned a local ID (MRN) for their clinic; an external process would update a MSSQL-based lookup table with new local IDs for each external ID received and Iguana would periodically scan that for new matches. Implementing a time delay would be relatively simple in comparison.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

Hi Jeff:

Could you respond by zipping up your code and posting here? I assume I would use SQLLite locally on my Iguana server to provide the storage whereas you used an external MySQL database, correct?

Dan

No, sorry. The code was developed under contract with a customer and the IP rights remain with them.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com