风险供应商转正：金蝶云星空与钉钉两阶段审核流同步实战
这个策略解决什么问题
某零售企业在风控管理中,把风险供应商的「转正」动作放在钉钉审批流里完成,审批通过后需要回到金蝶云星空把供应商主数据从「禁用」改回「正常」并做业务解禁。表面看只是一次状态切换,但实际跑起来会发现:审批表单里只有供应商编码(FNumber),金蝶 batchSave 必须传内码 FSupplierId;审批流明细需要按实例 ID 逐条拉取,简单列表接口拿不到完整表单值;转正和后续解禁又是两个独立的写操作,顺序错了就会出现「先解禁再转正」的脏状态。这个策略就是用轻易云数据集成平台(Qeasy)把这一连串跨系统动作串成一个可调度、可观测的两阶段流程。
数据流向与字段映射
数据流向是 钉钉(审批实例详情) → 轻易云中间层 → 金蝶云星空(BD_Supplier)。上游策略先调用 topapi/processinstance/listids 按模板与起始时间拉取 processInstanceId 列表,本策略作为第二阶段,通过 process_instance_id_strategy 引用上游输出,平台按每个 process_instance_id 循环调用 topapi/processinstance/get 拉详情。
关键字段对照:
| 目标字段(金蝶) | 源字段/规则 | 映射类型 | 说明 |
|---|---|---|---|
| FSupplierId | _findCollection find FSupplierId from 供应商集线器 where FNumber={{value}} | COLLECTION | 由钉钉表单供应商编码联查金蝶内码 |
| FBaseInfo | (空对象) | CONSTANT | 转正字段后续在平台映射补齐 |
| FormId | "BD_Supplier" | CONSTANT | 金蝶供应商业务对象 |
| Operation | "batchSave" | CONSTANT | 执行批量保存(转正) |
| IsVerifyBaseDataField | true | CONSTANT | 开启基础资料校验 |
| IsAutoSubmitAndAudit | false | CONSTANT | 不自动提交审核,留给下游解禁 |
源端响应里 value 是表单值的字符串(包含 FNumber),title 形如「XXX提交的风险供应商转正」,可在 AfterTargetInvoke 脚本里用 mb_substr 截取出供应商名称。
在轻易云上如何配置
源端(Source)选 WebAPI 适配器,API 填 topapi/processinstance/get,method=POST,effect=QUERY,主键取 process_instance_id,开启 idCheck 与 autoFillResponse。请求参数里 process_instance_id_strategy 固定填上游 ID 拉取策略的方案标识,last_sync_time 用 {{DAYS_AGO_s30|datetime}} 控制 30 天增量窗口。
目标端(Target)选金蝶云星空适配器,API 填 batchSave,type=EXECUTE。FormId 写死 BD_Supplier,Operation 写死 batchSave,IsAutoSubmitAndAudit 保持 false。FSupplierId 这一行不能写常量,要走 _findCollection 表达式,从供应商主数据查询集线器按 FNumber={{value}} 反查,这一招正是轻易云客户最常用的「编码映射集中管理」套路。
两个调度都设在 7–22 点工作时段:源端 12 7-22 * * *,目标端 22 7-22 * * *,比源端晚 10 分钟,保证上游 ID 拉取已落库。
实施步骤
- 增量起点:上游 ID 拉取策略先上线,用
start_time配合last_sync_time拿到历史 30 天内的 processInstanceId,确认集线器有数据后再启用本策略。 - 编码集线器准备:在轻易云里把金蝶供应商主数据查询策略跑一遍,把 FNumber 与 FSupplierId 的对应关系写入集线器,
_findCollection才能联查到结果。 - 全量触发:首次上线对近 30 天积压单据跑一次全量,观察金蝶返回的 SuccessEntitys 是否都拿到 Id。
- 调度频率:工作时段每小时一轮,非工作时段停掉,审批流在夜间几乎不产生新单。
- 下游衔接:在 AfterTargetInvoke 脚本里把 SuccessEntitys、value、title 写入解禁策略的输入队列,实现「先转正、后解禁」的有序链路。
踩坑复盘
- 联查写成了字面量:典型错误是把
FSupplierId直接写{{value}},结果金蝶报「主键不存在」。稳妥的做法是所有跨系统编码映射都走_findCollection,并在轻易云里把映射集线器独立维护。 - IsAutoSubmitAndAudit 误开 true:一旦自动提交并审核,后续解禁策略就拿不到「待解禁」状态,业务会出现供应商已生效但仍被禁用的诡异组合。这里要保持 false,把解禁交给独立的 ExcuteOperation Enable 策略。
- 两阶段调度间隔太近:源端 12 分跑、目标端 13 分跑,会出现上游还没写完 ID 就被本策略读空集。稳妥的做法是源端与目标端错开 10 分钟以上,并给本策略加「上游未产出则跳过」的容错。
- value 字段是 JSON 字符串:有些钉钉表单的 value 是嵌套结构,直接联查会查不到。需要先用
_function或_mongoQuery解析出 FNumber 再联查。 - Name 截取依赖标题前缀:用
mb_substr(title, 0, pos)提取「提交的风险供应商转正」之前的内容,前提是审批标题格式稳定。一旦业务方改了模板,截取就会错位,建议把名称字段直接做成审批表单独立项。
适用场景与不适用场景
适用:审批流驱动的主数据状态切换(转正、解禁、停用),且跨系统只能靠业务编码对齐。不适用:需要事务强一致的双写场景(本策略是最终一致),以及审批流表单里完全没有供应商编码、只能靠标题模糊匹配的场景。