知道为什么微软没有提供“多个”版本的 X12 820 架构吗？答案

【问题标题】：Any idea why microsoft did not provide a"multiple" version X12 820 schema?知道为什么微软没有提供“多个”版本的 X12 820 架构吗？
【发布时间】：2014-08-13 22:00:33
【问题描述】：

我需要处理一个巨大的 820 文件（超过 700M）。让 biztalk 编辑接收这个文件需要很长时间。所以我想把文件分成小块。在 BizTalk 中，834 和 837 都具有“多个”版本架构，允许将传入文件拆分为小消息（例如，根据 837 中的声明）。但是不存在这样的“多重”模式。是否有任何技术原因或业务原因阻止 820 文件被拆分？

（我确实尝试在 820 xsd 中添加 subdocument_break 等指令，但它最终得到了格式不正确的 xml）。

感谢任何关于如何处理巨大的 820 文件的想法/提示。

【问题讨论】：

您使用的是什么版本的 BizTalk？无效的 Xml 是 BizTalk Server...2006 的问题？

标签： biztalk biztalk-2013

【解决方案1】：

嗯，从技术上讲，你走在了正确的轨道上。虽然 subdocument_break 和 subdocument_creation_break 记录在 HIPAA 下，但它们只是 EDI 反汇编程序的一个功能，您可以添加到任何 EDI 架构中。

但是，我很抱歉地说，我认为这不会有帮助。 700MB 820 本身就很大，可能包含数十万笔交易。反汇编时，批处理中的事务数量是一个重要的处理因素，因为 BizTalk 将整个批处理视为单个事务。

如果您希望定期收到这样的文件，我将通过使用包装的 EDI 反汇编程序“取消事务处理”批处理，您可以在其中自己调用 GetNext 以对所有消息进行分批。但是，不要将它们传递给消息代理，而是通过边通道提交它们，即使它只是一个文件位置。意思是，BizTalk 只会调用一次 GetNext，然后你会做所有的分批工作。

这样，所有的消息都会自己接收。

【讨论】：

我不清楚你的“'de-transactionalize”。这不是管道中的去批处理过程吗？这与 subdocument_break 有什么区别？或者你真正的意思是“它不支持，你自己做你需要什么？”
反汇编是事务性的，意思是整个批次要么发布要么不发布。消息在分批时不会“流式传输”到 MessageBox 中。这意味着您可以针对 MessageBox 处理一个批次有 100 的数千个待处理事务。在管道中回避提交可以避免这种情况。
反汇编进程去事务处理和使用 subdocument_creation_break 的概念没有直接关系。它们只是碰巧在同一个过程中实现。