跳到主要内容

EDI系统集成

EDI 系统集成说明​

一、关于 EDI​

​ EDI（Electronic Data Interchange - 电子数据交换）是商业伙伴之间以标准电子格式进行的计算机间的商业文件交换。从以纸张为基础的商业文件交换转变为电子文件交换，企业可以享受到降低成本、提高处理速度、减少错误和改善与商业伙伴关系等重大好处。

​ 计算机到计算机的电子数据交换取代了邮寄、传真和电子邮件。虽然电子邮件也是一种电子方式，但通过电子邮件交换的文件仍必须由人而不是计算机来处理。人的参与会减慢文件的处理速度，还会造成错误。相反，EDI 文件可以直接流向接收方计算机上的相应应用程序（如订单管理系统），并立即开始处理。

1.1 人工参与的流程​

​ 典型的人工流程是这样的，有大量纸张和人员参与：

image-20250427143509972

​ 上图人工流程通常会发生以下操作：

  1. 库存系统自动通知买方下订单，或在查询库存系统后，买方确定需要创建订单

  2. 买方在采购系统屏幕上输入数据以创建 PO，打印并邮寄 PO

  3. 几天后，供应商收到采购订单，并手动将其输入销售订单系统

  4. 供应商打印发票，随货附上和/或单独邮寄

  5. 买方手动将发票输入应付账款系统

（纸质文件的交换可能会增加一周的时间。如果手工输入数据造成错误，时间还会大大增加。)

1.2 完全由计算机主导的流程​

​ 电子数据交换流程是这样的，没有纸张和人员参与：

​ image-20250427144457515

​ 上图电子数据交换流程如下：

  1. 买方的采购系统利用 EDI 软件，在库存达到临界水平时自动生成并发送 EDI 格式的采购单

  2. 在几分钟内，供应商的销售订单系统利用 EDI 软件接收 EDI PO，通知运输部门装运货物，并生成 EDI 发票，直接传送到买方的应付账款系统。

（电子数据交换过程可在数小时内完成。）

1.3 标准规范​

​ 企业之间通过 EDI 交换的最常见单据是采购订单、发票和预先装运通知。但还有很多其他类型的单据，如提单、海关单据、库存单据、运输状态单据和付款单据等。

​ 由于电子数据交换文档必须由计算机而非人类处理，因此必须使用标准格式，以便计算机能够阅读和理解文档。标准格式描述了每条信息的内容和格式（如整数、十进制、年月日）。如果没有标准格式，每家公司都会使用本公司特有的格式发送文件，就像说英语的人可能不懂日语一样，接收方的计算机系统也不懂发送方格式中的公司特有格式。

常见的标准格式有 ANSI ASC X12、EDIFACT：

  • ANSI ASC X12

    1979 年，美国国家标准协会 (ANSI) 授权认可标准委员会 (ASC) X12 制定行业间电子交换业务交易（即电子数据交换）的统一标准。ANSI X12 最初的设想是为北美不同行业的公司提供支持，但如今全球已有 30 多万家公司在日常业务交易中使用 X12 EDI 标准。ASC X12 还为在美国以外广泛使用的 UN/EDIFACT 信息做出了贡献。

  • EDIFACT（United Nations/Electronic Data Interchange for Administration, Commerce and Transport）

    联合国/行政、商业和运输电子数据交换是由联合国制定的国际标准。该标准的维护和进一步发展工作由联合国欧洲经济委员会下属的联合国贸易便利化和电子商务中心（UN/CEFACT）负责。EDIFACT 标准提供了一套结构语法规则和交互式交换协议，并提供了一套允许多国和多行业交换电子商业文件的标准信息。EDIFACT 在欧洲得到广泛应用，主要是因为许多公司很早就采用了这一标准。EDIFACT 在 ASPAC 地区也得到了一定程度的采用，但目前该地区使用的基于 XML 的标准更多。

1.4 标准流程​

​ 发送 EDI 文件有 3 个步骤：准备文件、将文件转换成 EDI 格式、将 EDI 文件传输给合作伙伴。

第一步：准备要发送的文件

第一步是收集和组织数据。例如，采购方系统不是打印采购订单，而是创建一个包含必要采购信息的电子文档，以建立 EDI 文档。生成电子文档的数据来源和方法可能包括：

  • 通过浏览器进行人工数据输入
  • 从电子表格或数据库中导出的数据
  • 将电子报告重新格式化为数据文件
  • 增强现有应用程序，自动创建输出文件，以便转换成 EDI 标准
  • 内置 EDI 文件接口的采购应用软件

第二步：将文件翻译成 EDI 格式

下一步是将第一步的电子数据输入转换软件，使用适当的分段和数据元素将内部数据格式转换为 EDI 标准格式。这需要专业的映射知识，以确定如何将内部数据映射成 EDI 格式的数据。

第三步：连接并向业务伙伴传输 EDI 文档

一旦业务文档被转换成适当的 EDI 文档后，就可以将其传输给业务合作伙伴了。这里必须决定如何连接到每个合作伙伴以进行数据传输。其中最常见的是使用 AS2 或其他安全互联网协议直接连接。

image-20250428101432393

1.5 结构说明​

​ EDI 文档在开头包括 2 个技术段，多条消息，在结尾处包括另一个技术段。以 EDIFACT 中的 D96A INVOIC 发票为例：

	Interchange control Header : 

​						UNA:+.? ' 

​						UNB+UNOC:3+Supplier_id:qualifier+SIRET number:14+Date:Hour+interchange number’ 

​						supplier_id : SIREN for French suppliers, DUN code or other id for non-French suppliers 

​						Orange Siret = 38012986600014

​	Messages : 

​						UNH Message Header 1 

​									Document Header Section 1 

​									… 

​									Document Details Section 1 

​									… 

​									Document Footer Section 1 

​									… 

​						UNT (Message Trailer 1) 

​						… 

​						… 

​						… 

​						UNH (Message Header XX) 

​									Document Header Section xx 

​									… 

​									Document Details Section xx 

​									… 

​									Document Footer Section xx 

​									… 

​						UNT (Message Trailer XX) 

​	Interchange control trailer : 

​						UNZ+XX+ interchange number’ with XX = number of messages in the interchange
  1. 交换层（Interchange）

  • Interchange control Header

    • UNA（可选）：定义分隔符（如数据元素分隔符+、子元素分隔符:、段终止符'、转义字符?）。
    • UNB（交换头）：包含语法版本、发送方、接收方、日期/时间、控制编号等。

  • Interchange control trailer

    • UNZ（交换尾）：记录交换内的报文数量及控制参考号。
  1. 报文层（Message）
  • UNH（消息头）：包含消息类型（如INVOIC）、版本号（如D.96A）和唯一标识。
  • 数据段（Segment）：按固定顺序排列的逻辑单元，如：
    • BGM（报文开始）：包含文档类型和编号。
    • DTM（日期/时间）：记录业务相关时间（如订单日期）。
    • NAD（名称与地址）：标识交易方（如买方、卖方）。
  • UNT（消息尾）：记录报文内的段总数和控制参考号。
  1. 数据段与元素的层级
  • 段（Segment）
    • 由段标记（3位代码，如BGM）和数据元组成，通过分隔符（如+或:）分隔
    • 分为服务段（如UNB、UNH）和通用段（如BGM、NAD）
  • 数据元（Data Element）
    • 简单数据元：单一值（如订单号）
    • 复合数据元：多个成分数据元组合（如日期+时间格式），需通过限定符明确含义（如DTM+137:20250428:102表示“订单日期”）
  • 限定符（Qualifier）
    • 定义数据元的业务含义（如NAD+BY表示“买方地址”）

  1. 示例

    注： 如果要使用示例EDI，请务必删除 # xxxx 注释内容！

# Interchange control Header
UNA:+.?*'
UNB+UNOC:3+87830609100017:14+38012986600014:14+250423:1705+17++INVOIC'
# Messages
# UNH Message Header 1
UNH+1+INVOIC:D:96A:UN:FTW200'
# 数据段（Segment）
BGM+380+FR20250402001+9'
DTM+3:20250405:102'
PAI+::30'
FTX+AAI+++878 306 091 RCS PARIS:87830609100017?:4669A:YOFC International (France) SAS:SAS'
FTX+ABY+++300000:EUR'
FTX+PMT+++INDEMNITE FORFAITAIRE DE 40 EUROS POUR FRAIS DE RECOUVREMENT'
FTX+PMD+++EN CAS DE PAIEMENT ANTICIPE PARVENANT AU VENDEUR AU MOINS 20 JOURS:AVANT LA DATE D ECHEANCE UN ESCOMPTE EGAL A L EURIBOR EN VIGUEUR A 3:MOIS PLUS UN POINT PEUT ETRE ACCORDE SUIVANT LE PRORATA DU NOMBRE DE:JOURS RESTANT A COURIR JUSQU A L ECHEANCE PREVUE'
FTX+AAB+++LE TAUX D INTERET DES PENALITES DE RETARD EST EGAL AU TAUX D INTERET:DE LA BANQUE CENTRALE EUROPEENNE EN VIGUEUR AU JOUR DU REGLEMENT:MAJORE DE SEPT POINTS. LES PENALITES DE RETARD DE PAIEMENT SONT:EXIGIBLES SANS QU UN APPEL SOIT NECESSAIRE.'
RFF+CT:IC091009'
RFF+ON:72424947'
NAD+BY+38012986600014:100++100+111 quai du President Roosevelt+lssy-les-Moulineaux++92130+FR'
RFF+VA:FR89380129866'
CTA+PD+:ZZ'
NAD+SE+87830609100017:100++YOFC INTERNATIONAL (FRANCE) SAS+37,rue des Mathurins+Paris++75008+FR'
FII+BF+FR7630056005120512009258476+:::30056:::HSBC OF FRANCE'
RFF+VA:FR03878306091'
CTA+AP+0102030405'
TAX+VAT+VAT+ENC'
CUX+2:EUR'
LIN+1++L1092-13_36G.657A2:SA'
PIA+1+03561296608426:BP'
IMD+++:::CABLE L1092 36FO MODULO 6 FTTH'
QTY+47:2400:MTR'
MOA+125:1447.2'
PRI+CAL:0.603::NTP'
PRI+AAB:0.603::NTP'
RFF+LI:1'
RFF+DQ:FH20250405001'
DTM+171:20250425:102'
TAX+7+VAT+ENC++:::20'
UNS+S'
MOA+125:1447.2'
MOA+124:289.44'
MOA+128:1737'
MOA+9:1736.64'
MOA+ZZZ:289.44'
TAX+7+VAT++1447.2+:::20'
MOA+150:289.44'
# UNT (Message Trailer 1) 
UNT+1+13514'
# Interchange control trailer
UNZ+1+17'

二、关于 AS2​

​ AS2（Applicability Statement 2）是一种基于 HTTP 和 S/MIME（Secure/Multipurpose Internet Mail Extensions） 协议的安全数据传输协议，旨在通过互联网实现点对点的可靠通信，尤其适用于 EDI（电子数据交换）场景。其核心功能包括数据加密、数字签名及传输回执（MDN），确保商业文档在公网传输中的完整性与不可抵赖性。

​ 示意图如下：

image-20250429170439825

2.1 核心原理​

  1. 点对点连接架构 AS2通信仅涉及发送方（客户端）与接收方（服务器），双方通过固定IP建立连接。传输前需交换数字证书，定义“贸易伙伴”（Trading Partner）关系以验证身份。
  2. 信封机制 数据封装采用 **S/MIME（Secure/Multipurpose Internet Mail Extensions）**协议，将 EDI文件 作为 附件 嵌入 HTTP消息体，并附加加密层（如AES）和签名层（如SHA-256）。
  3. 回执确认（MDN） 接收方成功解析消息后，返回 MDN（Message Disposition Notification）回执，包含 状态码 与 消息哈希值。发送方需验证 MDN签名 以确认交付成功。

2.2 技术特点​

  1. 安全性
    • 加密传输：支持 SSL/TLS加密 整个 HTTP连接，或通过 S/MIME加密消息体。
    • 数字签名：对原始数据和 MDN 进行 签名，防止篡改并确保身份真实性。
  2. 可靠性
    • 压缩传输：可对数据 **压缩（如ZIP）**以减少带宽消耗。
    • 断点续传：支持文件传输中断后恢复，避免重复发送。
  3. 协议与传输方式
    • 采用 HTTP/HTTPS协议，默认使用 POST方法 提交数据，兼容防火墙策略。
    • 支持 异步通信，发送与回执处理可分离，提升系统灵活性。

三、EDI 与 AS2 的关系​

  • EDI：是数据交换的方法论（“做什么”）。
  • EDIFACT：是EDI的数据格式标准（“如何组织数据”）。
  • AS2：是EDI文档的安全传输协议（“如何安全传输”）。

​ 电子数据交换（EDI）作为企业间标准化业务文档（如采购订单、发票）的传输机制，其核心在于统一数据格式（如EDIFACT、ANSI X12）和业务流程自动化。然而EDI本身不规定传输安全机制。AS2协议通过数字证书（X.509标准）实现端到端加密（AES-256/Triple DES）、数字签名（SHA-256/SHA-512）和消息完整性校验（MIC哈希算法），弥补了EDI在传输安全层面的短板。

四、服务端集成​

服务端集成可能会用到的证书、私钥、测试EDI及测试工具如下：

服务端集成步骤如下：

1. 新建客户端流程​

登录管理端，点击 "流程管理"-"创建流程"。

image-20250430104719114

2. 配置流程信息​

image-20250430105007352

3. 选择 "触发器"-"AS2"​

image-20250430105104277

image-20250430105154438

注： 选择 AS2 触发器后，需手动选择默认连接，该连接为内置连接，不需要额外添加！

image-20250430105317975

注： 选择 AS2 触发器后，需手动选择动作，AS2 组件的动作分为 client、server；其中 client 为客户端集成中 AS2 连接 默认操作，即发送AS2请求；这里由于选择的是** AS2 触发器，所以动作默认为 server，即接收AS2请求！

4. 配置 AS2 触发器​

image-20250430111247424

​ 通常 AS2 触发器 需要配置 端口号、请求URI、协议版本号、消息结构，其中端口号与请求URI，可以类比理解为restful接口用于指定请求端口及路径用于接收特定请求。配置号端口及URI后，再根据消息结构决定是否上传证书及密钥文件，用于消息签名、加密等操作。

​ 具体参数说明如下：

  • AS2 Server 端口号（必填）

    指定 AS2 服务端将在哪个端口号上启动、绑定并接收请求。

  • AS2 Server 请求URI（必填）

    指定 AS2 服务端将在目标 URI 接收请求。

  • AS2 协议版本（必填）

    AS2协议可选版本号，默认 V1.1，可选值有 V1.0、V1.0。

  • AS2 消息结构（必填）

    AS2 消息结构通常指的是消息的 MIME 类型和内容是如何封装的，AS2 消息可以包含一个或多个 MIME 部分，每个部分可以是不同的内容类型，例如文本、二进制数据或 EDI 文档。

    可选值如下：

    消息结构结构解析安全等级适用场景
    PLAINHTTP头 + AS2头 + 明文EDI负载无内部测试环境、可信内网传输
    SIGNEDHTTP头 + MIME签名层（PKCS8）包裹明文负载★★★需验证来源但无需加密的场景
    ENCRYPTEDHTTP头 + 加密层（接收方公钥加密）包裹明文负载★★★☆敏感数据内部传输
    SIGNED_ENCRYPTEDHTTP头 → 加密层 → 签名层 → 明文负载
    （先签名后加密）    		★★★★★金融交易、医疗记录传输
    PLAIN_COMPRESSEDHTTP头 + PKCS8-MIME压缩层包裹明文负载★☆跨境低带宽环境的大文件传输
    SIGNED_COMPRESSEDHTTP头 → 压缩层 → 签名层 → 压缩后负载
    （先压缩后签名）    		★★★☆零售业每日销售数据汇总
    ENCRYPTED_COMPRESSEDHTTP头 → 加密层 → 压缩层 → 压缩后负载
    （先压缩后加密）    		★★★★制造业设计图纸传输
    ENCRYPTED_COMPRESSED_SIGNEDHTTP头 → 加密层 → 压缩层 → 签名层 →
    压缩加密负载（顺序：压缩→签名→加密）    		★★★★★★军工/政府涉密文件交换

  • MDN 消息格式化模板

    用于指定 AS2 消息处理通知 (MDN) 消息的模板。MDN 消息是一个可选的回执，用于告知发送方消息已被接收和处理。

    **注：**可不填，AS2 服务端会根据用户请求配置选择是否返回 MDN 回执。

  • EDI消息签名收据算法列表

    用于指定用于生成和验证 AS2 消息的数字签名消息摘要（MIC）的算法。AS2 协议要求对 AS2 消息进行数字签名，以确保消息的完整性和真实性。常见的默认算法包括 MD5、SHA-1 等。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名算法

    用于指定在发送 AS2 消息时使用的数字签名算法。AS2 协议要求对 AS2 消息进行数字签名，以确保消息的完整性和真实性。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名证书

    指定用于生成 AS2 消息数字签名的证书链。证书链是一个包含多个证书的列表，每个证书都验证了前一个证书的有效性，直到最顶层的根证书。当前仅支持X.509标准的证书文件。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名密钥

    指定用于生成 AS2 消息数字签名的私钥。私钥是用于加密数字签名（私钥加密，公钥解密）的密钥，它是与证书关联的。当仅支持RSA算法、PKCS8格式。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息解密密钥

    指定用于解密接收到的 AS2 消息的私钥。AS2 消息可以使用 MIME 加密来保护消息内容的安全性，该参数提供解密过程中所需的私钥。当仅支持RSA算法、PKCS8格式。

    注：消息结构为ENCRYPTED、SIGNED_ENCRYPTED、ENCRYPTED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息压缩算法

    用于指定 AS2 消息压缩所使用的算法。该参数在发送 AS2消息时非常有用，允许指定一个压缩算法，该算法将应用于消息的内容，以便在传输过程中减小文件大小。

    注：消息结构为PLAIN_COMPRESSED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

    可选值为 ZIP。

以 SIGNED_ENCRYPTED 签名加密为例，配置如下：

image-20250430134933863

5. 配置 EDI 后置处理​

AS2 触发器收到请求，并解密出 EDI 报文后，将内容通过 SFTP 写入本地文件系统。配置如下：

步骤1：添加 SFTP 连接

image-20250430135407993

步骤2：配置 SFTP 操作

image-20250430135451157

image-20250430144609709

6. 调试​

流程编辑完成后，点击"保存"，再点击"开始调试"。

注： 测试工具使用附件中的 "install_mendelson_opensource_as2_1.1b65.exe"，需自行安装！安装后在安装目录下双击"AS2.exe"！

image-20250430140049032

image-20250430140101322

​ 步骤1：测试工具中上传附件中crt证书

image-20250430141855114

image-20250430141953866

image-20250430142026056

image-20250430142050633

​ 步骤2：测试工具中添加partner image-20250430141359802

​ image-20250430142559543

image-20250430143053543

​ 步骤3：测试连通性

​ image-20250430143228760

​ 步骤4：保存partner，开始发送测试请求

​ 将附件EDI ORDER通过测试工具发送。

​ image-20250430143824808

image-20250430143910142

image-20250430143959506

​ 选择附件后，点击"ok"即可。在运行时所在服务器的root目录下查看相关文件已接收成功。

image-20250430151440285

image-20250430144950384

7. 修改流程，将EDI转为XML​

将SFTP组件删除，选择并发组件，在AS2触发器接收到请求后，将EDI原始文档写入本地，同时将EDI文档转换为XML文档并写入本地。

注： SFTP 配置略过，详情参考前文配置说明！

步骤1：配置逻辑分支，选择EDI逻辑组件

并发组件中选中分支"XML_ORDER"，右键"逻辑"-"EDI"。

image-20250430150713577

步骤2：取出body，供后续EDI逻辑组件使用

注：为支持多种数据类型，AS2默认将请求体转为byte数组，方便后续流程使用。

image-20250430152122701

步骤3：配置EDI逻辑组件

这里请求报文为EDIFACT，故配置项如下：

image-20250430152317281

AS2触发器在收到订单信息后，由于数据为EDIFACT格式，业务系统无法解析使用，因此添加EDI组件将EDIFACT转换为XML格式。

具体参数说明如下：

  • EDI 格式

    数据格式。

    可选值如下：

    ​ (1) EDI

    ​ 非联合国制定的国际 EDI 标准。

    ​ (2) EDIFACT

    ​ 由联合国制定的国际 EDI 标准。

  • 操作类型

    转换操作类型。

    可选值如下：

    ​ (1) EDI TO XML

    ​ (2) XML TO EDI

  • EDI Schema

    格式为 EDIFACT 时，需要选定版本号。

  • EDI 消息类型

    格式为 EDIFACT 时，需选定消息类型，如订单(ORDERS)、发票(INVOIC)等。

步骤4：配置SFTP

类比之前的EDI文档写入本地，这里配置将XML写入本地。

image-20250430151302297

步骤4：保存调试，检查文件系统

**注：**首次调用EDI组件，加载资源文件较慢。

image-20250430151916522

image-20250430152005039

​ 如上图，通过AS2测试工具，将测试EDI发送到配置好的流程后，流程中AS2触发器对请求进行签名验证、请求解密后，将请求内容通过SFTP写入本地文件目录，同时将请求内容通过EDI逻辑组件转换为XML，并将XML写入本地文件目录。EDI逻辑组件支持EDIFACT与XML的互转，在客户端集成中将介绍另一种方式使用EDI。

五、客户端集成​

客户端集成可能会用到的证书、私钥、测试EDI及测试工具如下：

**注：**AS2 客户端很少连接运行时上的 AS2 服务端，通常是连接合作伙伴的AS2 服务端！

1. 修改服务端流程​

**注：**为演示客户端集成，将服务端集成原订单类型改为发票类型，相关操作未做大的改动。

修改如下图：

image-20250430154134305

image-20250430154258978

image-20250430154331378

2. 部署服务端流程​

将服务端流程部署到指定集群，供客户端流程使用。

3. 添加 AS2 连接器​

image-20250430170211379

image-20250430170313654

  • AS2 Server 端口号（必填）

    AS2 服务端监听的端口号，具体配置查看服务端配置，必须与服务端保持一致。

  • AS2 Server 请求URI（必填）

    AS2 服务端监听的 URI，具体配置查看服务端配置，必须与服务端保持一致。

  • AS2 协议版本（必填）

    AS2协议可选版本号，默认 V1.1，可选值有 V1.0、V1.0，必须与服务端保持一致。

4. 新建客户端流程​

步骤1：编辑流程基本信息

image-20250430155329013

步骤2：选择REST API触发器

image-20250430164446272

image-20250430164524984

步骤3：配置转换脚本

注： 由于脚本篇幅过大，仅介绍重要部分，完整脚本请查看 JSON 转 EDI 脚本 附件!

注： JSON 转 EDI 脚本 中展示了将 JSON 转为 EDI 的完整流程，通常需要用户先确定入参类型，再根据合作方的 EDIFACT 字段要求进行编写转换逻辑，示例脚本并不通用；该部分需要操作人员一定编程能力，同时了解 EDIFACT 规范！

注： JSON 转 EDI 脚本 中依赖类运行时已全部导入，如果要在编辑器中调试，需手动添加相关依赖jar包到classpath中。

// 依赖部分省略

public static boolean isEmpty(String val) {
    return val == null || val.equals("");
}

// 程序步骤1：从 exchange 中获取 json 格式的发票请求并转为 JSONObject
String invoicJsonStr = exchange.getMessage().getBody(String.class);
JSONObject invoicJson = JSON.parseObject(invoicJsonStr);

// 程序步骤2：定义 EDI Java 实体，获取 json 中字段并配置
Interchange interchange = new Interchange();

// UNA
interchange.withUNA(
        new UNA()
                .withCompositeSeparator(":")
                .withFieldSeparator("+")
                .withDecimalSeparator(".")
                .withEscapeCharacter("?")
                .withRepeatSeparator("*")
                .withSegmentTerminator("'")
);

// UNB ... 省略

Message message = new Message();

// ... message配置部分省略

interchange.withMessage(message);

interchange.withUNZ(
        new UNZInterchangeTrailer()
                .withE0036(new BigDecimal(1))
                .withE0020("17")
);

// 程序步骤3：定义输出流，用于存放由 Java EDI 转为 XML 的流数据 
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();

// 程序步骤4：将 interchange 转为 XML 并写入 byteArrayOutputStream
// 注：SmooksCaches 会缓存 XML 相关转换上下文，为后续转换操作提速
SmooksCaches.marshal(
                interchange,
                byteArrayOutputStream,
                Interchange.class,
                org.smooks.edifact.binding.service.ObjectFactory.class,
                org.smooks.edifact.binding.d96a.ObjectFactory.class
        );
       
// 程序步骤4：将 byteArrayOutputStream 中的 XML 转换为 EDI，并设置到 exchange 中 
${request.body} = SmooksCaches.translate("d96a", "INVOIC", byteArrayOutputStream, SmooksCaches.class.getClassLoader());

image-20250430170026964

步骤4：配置 AS2 客户端

"连接"-"AS2"，选择上文添加的AS2连接。

image-20250430170635534

image-20250430170742425

注： 选择 AS2 连接后，需手动选择动作，AS2 组件的动作分为 client、server；其中 client 为客户端集成中 AS2 连接 默认操作，即发送AS2请求。

image-20250430170904175

image-20250430170938705

  • AS2 消息结构（必填）

    AS2 消息结构通常指的是消息的 MIME 类型和内容是如何封装的，AS2 消息可以包含一个或多个 MIME 部分，每个部分可以是不同的内容类型，例如文本、二进制数据或 EDI 文档。

    可选值：PLAIN、SIGNED、ENCRYPTED、SIGNED_ENCRYPTED、PLAIN_COMPRESSED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED

  • AS2 发件人

    指定发送方的 AS2 ID，AS2 ID 是一个唯一标识符，用于在AS2 消息交换中识别发送方。这个标识符通常是由参与 AS2 通信的各方事先商定的。

  • AS2 收件人

    指定接收方的 AS2 ID。AS2 ID 是一个唯一标识符，用于在AS2 消息交换中识别接收方。这个标识符通常是由参与 AS2 通信的各方事先商定的。

  • AS2 消息发件人标识

    同 AS2 发件人。

  • AS2 消息主题

    用于设置 AS2 消息的主题。

  • AS2 消息传输编码

    配置请求传输编码，默认 UTF-8。

  • EDI 消息内容类型

    即 “content-type”，可选值如下：

    (1) application/edifact

    (2) application/edi-x12

    (3) application/edi-consent

    (4) application/xml

  • EDI消息压缩算法

    用于指定 AS2 消息压缩所使用的算法。该参数在发送 AS2消息时非常有用，允许指定一个压缩算法，该算法将应用于消息的内容，以便在传输过程中减小文件大小。

    注：消息结构为PLAIN_COMPRESSED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

    可选值为 ZIP。

  • AS2 消息处置通知(MDN)

    接收方成功解析消息后，返回 MDN（Message Disposition Notification）回执，包含 状态码 与 消息哈希值。发送方需验证 MDN签名 以确认交付成功。默认同步返回。

  • EDI 消息加密算法

    参数用于指定在发送 AS2 消息时使用的加密算法。AS2 消息可以使用 MIME 加密来保护消息内容的安全性，该参数就是用来指定加密过程中所使用的算法。

    注：消息结构为ENCRYPTED、ENCRYPTED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息加密证书(X.509)

    参数用于指定用于加密 AS2 消息的证书链。证书链是一个包含多个证书的列表，每个证书都验证了前一个证书的有效性，直到最顶层的根证书。当前仅支持单个X.509标准的证书文件。

    注：消息结构为ENCRYPTED、ENCRYPTED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名收据算法列表

    用于指定用于生成和验证 AS2 消息的数字签名消息摘要（MIC）的算法。AS2 协议要求对 AS2 消息进行数字签名，以确保消息的完整性和真实性。常见的默认算法包括 MD5、SHA-1 等。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名算法

    用于指定在发送 AS2 消息时使用的数字签名算法。AS2 协议要求对 AS2 消息进行数字签名，以确保消息的完整性和真实性。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名证书

    指定用于生成 AS2 消息数字签名的证书链。证书链是一个包含多个证书的列表，每个证书都验证了前一个证书的有效性，直到最顶层的根证书。当前仅支持X.509标准的证书文件。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

  • EDI消息签名密钥

    指定用于生成 AS2 消息数字签名的私钥。私钥是用于加密数字签名（私钥加密，公钥解密）的密钥，它是与证书关联的。当仅支持RSA算法、PKCS8格式。

    注：消息结构为SIGNED、SIGNED_ENCRYPTED、SIGNED_COMPRESSED、ENCRYPTED_COMPRESSED_SIGNED必填。

配置如下：

image-20250430173313165

其中 AS2消息结构 与服务端配置一致选择 SIGNED_ENCRYPTED 指定为签名加密；AS2 发件人、AS2 收件人、AS2 消息发件人标识 通常由贸易双方协商约定，这里任意填写；AS2 消息主题任意，这里定为 "INVOIC TEST"；EDI 消息内容类型 指定为 "application/edifact"，即仅发送 EDI 文档；

image-20250430173643629

由于消息结构为 SIGNED_ENCRYPTED，故不需要配置压缩算法，配置加密算法为 "DES_EDE3_CBC"，服务端会根据配置的证书及密钥进行解密。

5. 调试​

步骤1： 开启调试

image-20250430174245711

步骤2： postman 调用，请求示例查看 INVOIC TEST JSON 附件

image-20250430174737837

步骤3： 运行时所在服务器查看 invoic.edi 及 invoic.xml 文件已写入本地目录。

image-20250430174837155