MES Process Information Query Strategy in Practice: Syncing Virtual Materials from a Web-based MES to Kingdee Cloud Cosmos

What This Strategy Solves

In the workshop of a discrete manufacturing enterprise, processes are the smallest unit of a routing and must exist on both the MES side and the ERP side. The MES maintains labor hours, takt times, and outsourcing flags; the ERP side converts each process into a "virtual material" so it can flow into cost collection and downstream purchase requisitions. On paper this looks like a plain master-data sync. In practice, the most common pain point is: once the MES adds or renames a process, the virtual material on the ERP side does not catch up, and three months later the numbers diverge, breaking cost accounting.

This strategy exists to solve exactly that: pull process master data from the MES on a stable schedule and feed the ERP side, forming the material foundation for downstream strategies such as "process outsourcing application to expense purchase requisition" (sequence A/B). We use the Qeasy data integration platform to host the entire pipeline. The source side goes through a paginated WebAPI query, and the target side performs a lightweight write, forming an observable and rerunnable sync strategy.

Data Flow and Field Mapping

The overall flow is MES (WEB) → Qeasy middleware layer → Kingdee Cloud Cosmos. The source system is the common/search interface of a web-based MES, and the target system is the virtual material archive in Kingdee Cloud Cosmos.

Key field mapping:

Note: In real projects, we centralize the processCode mapping in one place. All downstream strategies that reference this field share the same mapping table, so a change only needs to be made once.

How to Configure It on Qeasy

In the Qeasy platform, the source and the target of this strategy are two independent data-source nodes:

Source node (MES side)

• Interface type: WebAPI
• Method: POST
• Path: common/search
• Pagination: pageNum, pageSize=100, loop until an empty page is returned
• Filter: wsId is a fixed value, queryKey=2 is used to scope the process range
• Primary keys: processCode as the number field, id as the id field, idCheck=false means we do not go back to the source for re-check
• Response parsing: autoFillResponse=true, the platform fills in undeclared fields automatically to avoid missing columns

Target node (Qeasy → Kingdee)

• Interface type: WebAPI (EXECUTE)
• API: "write empty operation" (placeholder; the actual write is triggered by the downstream "virtual material generation" strategy)
• idCheck=true, ensuring the target document already exists on the ERP side
• Request and response bodies are empty; this strategy only completes "fetch → land in middleware"

This layering, "strict parsing on the source side, staging on the target side," is a common pattern among Qeasy customers, especially when the same process data needs to be reused by multiple downstream strategies.

Implementation Steps

We typically push the project forward in three phases on the customer site to keep things under control:

1. Incremental start: full first run. Set crontab to manual trigger and pull all current processes from the MES to the Qeasy middleware in one pass. Reconcile counts and codes on both sides. The most common pitfall here is requesting one extra page after pagination has already drained. Add an "empty page break" check in the Qeasy loop.
2. Full run: manual reconciliation. After the first run, export the intermediate table and sample-compare it with the MES source to confirm that no processCode is missing and isIpsi is not misplaced, then switch to the production schedule.
3. Schedule: hourly incremental. The source strategy's crontab is configured as * 7-22 * * * (every hour from 07:00 to 22:00), covering workshop hours. The target side stays at a low frequency (1 1 1 1 1, a placeholder for early Sunday morning); actual writes are driven by downstream strategies.

This is a typical "incremental plus full reconciliation dual-track" mode: hourly incremental during the day, and a weekly full reconciliation as a safety net to catch missed pushes or code changes that did not trigger an incremental update.

Pitfalls From the Field

• Pagination infinite loop. When pageSize=100 is paired with an auto-incrementing pageNum, the source side may return an empty payload with HTTP 200, and the loop will keep requesting. The safe approach is to add a "break on data.length==0" check inside the Qeasy parser.
• wsId hard-coded, dropping data from other workshops. In one project, different workshops used different wsId values. We hard-coded it to a single value for convenience and ended up syncing only one workshop. Later we switched to maintaining a workshop list on Qeasy and iterating per workshop.
• autoFillResponse conflicts with manual field mapping. When auto-fill is on, manually declared fields can be overwritten. A typical mistake is declaring queryKey in the request and then declaring it again in the response. The safe approach is to declare only the differing fields and let auto-fill handle the rest.
• "Write empty operation" on the target side mistaken for a misconfiguration. During the first delivery, the customer saw the target API named "write empty operation" and thought the config was wrong. It is intentional: this strategy only fetches data and does not write to Kingdee directly. The actual write is handled by the downstream virtual material generation strategy, following the "header/body staged" design pattern.

When This Strategy Applies and When It Does Not

Applies: process master data must be synchronized between MES and ERP, and downstream chains such as outsourcing, cost accounting, and purchase requisitions depend on virtual materials; the environment is a private deployment with network reachability to the source MES WebAPI.

Does not apply: scenarios that require real-time (second-level) process change push, strong compliance and audit requirements on middleware persistence, or situations where the ERP side requires direct persistence rather than transformation through a downstream strategy.