核心功能
- 安全可靠的 B2B 文件交換
- 全面的安全支援，包括簽章、加密和壓縮
- 同步和非同步 MDN 回執處理，具有自動重試和重發功能
- 支援超大訊息，具備流式傳輸和中斷點續傳能力
- 面向交易夥伴關係的全面憑證管理
- AS2 可靠性和 FDA 擴充套件解析等高階功能
- 已獲得 Drummond Group 認證
概觀
AS2 連線需要在兩個位置進行配置。首先在 AS2 配置檔案頁面配置本地 AS2 識別碼、私密金鑰憑證以及適用於所有 AS2 連線的其他全域資訊。然後，為單個交易夥伴在各個 AS2 端口中配置專用連線設定。當輸入檔案由 AS2 端口處理時，它會被打包並傳送到指定的交易夥伴。 當 透過 AS2 接收檔案時，會嘗試將檔案路由到特定的 AS2 端口。應用程式使用 AS2 訊息中的 AS2 識別碼確定應由哪個 AS2 端口接收該檔案。檔案路由到 AS2 端口後，會放入端口的交易 Tab，或傳遞到工作流程中的下一個端口。 AS2 端口支援使 AS2 成為常用協議的所有安全性和可靠性機制。更多資訊，請參閱 AS2 協議交換說明和用於 AS2 安全性的憑證說明。影片資源
觀看此短影片，瞭解如何快速設定 AS2 端口。這是由三部分組成的影片系列的第一部分，涵蓋端到端 B2B 整合的每個步驟：託管檔案傳輸（以 AS2 為例）、後端整合以及 EDI 翻譯和對映。該系列其他部分的連結如下。- 第二部分： 資料庫端口操作指南
- 第三部分： EDI 工作流程操作指南
配置檔案配置
必須先配置 AS2 配置檔案，才能與各個 AS2 端口建立連線。單擊導覽列上的配置檔案。AS2 配置檔案 Tab
個人 ID
用於標識本地配置檔案的設定。個人憑證
與私有解密和簽章憑證相關的設定。應用程式 URL
與從公網存取 相關的設定和顯示值。其他
端口配置
配置全域 AS2 配置檔案設定後，可在工作流程頁面為每個交易夥伴建立並配置單獨的 AS2 端口。設定 Tab
交易夥伴資訊
用於識別並連線到特定 AS2 交易夥伴的設定。連線資訊
與指定交易夥伴連線參數相關的設定。MDN 回執
與傳送 AS2 訊息時請求 MDN 相關的設定。交易夥伴憑證
與交易夥伴提供的公開金鑰憑證相關的設定。公開配置檔案
釋出在公共端點上的 AS2 配置檔案詳情，交易夥伴可存取該端點。此端點在配置檔案頁面中配置。高階 Tab
超大訊息支援 (VLM)
用於支援傳送大型 AS2 訊息的設定。並非所有 AS2 系統都支援此功能。
可靠性
與 AS2 協議可靠性功能相關的設定。備用本地配置檔案
此特定 AS2 端口中用於覆蓋配置檔案頁面 AS2 配置的設定。設定備用本地配置檔案後，可以為某些交易夥伴使用不同的本地憑證和識別碼。TLS 用戶端認證
需要雙向 TLS 認證時，與用戶端認證相關的設定。HTTP 認證
與 HTTP 用戶端認證相關的設定。自定義頭
一組要包含在傳出訊息中的自定義頭。進階設定
先前類別中未包含的設定。代理設定
訊息
日誌
其他
自動化 Tab
自動化設定
與端口自動處理檔案相關的設定。效能
警示 Tab
SLA Tab
建立連線
交易夥伴必須提供配置新 AS2 端口時所需的一些連線詳情。這些詳情至少應包括：- AS2 識別碼
- 夥伴 URL
- 夥伴憑證
AS2 識別碼
在 AS2 交易中，交易夥伴透過其 AS2 識別碼進行識別。傳送傳出請求時，AS2 識別碼用於請求頭，以指示接收者。 要建立 AS2 自檢，識別碼應設定為與配置檔案頁面上的 AS2 識別碼相同的值。此值區分大小寫。
夥伴 URL
夥伴 URL 是交易夥伴接收 AS2 傳輸的端點。傳出的 AS2 訊息會傳送到此目標端點，且每個交易夥伴都必須具有唯一端點。可以使用 Web 瀏覽器測試夥伴 URL，以檢查網路或連線問題。 要建立 AS2 自檢，目標 URL 應與配置檔案頁面上的接收 URL 相同或幾乎相同。可以將“配置檔案”頁面中的域名替換為環回地址 localhost，使 AS2 交易保留在本地網路中。本地自檢 URL 範例為http://localhost:8001/pub/Receive.rsb。
如果不將域名替換為 localhost，AS2 訊息會被路由到本地網路之外。可以利用這一點檢查網路配置設定，並確保訊息能夠穿過任何防火牆到達 。
交易夥伴有時可能會提供多個 URL：一個接收 URL 和一個用於非同步 MDN 的 URL。在這種情況下，只需配置接收 URL（夥伴 URL）；應用程式可以從傳入的 AS2 傳輸中讀取非同步 MDN URL。
夥伴憑證
每個 AS2 端口都必須配置目標交易夥伴的公開金鑰憑證。交易夥伴會提供加密和驗證與其交換的 AS2 訊息所需的憑證。 接受 X.509 公開金鑰憑證（副檔名為 .cer、.der 或 .pem 的檔案）。 通常，交易夥伴會提供一個憑證，應將其配置在加密憑證欄位中。 如果交易夥伴提供多個憑證，應說明每個憑證的用途。如果夥伴提供完整憑證鏈（例如從商業憑證頒發機構取得），則只需配置葉子憑證（憑證鏈中的最後一個憑證）。少數情況下，可能需要單獨的公開金鑰憑證來驗證夥伴的數字簽章。在這種情況下，請在高階 Tab > 進階設定 > 夥伴簽章憑證中設定簽章驗證憑證。傳送和接收檔案
配置 AS2 配置檔案和特定於夥伴的 AS2 端口後，即可安全地傳送和接收檔案。傳送檔案
在 AS2 端口中，交易 Tab 顯示要傳送到目標交易夥伴的檔案。如果在自動化 Tab 上啟用了傳送自動化，到達端口交易 Tab 的檔案會自動打包並傳送。展開與已傳輸檔案關聯的行，即可存取所有傳輸的日誌檔案。 建立測試檔案按鈕可生成一組簡單的測試檔案，以傳送給交易夥伴。重發和重試
當預期交易夥伴傳回非同步 MDN，但其未在重發間隔時長內（預設為 60 分鐘）傳回時，將觸發 AS2 重發。隨後應用程式會嘗試重新傳送該傳輸。應用程式將繼續重發訊息，直到收到 MDN 或**最大嘗試次數（非同步）**用盡為止。 當交易夥伴的 HTTP 回應表明伺服器未收到傳輸（回應不是肯定的 200 OK 狀態）時，將觸發重試。這可能表示網路或連線問題，且通常是暫時性的。應用程式每隔重試間隔分鐘重試一次傳輸，直到傳輸被接收或最大嘗試次數用盡為止。接收檔案
在 AS2 端口中，交易 Tab 顯示應用程式已接收並路由到該端口的檔案（基於傳入 AS2 訊息中的 AS2 識別碼）。展開每個檔案行可顯示該傳輸的可用日誌清單。 這些檔案可在端口的交易 Tab 中檢視。如果端口連線到工作流程中的其他端口，檔案會自動從 AS2 端口的交易 Tab 移動到工作流程中下一個端口的交易 Tab。 AS2 協議不允許主動從交易夥伴拉取檔案：AS2 端口只能被動等待交易夥伴傳送檔案。接收檔案疑難排解
接收 AS2 訊息時發生的問題可能比傳送檔案時的問題更難追蹤。_傳送_檔案時發生錯誤，該錯誤會立即顯示在 AS2 端口的交易 Tab 和活動頁面上。_接收_檔案時，錯誤和其他偵錯資訊可能會出現在多個位置。 收到 AS2 訊息後，會根據端口中配置的 AS2 識別碼（以及傳入訊息中的 AS2 識別碼）嘗試將該訊息路由到特定的 AS2 端口。根據此路由操作是否成功，可以在三個位置檢查日誌資訊：- 如果 成功路由訊息，則為此交易夥伴配置的 AS2 端口的交易 Tab 中會有錯誤日誌。
- 如果 無法成功路由訊息，應用程式日誌中會有錯誤日誌。
- 如果 AS2 端口或應用程式 Tab 中都沒有日誌，則 AS2 訊息一開始就沒有到達 。
AS2 交換中發生了什麼
儘管 AS2 在應用層面較為複雜，但可以歸結為兩個基本部分：文件透過 HTTP 從 AS2 傳送方傳送到 AS2 接收方；HTTP 是一種非常靈活的用戶端-伺服器協議，也是 Web 的基礎。接收方透過向傳送方提供回執來確認傳輸。 下圖更詳細地展示了這些步驟。
步驟 1：EDI 文件準備
AS2 交換中可以傳送任何型別的文件，從文字檔案到 PDF 均可。不過，通常大多數交易夥伴會針對特定文件型別實施標準。 最常見的文件型別是電子資料交換（EDI）X12 文件（.x12 或 .edi 檔案）、行政、商業和運輸電子資料交換（EDIFACT）文件（.edifact 檔案），或 XML 檔案（.xml 檔案）。文件準備工作在 AS2 通訊開始之前完成。 EDI 是交易夥伴之間傳輸文件及其遵循標準的總稱，也稱為 Internet 上的 EDI（EDIINT）。步驟 2：AS2 打包
AS2 文件會被準備好以便傳送。這包含三種文件轉換：- 如果文件由可壓縮資料組成（即不是二進位資料），可以使用 zlib 壓縮演算法對文件進行_壓縮_，以減小傳輸資料的大小。
- 通常使用傳送方的私密金鑰對資料進行_簽章_，以確保傳送方作為文件建立者的身份（通常使用 SHA-1 簽章演算法）。
- 最後，可以使用接收方的公開金鑰對資料進行_加密_，使只有交易夥伴能夠讀取資料（通常使用 3DES 加密演算法）。如果資料將透過 HTTPS 等安全傳輸機制交付，則可以跳過此步驟。
步驟 3：HTTP/S 交付
準備好的文件會透過 HTTP 或 HTTPS 協議，經由 Internet 交付到交易夥伴的 Web 伺服器。步驟 4：AS2 解包
準備好文件的接收方會將其解包以取得 EDI 文件。如果資料已加密，則使用接收方的私密金鑰對準備好的文件進行_解密_。如果資料已簽章，則使用傳送方的公開金鑰_驗證_文件上的簽章，以確保傳送方身份。如果文件已壓縮，則對準備好的文件進行_解壓縮_，以生成原始 EDI 文件。步驟 5：EDI 處理
AS2 接收方將解包後的 EDI 文件傳遞給處理資料的後端流程，以執行任何額外的業務邏輯。系統會解析 EDI 文件，接收方還可能發起一個新的 AS2 交易，在該交易中傳送方和接收方角色互換。尤其對於 EDI-X12 文件，通常會向原始傳送方傳送 997 功能確認，以表示原始 EDI 文件已在後端業務邏輯中處理。步驟 6：MDN 回覆
接收方向傳送方傳送 MDN，通常使用接收方的私密金鑰進行_簽章_。MDN 是 AS2 交換中傳回的回執，用於向傳送方報告接收到了什麼以及是否成功接收。 MDN 包含文件是否成功解包的資訊，以及基於已接收負載計算出的訊息摘要。隨後，MDN 會根據傳送方請求的交付方式，以兩種方式之一傳回給傳送方。在_同步_交易中，接收方在其 Web 伺服器的 HTTP 回應中傳回 MDN。在_非同步_交易中，HTTP 回應包含一個簡單確認（200 OK），而 MDN 透過單獨連線傳回（通常在預計 AS2 傳輸解包需要一段時間時使用）。步驟 7：MDN 處理
傳送方從接收方收到 MDN 後，如果 MDN 已簽章，則會_驗證_ MDN 簽章。隨後檢查 MDN 狀態，以確認接收方是否成功處理了交易，或是否遇到 MDN 中報告的錯誤。最後，將 MDN 中報告的訊息摘要與根據已傳送 EDI 資料計算出的訊息摘要進行匹配。藉助簽章 MDN，傳送方可以驗證訊息接收者是否按預期收到了 EDI 文件的完整內容。憑證
AS2 端口同時使用私密金鑰憑證和公開金鑰憑證。私密金鑰憑證
AS2 端口允許指定 PKCS#12 格式（.pfx 檔案或 .p12 檔案）的憑證。私密金鑰憑證用於執行只有私密金鑰持有者才能執行的兩項操作：- _簽章_資料以證明你的身份
- _解密_原本傳送給你的資料
公開金鑰憑證
公開金鑰憑證由交易夥伴提供。AS2 端口允許指定 X.509 格式（.cer 或 .der 檔案）的公開金鑰憑證。公開金鑰憑證用於執行與需要私密金鑰的操作相反的工作。這些操作包括：- _驗證_交易夥伴建立的簽章
- _加密_資料，使只有交易夥伴能夠讀取
宏
範例
常見錯誤
以下是常見錯誤、原因和建議解決方案清單。如需更多資訊，請聯絡 support@kasoftware.cn。錯誤：The receipt signature could not be verified: Message digest mismatch in signature
造成原因 MDN 回執簽章包含訊息摘要，用於確保訊息內容在傳輸過程中未被更改。摘要不匹配可能表明 MDN 在接收前被更改，或未在夥伴端正確生成。 有時，此錯誤可能是由防病毒或檔案安全軟體錯誤剝離了 MDN 回應的一部分導致。ESET 的應用程式協議過濾功能存在一個已知問題：摺疊的 MDN 頭可能因空格被移除而失效。 解決方案 檢查夥伴傳回的 MDN 是否存在明顯問題。下載引發此錯誤的交易對應的 .mdn 檔案，並將其與問題說明一起傳送至 support@kasoftware.cn，或自行進行排查。 聯絡交易夥伴確認他們使用的 AS2 解決方案也可能有所幫助。 可與任何透過 Drummond 認證的 AS2 解決方案互操作。錯誤：The receipt signature could not be verified: The certificate specified does not match the signature
造成原因 MDN 回執使用私密金鑰簽章，並使用相應的公開金鑰驗證此簽章。此錯誤表明用於驗證此夥伴簽章的公開金鑰配置不正確。 解決方案 通常，用於加密的同一公開金鑰憑證也用於驗證簽章。在這種情況下，請檢查 AS2 端口中設定 > 加密憑證下設定的憑證，確保已為此交易夥伴正確配置。 有時，交易夥伴會使用單獨的憑證進行簽章。在這種情況下，請將高階 > 夥伴簽章憑證設定為與夥伴簽章金鑰匹配的公開金鑰憑證。錯誤：The receipt signature could not be verified: Message digest was encrypted with unknown algorithm
造成原因 這是應用程式較舊版本中的已知問題，這些版本僅支援 SMIME 加密 v3.1。如果 MDN 包含使用 SMIME 3.2 加密的訊息摘要，就會擲回此錯誤。 解決方案 的所有當前版本（包括 v2016 的最終釋出版本）均支援 SMIME 3.2。較舊版本需要升級才能解決此錯誤。錯誤：MDN Error
Authentication failed 或 Signature Authentication failed: Could not authenticate signer’s identity 造成原因 此錯誤作為 MDN 回應的一部分傳回，表示交易夥伴無法驗證 AS2 請求中的簽章。這通常表明交易雙方之間存在憑證不匹配。 解決方案 檢查 AS2 配置檔案中配置的私密金鑰憑證是否正確，並確認交易夥伴已在其端配置匹配的公開金鑰憑證。錯誤：MDN Error: Unexpected processing error
造成原因 此錯誤由交易夥伴系統擲回，並作為 MDN 的一部分傳回，用於指示處理 AS2 請求失敗。這是一個一般錯誤，當問題與簽章、加密或壓縮無關時擲回。 解決方案 由於此錯誤不包含具體偵錯資訊，請聯絡交易夥伴以取得有關故障原因的更多資訊。錯誤：System error: Connection refused
造成原因 此網路錯誤表示一般連線問題。當嘗試連線到未主動偵聽的伺服器時會擲回此錯誤。這可能表示伺服器已停機，或連線嘗試發往了錯誤 URL。 解決方案 檢查目標 URL 是否正確。如果錯誤仍然存在，請聯絡目標系統的伺服器管理員，確認伺服器是否已停機，或他們是否有關於該問題的更多資訊。錯誤：Connection failed
A connection attempt failed because the connected party did not properly respond after a period of time 或 Connection timed out 造成原因 此網路錯誤表示一般連線問題。當連線伺服器的嘗試在一段時間內（通常為 60 秒）沒有回應時會擲回此錯誤。這通常是防火牆干擾伺服器回應導致的，但也可能表示連線參數不正確。 解決方案 檢查防火牆是否阻止伺服器回應傳回。如果伺服器也位於防火牆後，請檢查傳送 AS2 訊息的 IP 是否已加入伺服器防火牆白名單。 如果已排除防火牆因素，請檢查目標 URL 是否正確。錯誤：Synchronous MDN expected but not received
造成原因 這是一個一般錯誤，表示 AS2 請求的回應不是 MDN。這可能表示 AS2 請求未按預期傳送到 AS2 伺服器。如果傳回了 MDN，但該 MDN 已損壞，導致 無法正確識別它，也會擲回此錯誤。 解決方案 檢查目標 URL 是否正確。然後檢查防火牆是否可能剝離了 MDN 內容，導致 無法正確解析。如果 MDN 問題不明確，請找到與失敗交易關聯的 .mdn 檔案，並將其與問題說明一起提供給 support@kasoftware.cn。錯誤：Unsigned MDN received, but signed MDN requested
造成原因 當預期交易夥伴回應為已簽章 MDN 回執，但實際收到其他內容時，會擲回此錯誤。這可能是未簽章的 MDN 回執，也可能是根本不是 MDN 的回應。 解決方案 檢查失敗交易的 MDN 日誌檔案內容。該檔案包含伺服器回覆，無論它是未簽章 MDN 還是某種非 MDN 回應。MDN 日誌檔案內容會指示後續步驟：如果伺服器回應根本不是 MDN，它可能包含錯誤，或表明傳送 AS2 請求的端點不是 AS2 接收端點。如果 MDN 日誌檔案包含未簽章 MDN，則表示交易夥伴系統存在配置問題。錯誤：Unable to find valid certification path to requested target
造成原因 此錯誤由 Java 版本中的底層 Java 安全提供程式擲回，表示目標 Web 伺服器提供的 SSL 伺服器憑證不受系統信任。 解決方案 可以在 AS2 端口中透過將交易夥伴憑證 > TLS 伺服器憑證設定為伺服器公開金鑰憑證或Any Certificate 來覆蓋 TLS 伺服器憑證信任。可以透過大多數 Web 瀏覽器連線到 Web 伺服器來取得伺服器憑證。
錯誤：Key does not exist
造成原因 這是 Windows CryptoAPI 的一個已知問題，會在多個執行緒嘗試存取同一私密金鑰時出現。預設情況下， 使用 Windows CryptoAPI 執行載入私密金鑰憑證等安全操作。 解決方案 自帶加密操作的內部實現，可以啟用此託管實現來繞過 Windows CryptoAPI 限制。導航到 安裝目錄中的data 資料夾，找到相關 AS2 端口的資料夾，並在文字編輯器中開啟 port.cfg。為在載入憑證時啟用託管安全實現，請確儲存在以下行：
錯誤：Input string was not in a correct format
造成原因 這表示 AS2 端口配置的某些方面未透過字串驗證。通常，接收 URL 設定或事件指令碼中的某些字串處理是錯誤來源。 解決方案 檢查接收 URL 中的目標 URL 是否以有效的 HTTP 字首開頭（純文字連線為http://，SSL 連線為 https://），並且不包含任何意外空白。
如果端口的事件中存在指令碼（例如 BeforeSend 或 AfterReceive），請檢查是否執行了無效字串處理。請聯絡 support@kasoftware.cn，確認指令碼是否導致該問題。
錯誤：500 Internal Server Error
造成原因 此 HTTP 錯誤表示一般伺服器端故障。AS2 訊息已成功接收，但處理訊息時發生錯誤，且沒有更多偵錯資訊可用。 解決方案 唯一可能與此問題相關的用戶端設定是目標 URL。如果該 URL 正確，請查閱伺服器端日誌，瞭解導致處理失敗的更多資訊。請與交易夥伴確認這些伺服器日誌是否可用。錯誤：404 Not Found
造成原因 此 HTTP 錯誤表示在目標 URL 處找不到資源。這通常表示 URL 前半部分正確（主機、端口），但 URL 後半部分（資源路徑）無法識別。 解決方案 檢查目標 URL 中的資源路徑是否正確。請與交易夥伴確認預期的資源路徑。錯誤：401 Unauthorized
造成原因 此 HTTP 錯誤表示存取指定 URL 需要授權。這可能是 TLS 用戶端認證或 HTTP 認證。 解決方案 如果需要 TLS 用戶端認證，請在端口配置的高階 > TLS 用戶端認證部分設定適當的憑證。如果需要 HTTP 認證，請在高階 > HTTP 認證中設定適當的憑據。 要確認是否需要 HTTP 認證，請使用 Web 瀏覽器測試到目標 URL 的連線，並留意是否出現使用者名稱/密碼憑據提示。錯誤：Incoming request did not match a configured trading partner profile
造成原因 當 收到 AS2 訊息時，應用程式會根據配置的 AS2 識別碼嘗試將訊息路由到特定 AS2 端口。此錯誤表示找不到傳送方和接收方 AS2 識別碼與 AS2 訊息中值匹配的端口。 解決方案 檢查 AS2 配置檔案頁面以及受此錯誤影響的特定交易夥伴對應 AS2 端口上配置的 AS2 識別碼。錯誤：Error during handshake: The token supplied to the function is invalid
造成原因 這是 WinSock 庫（Windows 套接字）傳回的幾個 SSL 錯誤之一。通常在嘗試透過 HTTP 連線到期望 HTTPS 連線的伺服器時，會發生此錯誤。 解決方案 請與交易夥伴確認 AS2 連線應使用 HTTP 還是 HTTPS，並檢查目標 URL 是否具有適當的字首和端口。錯誤：Error during handshake: the buffer supplied to a function was too small
造成原因 這是系統 WinSock 庫傳回的幾個 SSL 錯誤之一，也是某些伺服器作業系統上 Windows CryptoAPI 的已知錯誤。使用 TLS 1.2 和兩個特定密碼套件時會發生此問題：TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
data 資料夾，並在文字編輯器中開啟 profile.cfg 檔案。確保 [Application] 部分下存在以下行：