UDI Master Data Query and Write-Back: A Single-Strategy Practice from Sinopharm WMS to Qeasy Integration Platform
What This Strategy Solves (Scenario and Value)
When a pharmaceutical distribution enterprise was integrating supply chain between Sinopharm WMS and Kingdee Cosmos, it ran into a very specific and granular problem: UDI (Unique Device Identification) code segments were scattered across WebService interfaces on the WMS side, and Kingdee Cosmos could not get complete fields when triggered by documents, so a "light query, light landing" was needed at the integration layer. This strategy was prepared for exactly this scenario — actively pulling UDI return data from Sinopharm WMS' GetUdiRstErp interface, cleaning it at the middle layer, and then writing it back to the Qeasy (Qeasy) integration platform itself as a "no-op write", serving as the data source for downstream Kingdee Cosmos strategies. Its value lies not in moving the data itself, but in sinking UDI ownership information (ERP owner, ERP warehouse, order number, ASN type) into "quasi-master data" consumable downstream, avoiding repeated fetches from WMS in every downstream document.
Data Flow and Field Mapping
The flow of the entire link is very clear: Sinopharm WMS → Qeasy Integration Platform (middle layer) → Qeasy Integration Platform (target write). The source end is a WebService query interface, the target end is a POST-type "no-op write", and the data ultimately stays in an internal intermediate table on the platform for downstream consumption.
Key field correspondence:
| Source Field (WMS return) | Middle Layer Field | Target Landing | Description |
|---|---|---|---|
| ERP_OWNERID | erp_owner_id | intermediate table erp_owner_id | ERP owner code |
| ERP_WHSE_CODE | erp_whse_code | intermediate table erp_whse_code | ERP warehouse code |
| LORDERID | l_order_id | intermediate table l_order_id | upper-level order number |
| ASN_TYPE | asn_type | intermediate table asn_type | ASN type (P receipt / R return, etc.) |
| GRPNO | grp_no | intermediate table grp_no | group number, used as query input |
| BARCODE | barcode | intermediate table barcode | barcode, concatenated as interface id |
The id of the source interface is composed of {{GRPNO}}{{BARCODE}}, with idCheck turned off and autoFillResponse turned off, meaning the return value should be taken as-is from the response body, without letting the platform help itself fill in. We did a lightweight normalization at the middle layer: unified uppercase, trimmed spaces, kept numeric warehouse codes as strings — this step was to avoid repeated errors on the downstream Kingdee Cosmos side due to type inconsistencies.
How to Configure on Qeasy
In the Qeasy (Qeasy) integration platform, the source end of this strategy is Sinopharm WMS and the target end is Qeasy Integration Platform itself (datahub). Several non-default configuration points deserve individual explanation:
- Request body assembly: The source end has only one input parameter
GrpNowith a fixed value1, which can be written directly into the request parameter'svalue; if multi-group extension is needed later, changing it to the{{grp_no}}variable is more robust. - id concatenation strategy: Set the
idfield to{{GRPNO}}{{BARCODE}}and turn offidCheck, otherwise the platform will deduplicate based on the returned id and lose data. - Response parsing: Enable automatic field mapping, map source fields like
ERP_OWNERIDone-to-one to the intermediate table fields of the same name, and reuse the label and describe directly to reduce maintenance cost. - Target end no-op: The
写入空操作(Write No-Op) API (method=POST, effect=EXECUTE) has empty request and response. Its meaning is to trigger a "persistent landing" event, allowing Qeasy to register this data internally as an asset consumable downstream, rather than actually writing to some external system. - Schedule expression: The crontab is written as
1 1 1 1 1, which is a placeholder expression meaning "not triggered by schedule, but driven by preceding strategies".
Implementation Steps
We split the rollout of this strategy into three phases, and it only stabilized after a few pitfalls:
Phase 1: Confirm the incremental starting point. First confirm that the source of UDI data is on the WMS side, and new data enters the dispatch table when documents are posted. We subscribe to the WMS posting event in Qeasy, and when the event is triggered, write GRPNO and BARCODE into a lightweight "to-be-queried queue". This step is the starting point of the entire strategy; without it, everything afterwards is just spinning.
Phase 2: Full-volume compensation trigger. Incremental can only cover new data of the day, historical UDI must rely on full-volume compensation. We use a one-shot triggered strategy that pulls everything with GrpNo=1 as input, and after landing switches back to incremental. The buildModel of the full-volume strategy is set to true, letting the platform build the table structure from sample data first to avoid missing fields.
Phase 3: Scheduling frequency and retry. The incremental strategy polls the "to-be-queried queue" every 5 minutes, and skips if the queue is empty. The WebService interface occasionally times out, so we set 3 retries with 30-second intervals. Barcodes that still fail after retry are written to a "manual handling table" and checked uniformly by the on-duty colleague the next morning.
Pitfall Review
Pitfall 1: id concatenation order reversed. In an early version, id was written as {{BARCODE}}{{GRPNO}}, but the source WMS interface is sensitive to id order, and reversing it returns empty. The robust approach is to check character by character against the WMS-side interface documentation, not go by intuition.
Pitfall 2: The "no-op" on the target end was accidentally deleted. During a platform version upgrade, someone thought the 写入空操作 API had no business meaning and cleaned it up, resulting in downstream strategies not finding the data source. The no-op is not redundant — it is the event hook that triggers internal persistence on the platform, and downstream consumers must be confirmed before deletion.
Pitfall 3: autoFillResponse default on causes dirty data. When on by default, the platform uses request fields to fill in response fields, making all returned fields look like they have values, but they are fake. Fields like UDI that require precise matching must turn it off.
Pitfall 4: Full-volume and incremental run together. When the full-volume compensation was running, the incremental strategy was not stopped, causing the same UDI to be written multiple times and putting pressure on downstream deduplication logic. The robust approach is to suspend the incremental strategy during the full-volume window and release it after landing is complete.
Pitfall 5: Numeric fields forcibly converted. ERP_WHSE_CODE is the string 531 on the WMS side, and numeric on the Kingdee side. The platform by default does a forced conversion, dropping warehouse codes with leading zeros like 0531. The robust approach is for the middle layer to uniformly preserve strings and do an explicit conversion only before landing on the Kingdee side.
Applicable and Inapplicable Scenarios
Applicable: WMS side can only provide WebService query interfaces and cannot push change events; scattered return values need to be sunk into quasi-master data reused by multiple downstream strategies; data volume is within the tolerance of a single interface call (thousands per group in this case). Not applicable: Real-time requirement at the second level, UDI data volume at tens of thousands or above, or links requiring dual-write strong consistency — such scenarios should use real-time message middleware instead of query-and-write-back.