ERP Integration Patterns
Why ERP integration is unavoidable
Section titled “Why ERP integration is unavoidable”Commerce handles the customer-facing transaction, but the business runs on ERP. Inventory levels, customer credit limits, contract pricing, order fulfillment, invoicing, and financial reporting all live in systems like SAP, Microsoft Dynamics, Oracle, or NetSuite. Without integration, your storefront and your back office operate on different versions of the truth. Customers see stale inventory. Orders require manual re-entry. Pricing drifts between systems.
Optimizely Commerce provides event-driven and API-based integration points designed for ERP connectivity. The challenge is not whether to integrate, but how — and the pattern you choose determines your data freshness, system resilience, and operational complexity.
What data flows between Commerce and ERP
Section titled “What data flows between Commerce and ERP”Integration is bidirectional. Some data originates in the ERP and flows into Commerce. Other data originates in Commerce and flows back.
| Data | Source of truth | Direction |
|---|---|---|
| Product master data | ERP | ERP to Commerce |
| Inventory levels | ERP / Warehouse | ERP to Commerce |
| Contract pricing | ERP | ERP to Commerce |
| Customer accounts | ERP (often) | ERP to Commerce |
| Orders | Commerce | Commerce to ERP |
| Payment status | Commerce | Commerce to ERP |
| Shipment tracking | ERP / 3PL | ERP to Commerce |
| Returns / Credits | Both | Bidirectional |
Identifying the source of truth for each data type is the first and most important step in integration design. When two systems both believe they own the same data, conflicts are inevitable.
Sync patterns: real-time vs batch
Section titled “Sync patterns: real-time vs batch”The two fundamental integration approaches offer different trade-offs.
Real-time (event-driven)
Section titled “Real-time (event-driven)”Commerce publishes events (order placed, payment captured, return requested) that trigger immediate sync to the ERP. The ERP can also push changes (inventory updated, price changed) to Commerce through webhooks or API calls.
Advantages:
- Customers see current inventory and pricing
- Orders appear in ERP within seconds
- Problems surface immediately
Disadvantages:
- Requires both systems to be available simultaneously
- Network latency affects storefront performance if sync is inline
- High-volume spikes can overwhelm the receiving system
Batch (scheduled)
Section titled “Batch (scheduled)”A scheduled job collects changes since the last run and syncs them in bulk. Batch jobs might run every 5 minutes, every hour, or overnight depending on the data type.
Advantages:
- Tolerates temporary system outages
- Handles high volumes efficiently
- Does not affect storefront performance
Disadvantages:
- Data staleness — inventory shown to the customer may not reflect the latest warehouse state
- Larger error batches to diagnose when something fails
- Delayed order visibility in ERP
The hybrid approach
Section titled “The hybrid approach”Most production integrations use both patterns. Orders sync in real-time because timely fulfillment matters. Inventory syncs in near-real-time batches (every 5-15 minutes) to balance freshness with performance. Product master data syncs in nightly batches because it changes infrequently.
| Data type | Recommended pattern | Typical frequency |
|---|---|---|
| Orders | Real-time event | Immediate on order completion |
| Inventory | Near-real-time batch | Every 5-15 minutes |
| Pricing | Scheduled batch | Hourly or on-demand |
| Product data | Scheduled batch | Nightly or on catalog publish |
| Customer data | Event-driven or batch | On account creation or nightly |
Conflict resolution
Section titled “Conflict resolution”When two systems modify the same data, conflicts arise. A customer updates their address in Commerce while a service agent updates it in the ERP. Which change wins?
Common conflict resolution strategies:
Last-write-wins. The most recent change overwrites the other. Simple but dangerous — you can lose intentional changes.
Source-of-truth-wins. The designated source of truth always overwrites the other system. If the ERP owns customer data, Commerce changes are treated as suggestions that get overwritten on the next sync.
Merge with review. Conflicting changes are flagged for manual review. A queue of conflicts lets an operator decide which change to keep. This is the safest approach but adds operational overhead.
Field-level resolution. Different fields have different owners. The ERP owns the billing address. Commerce owns marketing preferences. Changes to each field follow its owner’s authority.
Data mapping
Section titled “Data mapping”Commerce and ERP systems rarely use the same data structures. A Commerce “variant” maps to an ERP “SKU item.” A Commerce “order” maps to an ERP “sales order” with different field names, required fields, and validation rules.
Data mapping involves:
- Field mapping — Which Commerce field corresponds to which ERP field
- Value transformation — Converting between data formats (dates, currencies, units of measure)
- Default values — Filling in ERP-required fields that Commerce does not capture
- Validation — Ensuring mapped data meets the target system’s constraints before sending
The integration layer
Section titled “The integration layer”Place mapping logic in a dedicated integration layer — not in Commerce and not in the ERP. This middleware (whether a custom service, an integration platform like MuleSoft or Azure Logic Apps, or a message queue) handles:
- Receiving events or pulling batch data from Commerce
- Transforming data to the ERP’s expected format
- Delivering data to the ERP
- Handling errors, retries, and dead-letter queues
- Logging all sync activity for auditing
This separation means changes to the ERP schema do not require Commerce deployments, and vice versa.
Error handling and resilience
Section titled “Error handling and resilience”ERP integrations fail. Networks go down. ERP systems have maintenance windows. Commerce must continue operating when the ERP is unavailable.
Design principles for resilient integration:
- Queue-based delivery — Use message queues between Commerce and ERP so orders are not lost during ERP downtime
- Retry with backoff — Failed sync attempts retry with increasing delays rather than hammering the unavailable system
- Dead-letter handling — Messages that fail after all retries go to a dead-letter queue for manual investigation
- Circuit breaker — If the ERP is consistently failing, stop sending requests and alert operations rather than queuing up thousands of failed attempts
- Compensating transactions — If an order syncs to the ERP but the ERP rejects it, Commerce needs a process to handle the rejected order (cancel, hold for review, or retry with corrections)
Monitoring and observability
Section titled “Monitoring and observability”Integration health requires active monitoring. Track these metrics:
- Sync latency — Time between a Commerce event and its appearance in the ERP
- Error rate — Percentage of sync attempts that fail
- Queue depth — Number of unprocessed messages waiting for sync
- Data freshness — Age of the last successful sync per data type
Set alerts on thresholds. A queue depth that grows steadily indicates the ERP cannot keep up. A spike in error rate might signal a schema change or network issue.
1. An architect is designing ERP integration for a high-traffic storefront. Inventory changes frequently and orders must appear in the ERP quickly. What sync pattern should they use?
The hybrid approach matches sync frequency to data sensitivity. Orders need immediate sync for fulfillment. Inventory needs frequent but not inline sync to avoid storefront performance impact.
The hybrid approach matches sync frequency to data sensitivity. Orders need immediate sync for fulfillment. Inventory needs frequent but not inline sync to avoid storefront performance impact.
Review this topic →2. During ERP downtime, customers continue placing orders on the storefront. What architecture prevents order loss?
Message queues decouple Commerce from the ERP. Orders queue up during downtime and process automatically when the ERP is available again.
Message queues decouple Commerce from the ERP. Orders queue up during downtime and process automatically when the ERP is available again.
Review this topic →3. A customer updates their address in Commerce while a service agent updates the same address in the ERP. Which conflict resolution strategy avoids data loss while minimizing manual work?
Designating the ERP as source of truth for customer data provides a clear, automated resolution rule. Commerce changes are overwritten on the next sync, keeping one consistent record without manual review overhead.
Designating the ERP as source of truth for customer data provides a clear, automated resolution rule. Commerce changes are overwritten on the next sync, keeping one consistent record without manual review overhead.
Review this topic →