Qeasy Cloud
Get Started

Integration Solution Overview: Kingdee Cloud Xingchen to Heihu MES

· 高金凤· Integration Solutions· 9 views· 4 min read
金蝶云星辰黑湖小工单ERP-MES供应链同步轻易云数据集成平台Incremental Sync

Scenario and Value

In a real manufacturing project we worked on, production scheduling had a recurring pain point: sales would place purchase orders in the ERP, the workshop would queue production in the MES, but the two sides never reconciled. Buyers did not know which batch was arriving first, and the workshop did not know which work order was waiting on material. Once an automated closed loop went live, production orders appeared on the shop-floor dashboard six hours earlier than manual dispatch, and material shortages became visible to procurement the same day.

The key was not a single document sync but four parallel data streams — material, product, work order, and inventory — that cross-validate each other at minute-level cadence. Kingdee Cloud Xingchen acts as the system of record on the ERP side, Heihu MES as the system of record on the shop-floor side, and we needed an integration layer in between that could orchestrate seven strategies and survive cross-lookups and retries. On customer sites we use Qeasy (轻易云数据集成平台) as that layer. This article unpacks the engineering details.

Integration Architecture and Data Flow

The solution consists of seven strategies executed in four phases: master data first, transactional documents next, inventory last, housekeeping at dawn.

mermaid
flowchart LR
    subgraph Phase1["Phase 1: Master Data"]
        S1["Strategy 1: Query-only Xingchen Products"]
        S2["Strategy 2: Xingchen Material → Heihu Material"]
    end
    subgraph Phase2["Phase 2: Production / Purchase"]
        S3["Strategy 3: Production Task → Work Order"]
        S4["Strategy 4: Subcontract → Work Order"]
        S5["Strategy 5: Purchase Order → Work Order"]
    end
    subgraph Phase3["Phase 3: Inventory"]
        S6["Strategy 6: On-hand Inventory → Heihu Inventory"]
    end
    subgraph Phase4["Phase 4: Housekeeping"]
        S7["Strategy 7: Clean Queues"]
    end
    S1 --> S2
    S2 --> S3
    S2 --> S4
    S2 --> S5
    S2 --> S6
    S6 --> S7

The seemingly innocuous "query-only Xingchen products" strategy is the linchpin: it does not write to Heihu but pulls products with custom fields like routing into the integration hub, and downstream material/work-order/purchase strategies then read back via _mongoQuery. This master-data-first layering is what keeps routing and other custom fields from being silently dropped on the shop floor.

Interface Catalog

Strategy IDData ObjectDirectionNotes
1Xingchen products (with custom fields)Xingchen → HubQuery-only, stored for cross-lookups
2Xingchen materialXingchen → HeihuMaster data, filter enable=1
3Xingchen production taskXingchen → Heihubill_status=C, line-item split
4Xingchen subcontract orderXingchen → Heihubill_status=C, default priority 1
5Xingchen purchase orderXingchen → Heihubill_status=C, audittime as plan start
6Xingchen on-hand inventoryXingchen → HeihuGrouped by material + warehouse
7Hub queues / logsHub internalDaily cleanup of records older than 30–90 days

Implementation Notes

Phased scheduling. Master data runs every 5 minutes, transactional documents every 5–10 minutes, and queue cleanup is fixed at 1:15 AM. Xingchen products and Xingchen material are deliberately offset (0-59/5 vs 2-59/5) so they never hit the source API in the same second and compete for quota.

Incremental fields. All transactional strategies carry modify_start_time and modify_end_time, combined with bill_status=C as the business filter. The filters are removed for one-off full pulls during initialization or data repair.

Centralized code mapping. Material code number → Heihu productCode and document number bill_no → work order projectCode are maintained in a single mapping table rather than hard-coded in strategy scripts, so adding fields later requires no code change.

Line-item split staged write. All work-order strategies expand material_entity row by row into deliveryList, producing one source document into N target work orders. This is a common place to fail: writing the whole document at once only delivers a single record downstream. The safe approach is configuring "array split" on the platform so each row creates its own work order.

Exception retry. Network timeouts use exponential backoff at 5s/15s/45s. Rate-limit 429s wait 60 seconds and retry up to twice. Cross-lookup failures log an alert rather than aborting the batch. Business validation failures skip retry and fall into the failure table for compensation.

Privacy handling. All source/target credentials are stored inside the platform connector. Strategy scripts only reference variables; real tokens, IPs, and tenant identifiers never appear in logs.

Best Practices and Lessons Learned

  1. Routing must be staged through the hub. The source API paginates materials, and the routing inside custom fields gets truncated mid-page. On Qeasy we use a query-only strategy to pull all products into the hub first, then let downstream strategies read via _mongoQuery. Stable and reusable.

  2. Split Qimen and non-Qimen traffic. Some customers run ERP↔MES direct integrations alongside Qimen-based third-party e-commerce warehouses. On Qeasy we split these into two channels with separate connectors and schedules, so an outage on one side does not bleed into the other.

  3. Do not default subcontract work orders to normal priority. Subcontract orders depend on external supplier lead time, so we hard-set priority to 1 (urgent) to keep them out of the back of the workshop queue. Production task orders default to 0, and urgency is raised manually when needed.

  4. Do not aggregate inventory. Xingchen on-hand inventory returns multiple rows per material across warehouses, but the Heihu product update endpoint only accepts one product at a time. Writing an aggregated total causes inventory drift in multi-warehouse setups. Group by material_number and write each row individually into customFieldValues, with warehouse code as a dimension field.

  5. Always have failure compensation as a backstop. A failure table is not enough; we also run a daily dawn compensation task that re-runs the previous day's failed records idempotently by business key, so month-end reconciliation never discovers silent gaps.

When to Use Qeasy

When ERP and MES need a minute-level closed loop rather than a one-off sync — and when routing cross-lookups, Qimen/non-Qimen channel splitting, failure compensation, and alerting are all required — Qeasy (轻易云数据集成平台) provides out-of-the-box strategy orchestration, managed connectors, and a visual operations console. It fits the integration needs of mid-to-large manufacturing, retail, and e-commerce environments where multiple systems coexist.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/solutions/sol-kingdee-cloud-pce9768-4764

Comments