EDI 組裝器的工做原理數據庫
BizTalk Server 執行大多數將發送到 EDI 發送管道的 EDI 編碼交換處理(Microsoft.BizTalk.DefaultPipelines.EDISendPipeline)。此管道包括用於執行下列處理的 EDI 組裝器管道組件:架構
序列化 EDI 交換,並將 XML 編碼的消息轉換成交換中的 EDI 事務集。ide
執行 EDI 架構驗證、X12 編碼消息的跨字段驗證(若是已配置)、EDI 結構驗證和擴展架構驗證(若是此架構是使用具備非 EDI 數據類型的節點自定義的)。編碼
將信封應用於 EDI 消息。url
處理爲響應 EDI 消息而收到的技術和功能確認,若是配置瞭解除批處理,則會對這些確認執行解除批處理操做。spa
將信封應用於傳出 EDI 消息事件
當 EDI 發送管道使用中間 XML 文件生成傳出 EDI 消息時,它會根據爲接收方協議創建的 EDI 屬性將包含交換和組標頭的信封應用於該消息。若是發送管道沒法根據發送端口肯定接收協議,它將使用回退協議來應用信封。事務
若是EdiOverride.OverrideEdiHeader上下文屬性設置爲 True,則 EDI 發送管道將使用 EdiOverride 屬性集中指定的值來構造信封。若是值還沒有出如今集中,則將使用協議屬性中的相關 EDI 值。若是值不存在於 EdiOverride 集或協議屬性中,則將使用回退 EDI 協議中的屬性。ip
若是中間 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 名稱的第8、第九和第十個字符。例如,映射到「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 段。