本主题介绍已知的验证问题。
消息已暂停，EDI 验证已关闭
症状
违反配对规则，并且验证已关闭，但消息已挂起（预期结果为消息已序列化）。
可能的原因
即使在 EDI 属性对话框的验证和 ACK 生成设置节点中取消选择EDI 类型属性，也会执行跨字段/段验证。 之所以进行验证，是因为它在架构注释中处于打开状态。
解决方案
关闭架构批注中的验证。
在编辑和重新部署架构后，需要重启 BizTalk 服务
症状
BizTalk Server 在编辑和重新部署架构后无法成功处理有效消息。
可能的原因
BizTalk Server 的架构缓存具有不受限的超时时间。
解决方案
编辑并重新部署架构后，重启 BizTalk Server 应用程序服务。 您还必须重启托管使用重新部署的架构的管道的主机实例。
对于单个参与方的单一编码类型消息，已中止处理
症状
已中止为单个参与方处理单一编码类型（例如 X12 或 EDIFACT）的所有消息。 处理同一方使用另一种编码类型的消息，或处理另一方的任何消息，都没有受到影响。
可能的原因
交换、组或事务集控制编号的长度已超过允许的最大长度。
对于 X12 消息，控制编号的最大长度为 9 位。 对于 EDIFACT 消息，控制编号的最大长度为三个字段的 14 位数字。
解决方案
在受影响方 EDI 属性对话框的相应属性页中重置控制编号。 可以在以下属性页中编辑控件编号：
X12 交换控制编号：X12 属性的 ISA 段定义页面（在作为交换接收方的参与方节点中）
X12 组或事务集控制编号：GS 和 ST 段定义页（在 Party 中作为 X12 属性的交换接收方节点）
EDIFACT 交换控制编号：UNB 段定义页（在 Party 中作为 EDIFACT 属性的交换接收方节点）
EDIFACT 组或事务集控制编号：UNG 和 UNH 段定义页（在 Party 中作为 EDIFACT 属性的交换接收方节点）
BizTalk Server 使用具有具有七个数据元素的 UNH 段的架构进行验证
在早期版本的 EDIFACT 中，UNH 段有四个元素，而不是 UNH 段在更高版本中具有的七个元素（其中三个是可选的）。 BizTalk Server 使用更新版本的七个元素进行验证。
为多个跨字段验证规则生成的错误消息不会特定于规则
如果架构包含消息中某个数据元素的多个跨字段验证规则，并且数据元素发生错误，则会为每个验证规则生成单独的错误。 但是，其中每个错误将具有相同的错误代码和说明;错误不会特定于验证规则。
如果在接收时禁用 EDI 类型验证并在发送时启用，则发送管道将无法序列化消息
如果在接收端关闭 EDI 类型验证，则 EDI 接收管道将从收到的 EDI 消息生成 XML 消息，无论消息是否有效。 如果在发送端启用了 EDI 验证，如果 XML 文件包含错误，EDI 发送管道将无法将 XML 重新处理到有效的 EDI 文件中，因此将生成错误。
只有在您的应用程序引用了 BizTalk EDI 应用程序的情况下，EDI 提升的属性才可用。
症状
EDI 命名空间下的已提升属性不会显示在您尝试使用的已提升属性列表中，例如，用于业务协调或发送端口的筛选器条件。
可能的原因
您正在使用的 BizTalk 应用程序没有引用 BizTalk EDI 应用程序。 EDI 升级属性的属性架构位于 Microsoft.BizTalk.Edi.BaseArtifacts.dll中，该架构包含在 BizTalk EDI 应用程序的 Resources 文件夹中。
解决方案
请在您正在使用的 BizTalk 应用程序中添加对 BizTalk EDI 应用程序的引用。
上下文属性名称中的数据元素名称包含下划线，而不是句点
EDI 段中的数据元素名称包含句号，例如 UNB2.1，这是用于 UNB2 发送方段的标识字段。 但是，当数据元素名称作为EDI上下文属性的一部分包含在内时，句号会被替换为下划线。 例如，发送方标识数据元素的上下文属性为 EDI。UNB2_1，而不是 EDI。UNB2.1. 原因是上下文属性名称不支持句号。
不相关的字符串追加到实例验证错误消息中
每当在实例验证期间收到错误时，字符串“BEC 2004”将追加到错误消息中。 可以忽略此字符串。
EDIFACT 模式名称 Case-Sensitive
EDIFACT 架构的架构名称（如架构的root_reference数据元素所示）区分大小写。 例如，EFACT_D98B_ORDERS和EFACT_d98B_Orders是两个不同的架构。
即使禁用了 EDI 类型验证，无效的 EDI 消息也可能会被暂停
即使禁用 EDI 类型验证，也会执行 EDI 结构验证。 即使禁用了 EDI 类型验证，也会暂停基本结构验证失败的交换。
即使在信封标头中使用了分隔符字符，EDI 汇编程序也会序列化未批处理的交换。
使用用于分隔标头和尾部字段的分隔符，不得在作为交换接收方的方定义的任何交换、组或事务集标头或尾部字段的定义中使用。 如果是这样的话，电子数据交换（EDI）会在发送方 BizTalk Server 的 EDI 汇编程序或接收方的反汇编器中处理失败。 如果交换是出站批处理，则将在 EDI 构建器中失败，因为构建器将根据消息头控制（服务）架构验证信封。 如果未对交换进行批处理，则 EDI 汇编程序将对其进行序列化，但在接收方反汇编程序中将失败处理。
字符集不匹配可能导致交换中止
用于传出交换的字符集应与用于创建插入交换的事务集的字符集相同。 否则，交换可能会暂停，并显示一条错误消息，指示存在无效字符。
例如，如果使用 UNOA 字符集创建 EDIFACT 批处理，但添加到批处理的事务集合中包含小写字符，批处理业务流程将暂停消息处理，因为 UNOA 不允许使用小写字符。
例如，如果您将 EDI 发送管道配置为 X12 交换指定“基本”字符集，但由于在 X12 交换信封生成页面中，为作为交换接收者的通信方选择了“扩展”或“UTF8/Unicode”字符集，导致 X12 批处理交换包含小写字符，则在应用信封设置时，批处理消息将被暂停。
使用 UNH2.5 进行架构解析需要更新架构
如果使用 UNH2.5（协会分配的代码）来解析传入的 EDIFACT 交换模式，则需要更新 \Program Files\Microsoft BizTalk Server 20xx\Schema 文件夹中的相关文档模式。 需要将 UNH2.5 的值追加到 root_reference、display_reference 和 xs：element 名称的现有值。 例如，如果 UNH2.5 为“EAN008”并且正在使用EFACT_D96A_INVOIC架构，则会将 root_reference、display_reference 和 xs：element 名称设置为“EFACT_D96A_INVOIC_EAN008”。
执行升级时，将替换压缩的架构文件
如果将 bizTalk Server 升级到更高版本Microsoft，则安装中的 MicrosoftEdiXSDTemplates.exe 文件将替换为与升级关联的 MicrosoftEdiXSDTemplates.exe 文件。 如果计划继续使用旧压缩文件中的架构，除非备份旧的压缩文件，否则升级后将不再有权访问压缩文件。
如果一个组包含多个 X12 事务集，则所有组必须具有相同的类型
BizTalk Server 不支持在同一组中混合不同的事务集。 当一个组包含多个事务时，ST01 的值对于所有事务都必须相同。
接收包含非ASCII分隔符的X12交换时，可能会导致消息被挂起。
症状
收到使用非ASCII字符的X12交换时，消息可能会挂起，并在应用程序事件日志中记录错误。
可能的原因
如果交换未编码为 UTF-8，则可能会出现此问题。
解决方案
确保包含非 ASCII 分隔符的任何传入 X12 交换都编码为 UTF-8。