EDI 解決方案之•EDI 消息傳遞•EDI 消息結構

EDI 消息結構

EDI 消息由信封和一系列分層結構元素組成。信封包含一組頭部和尾部，每組都描述幷包含一個結構元素。這些結構元素以下所示：

EDI 消息的層次結構容許對事務集/消息和組進行批處理。即便一個交換隻包含一個事務集/消息和一個組，該交換也具備與批處理時徹底相同的基本結構元素，不一樣的是，它不會有多個事務集/消息或組元素。

EDI 的頭部和尾部

EDI 交換的各部分由標頭和尾部分隔，而標頭和尾部必須遵循 X12 或 EDIFACT 標準。交換控制標頭和尾部只出現一次；功能組和事務集標頭和尾部可重複出現，前提是事務集和組在交換內是按批處理的。每一個標頭和尾部均由一系列數據元素組成，這些元素包含有關標頭和尾部所含內容的信息。

X12 和 EDIFACT 的標頭和尾部很類似。主要區別在於，在 EDIFACT 中，交換中使用的分隔符是在 UNA 服務字符串建議標頭中定義的。而在 X12 編碼中，分隔符是在 ISA 交換控制標頭中定義的。

交換控制和功能組標頭和尾部表示爲信封段。當 BizTalk Server 將傳入交換分割成事務集時，它將這些信封段另存爲上下文屬性。對路由很是有用的主要信封屬性可做爲單獨的屬性使用。當保留交換時，不會出現這種狀況，此時信封數據屬於消息自身的一部分。

當 BizTalk Server 生成傳出消息時，它根據貿易合做夥伴協議來肯定標頭和尾部，或者在未肯定任何參與方時根據全局協議肯定。

標頭字段和尾部字段，以及用於在交換中分隔它們的分隔符均在兩個參與方之間的協議中進行定義。按照對協議的規定，切勿在交換、組或事務集的任何頭字段或尾字段的定義中使用分隔符。若是使用了這樣的分隔符，則在做爲發送方的 BizTalk Server 的 EDI 組裝器中或在接收方的拆裝器中將沒法處理交換。若是交換爲出站批，它在 EDI 組裝器中將失敗，由於組裝器會根據頭控制（服務）架構驗證信封。若是交換未進行批處理，EDI 組裝器會將其序列化，但交換在接收協議的拆裝器中將沒法處理。

X12 的標頭和尾部

X12 編碼消息的標頭和尾部以下所示：

若是 ISA 標頭後面緊跟 IEA 尾部，則交換爲空。若是事務集存在，則 GS 標頭和 GE 尾部必須存在，不然它們將受條件限制。

在 X12 編碼的消息中，ISA 交換控制標頭字段是固定長度。對於某些字段，能夠輸入小於字段固定長度的值。若是這樣作，交換必須包含尾部空格（對於字符串字段）或前導零（對於數字字段），以便每一個字段都具備所需長度。當建立出站交換時，BizTalk Server 將輸入尾部空格或前導零，以便建立長度正確的交換控制標頭。GS 組標頭字段和 ST 事務集標頭字段的長度不固定。

在 X12 編碼中，功能安全標頭、功能保證標頭、功能安全值段和功能安全尾部段均超出 BizTalk Server EDI 和 AS2 的範圍。若是收到具備這些段的交換，則會掛起交換並顯示錯誤日誌，指示沒法識別這些段。

ST01 字段是事務集 ID 代碼；ST02 字段是事務集控制編號。ST03 字段是架構版本標識符。SE01 字段指示事務集中包含的段數；SE02 字段與 ST02 字段（事務集控制編號）相同。當解析傳入消息時，BizTalk Server 將驗證事務集中的段數是否與 SE01 字段的值相對應。當生成傳出消息時，BizTalk Server 會將 SE01 字段設置爲事務集中的正確段數。

要序列化到傳出 EDI 交換中的 XML 事務集應當具備事務集標頭和尾部。可是，若是沒有事務集標頭或尾部，EDI 組裝器將處理相應消息。X12 和 EDIFACT 架構中的事務集標頭和尾部段對於 XML 事務集而言是可選的。若是事務沒有標頭或尾部，則 EDISend 或 AS2EDISend 發送管道中的 EDI 組裝器將會向其添加事務集標頭和尾部值。這些值將基於映射或計算。EDI 組裝器將會爲交換 XML（保留批）、批處理的事務集 XML 和事務集 XML 執行此操做。有關詳細信息，請參閱X12 Transaction SetHeader and Trailer Segments或EDIFACT TransactionSet Header and Trailer Segments。

EDIFACT 的標頭和尾部

EDIFACT 編碼消息的標頭和尾部以下所示：

無需 UNA 標頭。但 UNB 標頭是必需的。若是 UNA 標頭存在，則其中將包含要在處理傳入消息時使用的分隔符，不然將使用爲 EfactDelimiters 管道屬性定義的分隔符。

若是 UNB 標頭後面緊跟 UNZ 尾部，則交換爲空。若是 UNG 標頭後面緊跟 UNE 尾部，則組爲空。UNG 標頭和 UNE 尾部對是條件元素，不必定必須出如今消息中。

EDI 交換結構元素

交換是 EDI 消息的最高級別的結構元素。它包含由兩個合做夥伴交換的一個或多個組的集合。交換的目標必須是一個貿易合做夥伴。交換可能包含一種或多種類型的事務集/消息。

使用交換時，交換自身以及其中的組和事務集/消息由標頭定義。段、數據元素和子元素由分隔符分隔。每一個分隔符都有一個默認值，但能夠爲參與方定義其餘字符。在 EDIFACT 交換中，在交換中用做分隔符的所選字符是在單獨的 UNA 交換標頭中定義的。而在 X12 交換中，分隔符是在 ISA 交換標頭中定義的。請注意，在 X12 中，數據元素分隔符是位於第四個字符位置的字符，數據段終止符是位於最後一個字符位置的字符。其餘 X12 分隔符和所有 EDIFACT 分隔符由字段定義，例如 X12 組件分隔符由 ISA16 字段定義，EDIFACT 數據元素分隔符由 UNA2 字段定義。有關詳細信息，請參閱UNA Segment Definition Page (EDI Properties)或ISA Segment Definition Page (EDI Properties)。

EDI 組結構元素

組包含一個或多個事務集。一個 EDIFACT 組必須包含同一類型的事務集。一個 X12 組可能包含相似類型的事務集（基於事務集 - 組 (GS01-ST01) 映射）或相同類型的事務集。下表列出了在單一組 (GS01) 可能會一塊兒發生的相似 X12 事務集 (ST01)。

 

GS01	ST01
CF	844
	849
DX	894
	895
FR	821
	827
GC	920
	924
	925
	926
HC	837
	837_D
	837_I
	837_P
IA	110
	980
IO	310
	312
ME	198
	200
	201
	245
	261
	262
	263
	833
	872
MG	203
	206
	259
	260
	264
	266
OG	875
	876
PK	196
	839
QG	878
	879
	888
	889
	896
QO	313
	315
RO	300
	301
	303
RQ	836
	840
RS	869
	870
SL	135
	139
SO	302
	311
	317
	319
	322
	323
	324
	325
	326
	361
TO	197
	199
	265
	485
	486
TP	460
	463
	466
	468
	490
	492
	494
WA	140
	141
	142
	143
HIPAA 5010 組還容許單一組內存在不一樣版本的事務集。

若是在處理事務集時遇到異常，將使用 EDI 參與方屬性來肯定是掛起整個交換仍是僅掛起失敗的事務集。

一個組必須以功能組標頭（X12 中的 GS 或 EDIFACT 中的 UNG），且必須以功能組尾部（X12 中的 GE 或 EDIFACT 中的 UNE）結束。組標頭包含發送方和接收方代碼、日期和時間、與標頭和尾部匹配的控制編號、可能包括在功能組內的用於定義事務集的集合的組標識符以及其餘信息。組尾部具備指示組內事務集數目的元素。

組在 EDIFACT 交換內是可選的。即便不存在組（不存在 UNG 段），一個 EDIFACT 交換也可包含多個事務集。在此狀況下，全部事務集都必須具備同一類型，由於一個組中的事務集的類型必須相同。例如，APERAK 和 ORDERS 事務集不能同時出如今一個組或不具備多個組的交換中。

組在 X12 交換內是必需的。

交換包括一個用於定義 EDI 消息的信封。該信封必須以交換標頭（X12 中的 ISA 或 EDIFACT 中的 UNA/UNB）開頭，且必須以交換尾部 (IEA/UNZ) 結束。交換標頭包括定義如下各項的元素：發送方和接收方、日期和時間、版本號、與標頭和尾部匹配的控制編號以及其餘信息。

ISA12 和 GS8 字段（對於 X12 交換）和 UNH2 字段（對於 EDIFACT 交換）包含發現架構所必需的版本信息。

交換尾部具備指示交換中的組數的元素。

EDI 事務集/消息結構元素

事務集（在 X12 編碼中）或消息（在 EDIFACT 編碼中）包含構成消息數據的段。事務集由標頭、數據段集合和尾部組成。事務集中提供了處理事務所需的全部詳細信息。

事務集必須以 ST 事務集標頭（在 X12 中）或 UNH 消息標頭（在 EDIFACT 中）開始，且必須以 SE 事務集尾部（在 X12 中）或 UNT 消息尾部（在 EDIFACT 中）結束。尾部提供包括標頭和尾部段在內的數據段的計數。

事務集能夠包含一個或多個循環，這些循環是重複相關段的集合所必需的。

EDI 段結構元素

段包含一個或多個數據元素，是消息中的中間信息單位。每一個段均以一個由三個字符組成的數據段標識符開頭，以段終止符（默認狀況下爲撇號 (')）結尾。段內的數據元素由數據元素分隔符分隔。默認狀況下，數據元素分隔符爲加號 (+)。段可分爲兩類：必需段和可選段。傳出交換的分隔符可在兩貿易合做夥伴間的協議中設置，也可設置爲後備貿易合做夥伴協議的一部分。

嵌套

段能夠按一種稱爲「嵌套」的分層關係進行分組。有兩種不一樣類型的嵌套：顯式和隱式。在任何一個交換內，只能使用一種類型的嵌套。

• 顯式嵌套顯式指示循環是嵌套的。使用顯式嵌套時，段標記中的第一個組件數據元素將爲段代碼。段代碼後將爲表示段的級別和重複發生率的條件組件數據元素。用於此目的的組件數據元素的數量由段在消息結構中出現的層級決定。若是段將出如今級別一，則會使用緊跟在段代碼以後的組件數據元素。若是段將出如今級別二，則會使用緊跟在段代碼以後的組件數據元素和下一個組件數據元素。若是段將出如今級別三，則會使用段代碼以後的三個組件數據元素。管道沒法執行將數據與層次結構比較的結構驗證。

• 在隱式嵌套中，將嚴格遵循在消息結構中指定的段的順序。段之間的嵌套關係是隱式的，處理時不須要進一步的指示。

循環

在一個事務集內，一個或多個段能夠「循環」的形式重複。有兩種不一樣類型的循環：未綁定和綁定。

未綁定循環

未綁定循環不具備標記循環的開頭和結尾的惟一標識段。未綁定循環按照計數進行重複。若是計數沒有值，則循環將重複兩次。循環中的每一個段只能按指定的順序出現一次。

未綁定循環以惟一的第一個數據元素開頭。在每次出現中，第一個元素可出現一次且僅出現一次。未綁定循環可在循環內進行嵌套；若是在循環內進行嵌套，則內部未綁定循環不能在與任何外部循環相同的序號位置處開始，也不能以與任何外部循環相同的段 ID 開頭。嵌套循環包含的段不能同時爲同一嵌套結構中任何外部循環的起始段。

綁定循環

綁定循環以預約義的段 LS（循環開頭）開頭，以預約義的段 LE（循環結束）結束。LS 段的可選性必須與循環中第一個段的可選性匹配。一個綁定循環能夠包含另外一個綁定循環。

便箋

X12 中的綁定循環與 EDIFACT 中的顯式循環等價。

在循環中使用綁定是爲了解決不明確的問題。LS/LE 段上的要求指示符與循環的第一個段的要求指示符相匹配。綁定會放鬆對某些常常重複段的用法的結構限制。綁定段對起始段 ID 沒有限制。這樣可以使同一段在做爲一個綁定循環的開頭的同時在該循環以外使用，以下例所示：

複製

AALSBBCCLEBB

容許存在從屬循環（循環內的循環）。若是綁定循環在循環內進行嵌套，則內部循環不能在與任何外部循環相同的序號位置處開始。內部綁定循環必須在與之相鄰的外部循環以前結束。

事務集內的每一個綁定循環必須具備一個惟必定義的 <loop_id> 值，該值由一到四個大寫字母或數字組成。建議對應的 LS 和 LE 段也應包含同一惟一的 <loop_id> 值。<loop_id> 數據元素將做爲「常規」數據元素進行處理並驗證其數據類型、最小/最大長度、可選性等等。不會執行跨段（跨越 LS 和 LE）驗證。BizTalk Server 將經過存在且僅存在 LS 和 LE 段來驗證模糊解析。在數據元素規則發生衝突的狀況下，將接受存在錯誤的事務集，且 BizTalk Server 在確認中返回 AK501=E 和 AK2/AK3 的相應評估。

還要求強制 LS/LE 段配對。在不匹配的狀況下，因爲存在內在的模糊解析問題而拒絕事務集，且在事件查看器和 997 確認中返回 AK501 = E 和 AK502 = 5。若是缺乏 LS/LE 段之一或二者，而事務集是明確的，將接受存在錯誤的事務集並返回 AK501=E 和 AK502 = 5。

LS/LE 對能夠是可選的，也能夠是必需的。可是，除非該對包含在可重複的父循環中，不然該對永不會是可重複的。在任一種狀況下，LS/LE 對的 MaxOccurs 可爲 1，但不能大於 1。在架構驗證中，這是強制要求。

EDI 拆裝器和 EDI 組裝器處理 LS 和 LE 段。在解析過程當中，拆裝器爲 LS 和 LE 段建立 XML 節點，並驗證這兩個段。在序列化過程當中，組裝器從 XML 節點建立 LS 和 LE 段，並驗證這兩個段。若是缺乏所需的 LS 或 LE 段，則會掛起/拒絕 AK501 = E 和 AK502 = 5 的事務集。若是存在 LS/LE 段而沒有對應的數據元素，且啓用了 EDI 驗證，則會接受存在錯誤的事務集並在事件查看器和 997 確認中報告 AK501 = E 和 AK502 = 5。

EDI 數據元素：結構元素

數據元素是消息中的基本數據單元。數據元素由數據元素分隔符分隔，默認狀況下 X12 是星號，EDIFACT 是加號。數據元素的可行性定義爲：必需、可選或條件。

數據元素能夠是簡單型，也能夠是複合型。簡單數據元素爲數值型，它們是最低級別的數據。複合數據元素是一串子元素，這些子元素是由複合元素分隔符分隔的簡單數據元素。默認狀態下，複合元素分隔符對於 x12 和 EDIFACT 是冒號。

對於 EDIFACT 編碼的消息，若是經由 EDI 發送的數據須要發送任何定義用做分隔符的字符，則須要使用轉義符來指明後面的字符不是分隔符，而是數據的一部分。默認狀況下，轉義符爲問號 (?)。

便箋

X12 不支持轉義符。若是遇到做爲 X12 編碼的交換數據一部分的分隔符，則交換將在接收方或發送方掛起。