Is a nested ACK on EnsLib.HL7.Operation.HTTPOperation response expected

Question

Question

Julian Matthews · Sep 28, 2022

Hi all.

I have setup a HL7 Operation using the HTTP adapter, and I'm getting what seems to me as an unusual response. When sending a sample message to the operation, I am getting a nested ACK. For example:

MSH|^~\&|||xxx|xxx|202209230806||ACK^HTTP^200|00|D|2.1|1 MSA|AA|RWSD7V5iuEC5F6zscDWz|HTTP ACK 'HTTP/1.1 200 OK' : MSH|^~\&|yyy|yyyy|xxx|xxx|20220923080633||ACK^A01|1663916793965||2.3|||||| MSA|CR|RWSD7V5iuEC5F6zscDWz|Error Message Goes Here.

The adapter is spotting the positive ACK in the first part of the message, but the second part is the actual response I need the adapter to be evaluating.

So my question is:

Is this nesting a common way of receiving HL7 ACKs via a HTTP adapter?
Has anyone faced this before and have any advice to give?

ETA - the supplier of the receiving system doesn't believe the first ACK is from them. Is this something being added by the adapter in Ensemble?

Discussion (1)1

Log in or sign up to continue

Julian Matthews · Sep 28, 2022

So upon further review, it seems that the first ACK is being generated by the Operation, and the second one is the body of the HTTP Response.

Basically, the operation will attempt to parse the http response into a HL7 message, and if that doesn't happen, it will then "generate" an ack and write the http response data at the end of the generated ack.

In my case, although there is a HL7 message in the response, it's not being parsed for some reason, so the code moves onto generating its own ack, followed by the http response body, which is the second ack I was seeing.

I'm now replicating the HTTP operation and attempting to pin down exactly where it's falling down, and failing that I will likely reach out to WRC as it seems to be an issue deeper than I can dive.

0 0