BizTalk + BTAHL7 MLLP - Return original nack to sender

Question

In my scenario, a client sends HL7 via MLLP to my BizTalk two way receive port. BizTalk makes a web service call to an external service, receives the response, translates it to an HL7 ACK and returns it to the client, all in a synchronous transaction.

To make this happen, I have an orchestration that is directly bound to the message box, and the BTAHL7 party configuration is set to not route the ACK to the send pipeline on request-response receive ports. Basically I'm turning off the default ACK generation and generating a custom ACK from my orchestration. I have also added an additional filter to my orchestrations receive shape BTAHL7Schemas.ParseError == false so that the orchestration does not receive bad messages, in the event received messages don't match the schema.

Everything works great. In my testing, I am purposely sending bad HL7 messages. In this case, I get a suspending routing error report because no subscribers were found.

The reason for this behavior is pretty clear - I am not subscribing to messages that have parse errors. In the event of a parse error, I want the error ACK to go back to the client. I could allow my orchestration to subscribe to messages with parse errors, and just formulate an error ACK, but I don't have any way to return the actual parse errors in the ACK.

Normally, in an asynchronous architecture, I would turn on the "Route ACK to send pipeline on request-response receive port" and let the BTAHL72X receive/send pipelines handle it. Then the client would get the error ACK containing the error details.

So my question is, is there any way to get the receive pipelines original ACK and return it from my orchestration?

Answer 1

Yes, what you what you want is certainly doable. I don't have an HL7 project in front of my right now so my memory may not be exact but something like:

1. Uncheck "Reoute ACK to send pipeline..."
2. You will need a custom pipeline component to Promote BTS.InterchangeID on the disassembler output.
3. In your Orchestration, implement a Convoy correlated on BTS.InterchageID.
4. The Orchestration will then pick up the HL7 Message and the auto generated ACK.
5. Do you normal processing.
6. Decide which ACK to return, yours or the generated.
7. Return ACK to the TwoWay port.

*Non custom pipeline solution: *

In BTAHL7 Configuration Explorer Acknowledgement tab:

1. Set Acknowledgement type to Enhanced
2. Set MSH15 (Accept Acknowledgement Type) to NE.
3. Set MSH16 (Application Acknowledgement Type to ER
4. Turn on Route ACK to send pipeline on request-response,

It appears to get the behavior I want. Success ACKs won't be generated by the pipeline, letting my orchestration handle it, but application ACK errors will be generated (AR - Application Rejection), and routed to the send pipeline.