Measurement Unit Update Synchronization: A Master Data Consistency Solution Between MES and Business Systems
What This Strategy Solves
In a manufacturing enterprise, measurement units are master data used by materials, recipes, and production material issues. If a unit is changed in the business system but the MES keeps the old information, unit names, codes, or conversion relationships may become inconsistent. We use the Qeasy Data Integration Platform to orchestrate the receive, transform, and update flow, while Qeasy provides scheduling and exception handling so that master data reaches the target system according to defined rules.
Data Flow and Field Mapping
This is a one-way update strategy: the source system supplies measurement-unit data; the Qeasy Data Integration Platform handles pagination, data preparation, and request assembly; and the target system receives the update parameters. Because the strategy focuses on modifications, the source data is first used to locate an existing unit by its unique identifier, and then the target update capability is called.
| Business meaning | Source field | Target field | Configuration note |
|---|---|---|---|
| Measurement-unit identifier | FUNITID | unitUuid | Used for locating and updating; do not look up by name |
| Unit code | FNumber | unitNo | Keep code rules consistent; use centralized mapping if needed |
| Unit name | FName | unitName | Update the name so that code and name do not diverge |
| Company scope | Configured from business context | companyCode | Obtain from controlled configuration or context; do not hard-code a sample value |
| Base-unit identifier | No unified source shown | basicUnitUuid | Confirm its default value, required status, and handling of existing relationships |
| Conversion coefficient | Not fully shown in the supplied material | coefficient | Confirm the source and target semantics before mapping; never infer from the field name alone |
| Disabled status | FForbidStatus | Map according to target API capability | If the target has no corresponding field, convert it in the intermediate layer to an update-control value |
The intermediate layer should perform at least three operations: merge paginated results, validate unique keys, and assemble target request parameters. The key issue is not merely that fields appear to match; every field must have a source, an update meaning, and an exception policy.
How to Configure It in Qeasy
First, configure the source connector to query measurement-unit data. The request uses POST, and the pagination parameter Limit is supplied by the platform variable {{PAGINATION_PAGE_SIZE}}. The output fields include FNumber, FName, FForbidStatus, and FUNITID. The page capacity should not be copied as an unchangeable environment-specific value; configure it according to data volume and interface limits.
Next, configure the target connector and call the measurement-unit update capability. Map unitUuid from FUNITID, unitNo from FNumber, and unitName from FName. The company code must come from controlled business context rather than from the sample value in the material. The complete source of basicUnitUuid and coefficient is not fully available in the supplied material, so both must be confirmed from the interface definition and project data model before implementation. They must not be guessed and then enabled in production.
In the transformation rules, we recommend centralizing field types, code mappings, and status conversions. If the project contains historical units or nonstandard codes, a mapping table in the Qeasy Data Integration Platform can manage them consistently. A common mistake is to use the unit name or code as the update key. A safer approach is to prioritize the stable identifier and retain a dual-path validation of “identifier first, code fallback.” The fallback path must be proven unique before use.
Finally, configure result handling. Successful updates enter a completed state; a target record that cannot be found is recorded separately; incomplete parameters or ambiguous mappings block the write instead of generating an unexplained request. In a private deployment, also confirm Qeasy scheduling-service availability, network connectivity, log desensitization, and failure-retry policies.
Implementation Steps
Step one is to establish a baseline. Manually select a small set of measurement units and verify code, name, status, and unit relationships to create a traceable test set. Prioritize update verification; do not use arbitrary test creation requests to trigger create behavior.
Step two is to execute the first full synchronization. Read source data page by page, and let Qeasy locate and update target records one by one. The initial run should use throttling or smaller batches so that interface responses, pagination boundaries, and status decisions can be observed. Full synchronization is appropriate for go-live, data repair, or realignment after a strategy change.
Step three is to switch to incremental synchronization. The incremental starting point should be the successful completion time of the first full run, or a supported change condition from the source system. If the source does not provide a reliable incremental signal, use a dual-track model of incremental and full synchronization: run incremental processing on schedule and periodically perform full calibration. A full run should not simply be a larger normal batch; it needs a separate entry point, separate batch controls, and separate alerts.
Step four is to configure scheduling. The supplied schedule is * 7-22 * * *, indicating per-minute execution during the business period. In a real project, the window can initially be narrowed and restored after stability is confirmed. When a maintenance window is required, avoid crossing a day boundary and define how missed schedules are recovered. The platform should retain the last successful position, provide failure retries, and offer a manual compensation entry point.
Step five is reconciliation and acceptance. Check the daily read, success, failure, unmatched, and target-rejection counts. Randomly sample modified units and confirm that code, name, status, and conversion relationships are consistent on both sides. After all tests pass, switch the process from verification mode to continuous synchronization.
Lessons Learned
- Only creating data does not handle updates. The usual master-data problem is not missing data, but the absence of a reliable modification path. The strategy must define both the update key and the update interface, avoiding the mistake of treating an update as a create.
- Pagination is easy to get wrong. The last page may contain fewer rows than the configured size, and data changes during execution can create duplicates. This is a common failure point. The safe approach is to use the platform pagination mechanism and validate identifier uniqueness.
- Not required does not mean optional to send. A source field being non-required does not mean that the target accepts arbitrary omissions. Fields such as
basicUnitUuidandcoefficientmust have confirmed update semantics; otherwise the interface may partially succeed or fail silently. - Hard-coding sample values is dangerous. Company codes and unit identifiers in the material only illustrate the data structure. Production values must come from controlled context or mapping tables and must be covered by secret and sensitive-information management.
- Full calibration should not share a task with the daily run. A common pattern at a manufacturing customer site is to run incremental and full synchronization in parallel: incremental processing protects timeliness, while periodic full synchronization repairs omissions. Configuring the two phases separately and keeping their failure logs separate makes diagnosis much clearer.
When to Use It and When Not to Use It
This strategy is suitable when measurement-unit codes, names, statuses, or conversion relationships must remain consistent across systems and the target system already supports updates by a stable identifier. It fits private deployments that need master-data synchronization, periodic calibration, and targeted repairs. Do not enable it directly when the source has no change signal, the target cannot locate a record for update, or the field sources for complex unit relationships remain unconfirmed. In those cases, complete interface verification and a trial run first.