钉钉生产审批结果回写小满OKKICRM生产订单状态:单一策略实战

这个策略解决什么问题

某制造业客户在钉钉里跑生产审批流,审批通过后,业务希望小满OKKICRM里的生产订单状态自动从「待生产」变成「已完成」。看似只是改一个状态字段,但审批实例的回调往往落后、审批字段命名混乱,人工同步经常漏。这一条策略专门做这件事:钉钉生产审批结果 → 小满生产订单状态。

数据流向与字段映射

整体流向是「钉钉 → 轻易云 → 小满OKKICRM」。源端用 topapi/processinstance/get 拉审批实例,目标端调 /v1/invoices/order/push 推送状态。中间层负责两件事:把钉钉侧晦涩的 TextNote_XXX 控件字段归一化,以及按订单编号在小满侧反查 order_id。

注意:order_id 不是从源端直接拿到的,而是通过 _findCollection 按订单编号反查出来的,这是这条策略里最容易踩坑的一环。

在轻易云上如何配置

我们在客户现场用轻易云数据集成平台搭这条策略,核心配置分三块:

1. 源端采集器:类型选 WebAPI,接口 topapi/processinstance/get,方法 POST,effect=QUERY。响应字段采用 _autoFillResponse 自动展开,把所有 TextNote_*、发起部门、下单品牌所属部门都铺出来,后面映射才不会缺字段。
2. 目标端执行器:类型 EXECUTE,接口 /v1/invoices/order/push。order_id 用 _findCollection 关联一张订单映射集合,入参 where order_no={{订单编号}};status 直接写常量——已完成对应的状态码。这是轻易云客户很常见的应对模式:编码映射集中管理,状态值这类「魔法数字」不散落在脚本里。
3. 调度:源端每 10 分钟一轮(0-59/10 7-22 * * *),目标端错开一分钟(1-59/10 7-22 * * *),避免两端同时抢同一行记录。

实施步骤

1. 增量起点:第一次上线不直接扫历史审批实例。先在轻易云里把增量游标配置好,只拉「当前时间之后新产生的、状态为已完成的」审批实例。历史数据用单独的全量任务补,避免一开始就把数据库打满。
2. 全量触发:在策略上线稳定跑两到三个调度周期后,人工触发一次全量回扫,把存量漏掉的「已完成」审批补回写到小满。一次性跑完即停,不要放进常规调度。
3. 调度频率:白天业务时段每 10 分钟一轮,夜间降到 30 分钟或停掉。审批回调本身就有分钟级延迟,过于频繁的轮询只会浪费配额。
4. 上线后:连续一周每天抽 10 条比对钉钉侧审批状态和小满侧订单状态,确认两边一致;同时监控目标接口的失败率,失败大多是 order_id 反查不到——见踩坑复盘。

踩坑复盘

• 典型错误:直接把审批表单里的 TextNote_XXX 当成订单编号推给小满。控件字段名随时可能被管理员重命名,业务字段必须先在中间层做一次归一化,稳的做法是引用一张「审批字段→业务字段」的映射表。
• order_id 反查为空:审批里的订单编号和小满里的 order_no 格式不统一(大小写、前后空格、有无前缀),导致 _findCollection 查不到。稳妥的做法是在中间层加一步 trim + 大小写归一化,必要的话再用模糊匹配兜底。
• 重复回写:同一个审批实例被多轮调度重复拉到,目标接口又没有幂等校验,小满侧会被反复打。这里的应对是增量与全量双轨:增量靠调度周期内的去重主键(流水号 + 已完成状态),全量靠目标接口的幂等字段。
• 状态值写死:「已完成」对应的状态码在不同租户、不同业务线下可能不同,千万别散落在多条策略里。集中放在编码映射表里,后续切换业务线只改一处。
• 审批回调延迟:钉钉侧审批完成事件回调常常落后 5–10 分钟,如果策略只盯实时回调会漏数据。这里源端走轮询而非回调兜底,正是为了让延迟数据也能被追平。

适用场景与不适用场景

适用:单一业务线、审批表单字段相对稳定、状态字段只有少量枚举值的回写场景,比如生产审批完成、合同审批完成等。不适用:审批表单字段频繁改动、跨多业务线共用同一审批模板、或者目标侧状态机比单纯「已完成」更复杂(比如「部分完成」「已驳回」也要分别回写)的场景——后者需要拆成多条策略,而不是塞进一条里。