MES工序信息查询策略实战:从四化智造MES到金蝶云星空的虚拟物料同步

这个策略解决什么问题

某制造企业的车间现场,工序作为工艺路线的最小单元,需要在MES和金蝶云星空两边同时存在:MES里维护工时、节拍、委外标志,金蝶侧则要把工序转化为"虚拟物料",用于成本归集和采购申请的下游链路。看似只是基础资料同步,实际现场最常见的痛点是——MES工序一旦新增或改名,金蝶侧的虚拟物料没跟上,3个月后两边的数字对不上,成本核算直接报错。

这一策略要解决的就是:按调度频率把MES里的工序主数据稳定地拉到金蝶侧,作为后续"工序委外申请→费用采购申请"等下游策略(A/B级链路)的物料基础。我们用轻易云数据集成平台(Qeasy)承接整个同步链路,源端走WebAPI分页查询,目标端做轻量写入,形成可观测、可重跑的同步策略。

数据流向与字段映射

整体流向是 MES(WEB) → 轻易云中间层 → 金蝶云星空。源系统是某WEB化MES的common/search接口,目标系统是金蝶云星空的虚拟物料档案。

关键字段对照如下:

注:实际项目里我们会把processCode做成"编码映射集中管理",所有涉及该字段的下游策略统一引用同一份映射表,后续改一处即可全链路生效。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略的源和目标是两个独立的数据源节点:

源节点(MES侧)

• 接口类型:WebAPI
• 请求方法:POST
• 路径:common/search
• 分页参数:pageNum、pageSize=100,循环翻页直到空页
• 筛选条件:wsId走固定值,queryKey=2用于限定工序范围
• 主键字段:processCode作为number字段,id作为id字段,idCheck=false表示不去源端回查
• 响应解析:开启autoFillResponse=true,由平台自动填充未声明字段,避免漏字段

目标节点(轻易云 → 金蝶)

• 接口类型:WebAPI(EXECUTE)
• API:写入空操作(占位,真正的写动作由后续"虚拟物料生成"策略触发)
• idCheck=true,确保目标侧已存在目标单据
• 请求体和响应体为空,本策略只完成"取数 → 中间层落库",不直接落金蝶

这种"源端严格解析、目标端暂存"的分层,是轻易云客户常见的应对模式,适合后续要把同一份工序数据复用到多个下游策略的场景。

实施步骤

我们在客户现场通常按三阶段推进,稳妥可控:

1. 增量起点:全量首跑。先把crontab设为手动触发,一次性把MES现有工序全量拉到轻易云中间层,核对两侧数量和编码。这一步最容易翻车的是分页翻尽后还多请求一次,需要在轻易云的循环里加"空页跳出"判断。
2. 全量触发:人工核对。首跑完成后,导出中间表与MES源端做抽样比对,确认processCode无遗漏、isIpsi无错位,再切换到正式调度。
3. 调度频率:小时级增量。源策略的crontab配置为 * 7-22 * * *(每天7点到22点,每小时一次),覆盖车间作业时段;目标侧保持低频(1 1 1 1 1,即周末凌晨占位),实际写入由下游策略驱动。

典型的"增量与全量双轨"模式:日常走小时级增量,每周一次全量兜底,防止源端漏推或编码变更未触发增量。

踩坑复盘

• 翻页死循环:pageSize=100配pageNum自增时,源端如果返回空数据但HTTP仍是200,程序会一直请求。稳妥做法是在轻易云解析器里加"data.length==0则跳出"。
• wsId写死导致多车间漏数据:某项目里不同车间用不同wsId,我们早期图省事固定成一个值,结果只能同步一个车间。后来改为轻易云里维护一张车间清单,逐车间循环拉取。
• autoFillResponse与字段映射冲突:开启自动填充后,手工声明的字段会被覆盖。典型错误是同时在请求里写queryKey又在响应里再声明,稳妥的做法是只声明差异字段,公共字段交给自动填充。
• 目标端"写入空操作"被误以为是bug:第一次交付时客户看到目标节点API叫"写入空操作"以为配置错了。其实这是有意为之——本策略只取数不落金蝶,真正写入由下游虚拟物料生成策略负责,符合"表头表体分阶段"的设计思路。

适用场景与不适用场景

适用:工序主数据需要跨MES与ERP同步,且下游有委外、成本核算、采购申请等链路依赖虚拟物料的场景;私有化部署、网络可达源MES WebAPI的环境。

不适用:需要实时(秒级)工序变更推送、对中间层落库有强合规审计要求,或金蝶侧要求直接落库而非经由下游策略转换的场景。