基于多单据EDI项目实施经验形成的总体集成方案

1. 方案概述

本方案面向企业与外部客户、供应商及物流伙伴之间的电子数据交换场景，建设以EDI平台为统一集成枢纽、以EDI传输协议和EDI为主要外部交换标准、以OA与ERP为内部业务承载系统的双向集成体系。

方案参考现有项目中已落地的多单据处理模式，将通信、协议解析、业务分流、数据映射、接口调用、状态通知和运行审计分层解耦，形成可扩展、可追踪、可验证的标准化链路。

• 减少订单、交货、库存和回执数据的人工录入及重复传递。
• 统一外部EDI报文与内部OA、ERP数据模型之间的转换规则。
• 建立端到端状态追踪、异常通知、重试补偿和审计机制。
• 将实施经验沉淀为可复制的接口模板、Mapping规范和验证资产。

2. 项目背景

外部交易伙伴通常采用标准EDI报文交换业务数据，而内部审批、订单执行、库存和交付业务分别由OA、ERP等不同的系统承载。两侧在通信协议、数据结构、认证方式、业务语义和错误处理机制上存在明显差异，直接点对点对接会产生接口数量多、维护边界不清、异常难追踪等问题。

• 入向统一进行单据类型分流。
• 根据业务状态调用接口查询、下推、保存和作废接口。
• 状态转换为企业微信、邮件等可读通知。

3. 建设目标与范围

3.1 建设目标

1. 建立统一、安全、可靠的外部EDI接入通道。
2. 建立标准报文到企业内部业务对象的映射与路由能力。
3. 完成EDI与OA审批流程、ERP业务单据的自动化接口集成。
4. 支持出向业务数据生成标准EDI报文并可靠发送。
5. 实现业务单号、EDI控制号、接口请求号和内部单据号的全链路关联。
6. 形成可监控、可告警、可补偿、可审计的生产运行机制。

3.2 业务范围

3.3 系统边界

• 外部交易伙伴：发送或接收标准EDI报文。
• EDI平台：负责通信、协议转换、路由、Mapping、编排、通知和审计。
• OA系统：承载采购订单及变更的审批、评审和流程状态。
• ERP系统：承载销售订单、交货通知、库存、发票、出库等核心业务单据。
• 数据库/主数据系统：承载多变、高频定时数据的分类落库。
• 通知平台：企业微信、邮件或统一告警平台。

3.4 各系统职责边界

在 EDI 与内部系统集成项目中，应避免把所有业务逻辑都堆在某一个系统中。比较合理的做法是：EDI 平台负责外部标准报文与内部接口之间的连接、转换和编排；OA、ERP 等业务系统继续承担各自的业务审批和单据处理职责。

整体原则是：EDI 平台负责“连接和转换”，业务系统负责“业务事实和业务决策”。例如，EDI 平台可以判断一笔外部订单应该调用哪个 OA 流程或 ERP 接口，但不应替代 OA 决定审批是否通过，也不应绕过 ERP 直接修改库存或财务结果。

4. 需求分析

4.1 业务需求

• 自动识别交易伙伴、单据类型和业务场景。
• 数据映射到不同OA流程，并保留订单版本、变更类型等信息。
• 根据关键字段选择创建或作废链路。
• ERP处理满足查询前置、下推、保存、作废等业务顺序约束。
• 出向报文基于内部标准业务结构生成，业务系统不直接拼装EDI。
• 错误数据及接口失败信息转换为业务人员可理解的通知内容。

4.2 技术与非功能需求

• 支持EDI传输协议签名、加密、MDN及证书管理。
• 支持EDI与XML/JSON双向转换及两级业务路由。
• 支持REST接口、Cookie/Token认证、加密参数及签名机制。
• 支持幂等、防重、超时、重试、补偿和人工重放。
• 接收成功的消息不得无记录丢失，失败消息必须可恢复。
• 凭证、证书、Cookie和Token不得明文写入业务日志。
• 可按伙伴、单据、业务单号、时间和状态查询处理记录。

5. 总体架构设计

5.1 分层架构

1. 通信接入层：AS2、SFTP或API通道，负责身份校验、加密传输和收发确认。
2. 协议处理层：EDI语法校验、EDI转XML、XML转EDI和控制号处理。
3. 路由编排层：按交易伙伴、业务类型、消息子类型及业务状态分流。
4. 数据转换层：将EDI结构映射为统一中间模型，再转换为OA/ERP接口结构。
5. 系统集成层：封装OA和ERP认证、请求提交、响应解析及公共参数。
6. 运行保障层：日志、监控、通知、重试、补偿、归档和审计。

5.2 入向与出向主链路

入向：交易伙伴 → EDI传输协议接收 → EDI语法解析 → 标准XML → 类型判断一级分流 → 业务字段二级分流 → Mapping/JSON序列化 → OA、ERP或数据库 → 状态记录与通知。

出向：OA/ERP业务事件 → 标准业务JSON/XML → 单据类型分支 → Mapping到EDI结构 → EDI校验 → EDI传输协议发送 → 回执 → 状态闭环。

5.3 统一中间模型

• messageId：平台全局消息标识。
• partnerId：交易伙伴标识。
• documentType：订单、变更、发货等单据类型。
• businessKey与documentVersion：业务主键和修订版本。
• sourceControlNumber：ISA/GS/ST控制号。
• payload：标准化头、行、层级及扩展字段。
• traceContext：OA请求号、ERP请求号和内部单据号。

6. 接口对接实现

6.1 统一入口与路由

入向报文统一经过EDI传输协议和EDIToXML组件处理。平台完成基础语法校验后，首先读取ST01确定单据类型；对于同一单据中的不同业务场景，再读取BCT03、W0501或消息类型等字段进行二次分流。推荐顺序为：接收落盘、生成消息ID、校验解析、一级分流、二级分流、Mapping、接口调用、响应归档、状态更新。

6.2对接OA

不同类型报文可根据业务类型，选择是否共用接收、解析和序列化主链路，但映射到不同的OA流程ID。

处理链路：EDI传输协议 → EDIToXML → 类型判断→ XML_MAP_消息→ 统一OA请求结构 → JSON序列化 → OA认证准备 → CreateRequest → 返回流程请求ID → 状态记录与通知。

6.2.1 OA认证准备

1. 获取应用注册信息和spk、secret。
2. 使用OA公钥加密secret，按接口要求放入请求头或认证参数。
3. 获取访问token并按有效期缓存。
4. 获取加密后的userid。
5. 建单时注入appid、token、userid等参数。 认证组件应独立封装。Token在有效期内复用，失效或收到明确认证错误时刷新一次；连续失败不得无限重试，应进入告警和人工处理队列。

6.2.2 OA建单请求与响应

• HTTP成功不等于业务成功，必须同时判断业务返回码和流程请求ID。
• 成功后记录OA请求ID、EDI消息ID、PO号及流程状态。
• 超时且结果未知时，先按messageId或业务键查询OA，确认未创建后再重试。
• 重复数据执行幂等拦截。

6.3 数据对接ERP

识别数据类型后，根据状态字段进入不同路径：比如【确认】场景查询可下推并创建单据；【拒绝】场景查询已有单据，保存必要信息后执行作废。

6.3.1 ERP认证与会话

参考项目采用签名登录方式：组织账套、组织、语言、时间戳和签名参数，调用认证接口获取Cookie；后续接口统一复用该Cookie。

• 登录签名参数由安全配置中心维护，运行时生成。
• Cookie仅保存在受控缓存或密钥存储中，并设置有效期。
• 收到未登录或Cookie失效响应时，允许刷新会话并重放一次。
• 查询、下推、保存、作废接口共用beforeSend处理器，统一补齐认证头、超时和追踪标识。

6.3.2 ERP接口编排

编排必须校验前一步业务结果：

• 查询无唯一结果时不得下推；
• 保存失败时不得作废。

6.4 信息通知

提取回执编号、日期、原单据类型、状态码、业务单号及错误描述。成功时更新原出向消息；失败时将TED等错误转换为可读内容并通过企业微信、邮件或告警平台通知。

7. 接口通用设计

7.1 接口契约与版本

所有内部接口应明确API 接口规范、业务返回码和示例。

7.2 幂等、防重与补偿

• 使用partnerId + documentType + businessKey + documentVersion作为业务幂等键，并以EDI控制号辅助校验。
• 网络失败、HTTP 5xx和临时限流可按退避策略重试；字段校验、权限不足等确定性错误不自动重试。
• 请求超时且结果未知时先查询目标系统状态，再决定是否补发。
• 超过自动重试阈值后进入人工队列，支持从失败节点重放。

7.3 状态与链路追踪

建议统一状态为RECEIVED、VALIDATED、MAPPED、SUBMITTED、BUSINESS_SUCCESS、BUSINESS_FAILED、RETRYING、MANUAL_PENDING和CLOSED。每条消息生成唯一messageId，并关联Message-ID、ISA/GS/ST控制号、PO/DN/Invoice、OA请求ID、ERP单据内码及通知记录。

8. 安全设计

• EDI传输协议启用TLS，并根据伙伴约定配置消息签名、加密和同步/异步MDN。
• 建立证书台账和到期预警，换证期间支持新旧证书平滑切换。
• OA公钥、应用密钥、ERP签名密钥、Token和Cookie存入密钥库或受控配置。
• 接口采用最小权限账号，并限制来源IP、访问路径和调用频率。
• 日志对Token、Cookie、个人信息、价格等敏感字段按策略脱敏。
• 关键配置变更、人工重放、消息删除和凭证更新纳入审计。

9. 验证与测试方案

9.1 验证层次

1. 连接验证：EDI传输协议连通、证书、签名加密、MDN；OA/ERP网络、TLS及白名单。
2. 认证验证：OA注册、密钥加密、Token和UserID；ERP签名登录及Cookie刷新。
3. 报文验证：EDI语法、必选段、控制号、字符集、代码值和Mapping字段。
4. 接口验证：请求结构、响应码、超时、重复提交、异常返回和数据落库。
5. 业务验证：OA建单、ERP查询/下推/保存/作废、出向回执闭环。
6. 非功能验证：性能、并发、稳定性、安全、备份恢复和可追踪性。

9.2 重点测试场景

9.3 数据核对与验收

• 逐字段核对原始EDI、标准XML、中间模型、OA/ERP请求和目标单据。
• 专项校验金额、数量、日期、时区、精度、代码转换和层级汇总。
• 正向关键场景全部通过，关键字段准确率达到100%。
• 重复消息不产生重复OA流程或ERP单据。
• 认证失效、接口超时和临时故障具备可验证的恢复机制。
• 所有失败均能定位到交易伙伴、报文、业务单号和处理阶段。
• 业务、接口、Mapping、运维和测试文档完整并完成确认。

10. 实施计划

建议按单据分批上线，优先选择业务边界清晰、价值高且依赖较少的链路；每批设置观察期，并保留人工处理或原流程作为短期回退方案。

11. 运维与治理

• 建立按日监控看板：接收量、成功率、失败量、平均耗时、重试量和积压量。
• 按严重程度定义通信中断、证书到期、认证失败、接口持续失败和消息积压告警。
• 建立失败消息处理SOP，明确技术异常与业务异常责任人及响应时限。
• Mapping和接口配置纳入版本控制，变更前完成评审、测试和回退准备。
• 定期执行证书与凭证轮换、归档清理、恢复演练和容量评估。

12. 交付物与风险前提

12.1 交付物

1. 总体集成方案与详细设计说明。
2. 业务流程图、系统架构图和接口时序说明。
3. EDI字段文档、OA/ERP字段映射表和代码转换表。
4. EDI传输协议伙伴配置、证书和网络白名单清单。
5. 接口定义、请求响应示例及错误码说明。
6. 测试案例、联调记录、验收报告及运维手册。

12.2 风险与前提

• OA流程ID、字段ID和表单版本由OA团队最终确认并受控变更。
• ERP查询和单据操作接口的业务规则、权限及状态限制由ERP团队确认。
• 交易伙伴提供正式EDI规范、样例、EDI传输协议参数、证书及测试窗口。
• 伙伴差异通过配置和伙伴级Mapping扩展，不破坏公共标准模型。
• 内部系统不支持幂等查询时，需增加EDI侧业务索引和人工确认机制。

13. 结论

本方案通过统一接入、分层解析、两级分流、标准中间模型和可复用接口组件，将外部EDI标准报文与内部OA、ERP业务流程连接起来。

最终系统不仅应实现“报文能够传输、接口能够调用”，还应实现业务状态一致、异常可恢复、过程可审计、能力可复制，从而形成稳定的企业级EDI集成平台。