Integration Solution Overview: Lemeng to DingTalk Master Data Sync

Scenario and Value

On a real engagement we ran into this: operations staff entered supplier settlement documents in Lemeng, then finance had to manually re-enter the same record into a DingTalk export form, slowing approvals and inviting mistakes. When supplier master data changed, it had to be edited in both systems. The problem was not the data entry itself — it was the lack of a closed loop. Once upstream master data moves, downstream approvals should follow automatically.

This solution treats Lemeng as the single source of truth for master data and pipelines supplier records and supplier settlements into DingTalk approval flows, creating a stable channel between the upstream business system and downstream OA. Three concrete values: less duplicate entry and manual reconciliation, alignment between approval documents and upstream data for traceability, and a governable, monitorable flow of master data changes into the workflow system.

Integration Architecture and Data Flow

The architecture is the classic three-stage model: source system → integration platform → target system. In our work we use the Qeasy iPaaS platform (轻易云数据集成平台) as the carrying layer.

┌──────────────────────────────┐
│  Lemeng (business/supply chain) │
│  Supplier master, supplier settlement │
└──────────────────────────────┘
              │
              ▼
┌──────────────────────────────────────────────┐
│  Qeasy iPaaS (ETL / sync engine)              │
│  Incremental & full pull · field mapping ·    │
│  bank field normalization · retry · DLQ ·     │
│  scheduling orchestration                     │
└──────────────────────────────────────────────┘
              │
   ┌──────────┴──────────┐
   ▼                     ▼
┌──────────────┐  ┌──────────────────────────┐
│ DingTalk export │  DingTalk OA approval       │
│ form instance   │  supplier approval flow     │
└──────────────┘  └──────────────────────────┘

The data flow runs in two phases. The first phase pushes supplier master data into DingTalk OA approval, establishing the precondition that "the supplier exists upstream" for downstream settlement documents. The second phase pushes supplier settlements into the DingTalk export form approval. Both phases are implemented as independent sync strategies on Qeasy, with no hard dependency, but they are triggered in a staggered sequence.

Interface List

Implementation Notes

Staged scheduling: The supplier strategy runs every 15 minutes on the hour; the settlement strategy runs 2–5 minutes later (for example, supplier at minute 0, settlement at minute 5). There is no hard dependency, but staggering avoids transient concurrency on the DingTalk side that triggers throttling.

Incremental fields and full-sync fallback: Incremental pulls use audit time or document creation time plus date_from / date_to. On first go-live or data repair, switch to full sync by removing the time filter and rely on idempotent writes at the target side. LAST_SYNC_TIME is maintained by the platform and advanced after each successful sync.

Field mapping: Most fields are direct mappings on primary keys, codes, names, dates, and amounts. Bank-related fields (opening bank, bank account, account name, bank category) require script-based normalization — for example, mapping Lemeng bank names to the categories recognized by DingTalk form controls, and deriving business flags such as "is Agricultural Bank of China" from source fields.

Retry handling: API timeouts and 5xx errors follow exponential backoff (30s / 60s / 120s) for three attempts; rate-limit 429 responses wait 60s and retry up to five times. Script exceptions are logged separately, and individual failures are isolated into a dead-letter table that can be rerun by strategy or by time window.

Data privacy: Bank account numbers, account holder names, and similar fields are sensitive. Mask them at the transport and storage layer and apply role-based access control. DingTalk-side processCode and originator_user_id should come from configuration or environment variables rather than being hard-coded in strategies.

Best Practices and Lessons Learned

1. Master data first, settlements second. A common failure is pushing settlement documents before the supplier master has landed in OA. Approvers then cannot find the supplier code in the dropdown and have to fill it in manually. The safe approach is to treat the supplier strategy as upstream gating and schedule it before the settlement strategy.
2. Do not pass bank fields through directly. A single opening-bank field in Lemeng often mixes three semantics — "is Agricultural Bank of China," bank category, and opening bank name. Passing the raw string leaves approvers confused. A typical mistake is collapsing all three into one string field. Split them in a script and manage the conversion rules centrally in Qeasy's mapping layer.
3. Staggered scheduling is not optional. When both strategies fire at minute 0, the DingTalk approval API tends to throttle around month-start and quarter-end. In our setup we put the supplier strategy at minute 0 and the settlement strategy at minute 5, which visibly smoothed out peak load.
4. Full sync fallback must be idempotent. On first go-live or data repair, a full backfill without dedup logic at the target produces duplicate approval instances. Make sure writes on the DingTalk side dedupe by document number and that idempotency is enabled on the platform.
5. Centralize sensitive field handling. Mask bank accounts and account holder names at the platform layer with role-based access control, rather than scattering ad-hoc handling across individual strategies.

When to Use Qeasy

When an enterprise needs to reliably pipe supplier master data and settlement documents from its business system into DingTalk OA and approval flows, but does not want to maintain its own scheduling, retry, field mapping, and dead-letter logic, the Qeasy iPaaS platform (轻易云数据集成平台) provides an out-of-the-box ETL engine, visual mapping, centralized code and script management, and per-strategy exception isolation — a fit for "master data + approval documents" multi-source to OA integration scenarios.