C# 截获并修改确认响应消息BizTalk 2013 R2

我已经编写了一个自定义管道组件汇编程序来修改响应ACK HL7消息

我在

IAssemblerComponent

接口的实现方法

Assemble（pContext）

中调用了

Microsoft.Solutions.BTAHL7.Pipelines.HL72fAsm的
Assemble（pContext）
给我结果
IBaseMessage
这是一个HL7，然后我对它进行操作以修复其中一个字段并返回修改后的
IBaseMessage

所有这些都很好，我试着去验证

但是发送方应用程序仍然没有收到修改后的消息，而是收到自动生成的消息

我是否遗漏了什么，为什么不从双向接收端口的发送管道中获取自定义汇编程序结果

注意：BTAHL7配置管理器是为原始模式配置的。RequestResponse接收端口上的发送管道设置为我的自定义管道
我的建议毕竟是更重要的一点

作为雇主或客户，你首先应该说“不”。这是无效的HL7，你不能支持它

但是，如果他们不能不愿意遵守，接下来你需要做的是通知你的管理层，他们的不遵守将花费你大量额外的时间和金钱来适应。要完全支持此更改，成本可能比实现业务消息要高，我是认真的。这不是BizTalk Server、您的应用程序或您的应用程序的问题

根据关系，您的管理层可以合法地询问他们将为此定制支付多少费用。为了遵守HL7而破坏HL7将比修复HL7花费更多

其次，也许是最重要的一点，由于其消息内容的性质，HL7具有非常严格的完整性要求，它们从根本上打破了这一要求。贸易伙伴需要完整记录这一要求以获得所有权，因为这会产生巨大的后果，他们正在破坏你方的跟踪

这意味着调查和解决您的消息传递问题将变得更加困难，而不是这些问题。这可能会引起您方需要注意的法律或法规遵从性问题

因此，如果您的技术、医疗和法律团队都满意，我将尝试的第一件事是一个管道组件，它可以简单地交换MSH10和MSA02这两个值。这样，他们将同时接收这两个值

最后，这里有一个新的解决方案。既然这是他们的问题，也是他们每一个贸易伙伴的问题，那么如果你提供帮助，帮助他们解决它怎么办。接下来需要做的就是按照我的建议，在收到的消息上交换MSH10和MSA02。
同样的问题：您认为为什么需要这样做。你本质上是在破坏HL7，这不是你应该考虑的。我完全同意你的观点，JONS305，但是基于错误观念和误解的贸易伙伴已经开发出一个解决方案，它读取ACK MSH10作为原始消息的参考，现在他们无法纠正他们的系统和客户。我们无法改变供应商，因此作为合作伙伴，我们正在寻找某种解决方案（尽管不是标准的）来解决这一问题。我还想与大家分享，我们设计了一种解决方案，利用开源项目打开mllp连接，作为完成任务的中间件/代理端点服务，请求在这个代理中来回移动，您可能不需要这样做。我以后再补充。