核心功能
- EDIFACT 與 XML 格式的雙向轉換：支援兩種格式之間的完整互轉。
- 全面的交換頭驗證與生成：確保報文結構的合規性。
- 支援多個 EDIFACT 版本：具有自動架構檢測功能。
- 交換確認與功能性確認支援：實現訊息收發的閉環確認。
概覽
接收 EDIFACT 文件時，EDIFACT 端口會驗證 EDIFACT 交換頭並將 EDIFACT 文件轉換為 XML。這作為一個暫存步驟非常有用，因為 XML 是 在流程中處理資料的主要格式。EDIFACT 端口會自動讀取輸入檔案以確定合適的 EDIFACT 架構，然後根據該架構解析文件。 生成 EDIFACT 文件時，EDIFACT 端口會將 XML 轉換為 EDIFACT 文件語法並應用相應的交換頭。在流程的其他位置取得並轉換 XML 資料後，這通常是建立 EDIFACT 文件的最後一步。啟用 Test Indicator 設定可以避免交換頭驗證。
必要條件
開始之前，請確保已為需要處理的文件型別安裝正確的架構。EDIFACT 端口原生支援以下架構定義：4.1、D03A、D04A、D07A、D96A、D96B、D97A、D99A 和 D99B。你可以在 安裝目錄的app_data/edifact_schemas 目錄中找到它們。如果需要其他架構，可以聯絡我們免費下載額外的架構檔案。
下載並解壓 zip 存檔後，將整個資料夾放入 app_data/edifact_schemas 目錄下命名合適的子目錄中。
端口配置
本節包含所有可配置的端口屬性。設定
轉換配置
與端口核心操作相關的設定。EDI 交易夥伴
交換頭配置
與 EDIFACT 交換頭相關的設定。從 XML 生成 EDIFACT 文件時，這些設定用於生成文件頭。解析 EDIFACT 文件時，這些設定用於驗證傳入文件。ACK
與生成和請求確認相關的設定。範例檔案索引標籤
高階頁面
EDI 分隔符號
指定用於分隔元素、段等內容的字元。交換頭配置
與 EDIFACT 交換頭相關的其他設定。這些選項會根據“設定”索引標籤上指定的 語法版本 顯示或隱藏。功能群組配置
與 EDIFACT 文件功能群組頭相關的設定。這些可選識別碼可以幫助將相似的交換分組在一起，或促進組織內的子地址。進階設定
前面類別中未包含的設定。訊息
日誌
雜項
EDI 交易夥伴索引標籤
自動化
自動化設定
與端口自動處理檔案相關的設定。效能
警示
SLA
轉換型別
以下部分詳細介紹 EDIFACT 到 XML 以及 XML 到 EDIFACT 的轉換過程。EDIFACT 轉換為 XML
將 轉換型別 設定為 EDI to XML 會指示端口將傳入的 EDIFACT 文件解析為 XML。端口首先讀取文件中交換和功能群組部分的所有頭資訊，並根據配置的端口設定進行驗證（除非勾選 Test Indicator）。然後，端口解析文件中使用的具體 EDIFACT 架構，並從磁碟上的edifact_schemas 資料夾載入架構（可以從聯絡我們免費下載額外的架構檔案）。端口使用該架構生成表示文件 EDIFACT 結構的 XML，用文件中的值填充 XML，並根據 Generate Descriptions As 的值，以 XML 註釋或 XML 元素屬性的形式為每個值提供上下文。
若要使用一組測試 EDIFACT 文件檢視此過程，請導航到 EDIFACT 端口的 交易 索引標籤（轉換型別 設定為 EDI to XML），然後選擇 More > Create Test Files。系統會自動生成發票、採購訂單、採購訂單確認和發貨通知的 EDIFACT 文件，並將其放入 交易 目錄。端口處理這些測試檔案後，導航到 交易 索引標籤即可檢視生成的 XML。
EDIFACT 文件轉換為 XML 後，可以透過多種方式轉換和處理這些資料。通常，EDIFACT 資料需要儲存在資料庫或其他後端應用系統中。由於 使用 XML 表示對這些後端系統的 inserts，因此儲存 EDIFACT 資料就變成了將一個 XML 結構對映到另一個 XML 結構。這通常透過視覺化設計器驅動的 XML Map 端口完成。
XML 轉換為 EDIFACT
將 轉換型別 設定為 XML to EDI 會指示端口從文件的 XML 表示生成 EDIFACT 文件。端口從 XML 解析出的資料構造 EDIFACT 訊息後，會根據配置的端口設定新增功能群組和交換頭。 若要使用一組測試 XML 檔案檢視此過程，請導航到 EDIFACT 端口的 交易 索引標籤（轉換型別 設定為 XML to EDI），然後選擇 More > Create Test Files。系統會自動生成表示發票、採購訂單、採購訂單確認和發貨通知的 XML 檔案，並將其放入 交易 目錄。端口處理這些測試檔案後，導航到 交易 索引標籤即可檢視生成的 EDIFACT 文件。列印檢視
與 XML Map 端口結合使用
上傳測試檔案
EDIFACT ACK
以下部分詳細介紹兩種 EDIFACT 確認（ACK），以及 如何期待、處理和生成 ACK。技術性 ACK 與功能性 ACK
技術性 ACK 有時稱為交換 ACK，表示雙方之間發生了交換，但不一定表示已交換任何單個訊息。它們作為傳送方的回執，指示 EDIFACT 訊息已成功接收，但不說明處理訊息內容時是否存在任何問題。 功能性 ACK 表示接收方已處理交換。它們可以報告已接受、帶問題接受或拒絕接收的文件。它們既作為交換已成功接收的回執，也表示該交換已被完整處理。期待 ACK、處理 ACK 和生成 ACK
期待 ACK
在 XML 到 EDI 模式下執行的 EDIFACT 端口可以配置為期望訊息傳回技術性 ACK 和/或功能性 ACK。當在設定索引標籤的 ACK 部分勾選 Technical acknowledgment (CONTRL) 和 Functional acknowledgment (CONTRL) 中的一個或兩個時，端口會在適當的 ACK 傳回並處理之前，將傳輸保持為 Pending ACK 狀態。這意味著可以使用端口狀態來確定接收方是否已確認收到交換。 下圖顯示了 期望發票文件傳回 ACK 時涉及的邏輯流程： ![EDIFACT 接收 ACK(/public/images/edifact-ack-receive.png) 在上圖中，XML 到 EDI 模式下的 EDIFACT 端口生成要交換的文件 (1)，並在文件傳輸給交易夥伴期間將其保持為 Pending ACK 狀態。交易夥伴根據其業務邏輯處理傳輸，並按照配置的交換參數建立確認 (2)。確認傳回後，會根據下一節中的資訊進行處理 (3)。處理 ACK
在典型流程中，EDIFACT ACK 會到達以 EDI 到 XML 模式執行的 EDIFACT 端口。可以將此 EDIFACT 端口配置為自動將收到的任何確認路由到最初生成被確認文件的 EDIFACT 端口。透過在 Flows 畫布上將 EDI 到 XML 模式下 EDIFACT 端口底部的灰點拖到 XML 到 EDI 模式下的 EDIFACT 端口，即可直觀配置 EDIFACT 端口之間的 ACK 路由。 XML 到 EDI 模式下的 EDIFACT 端口收到路由的 ACK 後，會將 ACK 與原始訊息配對，並將其狀態從 Pending ACK 更改為 Sent。生成 ACK
當 EDI 到 XML 模式下的 EDIFACT 端口收到訊息並生成相應的 XML 時，可以自動為收到的訊息生成 CONTRL 確認。為此，請在設定索引標籤的 ACK 部分勾選 Technical acknowledgment (CONTRL) 和/或 Functional acknowledgment (CONTRL)。這些確認必須路由到另一個 EDIFACT 端口（XML 到 EDI 模式）以完成 ACK。ACK 被路由到的端口會應用交換頭，並像任何其他 EDIFACT 訊息一樣將 ACK 傳遞到流程中的下一個端口。若要正確路由 ACK，請將 EDI 到 XML 模式下 EDIFACT 端口底部的灰點拖到 XML 到 EDI 模式下的 EDIFACT 端口。 下圖顯示了為收到的發票文件建立 ACK 時涉及的邏輯流程： ![EDIFACT 建立 ACK(/public/images/edifact-ack-create.png) 如上圖所示，在交易夥伴傳送需要確認的訊息後 (1)，解析該文件的 EDI 到 XML 模式 EDIFACT 端口會自動生成 ACK (2)。此 ACK 是一個 XML 檔案，包含與該交易相關的交易資訊。然後，此 XML 確認會路由回 XML 到 EDI 模式的 EDIFACT 端口 (3)，以便在將 ACK 傳送回交易夥伴之前應用交換頭（以及任何其他 EDI 方協議設定）。主-明細層級：轉換 CPS 和 HYN 迴圈
在 EDI 文件中，大多數層次關係由 EDI 段的順序表示。某些 EDI 結構（如 DESADV 文件中的 CPS 迴圈和 PRICAT 文件中的 HYN 迴圈）不遵循此約定，而是將層次關係嵌入 EDI 元素資料本身。這會使將 EDI 資料轉換為 XML 時保留這些層次關係變得困難。 EDIFACT 端口透過高階頁面上的 巢狀迴圈 設定，支援在 CPS 和 HYN 段中保留層次關係。啟用後，端口會解析 CPS 和 HYN 段中的元素，以確定哪些段在層次關係中“屬於”其他段。這些層次關係會在輸出 XML 中體現為父子關係；換句話說，此設定會將 EDI 內容隱含的層次結構轉換為 XML 結構表示的層次結構。 本節說明 CPS 和 HYN 資料中如何編碼層次結構，以及勾選 巢狀迴圈 時如何將此層次結構轉換為 XML。CPS 和 HYN 層級
所有 CPS 和 HYN 段都有兩個有助於建立層次結構的值：- Id 值，用於標識當前段（此值儲存在 CPS01 或 HYN01，即 CPS 或 HYN 段中的第一個元素）
- 父 Id 值，用於標識當前段的層次父級（此值儲存在 CPS02 或 HYN02，即 CPS 或 HYN 段中的第二個元素）
將 CPS 和 HYN 層級轉換為 XML
勾選 巢狀迴圈 時，EDIFACT 端口會自動處理 CPS 和 HYN 層次結構到 XML 層次結構的轉換。端口解析 CPS 和 HYN 段中的 Id 和父 Id 值，並確保生成的 XML 元素適當地巢狀在表示其父元素的元素中。 換句話說，如果segmentA 的父 Id 值等於 segmentB，則生成的 XML 會將 segmentA 作為 segmentB 的子級。這樣，在轉換 EDI 資料時，層次關係會保留在 XML 結構中。
宏
範例
EDIFACT 操作
除了 提供的操作之外，端口還可以提供將功能擴充套件到 ArcScript 的操作。這些端口操作可以像任何其他 ArcScript 操作一樣呼叫，但必須透過connector.rsc 端點呼叫幷包含身分驗證權杖。
以下操作特定於 EDIFACT 端口的功能。
edifactScan
從 EDIFACT 文件的頭中掃描頭值。必需參數
- file：EDIFACT 檔案的路徑。
可選參數
- format：檔案格式。預設值為 EDIFACT。
輸出屬性
- InterchangeSyntaxIdentifier：所使用語法版本的 Id（UNB1.1）。
- InterchangeSyntaxVersion：所使用語法規則的版本。值範圍為 1 到 5，數字越大支援越高階的字元集（UNB1.2）。
- InterchangeSenderIdQualifier：傳送方 Id 的交換限定符（UNB2.2）。
- InterchangeSenderId：交換傳送方 Id（UNB2.1）。
- InterchangeReceiverIdQualifier：接收方 Id 的交換限定符（UNB3.2）。
- InterchangeReceiverId：交換接收方 Id（UNB3.1）。
- DocumentType：文件型別或交易集識別碼程式碼（UNH2.1）。
常見錯誤
以下是常見錯誤、原因以及建議的解決方案清單。錯誤：Schema file not found ([schema major version] [schema document type])
原因 解析 EDIFACT 檔案時，首先會掃描檔案以取得 EDI 版本和文件型別，從而確定解析時使用的架構。應用程式包含大量 JSON 格式的 EDIFACT 架構。它們儲存在應用程式目錄中的schemas 資料夾（位於 data 資料夾旁）。
此錯誤表示應用程式找不到與檔案報告的主版本和文件型別匹配的架構檔案。
如果錯誤訊息中缺少 [schema major version] 或 [schema document type] 值，則 EDI 文件不包含主版本或文件型別。
否則，此錯誤表示合適的文件架構未包含在 自動包含的架構定義集中。
解決方案
如果 EDI 檔案不包含架構主版本或文件型別，請聯絡交易夥伴（或 EDI 文件的其他來源），並告知他們必須在訊息頭中包含這些值。
否則，請從我們的免費下載頁面找到合適的架構版本。下載架構資料夾並將其放在以下路徑：
[application_directory]\schemas\edifact_schemas\[major_version]\
錯誤：The segment at line [line number] with tag [segment name] is not in a valid position in the specified schema ([schema major version] [schema document type]). This may indicate that the input file contains segments that are out of order.
原因 解析 EDIFACT 檔案時，首先會掃描檔案以取得 EDI 版本和文件型別，從而確定解析時使用的架構。應用程式包含大量 JSON 格式的 EDIFACT 架構，儲存在根安裝目錄的www\app_data 資料夾中。
此錯誤表示剖析器在檔案中遇到了一個 EDI 段，該段與相關文件架構中定義的段順序不匹配。這可能表示以下幾種問題：
- 交易夥伴生成的 EDI 檔案不正確
- EDI 檔案使用的架構版本與檔案中指示的版本不同
- EDI 檔案使用自定義架構生成
- 位於磁碟上的端口資料夾內（例如，
<ConnectorDirectory>/Resources/Schemas/） - 如果一個架構由多個端口使用，知行軟體建議使用如下資料夾結構：
<ApplicationDirectory>/schemas/<type>_schemas/<major version>。在此範例中，<type>應為edifact。
- 手動編輯相應的 EDI 架構檔案（位於上述檔案路徑）以調整段順序，使其與合作伙伴的 EDI 檔案匹配。錯誤訊息會指示檔案中段與架構定義發生分歧的行。沿著 JSON 中的段順序定義追蹤，直到找到分歧點，然後重新排列 JSON 中的段，使其與合作伙伴提供的檔案匹配。
- 聯絡交易夥伴瞭解 EDI 檔案。確認該檔案是根據檔案報告的主版本生成的，並說明檔案中段的順序無法識別。