Overview: Integrating Xiaoman OKKI CRM with DingTalk Yida — 12-Strategy Master-Data Preload and Business Sync Orchestration

Scenario and Value

In one of our projects, a cross-border trading company ran its daily sales inside a CRM, while approvals and forms lived in DingTalk Yida (a low-code form platform). The result was two parallel 'product catalogues': the CRM kept a three-level product group hierarchy, while Yida forms only carried a single top-level category. Order owners showed up in the CRM with full names, but Yida forms only displayed employee IDs. During reconciliation, business users had to context-switch between the two systems based on memory. The worst moment came right after a promotional campaign: order statuses had already updated in the CRM, but Yida forms still read 'pending confirmation'.

This is not a bug in either system. It is a typical CRM-vs-low-code-form split: business documents must flow in both directions, master data needs on-demand lookups, and the lookup relationships cross both systems. This solution tackles exactly that combination — 'business document sync + master-data preload lookups' — by breaking the work into 12 well-defined strategies, orchestrating execution order explicitly, and turning code mapping and exception handling into a runnable operations SOP.

Integration Architecture and Data Flow

The architecture has three layers: source systems (Xiaoman OKKI CRM + DingTalk Yida), the integration platform (delivered on the Qeasy iPaaS / 轻易云 data integration platform), and target systems (DingTalk Yida forms + an internal hub on the platform itself). The integration platform does two jobs: write CRM business documents into Yida forms, and persist a set of 'master-data hubs' internally for downstream lookup.

There are two main data flows:

• Business flow (Xiaoman → DingTalk Yida): products, orders, and suppliers pass through field mapping and script completion before being written to Yida forms. Before writing an order, six hubs must supply usernames, exchange rates, product instance IDs, customer sources, and DingTalk user IDs.
• Master-data flow (bidirectional → internal hub): product groups, user mappings, and customer sources from Xiaoman, plus product instances, the current-month exchange rate, customer source platforms, and the user mapping table from Yida, are first written into the platform's internal 'master-data hubs', which then serve as lookup sources for the business strategies.

This 'precipitate first, consume later' pattern lets downstream business strategies simply ask 'which hub holds which value', without binding directly to the other side's real-time APIs. Network jitter and rate-limit pressure on business writes are isolated significantly.

Interface List

Implementation Essentials

Staged scheduling: Three stages are recommended. Stage 1 runs the 9 master-data preload strategies in parallel (product groups, user mappings, customer sources, product instances, exchange rate, user mapping table, etc.) with no inter-dependency. Stage 2 runs product sync and supplier sync in parallel. Stage 3 runs order sync, only after all dependent hubs are ready. Strongly-dependent strategies like order sync go last to avoid 'data arrived but lookup values empty' dirty writes.

Incremental and full sync: Daily operations run in incremental mode — products/orders/suppliers are pulled via start_time~end_time, while DingTalk Yida side uses modifiedFromTimeGMT~modifiedToTimeGMT. Timestamps are maintained centrally by the integration platform as LAST_SYNC_TIME. Initialization or data repair removes the time filter and runs full sync, with target-side idempotency enforced on business keys (product_no, order_no, supplier_id).

Centralized code mapping: Seven categories of mappings — product codes, product instance IDs, top-level category (based on a two-step group_id→parent_id→name lookup), user nicknames, DingTalk user IDs, current-month exchange rate — are unified in the hub and completed by AfterSourceInvoke / AfterTargetGenerate scripts before write. On a miss, the record is skipped and routed to the failure table with an alert, rather than silently persisting empty values.

Retry and alerting: API timeouts and 5xx errors retry 3 times with exponential backoff (30s/60s/120s); 429 rate-limit responses retry 2 times with a fixed 60s interval; 4xx validation failures do not retry and go directly to the dead-letter table; code-lookup failures skip the single record rather than failing the whole batch. Recommended alert thresholds: any single strategy failing ≥3 times consecutively is critical; daily failure rate >5%, data latency >2 schedule cycles, and code-mapping hit rate <95% are warnings.

Privacy and credentials: Connection strings, API keys, and userId-style sensitive configurations all go through environment variables or a secret-manager service. Real tenant names, account-set numbers, and authentication information never appear in design documents or logs.

Best Practices and Post-mortem Notes

• 'Header and detail written in separate stages': In order sync, the product detail is the line-item body, while the order owner and exchange rate are header attributes. Pushing the entire order in one shot easily produces 'header rate already carried over, but line-item product instance ID not yet looked up' situations. The safe approach is to preload the detail-related master data via strategies 7/8 first, then let the order strategy pull and assemble them uniformly.
• 'Centralized code mapping': Once the seven mapping categories are scattered across the 12 strategies, adding a new product category means editing scripts everywhere. The recommended approach is to maintain mappings centrally at the hub layer, have business strategies only 'read', and make changes only at the hub entry — this is exactly the 'master-data hub' pattern we see most often on customer sites running Qeasy (轻易云数据集成平台).
• 'Order detail accumulation and variance check': After order sync, use the AfterTargetGenerate hook to run a variance check between accumulated line-item quantity/amount and the header's receivable product amount. If the variance exceeds a threshold, route to the failure table instead of writing success. A common mistake is checking only the row count, not the amount — letting freight and tax-definition differences write dirty data silently.
• 'No-op strategies as placeholders': Strategies 10/11/12 are currently 'no-ops' (data lands in the hub only, no target-system write). The strategy IDs are reserved so the Yida-side master data can later be persisted in a unified store, instead of being fetched ad-hoc inside the business flow — avoiding two parallel data sources hanging off the business chain.
• '429 rate-limit needs channel separation': The Yida open APIs are sensitive to rate limiting. Business-side and master-data-side traffic should be scheduled at offset windows, so they do not converge in the same window and trigger throttling.

When to Choose Qeasy

If your scenario is 'multiple business systems requiring long-term, stable business-document sync, with strong reliance on master-data lookups', the Qeasy iPaaS (轻易云数据集成平台) is worth placing on the shortlist. Its master-data hubs, staged orchestration, centralized code mapping, per-strategy/per-time-range manual reruns, and dead-letter + alerting pipeline are all out-of-the-box. A 12-strategy scheme like this is typically orchestrated and integration-tested live within 1–2 days.