Querying Liquor Products from Wangdiantong: An Incremental Pull Strategy Based on Last-Modified Time

What This Strategy Solves

In retail and supply chain integration scenarios, liquor SKUs are numerous, prices change frequently, and listing/deratification cycles move fast. A retail company outsourced e-commerce fulfillment to Wangdiantong, while finance and supply chain planning run on Yonyou BIP. This creates a foundational question: how do you reliably pull the latest changed liquor products from Wangdiantong on an incremental basis, so downstream master-data sync or reconciliation analytics can consume them? This strategy covers exactly that "source-side active query" segment: it does not write to a target system, it only fetches data from the source within a time window and lands it in the middle layer for downstream strategies to consume.

Data Flow and Field Mapping

The overall flow is Wangdiantong QiMen → Qeasy Data Integration Platform (middle layer) → downstream consumer strategies. The current strategy only covers the first two segments. The target side is a "no-op write," meaning the data is first shaped and stored in the platform before anything else happens.

Key field mapping (excerpted from source interface metadata):

One detail that is easy to overlook: source-side goods_no (business number) and goods_id (system primary key) must be kept separate. In our past projects, the typical mistake was collapsing both into one field, which made deduplication and incremental reconciliation extremely painful later on.

How to Configure on Qeasy

Open the new-strategy page on the Qeasy data integration platform, choose the "query-type strategy" template, and focus on three blocks:

1. Source platform: Select Wangdiantong QiMen, choose API wdt.goods.query, method POST. Set source number field to goods_no, id field to goods_id, and keep idCheck off — this strategy only pulls data, it does not perform a write-back check.
2. Request parameters: Bind start_time to the built-in variable LAST_SYNC_TIME, bind end_time to CURRENT_TIME, hardcode deleted to 0, leave barcode empty, and fix page_size to 100.
3. Target platform: Choose the Qeasy integration platform itself, select the "no-op write" API, turn idCheck on, and land the data in the platform's intermediate database first. This step may look redundant, but it actually gives downstream strategies a stable landing pad.

When we are on customer sites, what Qeasy is most often praised for is exactly this "land in the middle layer first, then distribute" pattern: coding mappings can be centrally managed, headers and line items can be processed in phases, and you are not immediately blocked by target-system interface constraints.

Implementation Steps

Roll out in three phases. Do not rush the cadence.

Phase 1: Initialize the incremental start point. Before the first run, manually specify start_time to a conservative historical timestamp (for example, the beginning of the month) and set end_time to the current time, to backfill baseline data. After this round completes, switch to normal incremental mode. Phase 2: Set the scheduling frequency. The crontab in the source material is */3 7-22 * * *, meaning every 3 minutes between 07:00 and 22:00 every day. Liquor stores change prices and listings most frequently during this window, so a 3-minute interval keeps the downstream-visible latency within an acceptable range. If the business operates 24 hours, expand the time window to full-day. Phase 3: Full pull triggers and routine inspection. Do not put full-pull logic into regular scheduling. Configure it as a separate manual task that does not run by default; it is only triggered manually by operations when there is a large category change or product migration. This is the very common "dual track of incremental and full pull" approach we see among Qeasy customers — steady state goes through incremental, special scenarios go through full pull, and the two never interfere with each other.

Pitfall Review

1. start_time is not initialized: On the first run, using LAST_SYNC_TIME directly produces an empty value, and the source may return full data or throw an error. The safe approach is to hardcode a historical time on first run, then switch to the variable after one successful pass.
2. end_time is written as a fixed value: To save effort, someone hardcodes end_time to 2099-12-31. It looks convenient, but if the source imposes a length limit on the time window, data will be truncated and you will silently lose records. Let the platform inject the current time on every run — that is the correct answer.
3. deleted default value gets changed: After changing deleted to 1, deleted dirty data mixes in, and downstream reconciliation shows a pile of "ghost SKUs." This is where things go wrong easily. The recommended practice is to lock the default at 0, and if needed run a separate cleaning task.
4. page_size is set too high: The source-side limit is 100. Setting it to 500 will cause the server to truncate or throw an error. The typical mistake here is "using the local test environment configuration," and the problem only surfaces after going live.
5. idCheck state is not differentiated between sides: It is correct to have idCheck off on the source side and on for the target side, but some teams turn both off, which loses idempotency, and reruns then create duplicates.

Applicable and Non-applicable Scenarios

Applicable: Scenarios that need incremental retrieval of product master data by time window for reuse by multiple downstream strategies; categories with high daily price-change frequency and low latency tolerance such as liquor, fresh produce, and 3C electronics. Not applicable: Scenarios that need real-time push (second-level), or where the source does not provide a last-modified-time field and change detection requires full comparison — those cases need a different strategy template.