Qeasy Cloud
Get Started

Marketing Cloud and ERP Supply Chain Integration: A 66-Strategy Multi-Entity Closed-Loop Practice

· 冯潇· Integration Solutions· 15 views· 5 min read
汤臣倍健营销云金蝶云星辰供应链集成营销云轻易云多业务主体编码映射

Scenario and Value

In a real project for a nutrition and health brand, the marketing cloud handled front-end orders and channel flows, while the cloud ERP took care of back-end inventory and financial accounting—each system owned its own silo. A typical pain point showed up right after a promotion: outbound orders existed in the marketing cloud, but the corresponding sales outbound vouchers in the ERP kept lagging. Purchase inbound and return documents were scattered across multiple business entities, and manual reconciliation only revealed the gaps on the third day after the campaign. The root cause was not slow data capture in either system, but the absence of an automated cross-system closed loop—orders, shipments, inbound, returns, and inventory writeback all lived in isolation.

This implementation covered 5 business entities and 66 integration strategies, spanning customer/material/warehouse master data, sales outbound, purchase inbound, return inbound, warehouse transfers, inventory writeback, and connector maintenance. The single goal was to keep the marketing cloud and the ERP in real-time consistency at both master data and document levels, and to alert automatically on exceptions without blocking the main pipeline.

Integration Architecture and Data Flow

The overall architecture has four layers: source system (marketing cloud), target system (Kingdee Cloud Xingchen), integration orchestration layer (implemented on the Qeasy Data Integration Platform), and monitoring/Ops layer.

The data flow progresses in four phases:

  • Phase 1 Master Data Sync (Strategies 1~18): First pull customers, materials, and warehouses from the ERP to build code mappings; then sync master data to the marketing cloud by business entity, with warehouse transfer documents written directly to ERP transfer documents.
  • Phase 2 Business Document Sync (Strategies 19~48): Sales orders are split into 10 outbound-document strategies by business entity, with 10 return strategies and 10 purchase inbound strategies, all pushing audited documents incrementally.
  • Phase 3 Connector Refresh (Strategies 49~52): Credentials for 4 account sets (new, legacy, Hangzhou Yibeisheng, Hangzhou Youbaijia) are refreshed periodically to avoid 401 interruptions.
  • Phase 4 Validation and Ops (Strategies 53~66): Full validation of mapping table consistency, dead-letter queue retries, document status writeback to the marketing cloud, inventory reverse sync to the marketing cloud, and overall health check.

Interface List

Strategy RangeData ObjectSync DirectionNotes
1~3Customer/Material/Warehouse QueryERP → Mapping TableQUERY_ONLY, builds code mappings
4~8Warehouse TransferMarketing Cloud → ERPSplit by 5 business entities
9~13Customer Master DataERP → Marketing CloudSplit by 5 business entities
14~18Material Master DataERP → Marketing CloudSplit by 5 business entities
19~28New Order → Sales OutboundMarketing Cloud → ERPSplit into 10 entity combinations
29~38Return InboundMarketing Cloud → ERPSplit by business entity
39~48Purchase InboundMarketing Cloud → ERPSplit by business entity
49~52Account Set Credential RefreshSystem-levelEvery 2 hours
53~57Mapping Validation / DLQ RetryBidirectionalDaily 02:00
58~60Document Status WritebackERP → Marketing CloudOutbound/Purchase/Return
61~65Inventory QuantityERP → Marketing CloudBy 5 business entities
66Integration Health CheckSystem-levelDaily 02:00

Implementation Points

Phased scheduling. Master data runs every 20~30 minutes, business documents every 10 minutes, full validation and health check at 02:00 daily, connector refresh every 2 hours. Stagger base and business document runs to avoid exhausting interface quotas in the same time window.

Incremental plus full sync. Daily operation is incremental, filtered by update_time / LAST_SYNC_TIME; full sync runs on first deployment or data repair; master data recommends a daily full validation as a safety net.

Centralized code mapping management. Six mapping types (customer, material, warehouse, supplier, unit, business entity) live in a unified mapping table. All write strategies must only read from this table—hardcoding mapping values inside a strategy is a common pitfall: when master data changes, that strategy will fail silently.

Business entity pre-filtering. All strategies filter by org_code at the entry point, processing only the current entity's data to avoid cross-entity contamination.

Tiered exception retry. Token expiration (401) triggers connector refresh then retries once; network timeout retries 3 times with 30s/60s/120s exponential backoff; missing code mapping is logged and skipped without blocking downstream data; target system rate limiting pauses and alerts when over threshold.

Document status writeback. After ERP audit completes, write the status back to the marketing cloud so front-end business sees "completed". This step is key to the closed loop and is often overlooked.

Privacy handling. The solution contains no real customer names, account set IDs, or credential secrets; all company entities are referenced by business codes (ORG_xxx).

Best Practices and Pitfall Recap

  1. Header and body written in stages. Do not write the entire order document into the ERP at once. The reliable approach is to write the header first to obtain the ERP document number, then write the body lines, and finally write the status back to the marketing cloud. Any failure in between has a clear rollback point.

  2. Split by entity rather than merging strategies. We once tried to merge 5 business entities into one strategy with parameter switching, but upstream field differences got masked and troubleshooting was painful. The final design splits them into 5~10 independent strategies, each serving one entity or one entity combination—scheduling and retry become much more controllable.

  3. Separate connector refresh from credential rotation. Do not embed Token refresh logic inside business strategies. Use independent REFRESH-type strategies on Qeasy that run every 2 hours; business strategies only consume the latest credentials.

  4. Dead-letter queue is mandatory. A single record failure should not block the entire batch; failed records enter a dead-letter queue handled by an independent RETRY strategy, with manual intervention only on the DLQ.

  5. Inventory writeback must carry entity filter. When ERP inventory is reverse-synced to the marketing cloud without an org_code filter, it will pull inventory from other entities, causing oversell or stockout illusions on the front end.

When to Use Qeasy

When the supply chain involves multiple business entities, spans ERP/CRM/marketing cloud, requires flexible per-entity scheduling while preserving manual fallback channels, Qeasy Data Integration Platform provides unified capabilities from mapping table management and scheduling orchestration to dead-letter queue—converging 66 strategies' dependencies and exception handling into one workflow for Ops, eliminating manual chaining across multiple scripts.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/solutions/sol-p158a24-kingdee-cloud-4452

Comments