Querying MES Process Information: A Practical Guide to Virtual Material Master Sync in Kingdee Cloud Cosmos Supply Chain Integration

What This Strategy Solves

Process master data is often underestimated in MES–ERP integration projects. In one manufacturing engagement, the MES kept processes as sub-entries of a routing, while the Kingdee Cloud Cosmos supply chain module required every outsourced process to have a priceable, purchasable "virtual material" code. If the code mapping between the two systems is not designed properly from the start, within three months the outsourced purchase requisitions, goods receipts, and cost roll-ups end up with a flood of "material not found" red-flag documents.

We used the Qeasy data integration platform to handle this scenario: pull MES process query results, persist them, and turn them into Kingdee virtual material master data. The code mapping is centrally managed, so downstream outsourced process requisitions and expense purchase requisitions can reference the correct material archive.

Data Flow and Field Mapping

The data flow is unidirectional: MES (source) → Qeasy middleware → Kingdee Cloud Cosmos (target). The source uses a paginated WebAPI such as common/search to fetch process records, and the target uses a "write no-op" WebAPI as the landing point; the actual persistence is completed by the downstream virtual-material save interface.

Note that the target's "write no-op" does not write business data by itself. Its value is in first persisting the MES query results into a Qeasy intermediate table, which then becomes the input for the downstream virtual-material save strategy, avoiding repeated queries against MES.

How to Configure It on Qeasy

Step one: register the two platforms. The source MES and the target Kingdee Cloud Cosmos are named shzzmes and datahub respectively in Qeasy. These aliases are referenced later in strategies.

Step two: configure the source strategy. When creating a strategy, choose "WebAPI / QUERY / POST", then enter each field of the common/search request body. Pagination fields take default values; wsId and queryKey are exposed as query variables. Set number to processCode (the MES business primary key) and id to id (the idempotency key). We disable strict idempotency checking (idCheck: false) in this strategy to make manual repair easier later.

Step three: configure the target strategy. Create a "WebAPI / EXECUTE / POST" strategy named "write no-op", with an empty request body. This "dummy write" pattern is common in Qeasy — it drives the target's receiving action, while the real persistence is handled by the downstream strategy.

Step four: set up the field mapping. In Qeasy's transformer, map MES's processCode to the Kingdee virtual material code, and map business flags such as isIpsi to material attribute fields. We recommend maintaining the code rules centrally in Qeasy rather than scattering them across strategies.

Implementation Steps

We recommend a three-step rollout:

• Incremental start (initial full sync): on the first run, raise pageSize to the maximum the MES can handle (e.g. 100) and pull all processes in one go. Qeasy's scheduler then inspects every minute within the working window defined by * 7-22 * * *.
• Full sync trigger: at the start of each month, or after any batch addition of processes on the MES side, manually trigger a full sync to align the intermediate layer with Kingdee virtual materials.
• Schedule frequency: in steady state, a per-minute incremental inspection is enough. Qeasy runs an incremental-plus-full dual track internally: incremental uses an id-ordered cursor, while full resets pagination.

Lessons Learned from Real Projects

1. Do not bind the target directly to a strict write API. In our first attempt we shortcut by calling Kingdee's save API directly; whenever the MES payload was missing a field, the entire batch failed. Switching to "write no-op" plus a downstream staged persistence strategy made things far more stable.
2. MES processCode cannot be used as-is for the Kingdee material code. MES process codes are typically routing-internal numbers, while Kingdee requires material codes that conform to supply chain conventions. The safe approach is to maintain a code mapping table in Qeasy, reviewed regularly by a designated owner.
3. Workstation parameters like wsId are easy to overlook. They are optional, but if omitted the MES returns data for all workstations, doubling the payload and causing timeouts. Always pass a fixed value in the request body.
4. Do not forget the pagination loop. Leaving pageNum at its default of 1 only fetches the first page. In a Qeasy WebAPI strategy, the pagination field must be marked as a loop variable.
5. Persist header and body in separate stages. Process master data is the header; the heavy lifting is the outsourced process requisition attached below. Treat this strategy as "header sync" and leave the requisition to a follow-up strategy rather than cramming everything into one.

When to Use and When Not to Use

Use it when: the MES maintains process master data and the Kingdee Cloud Cosmos needs virtual materials to support outsourced purchasing accounting — typically manufacturing enterprises with frequent process additions and a need for cross-system code consistency in supply chain integration projects.

Do not use it when: the MES already outputs standard material codes to the ERP (in which case a direct material sync is sufficient and no "process → virtual material" mapping layer is needed); or when the business is pure assembly with no outsourcing and no need for per-process cost accounting.