Biztalk EDI接收管道性能问题

我有一个文件接收位置，edireceive管道配置为接收传入的HIPPA 5010 837文件

正常的传入文件大小为4到6MB，包含3K到5K记录。部署的837模式是“多”版本，其中包含子文档\u break=“yes”。因此，已处理的文件将为每个文件生成3K到5K条消息

管道工作正常，可以按预期将文件拆分为多条消息。对于单个文件，BizTalk处理所需时间少于5分钟

问题是，当同时将10个以上的文件放入传入文件夹时，Biztalk将开始并行处理这些文件。但处理这些文件需要几个小时，BizTalk主机消耗的内存超过10G

其他一些信息：

• BizTalk主机是专用的64位接收主机
• 未找到其他应用程序的文件锁定
• 文件适配器中的批处理设置为批处理中的MSG数=1；最大批量=10240000
• 选中读取时重命名文件

---

我的问题是：这种表现正常吗？如何改进它？

BizTalk并不是一次处理多个大文件，文件适配器也没有任何内置方式来限制一次提取多少文件

有一个商业解决方案可以帮助处理这个问题（披露：我为塔兰工作，并致力于此解决方案），称为T-Connect EDI拆分器（）。用例是将管道上的文件拆分为更易于管理的块，以便在其他地方使用。不幸的是，这不是一项微不足道的任务

如果您的文件足够小，可以在到达EDI接收管道之前进行处理而不进行拆分（您不需要进一步拆分，只需一次处理一个文件），那么您必须提出一个更复杂的消息流来处理该问题—使用直通传输接收它们，将它们发送到可以使用它们的地方，然后使用第二个接收位置对它们进行轮询，该位置提供更精确的轮询控制

---

您也可以编写自己的适配器，提供轮询和间隔设置，但这会更加复杂和混乱。

您是对的，5K消息并不是真正的问题，它是导致问题的5批5K消息

要序列化解除匹配，您可以使用带环回适配器的有序传递双向发送端口，该端口在接收端解除EDI的匹配。在这种情况下，初始接收位置将是PassThrough

---

您可以在这里找到几个环回适配器：

我怀疑如果文件作为批处理，BizTalk可能会工作得更好。您可以尝试将批处理计数和大小限制设置为足以包含所有文件吗？Microsoft确实为我们提供了文件适配器的代码，因此可能不太难使其性能更好。复杂的部分与其说是编写适配器，不如说是编写适配器——你说得对，因为微软提供了一个示例。复杂的是要让它按你想要的方式工作。拥有一种有序、可靠的方式来轮询单个文件并不简单——至少这样做不会带来内存效率、线程安全和其他稳定性。约翰。我试试看。只是想知道在消息通过环回适配器之后，消息上下文是否仍然存在？例如，上下文中是否仍有file.receivedfilename？是的，保留上下文是我实现的选项之一。我不确定其他人。