聚水潭与金蝶云星空集成:「删除60天前数据」策略实战教程

这个策略解决什么问题(场景与价值)

在某零售企业的聚水潭与金蝶云星空供应链集成方案里,主链路把销售出库单、调拨单、退货单持续推到下游 ERP。随着运行时间拉长,中间层与目标系统会堆积大量已完成、已归档的历史单据——既影响查询性能,也让运维同学在排查问题时被旧数据淹没。

「删除60天前数据」策略正是为这条主链路做的历史数据回收机制:以销售出库单同步产生的中间记录为目标,按时间窗自动清理过期数据。看似只是一个清理动作,实际上承担了三件事——一是控制中间层膨胀,二是降低目标系统的历史负担,三是让异常排查回归到「近期数据」这个可控范围。我们在客户现场交付时,通常把它作为整个供应链同步方案的收尾策略,与主链路并行运行。

数据流向与字段映射

这条策略的数据流向比较特殊:源端是轻易云平台自身产出的同步结果(以「销售出库单同步」为目标对象),目标端则是平台内部的一个无副作用写入动作(「写入空操作」),最终效果是按 60 天时间窗过滤后删除。

关键字段对照:

这里有一个值得强调的细节:target_1 是对象类型,且支持多对象扩展。换句话说,如果客户现场还有调拨单、退货单等需要一并清理,只要再加一个 target_2 对象,就能在同一次 API 调用里完成多业务对象的回收,不用为每个业务单据单独搭一条策略。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)上,这条策略的配置分三块。

第一块:源接口定义。选择轻易云平台自带的 DeleteStrategyData WebAPI,请求方式为 POST。它是一个 QUERY 类型的接口,作用是按传入的 target 对象和时间阈值返回待删除的记录集。需要注意 autoFillResponse 与 buildModel 这两个开关:开启自动回填后,响应里的 datetime 与 params 会自动生成,无需人工构造,这对清理类策略非常友好——你不需要为「这次清理是哪天跑的」单独维护字段。

第二块:目标接口定义。选用 写入空操作,同样为 POST,但 effect 是 EXECUTE。这是一个「占位型」目标,真实业务里它的意义在于让整条策略在调度层面闭环:源端按阈值筛出待删除记录,目标端用空写入把链路走完,平台据此统计策略执行结果。

第三块:对象与时间阈值。在请求体里配置 target_1 = 销售出库单同步,并明确比较字段(同步时间或单据日期)与阈值(60 天)。如果业务方提出「调拨单也要清」,直接在同请求里追加 target_2 = 调拨单同步 即可,轻易云会按对象分别筛选、分别清理。

实施步骤

我们在客户现场交付时,通常把这条策略按四个阶段推进。

阶段一:增量起点确认。先确认主链路的同步时间字段叫什么、在哪个对象下、格式是不是 ISO。清理策略的起点必须严格对齐主链路的写入时间,否则会出现「明明清理了,目标系统里还能查到」的尴尬。

阶段二:全量触发试跑。上线当晚手动触发一次全量清理,观察平台返回的 datetime 与 params,确认删除条数与预期量级匹配。稳妥的做法是先用一个保守阈值(比如 90 天)跑一次,确认链路通顺后再调回 60 天。

阶段三:调度频率设定。源端 DeleteStrategyData 配 20 8 * * *(每天早上 8:20),目标端「写入空操作」配 23 2 * * *(凌晨 2:23)。两个时间刻意错开,既保证清理动作在业务低峰期执行,也避免和主链路的同步窗口重叠造成资源争抢。

阶段四:观察与回收。上线一周内每天检查一次清理条数,确认没有出现「某一天突然清掉几万条」的异常放量;之后改为每周抽检,把异常告警阈值定在「单日清理量超过近 7 天均值 3 倍」。

踩坑复盘

坑一:阈值用错字段。典型错误是用业务单据日期做比较——但历史单据的业务日期可能很旧,新单据也可能因为补录导致业务日期早于同步日期。稳妥的做法是用同步时间(sync_time / datetime),它真实反映记录进入中间层的时间,清理语义最准确。

坑二:多对象合并到一个 target 里。有些工程师会把销售出库单、调拨单塞进同一个对象表达式,导致删除条件过宽,把不该清的也清了。应该每个业务对象独立一个 target 槽位(target_1、target_2……),让轻易云按对象分别处理。

坑三:清理策略和主链路同窗口。把清理和同步排在同一时刻,会出现「同步写一半、清理删一半」的竞态。错峰调度是基本功,源端 8:20、目标端 2:23 这种「两端错开」的安排,是我们给客户做运维规范时的默认推荐。

坑四:删除后没有审计痕迹。清理类策略最怕「删了就找不回来」。哪怕目标端是空操作,也建议在轻易云的执行日志里保留 datetime 与 params 两个回填字段,出问题时有据可查。

坑五:阈值一刀切。有些客户上来就要 30 天、有些要 180 天,但没考虑下游审计要求。稳妥做法是先和财务、审计对齐「数据至少保留多少天」,再定清理阈值,而不是由 IT 单方面决定。

适用场景与不适用场景

适用:中间层数据持续增长、目标 ERP 历史负担重、运维需要「近期数据」视图进行排查的场景;以及任何按时间窗做生命周期管理的同步链路。不适用:法规或审计要求长期保留的数据(如某些行业的财务凭证)、主链路尚未稳定运行的早期阶段,以及单据状态需要严格状态机管控而不能物理删除的业务对象。