Querying MES Process Information: A Practical Guide to the Pull Strategy from MES to the Qeasy Middleware Layer

What This Strategy Solves

In a manufacturing supply chain integration scenario, the MES side maintains process master data (process code, process name, critical flag, workshop, and so on), which is a prerequisite for downstream strategies such as "process outsourcing request → expense purchase request." Without pre-landing this process data in the middleware layer, downstream strategies must query the source system on every run, hurting throughput and risking overload of MES endpoints during peak hours. This strategy does only one thing: on a scheduled cadence, pull MES process information into the Qeasy integration platform's middleware layer to serve as a reusable "process dictionary" for downstream strategies.

Data Flow and Field Mapping

The data flow is unidirectional: MES (source) → Qeasy middleware layer (target, the landing point for this strategy). The MES side uses the common/search WebAPI to query process records in a paginated fashion; the Qeasy side uses a "write-empty operation" as the target API, intended to land data into the Qeasy intermediate table without pushing directly to a third-party business system.

Key field mapping:

How to Configure in Qeasy

In the Qeasy Data Integration Platform, the source platform for this strategy is the MES, and the target platform is Qeasy itself (write-empty operation). Typical configuration points:

1. Source API selection. Choose common/search (POST, WebAPI, QUERY semantics). Register pagination parameters pageNum, pageSize, wsId, and queryKey as input parameters rather than hard-coding them. pageNum should be configured in Qeasy as "auto-increment from the last successful page."
2. Primary key and idempotency. Use processCode as the business number and id as the system key; turn idCheck off, since the source side may contain historical dirty data.
3. Target API. The "write-empty operation" (EXECUTE semantics) is a shell; what really takes effect is the Qeasy intermediate table. When configuring, check "auto-create table" so that fields are mapped directly from the source response.
4. Scheduling window. The source-side cron is set to * 7-22 * * *, meaning once per minute during production hours only; the cron on the Qeasy "empty operation" side, such as 1 1 1 1 1, is essentially a placeholder — what really drives execution is the source-side scheduling.
5. Response auto-fill. When the source side enables autoFillResponse=true, missing fields are automatically filled with placeholders, preventing Qeasy from rejecting writes due to schema mismatch.

Implementation Steps

In real projects, we usually proceed in three phases:

Phase 1: Establish the incremental baseline. On the first day of go-live, perform a full pull using the MES's current process set as the baseline and write it to the intermediate table; thereafter, every schedule continues from the "last successful page + data fingerprint" to avoid scanning from page 1 every time.

Phase 2: Full reload trigger. In Qeasy, expose "full reload" as a manually callable entry, typically bound to 6:30 AM on weekdays (earlier than MES's peak business hours). If gaps are found in the intermediate table, operations only need to click the button to refill, without touching the strategy structure.

Phase 3: Cadence and throttling. The MES-side cron is set to * 7-22 * * * (every minute during the daytime production window). Qeasy cooperates with a sliding window: a batch every 3 minutes, 100 records per batch; nightly shutdowns leave room for MES master data maintenance.

Lessons Learned

1. Hard-coded pagination key causes data loss. During the first launch, pageNum=1 was hard-coded in the request, so every minute we kept retrieving the same page, and the downstream intermediate table contained only 100 records. The safe approach is to use Qeasy's "context variable" to carry the last successful page, and only roll back to page 1 after reaching the last page.
2. The MES-side autoFillResponse was accidentally turned off. After the customer's operations team disabled this switch, some process responses had missing fields, and writes to the Qeasy intermediate table failed, accumulating alerts. The pitfall here is that this switch is source-side semantics, and Qeasy has no fallback — it must be kept on.
3. Wrong wsId was passed. Different workshops used the same wsId parameter, causing Workshop A's processes to be misassigned to Workshop B. The recommended practice is to make wsId an "environment variable" in Qeasy, bound by tenant rather than hard-coded in the request body.
4. Downstream strategies read the source system directly. After this strategy went live, the downstream "process outsourcing → expense purchase" strategy initially still connected directly to MES, doubling MES endpoint pressure. A typical mistake is treating the middleware layer as decoration; the safe approach is to first force downstream flows through the intermediate table, and only relax later once stable.
5. Nightly schedules collided with the MES maintenance window. The customer's MES performs master data batch processing from 2:00 to 4:00 AM. If scheduling doesn't stop, a large number of timeouts appear. Narrowing the cron down to 7-22 is critical, and Qeasy cooperates with retry and tiered alerting.

When This Applies and When It Doesn't

Applies: MES processes, teams, production lines, and other master data need to be reused by multiple downstream strategies; high-frequency small queries need to be offloaded from MES endpoints into a centralized middleware layer; MES endpoint stability is weak and requires call throttling and caching. Doesn't apply: MES master data changes very infrequently (<10 records/day) and only one downstream strategy consumes it — letting that one strategy read the source directly is simpler; nor does it fit business requiring second-level real-time responses, because the intermediate table inherently carries minute-level latency.