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

1. 方案概述本方案面向企业与外部客户、供应商及物流伙伴之间的电子数据交换场景建设以EDI平台为统一集成枢纽、以EDI传输协议和EDI为主要外部交换标准、以OA与ERP为内部业务承载系统的双向集成体系。方案参考现有项目中已落地的多单据处理模式将通信、协议解析、业务分流、数据映射、接口调用、状态通知和运行审计分层解耦形成可扩展、可追踪、可验证的标准化链路。减少订单、交货、库存和回执数据的人工录入及重复传递。统一外部EDI报文与内部OA、ERP数据模型之间的转换规则。建立端到端状态追踪、异常通知、重试补偿和审计机制。将实施经验沉淀为可复制的接口模板、Mapping规范和验证资产。2. 项目背景外部交易伙伴通常采用标准EDI报文交换业务数据而内部审批、订单执行、库存和交付业务分别由OA、ERP等不同的系统承载。两侧在通信协议、数据结构、认证方式、业务语义和错误处理机制上存在明显差异直接点对点对接会产生接口数量多、维护边界不清、异常难追踪等问题。入向统一进行单据类型分流。根据业务状态调用接口查询、下推、保存和作废接口。状态转换为企业微信、邮件等可读通知。3. 建设目标与范围3.1 建设目标建立统一、安全、可靠的外部EDI接入通道。建立标准报文到企业内部业务对象的映射与路由能力。完成EDI与OA审批流程、ERP业务单据的自动化接口集成。支持出向业务数据生成标准EDI报文并可靠发送。实现业务单号、EDI控制号、接口请求号和内部单据号的全链路关联。形成可监控、可告警、可补偿、可审计的生产运行机制。3.2 业务范围业务含义内部处理目标采购订单 / 订单变更调用OA创建审批或评审流程仓库发货指令调用ERP查询、下推、保存、作废应用回执 / 业务反馈解析状态与错误并通知发票 / 库存通知从内部数据生成EDI并发送订单确认 / 变更确认从审批或订单结果生成EDIASN / 出库回执从ERP交付结果生成EDI3.3 系统边界外部交易伙伴发送或接收标准EDI报文。EDI平台负责通信、协议转换、路由、Mapping、编排、通知和审计。OA系统承载采购订单及变更的审批、评审和流程状态。ERP系统承载销售订单、交货通知、库存、发票、出库等核心业务单据。数据库/主数据系统承载多变、高频定时数据的分类落库。通知平台企业微信、邮件或统一告警平台。3.4 各系统职责边界在 EDI 与内部系统集成项目中应避免把所有业务逻辑都堆在某一个系统中。比较合理的做法是EDI 平台负责外部标准报文与内部接口之间的连接、转换和编排OA、ERP 等业务系统继续承担各自的业务审批和单据处理职责。系统适合承载的内容不建议承载的内容EDI平台外部通信、协议解析、报文校验、单据识别、Mapping转换、接口编排、状态追踪、异常通知、重试补偿、审计归档复杂业务审批规则、ERP库存核算逻辑、财务结算规则、人工业务决策OA系统采购订单评审、订单变更审批、内部流程流转、审批意见、流程状态EDI报文解析、外部通信、复杂Mapping转换、ERP单据核算ERP系统销售订单、采购订单、库存、交货、发票、出库、作废等核心业务单据及账务相关规则EDI协议处理、外部伙伴路由、报文控制号管理、通信重试数据库/主数据系统物料、客户、供应商、组织、地址、代码转换表、高频查询数据及历史对照关系替代ERP进行业务单据处理或绕过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 分层架构通信接入层AS2、SFTP或API通道负责身份校验、加密传输和收发确认。协议处理层EDI语法校验、EDI转XML、XML转EDI和控制号处理。路由编排层按交易伙伴、业务类型、消息子类型及业务状态分流。数据转换层将EDI结构映射为统一中间模型再转换为OA/ERP接口结构。系统集成层封装OA和ERP认证、请求提交、响应解析及公共参数。运行保障层日志、监控、通知、重试、补偿、归档和审计。5.2 入向与出向主链路入向交易伙伴 → EDI传输协议接收 → EDI语法解析 → 标准XML → 类型判断一级分流 → 业务字段二级分流 → Mapping/JSON序列化 → OA、ERP或数据库 → 状态记录与通知。出向OA/ERP业务事件 → 标准业务JSON/XML → 单据类型分支 → Mapping到EDI结构 → EDI校验 → EDI传输协议发送 → 回执 → 状态闭环。5.3 统一中间模型messageId平台全局消息标识。partnerId交易伙伴标识。documentType订单、变更、发货等单据类型。businessKey与documentVersion业务主键和修订版本。sourceControlNumberISA/GS/ST控制号。payload标准化头、行、层级及扩展字段。traceContextOA请求号、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认证准备获取应用注册信息和spk、secret。使用OA公钥加密secret按接口要求放入请求头或认证参数。获取访问token并按有效期缓存。获取加密后的userid。建单时注入appid、token、userid等参数。 认证组件应独立封装。Token在有效期内复用失效或收到明确认证错误时刷新一次连续失败不得无限重试应进入告警和人工处理队列。6.2.2 OA建单请求与响应字段含义来源/规则requestName流程标题伙伴、单号和单据类型组合workflowIdOA流程定义ID不同类型业务数据分别配置mainData主表字段单头、币别、日期、供应商detailData明细字段物料、数量、价格、交期messageIdEDI消息标识用于幂等和全链路追踪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接口编排场景接口动作输入重点成功输出销售订单查询OrderQuery客户、单号、物料、组织单号及明细发货通知创建DeliveryNoteCreate发货数据发货数据编排必须校验前一步业务结果查询无唯一结果时不得下推保存失败时不得作废。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 验证层次连接验证EDI传输协议连通、证书、签名加密、MDNOA/ERP网络、TLS及白名单。认证验证OA注册、密钥加密、Token和UserIDERP签名登录及Cookie刷新。报文验证EDI语法、必选段、控制号、字符集、代码值和Mapping字段。接口验证请求结构、响应码、超时、重复提交、异常返回和数据落库。业务验证OA建单、ERP查询/下推/保存/作废、出向回执闭环。非功能验证性能、并发、稳定性、安全、备份恢复和可追踪性。9.2 重点测试场景测试场景预期结果合法订单含多行明细OA流程创建成功头行字段一致同一伙伴、PO、版本重复发送不重复建单返回已有结果数量、交期或行项目变更进入变更流程并保留修订号Token失效刷新一次后成功或明确告警唯一可下推订单创建交货通知并回写单号查询为零或多条阻断下推并进入业务异常队列已有交货通知可作废按保存、作废顺序完成下推响应超时先查询确认不产生重复单据含TED错误信息关联原消息并发送可读通知MDN失败或证书错误状态可见、重试或及时告警9.3 数据核对与验收逐字段核对原始EDI、标准XML、中间模型、OA/ERP请求和目标单据。专项校验金额、数量、日期、时区、精度、代码转换和层级汇总。正向关键场景全部通过关键字段准确率达到100%。重复消息不产生重复OA流程或ERP单据。认证失效、接口超时和临时故障具备可验证的恢复机制。所有失败均能定位到交易伙伴、报文、业务单号和处理阶段。业务、接口、Mapping、运维和测试文档完整并完成确认。10. 实施计划阶段主要工作主要输出需求与调研确认伙伴、单据、字段、接口、规则和SLA需求清单、接口清单、范围基线方案设计架构、流程、状态、异常、安全和部署设计总体方案、详细设计、字段映射开发配置通道、路由、Mapping、接口组件、通知可部署流程、配置清单、单元测试联调测试伙伴连通、OA/ERP接口、全链路场景联调记录、问题清单、测试报告UAT与上线业务验收、初始化、切换和回退演练UAT报告、上线及回退方案运行移交监控、告警、手册、培训和质保运维手册、培训材料、交付清单建议按单据分批上线优先选择业务边界清晰、价值高且依赖较少的链路每批设置观察期并保留人工处理或原流程作为短期回退方案。11. 运维与治理建立按日监控看板接收量、成功率、失败量、平均耗时、重试量和积压量。按严重程度定义通信中断、证书到期、认证失败、接口持续失败和消息积压告警。建立失败消息处理SOP明确技术异常与业务异常责任人及响应时限。Mapping和接口配置纳入版本控制变更前完成评审、测试和回退准备。定期执行证书与凭证轮换、归档清理、恢复演练和容量评估。12. 交付物与风险前提12.1 交付物总体集成方案与详细设计说明。业务流程图、系统架构图和接口时序说明。EDI字段文档、OA/ERP字段映射表和代码转换表。EDI传输协议伙伴配置、证书和网络白名单清单。接口定义、请求响应示例及错误码说明。测试案例、联调记录、验收报告及运维手册。12.2 风险与前提OA流程ID、字段ID和表单版本由OA团队最终确认并受控变更。ERP查询和单据操作接口的业务规则、权限及状态限制由ERP团队确认。交易伙伴提供正式EDI规范、样例、EDI传输协议参数、证书及测试窗口。伙伴差异通过配置和伙伴级Mapping扩展不破坏公共标准模型。内部系统不支持幂等查询时需增加EDI侧业务索引和人工确认机制。13. 结论本方案通过统一接入、分层解析、两级分流、标准中间模型和可复用接口组件将外部EDI标准报文与内部OA、ERP业务流程连接起来。最终系统不仅应实现“报文能够传输、接口能够调用”还应实现业务状态一致、异常可恢复、过程可审计、能力可复制从而形成稳定的企业级EDI集成平台。阅读原文基于多单据EDI项目实施经验形成的总体集成方案