核心功能
- 安全可靠的 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] 部分下存在以下行：