企业应用之间的数据交换，常见问题往往不在接口能否连通，而在字段含义、触发时机和失败处理各说各话。制定数据交换规则，就是把“谁在什么条件下、把哪些字段、以什么格式和频率、交给哪个系统、失败怎么办”写成可执行的约定。本文按范围、字段、触发、校验、职责、示例和上线检查的顺序展开，覆盖规则文档的主要构成；目录认证与账号集成、日常沟通规范属于相邻主题，这里只在边界处注明引用关系。
要点总览（TL;DR）
- 先按业务链路盘点参与系统、数据对象与交换方向，形成范围清单，明确本期纳入与暂不纳入的边界。
- 为每个交换对象建立字段字典，写明类型、必填性、取值范围、示例与主数据归属方，唯一标识和枚举值集中维护并记录版本。
- 按时效与数据量选择批量同步、事件推送或按需查询，把触发条件、频率、时间窗口、幂等键和重试上限写到可开发的程度。
- 校验项与失败动作一一对应，监控覆盖成功率、延迟、积压量和失败分布，异常处置写清告警对象、补数方式与责任人。
- 上线前用范围、字段、触发、校验、责任五类清单核对，并选一条真实链路试点跑通正常交换、校验失败、重试与补数后再推广。
先定范围：哪些应用与数据需要纳入交换规则
规则建设的第一步是盘点，先把交换场景列清楚，再动笔写条款。范围不清时，规则容易写成“各系统应保证数据一致”这类无法执行的通用表述，既不能指导开发，也无法验收。
盘点建议按业务链路组织，而不是按系统逐个罗列。一条链路从业务发起开始，经过哪些系统、在哪个环节产生或消费数据、最终落到哪里，按顺序写下来。每条链路标注参与系统、数据对象、交换方向和优先级，形成范围清单。按链路组织的好处是能直接看出上下游依赖，排期和责任分配也有依据。
交换内容可以粗分为三类，规则写法各有侧重：
| 交换内容类型 | 典型对象 | 规则侧重点 |
|---|---|---|
| 主数据 | 客户、物料、组织、供应商 | 唯一来源、同步方向、变更后多久生效 |
| 业务单据 | 订单、合同、发票、工单 | 字段完整性、关联关系、状态流转一致性 |
| 状态事件 | 订单状态变更、审批结果、库存变动 | 时效、顺序、重复投递的处理 |
范围清单还要明确本期纳入与暂不纳入的边界。暂不纳入的链路写明原因和计划时间，避免后续讨论中反复拉扯。完成标志是：每条纳入的链路都有明确的参与系统、数据对象、方向和责任人，评审时无人对“这条链路归谁管”提出异议。
统一字段口径：数据对象、主数据归属与编码约定
字段口径不一致是数据交换中最常见的返工来源。同一个“客户状态”，销售系统用五个枚举值，财务系统用三个，接口上线后必然出现映射争议。解决办法是为每个交换对象建立字段字典，并明确主数据归属方。
字段字典应逐字段列出以下要素：
- 字段名称与业务含义说明，避免仅凭英文名猜测用途；
- 数据类型、长度与精度，金额类字段注明币种和单位；
- 是否必填，以及为空时的业务解释；
- 取值范围或枚举值清单；
- 一个符合规则的示例值；
- 主数据归属方与维护系统。
唯一标识的确定要先于字段清单定稿。每个交换对象需要一个跨系统稳定的业务主键，例如订单号由订单系统生成并作为全局标识，其他系统只引用不重编。若某系统内部另有编码，应在字典中登记映射关系，而不是让两套编码并行流转。
主数据归属遵循“一处维护、多处引用”的原则：每个主数据对象指定唯一权威系统，其他系统通过交换获取，不在本地随意修改。归属表应写明对象、权威系统、同步方向、同步频率和冲突时的裁决方。当两个系统对同一字段都有写入能力时，必须约定以哪一方为准，冲突数据如何回退。
编码与枚举值集中维护，并记录版本。新增枚举值要走变更流程，注明生效时间和影响系统，避免一方扩展、另一方解析失败。字段字典与归属表定稿后作为规则文档的附件，后续修改同步更新版本号。
交换方式与触发规则：批量、事件与频率如何约定
交换方式的选择依据主要是时效要求和数据量。批量同步适合对账类数据、全量初始化和日终汇总，实现简单、便于核对；事件推送适合状态变化类数据，时效高，但需要处理重复和乱序；按需查询适合低频核对场景，由使用方主动发起，减少无效传输。同一条链路可以组合使用，例如主数据每日批量同步、状态变更实时推送。
触发规则要写到可开发的程度，至少包含四项：
- 触发条件：什么业务动作或时间点发起交换，例如“订单状态变为已发货时推送”；
- 频率与时间窗口：批量任务的具体时点、允许的运行窗口，以及窗口内未完成时的处理；
- 幂等键：用哪个字段组合判断重复，例如订单号加状态版本号；
- 重试约定：重试次数上限、重试间隔，以及超过上限后的处置方式。
重复数据处理需要在规则中正面约定。事件推送可能因网络重发导致同一消息到达多次，接收方应基于幂等键做去重，重复消息返回成功而不重复执行业务。批量同步则要约定全量覆盖还是增量合并，增量合并时以哪方数据为准。重试次数不宜无限，建议设定上限并转入异常队列，由责任人判断是补数还是人工修正。
时间窗口的写法要具体，例如“每日02:00至04:00执行，04:00未完成则记录断点，次日续跑并告警”。这类约定让运维在出现延迟时有明确动作，而不是临时商量。
校验、监控与异常处置：让规则可被验证
规则是否有效，取决于交换结果能否被核对、失败能否被定位。校验和监控条款应与字段、触发规则同步设计，而不是上线后再补。
校验项通常包括以下几类，规则中逐项写明校验位置（发送前、接收后或双方）和失败动作：
| 校验类型 | 检查内容 | 失败动作示例 |
|---|---|---|
| 必填校验 | 关键字段是否为空 | 拒收并返回错误码，记录原始报文 |
| 格式校验 | 日期、金额、编码格式是否符合约定 | 拒收，提示具体字段 |
| 范围校验 | 枚举值、数值区间是否在字典范围内 | 拒收或标记待确认 |
| 关联完整性 | 引用的主数据、上游单据是否存在 | 暂存待补，超时转异常 |
| 业务规则校验 | 状态流转是否合法、金额是否匹配 | 拦截并通知业务负责人 |
监控指标建议至少覆盖成功率、端到端延迟、积压量和失败分布。成功率按链路统计而非全局平均，避免一条问题链路被整体数据掩盖；延迟从发送时间算到接收确认，明确统计口径；积压量用于发现消费能力不足；失败分布按错误类型归类，便于判断是字段问题还是系统问题。指标基线在试点阶段实测确定，不同重要性的链路可以设不同阈值。
异常处置路径要写清四件事：告警发给谁、补数怎么做、什么条件下转人工、最终由谁负责闭环。例如连续失败达到重试上限后，系统告警至集成运维，运维在约定时限内判断原因，属于数据问题的转数据负责人修正后补数，属于系统故障的按故障流程处理。失败数据应有存放位置和保留期限，避免长期滞留无人认领。
角色分工与交付物：谁维护规则、谁审批变更
规则无人维护就会逐渐失效。角色划分不必复杂，但要覆盖口径、接口、传输和运行四个层面，并与交付物一一对应。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 数据负责人 | 确定字段口径、主数据归属与冲突裁决 | 字段字典、主数据归属表 |
| 应用负责人 | 确认本系统字段、接口与业务规则 | 本系统字段映射说明 |
| 集成开发 | 实现映射、传输、校验与重试逻辑 | 接口说明、映射配置 |
| 运维监控 | 监控运行状态、处理告警与补数 | 监控看板、异常处置记录 |
规则文档、字段字典和变更记录各设一名维护人，通常由数据负责人牵头、集成开发协助更新。新增或修改交换规则应走评审：提出方说明变更原因、影响系统和字段范围，数据负责人确认口径，相关应用负责人确认本系统改造量，评审通过后更新文档版本并通知下游。变更记录保留时间、提出人、审批人和生效日期，便于回溯。
规则文档、字段字典与变更评审记录需要有承载位置，形成可追溯的版本与工作项流转。ONES 可用于承载规则文档、字段字典和变更评审工作项，把评审意见、审批结论与文档版本关联在同一处；具体使用方式按团队现有工具与流程确定。
示例：一条订单状态回传链路的交换规则
以下示例演示规则如何写成可执行条目。场景为订单系统向仓储系统回传订单状态，属于状态事件类交换。
参与系统与方向：订单系统为发送方，仓储系统为接收方，方向为单向推送。订单号由订单系统生成，作为全局唯一标识。
字段与触发条件示例写法：
- 交换字段：订单号（必填，字符串，示例 SO20240612001）、状态编码（必填，枚举：待发货、已发货、已签收、已取消）、变更时间（必填，时间戳）、版本号（必填，整数，每次状态变更递增）。
- 触发条件：订单状态发生变更并保存成功后推送，同一订单的多次变更按版本号顺序处理。
- 幂等键：订单号加版本号，接收方已处理过的版本直接返回成功。
- 重试约定：失败后间隔1分钟重试，最多3次，超过后进入异常队列并告警。
校验与异常处置示例：接收方校验订单号非空、状态编码在枚举范围内、版本号大于已记录版本。校验失败返回错误码并记录原始报文；版本号小于等于已记录版本的视为重复消息，返回成功不重复处理；连续3次重试失败后，告警发送至集成运维，运维核对订单系统日志，确认是网络问题则补推，确认是数据问题则转订单系统负责人修正后重新推送。补数完成后在异常记录中登记处理结果。
完成检查：规则上线前的核对项
规则文档定稿后，用一份检查清单判断是否具备上线条件。以下五类核对项逐条确认，全部通过再进入试点。
| 核对类别 | 核对内容 |
|---|---|
| 范围 | 纳入链路均有参与系统、数据对象、方向和责任人；暂不纳入项已注明原因 |
| 字段 | 字段字典覆盖全部交换字段；唯一标识与主数据归属已确认；枚举值有版本记录 |
| 触发 | 触发条件、频率、时间窗口、幂等键与重试上限均已写明 |
| 校验 | 校验项与失败动作对应；监控指标与告警对象明确；异常处置路径可执行 |
| 责任 | 文档维护人、变更审批流程已确定；变更记录格式已约定 |
试点验证建议选一条真实链路跑通全流程，通过标准包括：正常交换成功且数据核对一致；人为构造校验失败时能正确拒收并告警；重试与补数流程实际走通一次；异常记录完整可查。试点中发现的问题回写到规则文档，修订后再推广到其他链路。
规则版本与文档归档同样纳入检查：每次变更生成新版本号，旧版本保留备查，字段字典与规则文档版本对应。完成以上核对，规则才具备可执行、可校验、可维护的基础。
常见问题
规则文档写好后，如何判断它真的可执行？
判断标准是规则能否被开发和运维直接使用，而不是文档是否完整。可以选一条真实链路做试点，按规则实现映射、触发、校验和重试，实际跑一遍正常交换、构造一次校验失败、触发一次重试与补数。如果开发不需要再追问字段含义，运维看到告警知道该找谁、怎么补数，异常记录完整可查，说明规则具备可执行基础。试点中发现的问题回写到文档，修订后再推广到其他链路。
两个系统对同一字段都有写入权限，冲突时以哪一方为准？
这属于主数据归属问题，应在字段字典和归属表中提前约定，而不是等冲突出现再协商。通常为每个主数据对象指定唯一权威系统，其他系统只引用不本地修改；确实需要多方写入的字段，明确以哪一方为准、冲突数据如何回退，并指定裁决方。约定写入规则文档后，接口实现按此执行，冲突数据进入异常记录由裁决方处理。
交换频率和监控阈值应该设成多少？
频率取决于业务时效要求和数据量：对账类数据可以日终批量，状态变化类适合事件推送，低频核对可用按需查询。监控阈值没有统一数值，建议在试点阶段实测正常链路的成功率、端到端延迟和积压量，以此为基线设定告警线，不同重要性的链路可以设不同阈值。阈值确定后写入规则文档，后续按运行情况调整并记录变更。
规则上线后由谁负责日常维护和变更？
规则文档、字段字典和变更记录各设一名维护人，通常由数据负责人牵头、集成开发协助更新。新增或修改交换规则走评审：提出方说明变更原因、影响系统和字段范围，数据负责人确认口径，相关应用负责人确认本系统改造量，评审通过后更新文档版本并通知下游。变更记录保留时间、提出人、审批人和生效日期，便于回溯。规则文档与评审记录需要有承载位置，ONES 可用于承载规则文档、字段字典和变更评审工作项，具体使用方式按团队现有工具与流程确定。
目录认证和账号同步要不要写进数据交换规则？
目录认证与账号集成属于相邻主题，本文不展开。制定数据交换规则时，只需在边界处注明与身份账号体系的引用关系，例如哪些字段来自账号系统、由谁维护，避免两套规则互相覆盖。日常沟通规范与消息通知策略同样属于相邻主题，不在数据交换规则中展开。
