A CRM-to-ERP webhook needs acceptance tests for failures and redelivery. The aim is to preserve accepted work, avoid duplicate orders, and prevent older data from overwriting newer state. Test the behavior of the complete workflow, including recovery after an interrupted attempt.
Separate event identity from business identity
An event ID identifies a change; a business ID identifies an order or customer. One order can have several legitimate changes. Verify the sender's identifier contract and scope deduplication keys by source and account. Do not suppress every update simply because it refers to an existing order.
Persist accepted work before acknowledging it
Verify signatures using the provider's documented method, preserving the raw request body where required. Enforce signature freshness where the protocol supports it. Reject requests with invalid signatures before business processing.
Persist the event key, payload, and pending status in one transaction with a database uniqueness constraint. This durable inbox can serve as the worker's queue. Return an acknowledgement, or HTTP 2xx ACK, only after the transaction commits. If persistence fails, do not report successful acceptance. An in-memory flag is insufficient.
Hypothetical acceptance cases
The identifiers and expected outcomes below are illustrative, not client results. Run these cases in a test environment.
- Concurrent duplicates. Deliver E101 three times for order O42. Pass when there is one accepted job and one ERP order. Also send E102 for the same create-order operation on O42: there must still be one order.
- Failure during acceptance. Make the queue transaction fail, then redeliver after connectivity returns. Also restart the worker after an ACK. Pass when accepted work survives and is processed.
- Failure after the ERP saves. Stop the worker before it records completion. On recovery, reuse the same operation key supported by the ERP's idempotency mechanism, or a reference protected by ERP-enforced uniqueness. Reconcile the ERP record ID. If the outcome remains uncertain, assign it for investigation instead of blindly creating another order.
- Out-of-order updates. Deliver version 8 of O42 before version 7. Pass when an atomic version check at write time prevents version 7 from overwriting version 8, while version 9 can still update it. If the source lacks reliable versions, retrieve current authoritative state or route the change for reconciliation.
- Errors and forged requests. Simulate ERP 429 and 503 responses; send invalid data and invalid signatures. Retry transient failures with increasing delays, random jitter, and a retry limit; honor Retry-After when supplied. Route business-processing failures requiring intervention to a failed-work queue with an alert and an assigned owner.
Capture acceptance evidence
Record event IDs, business IDs, attempt counts, processing states, ERP IDs, and reconciliation results. Mask sensitive data. Test replay after correcting a failure. For document-based input, see our related guide to testing AI quotation extraction before ERP entry.
Frequently asked questions
Does HTTP 200 mean the ERP has been updated?
No. In this design, it confirms durable acceptance. Track processing separately to establish whether the ERP update completed.
Can this guarantee exactly-once processing?
There is no universal guarantee. Duplicate protection depends on the ERP mechanism, key retention periods, and replay rules.
To discuss an acceptance test scope, contact Viet Nis – IT On Cloud or call +84 888 728 730.
Leave a Reply