LLP->Trans channel error: Message still queued

We have an LLP->Trans channel which reads HL7 messages.
If something goes wrong in the destination script, we would like to stop the channel with an error.
In this case, it seems that the message which triggered the error is still queued in the channel. I.e. if I restart the channel, the same message will be reprocessed which most probably leads to the same error again.

Is there a way to:
a) Stop the channel with an error, but set the message as processed, so it is not queued any more?
Or, alternatively:
b) Clear the channel’s queued messages via the HTTP API?

a quick answer is ‘no’ and ‘no’, respectively. but one could use module ‘store’ (in Wiki) to record in a table some specific parameter for this message (to identify it uniquely) and if same message pushed from queue again – to ignore it.

An alternative would be to trap the error with an exception handler (see pcall()) and when an exception occurs, log the message to a file and optionally send an alert. This would have the effect of marking the offending message as consumed, but it wouldn’t stop the channel.

I’m not sure what would happen if, as part of the handler, you invoke the API to shut the channel down. That would be an interesting experiment 🙂

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

Hi roho,

If I understand your requirement correctly you can always set in the translator

iguana.stopOnError(false)

This will log the error, consume the message and continue on processing. You can then setup some error notifications around this? This would however be an automated approach and the risks would be around message sequencing if that is important to you. It would also skip on error for anything else on the channel unless you specified a conditional for the stopOnError.

Hi, thank you for the proposals!
Our requirement is if we receive a bad message (e.g. when hl7.parse throws an error) to stop the channel with an error. This is because we assume some HL7-sending application has a bigger problem, and the user should have a look on that.
Also, we react on the channel status in another application. We read the channel status via the HTTP API, and we would like the channel to be red there, so the user gets notified.

So, the proposal not to stop the channel is not really what we want.

I think the best workaround would be to go for something like lev’s proposal:

• If the message parsing fails, write the message, or a hash value of it, to a temporary “failed_message.txt” file. Then, stop the channel with an error.
• When starting the channel and receiving a message, first check for “failed_message.txt”. If it exists and matches the received message, delete the file and ignore the message. This will unqueue the pending message. If the file exists and doesn’t match, just delete it.