本文旨在針對AS2協議操作展開全面描述，主要內容包括：

• AS2是如何工作的？
• AS2系統的關鍵組成部分
• AS2中的信息流

AS2是如何工作的？

首先需要通過內部應用生成需要通過AS2傳輸給合作伙伴的文件。大多數此類文件是遵循 ANSI X12 （美國國家標準委員會）標準或者遵循 UN/EDIFACT （聯合國行政、商業和運輸電子數據交換）標準的電子數據交換（EDI）格式。企業內部的業務系統（如ERP系統等）會提供需要的業務數據并經由EDI系統將這些業務數據轉換為標準的EDI報文或其他文件格式，此類文件會提交給AS2通信軟件，以便傳輸給合作伙伴。

合作伙伴詳細信息是針對 AS2 軟件定義的，包括合作伙伴 AS2 標識符、URL 和證書。上游應用程序使用 API、共享目錄、SFTP或消息等與 AS2 軟件集成。

在知行之橋EDI系統中，將AS2功能封裝在功能模塊中，用戶無需添加代碼，只需要在可視化界面中配置自己和合作伙伴的AS2連接參數即可開始AS2連通性測試。

AS2 端口的關鍵組成

AS2端口配置

知行之橋EDI系統中的端口即功能模塊，AS2端口中集成了AS2通信所需的功能，并提供可視化界面，降低操作難度。用戶需要在AS2端口中配置AS2連接信息，包括：AS2標識符、密鑰對以及證書。大多數組織/企業都會為 AS2 定義一個端口，有些會創建獨立的端口以供測試和生產使用。組織還可以為不同的業務部門或者身份創建單獨的端口，每個AS2端口都應具有描述性的AS2標識符，例如：

• CompanyA_AS2單個AS2端口，用于測試和生產，適用于大多數組織的業務需求。
• CompanyA_AS2_TEST,CompanyA_AS2_PROD兩個用于測試和生產使用的AS2端口，通常用于大型組織。
• CompanyA_AS2_MANUFACTURING,CompanyA_AS2_DISTRIBUTION同一組織的不同業務部門使用的多個端口，適用于超大型組織。

證書存儲區

點擊知行之橋EDI系統右上角的 齒輪 圖標，在 證書 選項卡下，列出了當前使用的所有證書。在這個界面中，能夠創建和上傳證書以及了解已有證書的基本信息，包括：名稱、主題、頒發者、失效日期等。到期后輪換的證書和新證書通常由合作伙伴提前提供。

Mailboxes 郵箱

郵箱（如收件箱和發件箱）存儲接收和發送的郵件。郵箱就像電子郵件文件夾，有助于組織和查看郵件。可以撰寫或發送新消息，也可以下載和查看已接收的消息。每條消息還會將其 MDN 狀態顯示為 success 或 failed。

集成

AS2 解決方案可能會提供多個選項，以便與生成和處理文件的現有系統集成?？捎玫某Ｒ娺x項如下：

• API，例如 REST API
• SFTP 服務器
• AWS S3 存儲桶集成
• 共享文件系統位置 / NFS
• 消息系統

大多數基于 SFTP、S3 或本地共享文件夾等文件的系統將具有如下目錄結構。此外，可能還有傳輸失敗的目錄。

傳出文件被放置的位置：例如 AS2/send// /
收到的傳入文件：例如 AS2/files// /inbox/
發送后的傳出文件：例如 AS2/files// /outbox/

大多數基于 REST 的 API 可能會公開 URL，如下所示。

提交消息：例如 POST /message/submit
列出收到的消息：例如 GET /message/inbox
列出發送的消息：例如 GET /message/outbox
按 ID 下載特定消息：例如 GET /message/inbox/

AS2中的消息流

發送方

1.使用安全哈希函數計算消息完整性檢查 （MIC） 或消息摘要。最常用的哈希算法是 MD5、SHA-1 或 SHA-256
2.如果文檔包含可壓縮的數據（即不是二進制數據），則可以使用 zlib 壓縮算法對文檔進行壓縮，以減少傳輸數據的大小。
3.使用發件人的私鑰對文件內容進行數字簽名（通常使用SHA-1 簽名算法），并將文件內容和簽名放入 MIME 消息中。
4.使用接收方的公鑰或證書，使用文件內容和簽名加密（通常使用3DES 簽名算法） MIME 消息。使用現在加密的內容覆蓋 MIME 消息。（請注意，解密后，上述步驟 #2 的內容將可用，包括簽名和文件內容）
5.添加 AS2 協議特定的頭部信息，例如 AS2-From、AS2-To 等，并將 S/MIME 消息作為 HTTP POST 傳輸到合作伙伴的 URL

接收方

1.檢查收到的 AS2 消息頭部信息，以驗證收到的消息是否發送給收件人，以及發件人是否已知。
2.如果收到被進行壓縮處理的文檔，則文檔將被 解壓縮 生成原始的EDI文檔。
3.使用接收方的私鑰解密最外層的payload
4.驗證發件人放置的數字簽名，以驗證發送消息的合作伙伴，并且payload未被更改
5.計算消息完整性檢查（MIC），通過對收到的原始payload進行哈希處理
6.通過使用接收方的私鑰對收到的 MIC 進行數字簽名來創建消息處置通知 （MDN）。
7.使用HTTP響應向發送方回復MDN（即同步MDN）或者回復一個新的HTTP消息（即異步MDN）

發送方接收MDN

1.收到 MDN 后，使用合作伙伴的證書驗證其簽名，以確認它已由收到原始消息的已聲明的合作伙伴進行數字簽名和發送。
2.存儲成功（或失敗）的 MDN，以便進行不可否認、調查或故障排除。

說明

• 即使使用 HTTP 能夠提供 AS2 的所有保證，但也可以使用 HTTPS 代替 HTTP 作為傳輸機制。
• 簽名、加密和 MDN 不是由 AS2 規范強制實施的，各合作伙伴之間可以溝通協商是否需要使用。
• 每個合作伙伴的證書都包含其非對稱密鑰對的公鑰，在開始通過AS2傳輸文件之間，通常需要企業通過電子郵件獲取到其交易伙伴的公鑰。
• AS2 中使用的證書不需要由第三方受信任的證書頒發機構 （CA） 簽名。但是，某些行業（例如歐洲的能源行業）可能需要此類簽名證書。

閱讀原文