BizTalk Server 如何发送 EDI 消息(2)
传出EDI 消息的协议解析和架构确定若要向贸易合作伙伴生成 EDI 消息，EDI 发送管道必须执行下列操作：
[*] 确定消息解析为的协议
[*] 确定用于验证消息的架构
协议解析
EDI 发送管道执行一系列步骤，确定传出交换和协议属性是否匹配，进而查找协议。一旦 BizTalk Server 确定协议，便可确定适用于交换的文档架构（见下文）。它使用与匹配协议关联的属性及相关架构来生成并验证传出消息。
若要执行协议解析，BizTalk Server 将按照以下方式继续进行操作：
[*]
通过将 AgreementPartIDForSend 上下文属性与单向协议的>
[*] 如果步骤 1 没成功，则通过将以下所有三个上下文属性与协议属性进行匹配来解析协议：AgreementNameForSend、SenderPartyNameForSend、ReceiverPartyNameForSend。请注意，要成功解析为协议，这三个属性都必须要设置。这些属性可以在自定义组件中进行设置，它们并不是由 BizTalk Server 设置的。
[*] 如果步骤 2 没成功，则通过将消息上下文属性中的参与方名称与 DestinationPartyName 属性进行匹配来解析协议（这在协议属性的“标识符”选项卡中设置为附加协议解析程序）。
[*] 如果步骤 3 没成功，则通过将消息上下文中的以下属性与协议属性中的属性进行匹配来解析协议：DestinationPartySenderIdentifier、DestinationPartySenderQualifier、DestinationPartyReceiverIdentifier 和 DestinationPartyReceiverQualifier。请注意，要成功解析为协议，所有这四个属性都必须设置。这些属性可以在自定义组件中进行设置，它们并不是由 BizTalk Server 设置的。有关详细信息，请参阅以下内容。
http://blog.51cto.com/e/u261/themes/default/images/spacer.gif便笺
如果上述任何上下文属性集经过升级，且 BizTalk Server 无法找到与这些上下文属性关联的协议，则 BizTalk Server 将挂起此消息。
如果用户有意编写上下文属性集进行协议解析，且解析程序无法识别 OnewayAgreement，则该消息将挂起。在根据上下文属性集无法解析为协议时，将在 EventLog 中引发相应的警告消息。
[*] 如果步骤 4 没成功，或上述上下文属性均未升级，则通过将订阅该消息的发送端口与协议关联的发送端口进行匹配，EDI 消息会解析为一条协议。
http://blog.51cto.com/e/u261/themes/default/images/spacer.gif便笺
如果同一发送端口与多个协议关联，BizTalk Server 将生成错误。
[*] 如果在步骤 1、2、3 或 4 中找不到协议，则发送管道将使用备用协议设置生成传出消息。
通过匹配发送方和接收方上下文属性执行协议解析
在上面的第二个步骤中，用于匹配的四个上下文属性为 EDI.DestinationPartySenderIdentifier、EDI.DestinationPartySenderQualifier、EDI.DestinationPartyReceiverIdentifier 和 EDI.DestinationPartyReceiverQualifier。这些上下文属性的命名空间为http://schemas.microsoft.com/Edi/PropertySchema。BizTalk Server 尝试将这些值与单向协议属性中的相关发送方和接收方的标识符和限定符进行匹配。对于 X12，这些字段为“协议属性”对话框中单向协议选项卡的“标识符”页中的 ISA05、ISA06、ISA07 和 ISA08；对于 EDIFACT，这些字段为“协议属性”对话框中单向协议选项卡的“标识符”页中的 UNB2.1、UNB2.2、UNB3.1 和 UNB3.2。
若要使用所有四个发送方和接收方的标识符和限定符启用发送端协议解析，必须设置所有四个上下文属性。以唯一方式执行此操作可标识协议。使用上述协议查找方法可以更灵活地执行发送端处理。例如，在某些情况下，使用该方法您可以避免创建多个发送端口，并避免采用复杂的发送端口筛选器。同时，您还可以根据需要避免设置 OneWayAgreementId 属性。
如果已为消息设置所有四个上下文属性，并且这些上下文属性和属性页中的属性不匹配，消息则挂起。仅在尚未设置所有四个上下文属性时，才会使用与协议关联的发送端口解析该协议。
http://blog.51cto.com/e/u261/themes/default/images/spacer.gif便笺
EDI 管道中的协议将转到协议解析中的后续步骤，直到通过相应步骤（协议处于启用状态）解析该消息为止。例如，如果消息在协议解析的第一步中得以解析，但协议处于禁用状态，则消息将转到后续步骤进行解析。
架构确定
EDI 发送管道根据每个事务集的中间 XML 文件包含的架构名称和架构命名空间（以 doc 类型信息形式或位于根节点中）确定适用于消息的架构。
对于已保留的交换，发送管道使用完整交换的中间 XML 文件中各个事务集包含的 doc 类型信息。该发送管道使用控制段架构处理信封段。
页:
[1]