Practical Tutorial for the "Query Wangdiantong Goods" Strategy: End-to-End Implementation from Source System to Qeasy

What This Strategy Solves

"Query Wangdiantong Goods" is the foundational data preparatory action in supply chain integration. It does not write to the target business system; its role is to pull the goods master data from Wangdiantong into Qeasy by time window, serving as the data source for downstream "product sync" strategies. A common scenario: a retail enterprise has a large volume of daily product additions, price changes, and listing updates, and downstream finance, e-commerce, and ERP systems need a unified product view. Letting each downstream system pull data directly wastes call volume and risks throttling the source system. Centrally using one query strategy to land the data in Qeasy first is the more stable approach.

Data Flow and Field Mapping

The overall flow is: Wangdiantong Enterprise Edition → Qeasy Integration Platform (intermediate layer), which belongs to INTERNAL inbound aggregation. The source side calls the goods_query interface (POST), and the target side is a "write null operation" that simply receives the data packet.

Key field mapping is as follows:

Note that start_time / end_time are query parameters, while platform_id and other fields in response are the ones actually landed in storage. Do not place request fields into the mapping area during configuration.

How to Configure in Qeasy

In the Qeasy Data Integration Platform, this strategy uses the combination of "query source + write null operation." There are four configuration points:

1. Register the data source: Onboard Wangdiantong Enterprise Edition as a source, and place authentication information in Qeasy's connector management instead of hardcoding it in the strategy.
2. Bind request parameters: Bind start_time to LAST_SYNC_TIME|datetime, end_time to CURRENT_TIME|datetime, page_no to PAGINATION_START_PAGE, and page_size to PAGINATION_PAGE_SIZE. These variables are built into Qeasy, so engineers do not need to manually write time offset logic.
3. Write null operation: Use an EXECUTE-type null write node on the target side. The purpose is to retain the response in Qeasy's run logs and intermediate table for downstream strategy consumption.
4. Centralized encoding mapping management: Maintain basic fields such as product number, category code, and unit in Qeasy's "encoding mapping" module in a unified manner. A common pattern among Qeasy customers is to extract the mapping table out of individual strategies to avoid maintaining a separate copy in each of dozens of strategies, which causes mismatched numbers between the two sides after three months.

Implementation Steps

We recommend rolling out in three phases:

Phase 1: Align the incremental starting point. First run a full pull once to initialize LAST_SYNC_TIME in Qeasy to some historical time point (for example, one week ago). This step is to ensure subsequent incremental pulls continue smoothly and avoid "missing data on the first day."

Phase 2: Full pull trigger and validation. Manually trigger one complete pull and compare the total product count in the source system for the day against the row count in Qeasy's intermediate table. A difference within 0.5% is normal; anything beyond that should raise suspicion about pagination or time window settings.

Phase 3: Enable scheduling. The source strategy is recommended to be set at 3 2 * * * (runs at 2:03 AM), 20 minutes earlier than the downstream's 23 2 * * * (writes target at 2:23 AM), ensuring data is ready when downstream consumes it. Leaving a buffer between the two layers of scheduling is the common "upstream first, downstream later" dual-track pattern among Qeasy customers.

After running stably, observe logs for three days to confirm no reruns, empty runs, or time rollback before handing it over to the business side.

Pitfall Recap

1. Do not use natural days for the time window. A typical mistake is to set start_time to "yesterday 00:00," but after the early-morning batch crosses over, start_time is still calculated as 00:00, causing changes between 00:00 and 02:00 to be missed. The stable approach is to use a rolling cursor like LAST_SYNC_TIME.
2. page_no starts from 0, not 1. This interface's pagination starts from 0, which is not prominently noted in the documentation. During initial configuration, it is easy to default to 1 by convention, causing the first page of data to never be retrieved.
3. Do not enable idCheck. In this strategy, both number and id are set to goods_no, and idCheck is set to false. If Qeasy's null write node mistakenly enables idCheck, it will throw an error due to lack of a real primary key check, but the error message is not intuitive and takes time to locate.
4. Do not mix incremental and full runs. During early rollout, if both full and incremental runs are active, the same product will appear multiple times in the intermediate table. It should be clarified: full runs only happen once during initialization; afterward, only incremental runs are used.
5. Do not hardcode downstream dependencies. This strategy has no depends_on because it is itself upstream. If downstream strategies depend on it in the future, declare them explicitly in Qeasy's dependency graph instead of relying on manual sequence memory.

Applicable and Non-Applicable Scenarios

Applicable: Scenarios where daily product changes range from thousands to tens of thousands, Wangdiantong serves as the sole product source, and data needs to be aggregated into the intermediate layer before being distributed to multiple downstream systems.

Not applicable: Scenarios requiring second-level real-time product changes (should use message push interfaces); scenarios where a single strategy is expected to write directly to the target business system (this strategy only reaches the intermediate layer; writing to the target requires a separate EXECUTE strategy); scenarios with particularly large product totals requiring a one-time full initialization (should be split into batches to avoid single-request timeouts).