EDI 組裝器的工作原理
BizTalk Server 執行大多數將發送到 EDI 發送管道的 EDI 編碼交換處理(Microsoft.BizTalk.DefaultPipelines.EDISendPipeline)。此管道包括用於執行下列處理的 EDI 組裝器管道組件：
序列化 EDI 交換，並將 XML 編碼的消息轉換成交換中的 EDI 事務集。
執行 EDI 架構驗證、X12 編碼消息的跨字段驗證（如果已配置）、EDI 結構驗證和擴展架構驗證（如果此架構是使用具有非 EDI 數據類型的節點自定義的）。
將信封應用於 EDI 消息。
處理爲響應 EDI 消息而收到的技術和功能確認，如果配置瞭解除批處理，則會對這些確認執行解除批處理操作。
將信封應用於傳出 EDI 消息
當 EDI 發送管道使用中間 XML 文件生成傳出 EDI 消息時，它會根據爲接收方協議建立的 EDI 屬性將包含交換和組標頭的信封應用於該消息。如果發送管道無法根據發送端口確定接收協議，它將使用回退協議來應用信封。
如果EdiOverride.OverrideEdiHeader上下文屬性設置爲 True，則 EDI 發送管道將使用 EdiOverride 屬性集中指定的值來構造信封。如果值尚未出現在集中，則將使用協議屬性中的相關 EDI 值。如果值不存在於 EdiOverride 集或協議屬性中，則將使用回退 EDI 協議中的屬性。
如果中間 XML 文件具有保留標記或 ReuseEnvelope 上下文屬性，則該消息是保留批，將不會對其應用信封應用程序邏輯。
X12 信封值的來源
下表顯示了 EDI 發送管道在何處爲 X12 信封的每一部分獲取其所需的信息：
標頭 | 來源 | ||
交換控制標頭 (ISA) |
| ||
功能組標頭 (GS) |
如果定義了協議，則 GS 數據元素的值是根據事務集標識符 (ST1)、版本和目標命名空間的組合確定的。這些值將與協議屬性（如果已定義協議）或回退協議屬性（如果未定義協議）“信封”頁（“事務集設置”部分下）中的網格進行比較：
如果未定義協議，則從回退協議屬性中填充 GS 數據元素。 |
EDIFACT 信封值的來源
下表顯示了 EDI 發送管道在何處爲 EDIFACT 信封的每一部分獲取其所需的信息：
標頭 | 源 | ||
服務字符串建議 (UNA) |
| ||
交換控制標頭 (UNB) |
| ||
功能組標頭 (UNG) |
如果定義了協議，則 UNG 數據元素的值是根據消息類型 (UNH2.1)、消息發行版號 (UNH2.3)、分配的代碼 (UNH2.5)、版本和目標命名空間的組合確定的。
|
應用事務集標頭和尾部段
要序列化到傳出 EDI 交換中的 XML 事務集應當具有事務集標頭和尾部。但是，如果沒有事務集標頭或尾部，EDI 組裝器將處理相應消息。X12 和 EDIFACT 架構中的事務集標頭和尾部段對 XML 事務集而言是可選的。如果事務沒有標頭或尾部，則 EDISend 或 AS2EDISend 發送管道中的 EDI 組裝器將會向其添加事務集標頭和尾部值。這些值將基於映射或計算。EDI 組裝器將會爲交換 XML（保留批）、批處理的事務集 XML 和事務集 XML 執行此操作。
如果映射造成驗證錯誤，則 XML 事務集或交換 XML 將會被掛起，並且在事件查看器中會顯示相應的錯誤，例如長度或數據類型無效，或者控制機構代碼無效。
X12 事務集標頭和尾部段
對於沒有標頭和尾部段的 X12 編碼的事務集，EDI 組裝器會將 ST 和 SE 段設置爲以下值：
標頭/尾部段 | 值 | ||
ST01（事務集標識代碼） | 映射到傳入 XML 事務集中的 RootNode 名稱的最後三個字符。例如，映射到“X12_00401_855”中的“855”。對於具有 TS 標識代碼 837P、837D 或 837I 的 HIPAA 聲明，使用“837”。 | ||
ST02（事務集控制編號） | EdiOverride.ST02的值（如果EdiOveride.OverrideEdiHeader爲 True，）或映射到 “協議屬性”對話框單向協議選項卡“本地主機設置”頁（“交換設置”下）中“事務集控制編號(ST02)”的值。 不論“應用新 ID”屬性的設置如何，都會應用新的或遞增的控制編號。 | ||
ST03（版本標識符） | 映射到來自傳入 XML 事務集的 ST03 值。例如，適用於 5010 HIPAA 820 文檔的“005010 X 218”（工資扣繳）。ST03 對用於驗證事務集的架構進行驗證。
| ||
SE01（包含的段數） | 設置爲事務集中的總段數，其中包括 ST 和 SE 段。 | ||
SE02（事務集控制編號） | 映射到事務集中 ST02 的值。 |
事務集標頭中的其他數據元素（如 ST03）是可選的，因而在生成的段中未賦值。
EDIFACT 事務集標頭和尾部段
對於沒有標頭和尾部段的 EDIFACT 編碼的事務集，EDI 組裝器會將 UNH 和 UNT 段設置爲以下值：
標頭/尾部段 | 值 |
UNH01（消息引用控制編號） | EdiOverride.UNH1的值（如果EdiOverride.OverrideEdiHeader爲 True，）或映射到 “協議屬性”對話框單向協議選項卡“本地主機設置”頁（“交換設置”下）中“參考編號(UNH1)”的值。不論“應用新 ID”屬性的設置如何，都會應用新的或遞增的控制編號。 |
UNH2.1（消息類型） | 映射到傳入 XML 事務集中的 RootNode 名稱的最後六個字符。例如，映射到“EFACT_D96A_INVOIC”中的“INVOIC”。 |
UNH2.2（消息版本號） | 映射到傳入 XML 事務集中的 RootNode 名稱的第七個字符。例如，映射到“EFACT_D96A_INVOIC”中的“D”。 |
UNH2.3（消息發行版號） | 映射到傳入 XML 事務集中的 RootNode 名稱的第八、第九和第十個字符。例如，映射到“EFACT_D96A_INVOIC”中的“96A”。 |
UNH2.4（控制機構代碼） | 始終映射到字符串“UN”。 |
UNT01（包含的段數） | 設置爲事務集中的總段數，其中包括 UNH 和 UNT 段。 |
UNT02（消息引用控制編號） | 映射到 “協議屬性”對話框單向協議選項卡“本地主機設置”頁（“交換設置”下）中“參考編號(UNH1)”的值。 |
UNH 事務集標頭中的其他數據元素（如 UNH3 到 UNH6）是可選的，因而在生成的段中未賦值。如果這些字段中有任何字段是必需的，則必須將它們設置爲傳入 XML 事務集中的值。
對傳出消息信封的其他處理
EDI 發送管道對傳出消息的信封執行以下處理。
控制編號
EDI 發送管道會將交換控制編號、組控制編號和事務集控制（或參考）編號輸入到每個傳出交換的信封段中。下表顯示了這些編號：
控制編號 | X12 字段 | EDIFACT 字段 |
交換控制編號 | ISA13 | UNB5 |
組控制編號 | GS6 | UNG5 |
事務集控制編號 (X12) 事務集參考編號 (EDIFACT) | ST2 | UNH1 |
根據“協議屬性”對話框單向協議選項卡“本地主機設置”頁（“交換設置”下）“交換控制編號(ISA13)”屬性上輸入的範圍值，BizTalk Server 將設置下一個發送交換的交換控制編號。它將會爲每個後續交換遞增此編號，直到達到最大值。
如果使用 EdiOverride 上下文屬性指定交換控制編號，則指定的值將用於此交換，並且不會影響在協議中指定的交換控制編號。
|
只有選中 EDIFACT 協議屬性“信封”頁中的“應用 UNG 分段”屬性，EDIFACT 中組控制編號纔會遞增。第二個字段（參考編號）會遞增；前綴和後綴字段不會遞增。僅在選擇了“應用新 ID”屬性的情況下，事務集控制編號纔會遞增。 |
|
在保留批交換中，您可以使用消息收集示例創建自定義交換控制編號。有關詳細信息，請參閱消息收集示例（BizTalk Server 示例）。 |
如果未定義協議，則會從回退協議中的相同頁獲取編號。發送管道存儲了上次使用的控制編號，然後爲下一個交換、組和事務集輸入遞增編號。
|
如果任何控制編號達到指定範圍的最大值，則 BizTalk Server 將會引發錯誤，並掛起交換。您可以在“協議屬性”對話框中“本地主機設置”頁爲 X12 和 EDIFACT 消息手動重置控制編號，或配置 BizTalk Server 以自動重置下限值。 |
|
控制編號保存在 BizTalk MessageBox 數據庫的 dbo.EdiSequenceNumbers 表中。您應根據需要通過從表中清除控制編號或存檔控制編號來管理此數據庫表。 |
在 EDIFACT 中，控制編號由字母數字值構成。支持以下格式：
數字（例如“1”）
前綴數字後綴（例如“WA1A”）
前綴數字（例如“AA1”）
數字後綴（例如“1AA”）
在這些格式中，數字字符可以爲“0”到“9”，前綴和後綴字符可以是數字以外的任何字符。只有編號遞增纔可以達到最大值。
段計數
對於交換中的每個事務集，EDI 發送管道都將驗證事務集中的段計數，對於 X12，事務集中的段計數在 SE01 數據元素中指示，對於 EDIFACT，則在 UNT01 數據元素中指示。如果相應數據元素的值與實際計數不符，則發送管道將更新此計數以反映實際段數。不會因爲計數錯誤而拒絕事務集。計數的更新將記錄在事件查看器中的警告中。這不適用於對保留批的處理。
序列化 EDI 交換過程中的其他步驟
在序列化過程中，EDI 發送管道還執行以下步驟。
序列化轉義指示器
在 EDIFACT 消息的序列化過程中，EDI 發送管道會將任何需要的轉義指示器插入到 EDI 交換中。假定路由到發送管道的中間 XML 不包含轉義的數據。例如，如果路由到發送管道的 XML 數據中存在轉義指示器，則發送管道將在現有轉義指示器前添加另一轉義指示器以便對它進行轉義。
進行 EDI 驗證時，不會驗證轉義指示器。EDI 發送管道在計算長度限制時也不會將轉義指示器納入到計算範圍內。
添加尾隨零以便滿足隱式小數要求
如果 EDI 組裝器遇到在小數點後的位數不足的數字，它會在小數點後添加尾隨零以便滿足隱式小數要求。例如，當數字應採用 N2 格式時，如果 EDI 組裝器遇到數字“4.5”，則組裝器會將此數字更改爲“4.50”。
替換負載數據中的分隔符
如果出站消息中的數據還包含配置爲數據、分段或複合元素分隔符的字符，則 EDI 發送管道可以替換這些字符。例如，如果消息包含“test*data” 值，並且數據元素分隔符配置爲‘*’，則這將可能在接收系統上引起解析問題。
通過啓用“替換負載中的分隔符”屬性和指定替換字符，EDI 發送管道可以配置來替換此字符。此屬性位於“協議屬性”對話框單向協議選項卡“字符集和分隔符”頁中。
基於觸發器字段轉換 HIPAA 記錄
如果出站文檔是 HIPAA 事務集，則 EDI 程序集將包含觸發器字段的任何唯一 XML 記錄轉換爲匹配的普通 EDI 分段（請參見HIPAA 架構觸發器字段批註）。通過刪除“_” 字符之後 XML 記錄名稱的後綴，可以完成該操作。
例如，元素 <N1_PayerIdentification_TS835W1_1000A> 和 <N1_PayeeIdentification_TS835W1_1000B> 都將變爲 N1 段。