采购申请单审批事件回写:钉钉→金蝶云星空的实战集成方案
这个策略解决什么问题(场景与价值)
在一次实际项目里,某零售企业的采购申请流程是"业务在钉钉发起 → 钉钉审批流走完 → 金蝶云星空生成采购申请单"。问题是:审批一旦通过,金蝶侧的单据状态、审批编号、办理人等关键信息是空的,业务方常常要回到金蝶里手工补一遍。
这条策略要解决的,就是把钉钉侧"审批已结束"的事件,以及审批编号、办理人等信息,稳定回写到金蝶云星空对应的采购申请单上,让审批轨迹和业务单据一致。它本身不负责单据的首次创建,只负责"审批回写"这一段,典型的轻量、定向、低频同步。
数据流向与字段映射(源 → 中间层 → 目标)
数据流是单向的:钉钉(源) → 轻易云(Qeasy)中间层 → 金蝶云星空(目标)。调度频次 */3 * * * *,每 3 分钟一轮,以"轮询拉取 + 增量过滤"的方式执行。
源端从钉钉的审批实例接口(topapi/processinstance/get,POST)读取本次审批的关键字段,包括单据编号、办理人、申请事由、申请日期、采购组织等,作为回写的业务上下文。
目标端调用金蝶云星空的 batchSave 接口(POST,Operation=Save),业务对象表单 Id 固定为 PUR_Requisition。关键字段对照如下:
| 业务含义 | 钉钉侧字段 | 轻易云中间变量 | 金蝶侧字段 | 备注 |
|---|---|---|---|---|
| 单据 id | 单据编号 | {{单据编号}} | FID | 通过 _findCollection 按 FBillNo 反查得到 |
| 钉钉审批编号 | business_id | {{extend.business_id}} | F_ora_PSWZ_Text | 唯一标识,用于幂等防重 |
| 审批完成标记 | – | – | F_ora_CheckBox | 固定值 "0",用于业务方筛选 |
| FormId | – | – | PUR_Requisition | 必填,标识业务对象 |
这里有一个工程上很关键的点:FID 不是从钉钉传过来的,而是在轻易云里通过 _findCollection 按单据编号反查金蝶的 FID。这是轻易云客户常见的"编码映射集中管理"模式之一——把跨系统的业务编号↔系统主键映射统一收敛到集成平台,不在两个业务系统里各存一份,后期对账方便。
在轻易云上如何配置
在轻易云数据集成平台里,这条策略属于"源映射 + 目标映射 + 调度"三段式。
源端配置要点:接口选 topapi/processinstance/get,效果(Effect)设为 QUERY,autoFillResponse 开起来,响应字段映射只需要保留单据编号、办理人、申请事由、申请日期、采购组织这些后续要用到的字段,不必全量拉。idCheck 打开,以钉钉侧的实例 id 做去重,避免重复回写。
目标端配置要点:接口选 batchSave,Effect 设为 EXECUTE,业务对象表单 Id 写 PUR_Requisition,Operation 写 Save。FID 字段的值表达式用 _findCollection 在金蝶的采购申请单集合里按 FBillNo = {{单据编号}} 查 FID,这样就把"钉钉单据编号 → 金蝶内部主键"的映射收敛到轻易云这一层。F_ora_PSWZ_Text 写 {{extend.business_id}},作为幂等键;F_ora_CheckBox 写固定 "0"。
调度上,crontab 写 */3 * * * *,idCheck 打开,确保同一审批事件不会被多次落库。
实施步骤(分阶段调度)
第一阶段,确定"增量起点":先把策略依赖的"采购申请单金蝶=>钉钉"那条策略跑稳,确保金蝶里有相应的单据、钉钉里有相应的审批实例,两端能通过 FBillNo ↔ business_id 对得上。这是回写策略的前置条件,depends_on 不能空。
第二阶段,触发全量验证:不上线正式调度,先用历史 1-2 天的审批事件做一次性回填,观察 _findCollection 是否每次都能反查到 FID,审批编号是否都能正确落到 F_ora_PSWZ_Text。这里如果反查命中率低,说明两端编号映射规则不一致,要回头修上游策略,而不是在回写里硬补。
第三阶段,接入正式调度:把 crontab 设成 */3 * * * *,先开观察模式,核对 1-2 个工作日的回写条数和钉钉审批结束条数是否大致吻合,再切到生产。增量与全量双轨是轻易云客户常见的稳妥做法——日常增量靠定时调度,数据异常时再用一次性全量补。
踩坑复盘
- 反查命中率低,直接报错。这里容易翻车的典型错误是"金蝶侧 FBillNo 拼了前缀,钉钉侧没拼",导致 _findCollection 查不到 FID。稳妥的做法是把 FBillNo 的生成规则在轻易云里集中维护,两套策略共用一份。
- 重复回写,金蝶侧出现多条审批记录。原因是 idCheck 没开,或者开在了错误字段上。审批事件一定要用钉钉侧的审批实例 id 做幂等键,而不是单据编号。
- 回写成功但业务方看不到审批编号。多半是自定义字段 F_ora_PSWZ_Text 没有挂到 PUR_Requisition 的单据头,或者字段没发布。要先在金蝶侧把自定义字段建好并发布,再在轻易云里映射,顺序不能反。
- */3 的频率在审批高峰时段出现堆积。这种短间隔轮询适合轻量回写,如果一次拉回的批量变大,需要加分页或限流,不要盲目把 crontab 调得更密。
- 私有化环境下钉钉回调不通,反复走轮询。这里要确认是钉钉侧应用配置问题还是网络问题,不要在轻易云策略层反复改 api,先排障源端。
适用场景与不适用场景
适用:钉钉做审批、金蝶做业务底座、单据由金蝶创建、审批事件需要回写做轨迹对齐的场景;典型是采购申请单、费用报销单等需要审批与业务单据一一对应的流程。
不适用:需要在金蝶侧首次创建单据的场景(应该走"采购申请单金蝶=>钉钉"那条策略);也不适用于大批量、跨多组织的复杂审批编排——那种场景需要专门的审批中台,而不是一个 3 分钟一轮的回写策略。