EDI 接收管道性能问题

Question

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

正常的传入文件大小为 4 到 6 兆字节，包含 3K 到 5K 条记录。部署的 837 模式是具有 subdocument_break="yes" 的“多个”版本。所以处理过的文件会为每个文件生成 3K 到 5K 条消息。

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

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

其他一些信息：

• BizTalk 主机是专用的 64 位接收主机
• 未发现其他应用程序锁定文件
• 文件适配器中的批处理设置是批处理中的消息数 = 1；最大批量大小 = 10240000
• 检查读取时重命名文件。

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

Answer 1

你是对的，5K 消息并不是真正的问题，是 5 批 5K 消息同时导致了问题。

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

你可以在这里找到几个环回适配器：http://social.technet.microsoft.com/wiki/contents/articles/12824.biztalk-server-list-of-custom-adapters.aspx#jjj

Answer 2

BizTalk 并不是真正用于一次处理多个大文件，而且文件适配器没有任何内置方法来限制一次提取的文件数量。

有一个商业解决方案可以帮助解决这个问题（披露：我为 Tallan 工作并致力于此解决方案），称为 T-Connect EDI 分路器 (https://www.tallan.com/products/t-connect/edi-file-splitter/)。用例是将管​​道上的文件拆分为更易于管理的块，以便在其他地方使用。不幸的是，这不是一项简单的任务。

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

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