拦截并修改Ack响应消息BizTalk 2013 R2

Question

I have written a custom pipeline component assembler to modify the response ACK HL7 message.

I have invoked Assemble(pContext) of Microsoft.Solutions.BTAHL7.Pipelines.HL72fAsm in the implemented method Assemble(pContext) of IAssemblerComponent interface gives me result IBaseMessage which is an HL7, then I do my manipulations on it to fix one of the fields and return that modified IBaseMessage .

All these works just fine, I tried EvenLogger to verify it.

But still the Sender application doesn't receive the modified message, it receives the auto-generated message.

Is there something I'm missing out, why do I not get the custom assembler result out from the SendPipeline of 2 way receive port

Note : BTAHL7 Configuration explorer is configured for original mode. The send pipeline on RequestResponse receive port is set to my custom pipeline

Answer 1

My suggestion is after all the more important points.

The first thing you're employer or customer should say is NO. That is invalid HL7 and you cannot support that.

But, if they are unable to unwilling to comply, the next thing you need to do is inform your management that their non-compliance will cost you a lot of extra time and money to accommodate. To fully support this change will likely cost more then implementing the business messages , I am totally serious. This is not a problem with BizTalk Server, you app or you.

Depending on the relationship, your management can legitimately ask them how they are going to pay for this customization . It's going to cost your side a lot more to break HL7 to comply with them than it will for them to fix it.

Next, and perhaps most important, due to the nature of it's message content, HL7 has very strict completeness requirements, which they are fundamentally breaking . The Trading Partner needs to fully document this requirement to take ownership of it because there is a huge consequence, they are breaking tracing/tracking on you end.

This means that it will be substantially more difficult to investigate and resolve messaging issues for you, not them . This might raise legal or compliance issues your side needs to be aware of.

So, provided you technical, medical and legal teams are all satisfied, the first thing I would try is a Pipeline Component that simply swaps the two values, MSH10 and MSA02. That way, they will receive both values.

Finally, here's a novel solution. Since this is their problem, and a problem for every one of their trading partners, what if you offer help them fix it . All then need to do is what I suggested, swap MSH10 and MSA02 on the received message.