Querying Kingdee Cloud Galaxy Product Master Data: Getting the First Mile of Material Sync Right

What This Strategy Solves

A manufacturing enterprise runs Kingdee Cloud Galaxy as its ERP and Heihu Lite Work Orders as its MES. Material master data must stay consistent across both. The first mile is almost always the material query interface: products in Galaxy are the baseline for every downstream document sync (production tasks, sales orders, inventory). If the extraction step is poorly designed, every downstream chain will wobble with it.

The core value of the query-only product strategy is to pull material data from Galaxy into the middle layer in a stable, replayable way. The source side only queries; the target side performs a no-op write (write empty operation). The intent is to let the Qeasy data integration platform hook in subsequent write logic while preserving the full query result and observability. This is the most common opening move in any "master data sync" chain.

Data Flow and Field Mapping

Data flow: Kingdee Cloud Galaxy V2 (source, type QUERY) → Qeasy Integration Platform (middle layer) → Heihu Lite Work Orders (target). This strategy currently completes only the "source → middle layer" extraction; the target-side write logic is handled by other strategies.

Key request parameters:

Field	Label	Type	Required	Description
enable	Available status	string	No	1 available, 0 disabled, -1 all; recommended to hardcode as 1
search	Fuzzy search	string	No	Fuzzy match on name, code, spec, barcode
parent_id	Product category	string	No	Filter by category ID
isdataperm	Data permission	string	No	Whether to enforce data permission; default false
create_start_time	Creation start timestamp	string	No	Unix seconds format; -1 means no filter
create_end_time	Creation end timestamp	string	No	Pairs with start to bound incremental window

The source API is GET /jdy/v2/bd/material. Primary key fields are number (code) and id (internal ID). The target side is configured on Qeasy as a WebAPI placeholder with a "write empty operation," ready to host the real downstream write.

How to Configure on Qeasy

Source-side configuration: connect the Kingdee Cloud Galaxy V2 adapter, select API /jdy/v2/bd/material, request method GET. Hardcode enable to 1 to avoid pulling disabled materials every cycle. Use Qeasy's built-in page paginator with a page size of 100–200; too large risks Galaxy rate-limiting.

Target-side configuration: select Qeasy's native WebAPI and configure a write empty operation. Set both number and id to 0, and idCheck to true. The point here is not to write data but to reserve the slot. Later, when you actually write to Heihu materials, only this WebAPI's implementation changes; the upstream extraction chain stays untouched.

Middle-layer governance: we usually centralize code mapping in Qeasy's mapping table—material code → Heihu material code, unit conversion, category mapping all live in one table. This "centralized code mapping" pattern is the most common approach among Qeasy customers: change once, propagate everywhere.

Implementation Steps

We recommend running this in three phases.

Phase one: incremental starting point. On Qeasy, pull materials modified in the last 7 days from Galaxy, then reconcile both sides to locate differences in code, unit, and spec fields. This step usually takes two or three iterations to clear out anomalies and is where hidden cost lives.

Phase two: full-volume trigger. Set create_start_time to 0, leave create_end_time empty, and run a complete full pull. Immediately afterward, reconcile code counts on both sides and sample 50 records for field consistency. Full pulls typically run during business off-peak hours (e.g., early morning).

Phase three: scheduling frequency. The source strategy's crontab is recommended as 0-59/3 7-22 * * *, i.e., every 3 minutes from 07:00 to 22:00. Since this strategy is read-only with zero write pressure, the frequency can be high; downstream write strategies can be throttled to business needs. This "incremental and full-volume dual-track" pattern is also the most common steady-state among Qeasy customers.

Lessons Learned

enable not hardcoded. The common pitfall is leaving the query parameter unfixed, so disabled records get mixed in and downstream writes fail. The safe approach: hardcode enable=1 in the Qeasy source; open a separate strategy if disabled materials need querying.
Timestamp unit mismatch. The Galaxy API expects seconds, not milliseconds. A typical mistake is passing milliseconds directly, which results in zero data returned.
Pagination edge. Galaxy's default page size is modest, but with 100k+ records, a single run without retries will drop the tail pages.
Forgetting to attach the downstream. Once this no-op write strategy is live, it is easy to mark it "done" and forget the downstream material sync. Explicitly declare "this strategy is the prerequisite of X" in Qeasy's strategy dependency settings.
Data permission toggle. If isdataperm flips from default false to true after an account upgrade, only partial materials will suddenly be returned. Pass false explicitly and add monitoring alerts.

Applicable and Non-applicable Scenarios

Applicable: first-time master data integration from ERP to MES or downstream systems, scenarios requiring stable replayable query chains, and any setup that will later host multiple write strategies.

Non-applicable: target systems requiring strong-consistency real-time writes (use change data capture or message queues instead), transactional business documents (use form sync rather than master data query).