Fast ACK Information

I have not been able to find much documentation on the Fast ACK option on LLP channels. I am looking for some details on what checks are performed on the message to ACK or NAK accordingly. Can anyone point me in the right direction?

Greg Tataryn | Interface Engineer | Glytec Systems | e: gtataryn@glytecsystems.com

As far as I can tell, Fast ACK ACKs everything, even grossly malformed messages. If the MSH is missing or unreadable, this will be the ACK sent to the source system:

MSH|^~\&|UNKNOWN|UNKNOWN|UNKNOWN|UNKNOWN|||ACK|UNKNOWN|P|2.3|
MSA|AA|UNKNOWN|

If you want to be able to NAK messages that meet (or don’t meet) certain criteria, you should look into the Translator option for generating ACKs.

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

Thank you for the information. That is a little concerning that it likely positively ACK’s everything, even if malformed. Definitely will be looking into making some changes.

Greg Tataryn | Interface Engineer | Glytec Systems | e: gtataryn@glytecsystems.com

Generally (IMHO), you’ll want an interface engine to accept everything it gets and do any sort of malformed message handling out-of-band. Why NAK a message when it will only slow things down?
Fortunately, iFW provides the Translator ACK option, which gives you very fine-grained control over what’s sent back to the source system. You can do any message or string processing, database queries, web service calls, etc. in the ACK Translator that you can perform in a Filter or other Translator, but in the end what needs to happen is that an ACK or NAK gets sent back to the source system.
Fast ACK is there for speed. It very efficiently extracts the necessary field data from the MSH to build the ACK’s MSH and MSA segments, and fakes it if it can’t. I think that’s a good thing.

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