WDT Real-Time Inventory to Xiaoman OKKICRM: A Single-Strategy Tutorial
What This Strategy Solves
A retail enterprise uses WDT for e-commerce fulfillment and Xiaoman OKKICRM for sales front-end and customer management. Both sides need to see "how much stock is available right now," but inventory is only updated inside WDT, so the CRM side is always looking at overnight numbers. After every promotion peak, customer service oversells and operations restock on instinct — the problems converge into a single incident.
We used the Qeasy Data Integration Platform to push real-time inventory from WDT into Xiaoman OKKICRM, so the front-end numbers stay roughly in sync with the fulfillment side.
Data Flow & Field Mapping
Flow: WDT Flagship Edition (B, source) → Qeasy middleware → Xiaoman OKKICRM (A, target), direction B_TO_A.
Key field mapping (typical shape, adjust to the real dictionary on-site):
| Business meaning | WDT (B, source) | Middleware mapping | Xiaoman OKKICRM (A, target) |
|---|---|---|---|
| Product code | sku_id | Routed via unified mapping table | product_code |
| Warehouse code | warehouse_no | Pass-through | warehouse_id |
| Available stock | available_qty | Pass-through | stock_available |
| Reserved stock | locked_qty | Pass-through | stock_reserved |
| Update time | modified_time | Converted to UTC string | update_timestamp |
| Sync batch | — | Generated by Qeasy | batch_id |
Centralized code mapping is a common Qeasy customer pattern: do not hard-code mappings inside every strategy. Build one "product / warehouse master mapping table" and let other strategies (materials, sales orders) reference it — so that changing one code does not require editing three lines.
How to Configure on Qeasy
- Source connector: pick the WDT Flagship Edition adapter; configure pull parameters for the real-time inventory endpoint (page size, incremental timestamp field); credentials are managed by the platform.
- Target connector: pick the Xiaoman OKKICRM adapter; confirm the stock write API (upsert by warehouse + product is the safe choice).
- Middleware mapping: on Qeasy's field-mapping canvas, create the mapping table that maps source fields to target fields; code-type fields reference the "unified mapping table."
- Filter & dedupe: deduplicate by the
warehouse_no + sku_idcomposite key to avoid push overlaps. - Failure handling: enable the platform's built-in exception queue — a single bad row should not block the entire batch.
Implementation Steps
Phased scheduling is another common Qeasy pattern. This strategy uses an "incremental-daily + full-daily" two-track design:
- Stage 1 — incremental baseline: use the strategy's go-live
modified_timeas the baseline; pull increments every 5–15 minutes. For first rollout, gray-launch on one warehouse, confirm numbers match, then expand. - Stage 2 — full reload: trigger a daily full reload during business off-peak (e.g., early morning) to backfill any updates missed during the day. Header/body staged — this strategy involves only one fact-type data ("stock values"), no line items, so it is far simpler than order-type strategies.
- Stage 3 — scheduling cadence: increments every 5–15 minutes, full reload once a day. During promotions / 618 / Double-Eleven, tighten increments to 1–3 minutes, but watch source-side rate limits.
Pitfall Recap
- Timezone trap: WDT timestamps carry local time, while Xiaoman OKKICRM expects UTC. This is a classic trap; the safe play is to normalize timezones in the Qeasy middleware before writing
update_timestamp. - "Zero stock" misread as deletion: some APIs treat zero stock as a delisting signal, so the target side gets wiped. Confirm the write semantics is "upsert current value," not "overwrite update."
- Missing warehouse dimension: the source pushes by physical warehouse, but the target aggregates by logical warehouse. Align both sides' warehouse ledgers before go-live — otherwise numbers will never match.
- First full reload overruns the target DB: the initial full reload was not batched, and the target write API was instantly overloaded. Configure pagination and rate-limiting on Qeasy and push in batches.
- No batch field set: post-incident investigation cannot tell which run a particular number came from. Add a
batch_idin the middleware and write it into a spare field on the target side for fast traceability.
Where It Fits and Where It Does Not
Fits: scenarios where WDT is the fulfillment master warehouse and available / reserved stock must be reflected in real time on the CRM side; multi-warehouse, multi-SKU businesses with frequent stock changes.
Does not fit: when WDT is used as the financial reconciliation source of truth (use a reconciliation strategy instead of real-time push); or when SKU scale is huge and second-level latency is required (you must evaluate source-side API throughput and rate limits first).