BizTalk 2016 WCF-WebHttp 缓存标头答案

【问题标题】：BizTalk 2016 WCF-WebHttp Caching HeadersBizTalk 2016 WCF-WebHttp 缓存标头
【发布时间】：2020-01-18 01:52:47
【问题描述】：

我创建了一个发送管道，其中仅包含一个自定义管道组件，该组件创建一个 mime 消息以 POST 到需要 multipart/form-data 的 Rest API。它可以工作，但每次第二次调用都会失败。它在成功和失败之间交替。当它失败时，我写入标头的边界似乎被 WCF-WebHttp 适配器使用先前成功消息的边界覆盖。

我已确保将正确的边界写入标题。
我在管道组件中使用的所有流都已添加到管道资源管理器中。
如果我在第一条成功消息后重新启动主机实例，则下一条消息将成功。
在处理每条消息之间等待 10 分钟，观察到的行为没有任何变化。
如果我在预期会发生故障时发送不同的文件，则标头内容长度仍与前一个文件相同。这表明使用的标头与之前的调用完全相同。
标准 BizTalk mime 组件不会将边界写入标题，因此不提供任何线索。

成功

POST http://somehost/Record HTTP/1.1
Content-Type: multipart/form-data; boundary="9ccdeb0a-c407-490c-9cce-c5e3be639785"
Host: somehost
Content-Length: 11989
Expect: 100-continue
Accept-Encoding: gzip, deflate

--9ccdeb0a-c407-490c-9cce-c5e3be639785
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=uri

6442
--9ccdeb0a-c407-490c-9cce-c5e3be639785

失败：标头中的边界与有效负载中的边界不同

POST http://somehost/Record HTTP/1.1
Content-Type: multipart/form-data; boundary="9ccdeb0a-c407-490c-9cce-c5e3be639785"
Host: somehost
Content-Length: 11989
Expect: 100-continue
Accept-Encoding: gzip, deflate

--3fe3e969-8a41-451c-aae7-8458aee0c9f4
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=uri

6442
--3fe3e969-8a41-451c-aae7-8458aee0c9f4
Content-Disposition: form-data; name=Files; filename=testdoc.docx; filename*=utf-8''testdoc.docx

如果我能让标题使用正确的边界，我的问题将得到解决。有什么建议吗？

【问题讨论】：

标签： biztalk biztalk-2016

【解决方案1】：

我更惊讶的是，您实际上使用这种方法取得了一些成功。问题是，标头不是正式的消息属性，而是端口属性。端口缓存它们的设置。您必须使其成为动态发送端口才能正常工作。另一种方法是在自定义行为中设置标题，但我认为这不适合您的场景。

【讨论】：