Event-Driven ERP Integration: Architecture That Holds Up

How to design event-driven ERP integration

1. 1Identify the events the business actually needs: sales order released, receipt posted, work order completed, item changed. Resist publishing every table change.
2. 2Find the ERP's native event source first: ION BODs on Infor, SAP business events through Event Mesh, Dynamics business events, Oracle Fusion business events, or a SuiteScript user event or workflow that calls out from NetSuite.
3. 3If no native source exists, capture changes with log-based CDC, or write events to an outbox table in the same database transaction as the business change and publish from it.
4. 4Publish to a broker with durable storage: Kafka, RabbitMQ, Azure Service Bus, AWS SNS/SQS or the vendor's own bus. Choose retention long enough to replay after a consumer bug.
5. 5Define a stable event contract with an ID, type, version, timestamp, entity key and a minimal payload. Prefer sending the key and fetching current state from the ERP when freshness matters.
6. 6Make consumers idempotent: store processed event IDs or use natural idempotency keys, so duplicate delivery never creates a second order or receipt.
7. 7Handle ordering explicitly. Partition by entity key where ordering matters, and use version or timestamp checks to discard stale updates.
8. 8Add a dead-letter queue, alerting on lag and a replay procedure, and test them before go-live.

The outbox pattern and why dual writes fail

-- Outbox table written in the same transaction as the business change
CREATE TABLE integration_outbox (
  event_id     UNIQUEIDENTIFIER PRIMARY KEY,
  event_type   VARCHAR(80)  NOT NULL,
  entity_key   VARCHAR(80)  NOT NULL,
  payload_json NVARCHAR(MAX) NOT NULL,
  created_at   DATETIME2 DEFAULT SYSUTCDATETIME(),
  sent_at      DATETIME2 NULL
);

Common pitfalls

• !Publishing from application code after the ERP commit. A crash between the two creates silent data loss; use an outbox or native events.
• !Treating row-level CDC as business events. Consumers then see half-complete transactions and must reconstruct meaning themselves.
• !Making the ERP callout synchronous. A slow external endpoint blocks users and can hit governance or timeout limits.
• !Assuming exactly-once delivery. Design every consumer for duplicates and out-of-order arrival.
• !Fat payloads that duplicate ERP state. Stale copies cause conflicts; send keys and fetch when freshness matters.
• !No dead-letter queue or lag alerts. Failures sit unnoticed until a department notices missing data.