共用方式為


EDI 傳送處理的已知問題

本主題說明處理 EDI 傳送管線的已知問題。

X12 隱含的小數點導致長度驗證失敗

徵兆

當 EDI 傳送管線在外寄的 EDI 交換中,將中繼 XML 中的 10 進制數值轉換成 Nn 格式的數字時,XML 交換的長度驗證程序失敗。

可能的原因

在序列化 X12 編碼的 EDI 交換時,EDI 傳送管線永遠都會將 10 進制數值轉換成具有隱含小數點的 Nn 格式數字。 例如,如果中繼 XML 檔案中有個值為 12.34,而其數字型別指定為 N2 時,EDI 傳送管線便會在 EDI 交換中將它轉換成 1234。 10 進制數值的長度將比 Nn 格式的數字大一。 如果 Nn 格式數字的長度是最大值,中繼 XML 中的 10 進制數值 XML 長度驗證可能會失敗。

這個問題只有在 X12 編碼的交換中才會發生。

解決方法

在 XML 數字的最大長度值加上 1 的值。

控制編號可能必須重設、封存或清除

如果有任何控制編號的長度已達到欄位長度限制的上限,BizTalk Server 會引發錯誤並擱置交換。 您必須重設輸入於 [EDI 屬性] 或 [EDI 全域屬性] 對話方塊中的控制編號。

控制編號儲存在 BizTalk MessageBox 資料庫的 dbo.EdiSequenceNumbers 資料表中。 您應該視情況清除資料表中的控制編號或是封存控制編號,以便管理這份資料庫資料表。

您也可以在 [EDI 屬性] 對話方塊中選取 [重 設為下限] 以 啟用自動重設控制編號。

內容屬性名稱中的資料元素名稱包含底線,而非句號

EDI 區段內資料元素的名稱包含句號,例如 UNB2.1 (UNB2 Sender 區段的識別欄位)。 不過,當 EDI 內容屬性中包含資料元素名稱時 (例如,在傳送埠的篩選運算式中),便會將句號取代為底線。 例如,Sender Identification 資料元素是 EDI.UNB2_1,不是 EDI.UNB2.1。 這是因為內容屬性名稱不支援句號。

資料元素中的內容屬性值在篩選運筫式中不能包含前置或尾端空格

如果 EDI 交換的信封中的資料元素包含前置或尾端空格,而接收管線又以該資料元素的值升級內容屬性,則接收管線將會從內容屬性中移除前置或尾端空格。 因此,使用該內容屬性建立篩選運算式時,您必須輸入不含前置或尾端空格的屬性值。 如果您的篩選運算式包含前置或尾端空格,則篩選運算式不會解析成與內容屬性相符的值,它將不會包含前置或尾端空格。

以預設合作對象做為保留交換的交換接收者屬性將導致傳送管線失敗

如果 BizTalk Server 收到應該保留的批次交換 (交換因為發生錯誤而擱置),若做為交換接收者之合作對象的屬性設定為其預設值,訂閱該交換的傳送管線將會失敗。 這些屬性,例如 ISA5 (傳送者辨識符號) 和 ISA6 (傳送者識別項),必須設定為有效的值。 BizTalk Server 將會發佈錯誤,指出由於合作對象組態無效,因此無法序列化訊息。 這種處理方式並不正確,因為保留的交換在其標頭中具有必要的組態設定,例如傳送者辨識符號和傳送者識別項。

如果傳送端合作對象或全域設定指定不同的小數點標記,訊息中的小數點標記將會改變

如果交換中使用的小數點標記與 UNA3 合作對象屬性針對外寄訊息所指定的小數點標記不同,BizTalk Server 便會在序列化交換以便傳送時,變更該交換的信封中所使用的小數點標記。 如果使用的是 UNA3 全域屬性而非 UNA3 合作對象屬性,也會發生這種情況。 例如,如果內送訊息中使用的小數點標記是句號,而決定外寄訊息小數點標記的 UNA3 合作對象屬性或 UNA3 全域屬性指定的是逗號,BizTalk Server 便會將外寄訊息中的小數點標記改成逗號。

EDI 傳送管線無法從協調流程內部執行

在BizTalk Server中,您通常會在協調流程的運算式圖形內執行傳送管線。 不過,這並不適用於 EDISend 管線或 AS2EdiSend 管線。 這些管線必須從傳送埠內部執行。 如果您嘗試在協調流程中的「運算式」圖形中執行 EDISend 管線或 AS2EdiSend 管線,管線不會繫結至傳送埠,而且訊息也會擱置。

不得修改 BizTalk EDI 應用程式

不得修改或刪除 BizTalk EDI 應用程式內的成品。 應用程式一經修改就無法還原,取消設定和重新設定 EDI 與 AS2 的功能也不行。

使用功能群組標頭方格中的預設資料列可能會導致交換標頭與群組標頭之間的 Message-Type 不符

如果傳出 EDIFACT 編碼交換的 UNH2.1 值不符合 UNG 和 UNH 區段定義頁面中方格中 「For message type UNH2.1」 的值,則訊息中輸入的 UNG1 值可能不會對應至 UNH2.1 的值。

這是因為 BizTalk 會將 UNG1 的值填入方格預設資料列中的 UNG1 訊息,即使訊息與該預設資料列的 UNH2.1 元素不相符也一樣。

如果傳出 X12 編碼交換的 ST1 值不符合 GS 和 ST 區段定義頁面中方格中的 「For ST1」 值,則訊息中輸入的 GS1 值會根據 ST1 的值動態決定。

Data 元素中的字元無效

徵兆

使用 EDI 傳送管線傳送 EDI 交換時,您可能會在應用程式事件記錄檔中收到錯誤,指出資料元素中有「不正確字元」。

可能的原因

如果承載資料中包含的字元也做為分隔符號,就會發生此錯誤。 例如,如果您使用 ':' 字元做為元件分隔符號,但承載資料也包含 ':' 字元。

這個問題只有在 X12 編碼的交換中才會發生。

解決方法

使用 承載中的取代分隔符號搭配 EDI 合作物件屬性之 ISA 區段定義 頁面中的設定,指定在傳送交換時,在承載資料中找到的分隔符號應該由指定的取代字元取代。

例如,選取 [ 以 取代承載中的分隔符號 ],然後輸入 '|' 字元,會在使用 EDI 傳送管線傳送交換時,以 '|' 字元取代承載資料中任何出現的分隔符號。

另請參閱

EDI 處理的已知問題
BizTalk Server 如何傳送 EDI 訊息
逐步解說 (X12):傳送 EDI 交換