Not able to suppress ACKs
Hope someone can help me understand how to suppress ACKs on LLP Listener. I have created a basic channel from LLP Listener to Translator with custom translator as ACK. The code for ACK translator is:
-- The main function is the first function called from Iguana. -- The Data argument will contain the message to be processed. function main(Data) -- Send no ack ack.send(nil) end
There is no filter and no code for destination translator.
Nevertheless, upon receiving a message on the LLP Listener channel stops with the following error:
[string "No_ACK-Ack-kcDw1TkhjVzZFz/main.lua"]:5: Please pass in an ACK as a string or HL7 node tree object. Stack Traceback : [C]: in function 'send' [string "No_ACK-Ack-kcDw1TkhjVzZFz/main.lua"]:5: in function <[string "No_ACK-Ack-kcDw1TkhjVzZFz/main.lua"]:3>
Our engine version is 6.1.0.
How about not calling ack.send, instead replacing it with
I haven’t tried this … I’m just replying with a hunch 😉
Thank you for the reply Jeff. Tried different variations with the return and ack.send statements, and still end up with an error.
Looks like the LLP listener is going to force you to send something as an ACK, so the key will be seeing what you might get away with.
I’ve set up a little test with Iguana receiving messages from another interface engine that doesn’t expect ACKs, and then called ack.send() with just a carriage return as an argument:
I’m not sure your application will let you do this, though, as Iguana will still send a carriage return in an LLP envelope to the source system. Just because I’ve told my other engine not to expect ACKS doesn’t mean that it will error if it receives something … It ignores data returned rather than failing.
You are correct, if we could control the behavior of the sending system to ignore the \r. Calling
Still results in
ACK generation script did not call ack.send()
It’s probably worth sending an email to the Support team at Interfaceware, Sergei. I’ve also run into interfaces that have odd ACK requirements, and while the custom ACK feature handles most of them it doesn’t cover every possibility.
I ran into a situation not too long ago where the sending system expected LLP envelope characters on the ACK that were different from the message received. Obviously a coding mistake on the external vendor’s end, but sometimes it’s just more expedient to code around it yourself where possible.
Interesting – it would have to be a change to the product. Sergei – if you can reach out to us directly through the support channel and help us understand the context and have a conversation we can take it from there.
Thank you for your replay. We had the conversation with the support team, and seems this is a hard-coded requirement to issue an ACK from the ACK Translator. There are a number of use cases when a custom script is necessary and having an ability to suppress a response would be great.
One of the use cases is Quest Diagnostics to Epic results interface. Since Epic has developed a custom interface for Quest, including a custom ACK, such interface would be a complete pass-through for messages and ACKs. Certainly the logic for the custom ACK can be implemented in Iguana, but this require constant maintenance if Epic or Quest update their logic.
You must be logged in to reply to this topic.