Biztalk 你知道微软为什么不提供；“多重”；版本X12 820模式？

我需要处理一个巨大的820文件（超过700M）。让biztalk EDI接收此文件需要花费很长时间。所以我想把文件分成小块。在BizTalk中，834和837都有“mulltiple”版本模式，允许将传入的文件拆分为小消息（例如837中的每个声明）。但目前还没有这样的“多重”模式。是否有任何技术原因或业务原因阻止拆分820文件

（我确实尝试在820XSD中添加子文档_break etc指令，但最终得到的是非良好格式的xml）

---

如果您有任何关于如何处理820个大文件的想法/提示，我们将不胜感激。

好吧，从技术上讲，您的思路是正确的。虽然子文档中断和子文档创建中断都记录在HIPAA下，但它们只是可以添加到任何EDI模式的EDI反汇编程序的一个功能

然而，我很抱歉地说，我不认为这将有助于它自己。700MB 820本身就很大，可能包含数十万个事务。在反汇编时，批处理中的事务数是需要处理的重要因素，因为BizTalk将整个批处理视为单个事务

如果您希望定期收到这样的文件，我会使用包装的EDI反汇编程序来“反事务化”批处理，您可以自己调用GetNext来解除所有消息的争用。但是，不要将它们传递给消息传递代理，而是通过一个侧通道提交它们，即使它只是一个文件位置。也就是说，BizTalk只会调用GetNext一次，而您将执行所有的清除工作

---

这样，所有消息都可以自己获取。

您使用的BizTalk版本是什么？无效的Xml是BizTalk Server的一个问题…2006？我不清楚您的“'de-transactionalize”。这不是一个正在进行的分批处理过程吗？这与子文档_break有什么区别？或者您真正的意思是“不支持它，自己做任何需要的事情？”反汇编是事务性的，这意味着，要么发布整个批，要么不发布。消息不会“流式”进入MessageBox，因为它们已被删除。这意味着，在MessageBox处理一个批处理时，可能会有100到数千个挂起的事务。在管道中避免提交避免了这一点。反汇编程序过程的非转换和使用子文档的创建与中断的概念没有直接关系。它们恰好是在同一个过程中实现的。