傳出 EDI 消息的協議解析和架構確定
若要向貿易合作伙伴生成 EDI 消息，EDI 發送管道必須執行下列操作：
確定消息解析爲的協議
確定用於驗證消息的架構
協議解析
EDI 發送管道執行一系列步驟，確定傳出交換和協議屬性是否匹配，進而查找協議。一旦 BizTalk Server 確定協議，便可確定適用於交換的文檔架構（見下文）。它使用與匹配協議關聯的屬性及相關架構來生成並驗證傳出消息。
若要執行協議解析，BizTalk Server 將按照以下方式繼續進行操作：
通過將 AgreementPartIDForSend 上下文屬性與單向協議的 ID 相匹配來解析協議。此屬性應爲整數類型，此屬性可以在自定義組件中進行設置，它並不是由 BizTalk Server 設置的。
如果步驟 1 沒成功，則通過將以下所有三個上下文屬性與協議屬性進行匹配來解析協議：AgreementNameForSend、SenderPartyNameForSend、ReceiverPartyNameForSend。請注意，要成功解析爲協議，這三個屬性都必須要設置。這些屬性可以在自定義組件中進行設置，它們並不是由 BizTalk Server 設置的。
如果步驟 2 沒成功，則通過將消息上下文屬性中的參與方名稱與 DestinationPartyName 屬性進行匹配來解析協議（這在協議屬性的“標識符”選項卡中設置爲附加協議解析程序）。
如果步驟 3 沒成功，則通過將消息上下文中的以下屬性與協議屬性中的屬性進行匹配來解析協議：DestinationPartySenderIdentifier、DestinationPartySenderQualifier、DestinationPartyReceiverIdentifier 和 DestinationPartyReceiverQualifier。請注意，要成功解析爲協議，所有這四個屬性都必須設置。這些屬性可以在自定義組件中進行設置，它們並不是由 BizTalk Server 設置的。有關詳細信息，請參閱以下內容。
|
如果上述任何上下文屬性集經過升級，且 BizTalk Server 無法找到與這些上下文屬性關聯的協議，則 BizTalk Server 將掛起此消息。 如果用戶有意編寫上下文屬性集進行協議解析，且解析程序無法識別 OnewayAgreement，則該消息將掛起。在根據上下文屬性集無法解析爲協議時，將在 EventLog 中引發相應的警告消息。 |
如果步驟 4 沒成功，或上述上下文屬性均未升級，則通過將訂閱該消息的發送端口與協議關聯的發送端口進行匹配，EDI 消息會解析爲一條協議。
|
如果同一發送端口與多個協議關聯，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 屬性。
如果已爲消息設置所有四個上下文屬性，並且這些上下文屬性和屬性頁中的屬性不匹配，消息則掛起。僅在尚未設置所有四個上下文屬性時，纔會使用與協議關聯的發送端口解析該協議。
|
EDI 管道中的協議將轉到協議解析中的後續步驟，直到通過相應步驟（協議處於啓用狀態）解析該消息爲止。例如，如果消息在協議解析的第一步中得以解析，但協議處於禁用狀態，則消息將轉到後續步驟進行解析。 |
架構確定
EDI 發送管道根據每個事務集的中間 XML 文件包含的架構名稱和架構命名空間（以 doc 類型信息形式或位於根節點中）確定適用於消息的架構。
對於已保留的交換，發送管道使用完整交換的中間 XML 文件中各個事務集包含的 doc 類型信息。該發送管道使用控制段架構處理信封段。