Another one of the gotchas (yes, my blog seems to be full of them) is the ‘association’ of the acknowledgment with the original message that is generated from the BTAHL7 receive pipeline. In the BTAHL7 Configuration explorer, by default the Acknowledgment settings are as follows:
Notice that the MSH15 and MSH16 overrides are set to AL- Always generate the System and Application Acknowledgment, and that below the Route ACK to send pipeline on request-response receive port is checked. This means that the default behavior of the pipeline is to generate two acknowledgments, and route one of them back along the receive location’s send pipeline. What is it supposed to do with the second acknowledgment that it created?
That is where the error message is generated: Event ID 5778: The Messaging engine failed to process a message submitted by adapter: MLLP Source URL:{whaver server:port} Details: The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted.
The resolution: a simple solution is to create a send port for this data and drop it off as a file.
Not quite the elegant solution that I want to deal with, as now there is a maintenance aspect of making sure that this folder is purged.
Let’s just not create the application acknowledgment. You do this by changing the parties definition from Original to Enhanced mode and turning the application acknowledgment to NE (never).