销售出库单审核结果回传:从金蝶云星空到 MES 的闭环策略实战

这个策略解决什么问题

在一次面向制造企业的供应链集成项目中,客户在 MES(MySQL)发起销售出库单,推送到金蝶云星空走审核流程。审核提交后,结果(成功 / 失败、消息文本、原始报文)需要回写到 MES 的标签审批表中,让现场能继续拣货、打印或停单。

这条策略的本质是"审核结果的回写闭环":出库单状态从 MES 单向走向 ERP,再从 ERP 回到 MES。我们用轻易云数据集成平台(Qeasy)承接,核心做法是——源端定时查询 ERP 端"已提交审核"的出库单,目标端用 SQL 直接更新 MES 业务表的标记位与消息字段。

数据流向与字段映射(源 → 中间层 → 目标)

源端:金蝶云星空(WebAPI 查询接口)

源端调用的是"请求空操作"型 WebAPI(POST,QUERY 语义),相当于一个轻量查询钩子,返回的是已提交审核的销售出库单记录集合。

中间层:轻易云集成平台

平台把源端返回的字段统一收口,再交给目标端去执行。

目标端:MySQL(执行型 SQL)

目标端是一条 update 语句,作用是把审核结果写回 MES 的标签审批表。

关键字段对照表:

源端字段(金蝶云星空响应)	含义	目标端字段 / SQL 绑定变量	说明
sd_code	销售出库单号	:sd_code	主键,定位唯一一张单
is_sucess	审核是否成功	:is_success	写入 flag 标记位
result_message	审核消息文本	:message	写入 message 字段,便于现场定位
json_data	原始 JSON 报文	json_data	留作审计/对账使用
(源端无,SQL 内置)	—	update_date = now()	每次回写刷新时间戳

完整 SQL 形如:

sql

update ty_mes.mt_so_delivery_not_label_approve
set flag = :is_success,
    message = :message,
    update_date = now()
where sd_code = :sd_code

在轻易云上如何配置

源端选 WebAPI 资源,API 选"请求空操作",方法是 POST,effect 选 QUERY。响应字段直接绑定 sd_code / is_sucess / result_message / json_data 四个字段,is_required 保持 false,因为回传场景允许字段为空字符串。

目标端选 MySQL 资源,type 选 SQL,effect 选 EXECUTE。otherRequest 里写完整的 main_sql(即上面那段 update),request 里的 main_params 接收来自源端转换后的参数对象。

字段映射这一步,我们建议把"编码映射"集中放到轻易云的转换脚本里,而不是散落在每条策略里。具体到这个场景:sd_code 透传,is_sucess 做布尔归一化(把 ERP 的 Y/N、1/0、true/false 全部归到 0/1),result_message 做长度截断(避免超长把 message 列撑爆)。这是轻易云客户常见的做法之一:"编码映射集中管理"。

实施步骤

我们一般把这套回传策略拆成三段来上线。

第一段:增量起点初始化。 在轻易云里先用一次性全量,把过去 7 天内"已提交审核"的出库单全量回查一遍,保证历史单据的状态先对齐。这一步用轻易云的手动触发即可。

第二段:定时调度上线。 源端金蝶云星空的 crontab 配置为 1 1 1 1 1(五位表达式里只取最后一位,表示仅在周五触发一次,作为兜底重查),目标端 MySQL 的 crontab 配置为 */1 * * * *,每分钟执行一次 SQL 更新。这种"源端低频兜底 + 目标端高频轻量执行"的组合,正是轻易云上"增量与全量双轨"的典型形态。

第三段:依赖与监控。 这条策略在业务上"不依赖"前序策略——它是出库闭环的最后一棒,因此 depends_on 留空。但我们建议在轻易云里加上对失败条数的告警:连续两个周期内 is_success = false 的条数超过阈值,就推送到运维群,避免现场拣货停摆。

踩坑复盘

字段名拼写不一致。 源端响应里写的是 is_sucess(少了字母 c),而 SQL 绑定变量是 :is_success。千万别在文档里"顺手改齐"——金蝶云星空那边是固定的,改了我们这边就匹配不上。稳妥的做法是,在轻易云的转换脚本里做一次显式重命名,把 is_sucess 重命名为 is_success,再喂给 SQL。
空操作接口的隐含语义。 源端选的是"请求空操作",意味着请求体是空的,真正驱动查询的是 ERP 内部状态机。如果 ERP 端的审核队列有积压,这里会查不到新单——典型错误是只盯着轻易云日志,而不去 ERP 端看审核工作流。
SQL 写法的可重入性。 update 用了 set flag = :is_success, message = :message,看似幂等,但如果源端 result_message 为空,会把之前非空的消息覆盖成空字符串。建议在轻易云转换层加判断:只有当 :message 不为空时才回写 message 字段,避免"成功信息被空消息盖掉"。
时间戳刷新带来的副作用。 update_date = now() 每次都会刷新,如果 MES 端有基于这个字段的"最后变更"逻辑,可能会误判为"单据又有更新"。稳妥做法是和业务确认 update_date 的语义,必要时把时间戳更新挪到只在 flag 真正翻转时才执行。
依赖关系留空的代价。 因为 depends_on 是空数组,平台不会自动等前序策略跑完。如果上游"销售出库单推送"还没把单据推到 ERP,这里就查不到——结果是 MES 永远停在"未审核"。建议即便 depends_on 留空,也在文档里写明"必须先有上游推送",上线时人工核一次顺序。

适用场景与不适用场景

适用: MES 发起出库 → ERP 审核 → 审核结果回写 MES 这种"两端确认"的轻量闭环;回传字段少(4 个以内)、单据量大、每分钟级别的近实时同步。

不适用: 审核过程需要回传明细行(行项目、序列号)或多审批节点状态的场景——本策略只回传表头级结果,不够用;也不适用于跨组织的复杂审批流,那种建议走金蝶云星空的工作流回调,而不是定时查询。