我有一个文件接收位置，其中edireceive管道被配置为接收传入的HIPPA 5010 837文件。
正常的传入文件大小为4到6兆字节，包含3K到5K的记录。部署的837架构是＆＃34;倍数＆＃34;具有subdocument_break =＆＃34; yes＆＃34;的版本。因此，处理的文件将为每个文件生成3K到5K的消息。
管道工作正常，可以按预期将文件拆分为多个消息。对于1个单个文件，BizTalk处理时间不到5分钟。
问题是当同时向传入文件夹放入10个以上的文件时，Biztalk将开始并行处理这些文件。但是处理这些文件需要数小时，而BizTalk主机消耗的内存超过10G。
其他一些信息：
我的问题是：这种表现是否正常？我该如何改进呢？
答案 0 :(得分：2)
你是对的，5K消息不是真正的问题，它同时导致问题的5批5K消息。
要序列化debatching，您可以使用Ordered Delivery双向发送端口和Loopback Adapter，它可以在接收端调试EDI。在这种情况下，初始接收位置将是PassThrough。
您可以在此处找到多个Loopback Adapters：http://social.technet.microsoft.com/wiki/contents/articles/12824.biztalk-server-list-of-custom-adapters.aspx#jjj
答案 1 :(得分：1)
BizTalk并不是真的可以同时处理多个大文件，并且文件适配器没有任何内置的方法来限制它一次提取多少个文件。
有一个商业解决方案可以帮助解决这个问题（披露：我为Tallan工作并开发此解决方案）称为T-Connect EDI Splitter（https://www.tallan.com/products/t-connect/edi-file-splitter/）。用例是将管道上的文件拆分为更易于管理的块，以便在其他地方使用。遗憾的是，这不是一项微不足道的任务。
如果您的文件足够小，无法在它们点击EDI接收管道之前进行处理（您不需要进一步拆分它们，您只需要一次处理一个），您就可以了。我必须提出一个更复杂的消息传递流程来处理它 - 使用PassThrough传输接收它们，将它们发送到可以消耗它们的地方，然后使用第二个接收位置轮询它们，提供更精确的轮询控制。
您也可以编写自己的适配器，提供轮询和间隔设置，但这更加复杂和混乱。