Practical Guide: Hand-Priority Sync Strategy for Jushuitan Sales Orders (Qimen) to MySQL
What This Strategy Solves
A retail enterprise runs Jushuitan Qimen for online sales and a MySQL data warehouse for downstream analytics. Occasionally, a historical sales order is modified upstream and must be re-synced out-of-band—regular scheduled jobs cannot handle such urgent cases within the required window. The hand-priority (manual override) strategy is designed for these controlled, low-frequency, fully traceable scenarios: it preserves the stability of automated batches while letting operators actively trigger sync for specific orders.
Data Flow and Field Mapping
Overall flow: Jushuitan Qimen (source) → Qeasy data integration platform (middleware, handling protocol conversion, deduplication, and field standardization) → MySQL (target).
Key field mapping (excerpt):
| Business meaning | Jushuitan Qimen | MySQL target table |
|---|---|---|
| Order number | io_id / so_id | order_no |
| Shop code | shop_id | shop_code |
| Order time | order_time | created_at |
| Consignee | receiver_name | consignee |
| SKU code | sku_id | sku_code |
| Quantity | qty | qty |
| Order amount | total_amount | amount |
| Status | status | order_status |
Code mapping (shop codes, SKU codes, order status) is the most error-prone area in such projects. A common on-site pattern is to maintain all mapping rules in a single dedicated mapping table inside Qeasy—the source pushes raw codes, the target only references normalized values—so you don't repeat if/else logic in every business table.
How to Configure in Qeasy
- Register source and target connections: Connect Jushuitan Qimen (via the Qimen gateway) and the target MySQL; credentials are stored in the platform's secret vault and never appear directly in the strategy.
- Build the middleware data flow: Create a new data flow in Qeasy named "Jushuitan sales orders to MySQL" using the hand-priority trigger mode—do not attach a regular crontab; instead, expose a manual trigger entry that accepts the specific order number passed in by the operator.
- Field mapping and cleansing: Complete the one-to-one mapping in the visual panel; normalize date, numeric, and status-enum formats; enable a deduplication key (order number + shop code).
- Write strategy: The target table uses "UPSERT by primary key" rather than DELETE-then-INSERT, ensuring idempotency and preventing concurrent overrides.
- Logging and lookup: Enable Qeasy's per-record execution log, capturing source order number, write time, and affected rows for post-event verification.
Implementation Steps
Phase 1: Confirm the manual entry point and permissions Agree with the business side: use this strategy only for three scenarios—upstream modification of historical orders, data repair, and audit backfill. Daily incrementals still go through another scheduled strategy (the regular sales-out sync with sequence B) to prevent the two pipelines from competing.
Phase 2: Establish the incremental starting point Before first use, define the unique key on the MySQL target as (shop_code, order_no), inventory the current maximum order number, and use it as the starting point for any backfill.
Phase 3: Trigger full backfill (optional) If historical data is missing, the operator can manually trigger a batch of hand-priority jobs once to backfill order by order; switch to on-demand triggering afterward.
Phase 4: Daily on-demand scheduling Hand-priority itself has no automatic frequency—trigger timing is human-driven. However, define a response SLA (e.g., complete within 2 hours of ticket submission) and tag every trigger with the ticket number inside Qeasy for traceability.
Lessons Learned
- Don't let hand-priority and regular incrementals share the same staging table: On one project, both strategies wrote to the same staging table, causing deduplication key conflicts—the later manual run re-pulled orders that had already been loaded. The safe approach is to route hand-priority through a dedicated channel and check the target primary key before writing.
- Status fields must be normalized via mapping: Jushuitan returns Chinese status codes; the MySQL analytics table uses enum values. Without mapping, you'll have "Shipped" and "SHIPPED" coexisting, and reports will not reconcile after three months.
- Watch amount precision: Jushuitan returns amounts in cents, but the MySQL column stores yuan. Forgetting to divide by 100 in the mapping layer causes thousand-fold errors.
- The idempotency key must include shop code: The same order number can exist independently across shops; using only the order number leads to false positives.
- Tag every manual run: Add a
sync_sourcecolumn (e.g.,CRON/MANUAL) to the target table so you can later tell which pipeline wrote each row—troubleshooting becomes much faster.
When to Use and When Not to
Use when: upstream occasionally modifies data that needs backfill, single-order repair or audit backfill is required, latency tolerance is high but traceability is mandatory. Do not use when: high-frequency real-time sync is needed (use the regular incremental strategy), bulk backfill during peak promotions (hand-priority is inefficient and easy to miss), or the source has no primary key / the order status is non-idempotent.