BizTalk Server 如何發送 EDI 消息(2)

傳出 EDI 消息的協議解析和架構肯定

若要向貿易合做夥伴生成 EDI 消息，EDI 發送管道必須執行下列操做：

• 肯定消息解析爲的協議

• 肯定用於驗證消息的架構

協議解析

EDI 發送管道執行一系列步驟，肯定傳出交換和協議屬性是否匹配，進而查找協議。一旦 BizTalk Server 肯定協議，即可肯定適用於交換的文檔架構（見下文）。它使用與匹配協議關聯的屬性及相關架構來生成並驗證傳出消息。

若要執行協議解析，BizTalk Server 將按照如下方式繼續進行操做：

1. 經過將 AgreementPartIDForSend 上下文屬性與單向協議的 ID 相匹配來解析協議。此屬性應爲整數類型，此屬性能夠在自定義組件中進行設置，它並非由 BizTalk Server 設置的。

2. 若是步驟 1 沒成功，則經過將如下全部三個上下文屬性與協議屬性進行匹配來解析協議：AgreementNameForSend、SenderPartyNameForSend、ReceiverPartyNameForSend。請注意，要成功解析爲協議，這三個屬性都必需要設置。這些屬性能夠在自定義組件中進行設置，它們並非由 BizTalk Server 設置的。

3. 若是步驟 2 沒成功，則經過將消息上下文屬性中的參與方名稱與 DestinationPartyName 屬性進行匹配來解析協議（這在協議屬性的「標識符」選項卡中設置爲附加協議解析程序）。

4. 若是步驟 3 沒成功，則經過將消息上下文中的如下屬性與協議屬性中的屬性進行匹配來解析協議：DestinationPartySenderIdentifier、DestinationPartySenderQualifier、DestinationPartyReceiverIdentifier 和 DestinationPartyReceiverQualifier。請注意，要成功解析爲協議，全部這四個屬性都必須設置。這些屬性能夠在自定義組件中進行設置，它們並非由 BizTalk Server 設置的。有關詳細信息，請參閱如下內容。

便箋

若是上述任何上下文屬性集通過升級，且 BizTalk Server 沒法找到與這些上下文屬性關聯的協議，則 BizTalk Server 將掛起此消息。 若是用戶有意編寫上下文屬性集進行協議解析，且解析程序沒法識別 OnewayAgreement，則該消息將掛起。在根據上下文屬性集沒法解析爲協議時，將在 EventLog 中引起相應的警告消息。

5. 若是步驟 4 沒成功，或上述上下文屬性均未升級，則經過將訂閱該消息的發送端口與協議關聯的發送端口進行匹配，EDI 消息會解析爲一條協議。

便箋

若是同一發送端口與多個協議關聯，BizTalk Server 將生成錯誤。

6. 若是在步驟 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 類型信息。該發送管道使用控制段架構處理信封段。