本主题介绍在 EDI 接收管道处理中存在的已知问题。
Receive-Side 无法处理尾随分隔符
症状
对于 X12 编码的消息，带有尾随分隔符的事务集失败，错误代码为 AK403=6；对于 EDIFACT 编码的消息，错误代码为 UCM3=4/UCD1=45。
可能的原因
未启用尾部分隔符的处理。
解决方案
打开发送消息的参与方的 EDI 属性。 在“EDI 属性”对话框的“验证和 ACK 生成”页（适用于 X12 或 EDIFACT），选择“允许尾随分隔符”。 单击此复选框后，您可以通过单击“为尾随分隔符创建空 XML 标记”指定要为中间 XML 中的尾随分隔符创建空 XML 标记。
已启用 CONTRL ACK 功能，但未生成
症状
发送方验证和 ACK 生成流程中的“生成功能确认”复选框已选中，但 EDI 接收管道未生成 CONTRL 确认。
可能的原因
CONTRL 消息包含多个必须从交换复制的必需数据元素。 如果交换中的数据元素缺失或语法无效，则接收管道无法生成语法有效的 CONTRL 消息。
解决方案
通过除 CONTRL 确认以外的其他方式报告错误条件。
“执行接收管道失败...”错误信息
症状
尝试运行 AS2 接收管道会导致80040154错误。
可能的原因
64 位主机实例不支持管道。
解决方案
将管道与 32 位主机相关联。
如果启用 Port-Based 身份验证并且 BizTalk Server 无权访问授权和安全信息，则会暂停 X12-Encoded 消息
症状
当通过启用身份验证的接收端口接收到消息但无法确定发送方时，BizTalk Server 将挂起该消息。
可能的原因
如果为接收端口启用了身份验证（清除接收端口的“无身份验证”属性），BizTalk Server 需要设置“ISA1-2（授权限定符和信息）”和“ISA3-4（安全限定符和信息）”属性才能处理交换。 这些属性在 X12 交换处理属性页中为作为交换发送方的参与方设置。 如果 BizTalk Server 无法确定这些属性的值，它将暂停处理该消息。
这可以通过两种方式发生。 在第一种情况下，如果 BizTalk Server 无法确定发送消息的参与方，它将使用 EDI 全局属性，并且无法访问授权和安全设置。 因此，它将暂停消息。 第二种情况是，如果 BizTalk Server 确定参与方，但未配置参与方的 ISA1-2 和 ISA3-4 属性，则 BizTalk Server 将再次无权访问授权和安全信息，并将挂起消息。
解决方案
确保可以标识消息的发送方，并在参与方协议中定义 ISA1-2 和 ISA3-4 属性。
在拆分的 HIPAA 子文档中，SE01 不正确。
症状
事务集尾部（SE01 字段）提供数据段的计数，包括 X12/HIPAA 文档的标头和尾部段。 但是，对于拆分 HIPAA 子文档，EDI 接收管道应用与原始文档相同的 SE01 值，而不是重新计算它。
原因
EDI 接收管道将 SE01 的值从原始 HIPAA 文档复制到拆分的子文档中。
重复 UNB5 或 UNH1 的错误消息没有描述性
如果 BizTalk Server 收到具有重复 UNB5（交换控制编号）或 UNH1（事务集引用编号）的消息，则其发布的错误代码和说明不会清楚地指示问题的性质。
如果 BizTalk Server 内存不足，将挂起非常大的交换
在分析非常大的交换时，BizTalk Server 可能会耗尽内存。 如果这样做，它将显示错误并暂停交换。 在“组中心”页中，你将无法看到已挂起的非常大的交换的所有内容。 你将能够看到消息的初始部分，但在显示挂起互换涉及的数据量方面，BizTalk Server 存在限制。
添加到 KEDIFACT 架构中的枚举的韩文字符必须以 UNICODE 形式表示
当 BizTalk Server 收到包含朝鲜字符的 KEDIFACT 编码交换时，它将使用 UNB2 字段中的代码页/字符集值来处理交换。 如果通过将一个ID数据类型的韩文字符添加到枚举中来修改KEDIFACT架构，必须在架构开头指定的UTF-16 UNICODE中添加该值。
不支持从编排中执行 EDI 接收管道
在 BizTalk Server 中，通常可以在业务流程中通过表达式形状来执行接收管道。 此功能尚未针对 EDIReceive 管道或 AS2EdiReceive 管道进行测试，因此不受支持。
不得修改 BizTalk EDI 应用程序
不得修改或删除 BizTalk EDI 应用程序中的项目。 如果修改了此应用程序，则无法通过取消配置和重新配置 EDI 和 AS2 功能还原到原始应用程序。
另请参阅
EDI 处理的已知问题
BizTalk Server 如何接收 EDI 消息
指南 （X12）：接收 EDI 交换并发送回回执