Data Exchanges or a legacy ERP touchpoint: choose the right starting point
Document one integration flow's trigger, ownership, delivery rules, and recovery needs before choosing its supported Znode mechanism.
In this guide
- Business event
- Decision record
- Data Exchange evaluation
- Legacy touchpoint evaluation
- Synthetic sandbox
- Approved implementation path
Do not choose from product names alone
Integration discussions often begin with a request to connect an ERP, but the needed behavior may be product import, inventory synchronization, price retrieval, order delivery, status readback, or scheduled reconciliation. These flows have different direction, timing, ownership, error handling, and operational needs. Naming the required business event first is more useful than assuming one connector label covers every case.
Current vendor materials describe Data Exchanges and legacy ERP connector setup as separate subjects. Treat that distinction as a prompt to investigate, not as evidence that either option fits a particular storefront. The final design depends on the chosen Znode release, licensed capabilities, deployed hosting model, integration direction, and the external system's contract.
- What business event starts the flow?
- Is the flow command delivery, data import, read-through query, or reconciliation?
- Which system owns the authoritative result?
- What should happen after timeout, duplication, rejection, or partial completion?
Use a decision record
Create one decision record for each integration flow. The example describes an accepted commerce order being sent to an ERP. Commerce owns whether it accepted the order; the ERP owns whether it accepted that order for fulfillment. Record both events so a successful dispatch cannot be mistaken for completed fulfillment.
The JSON is a project runbook format, not Znode configuration. Fill requiredEvidence from the installed extension contract, actual trigger, and hosting requirements. Leave the mechanism undecided until that evidence identifies the supported path.
order-delivery-decision.json json
{
"flow": "accepted-order-to-erp",
"trigger": "commerce-order-accepted",
"direction": "outbound-command",
"authorities": {
"orderAcceptance": "commerce",
"fulfillmentAcceptance": "erp"
},
"mechanismDecision": {
"candidates": [
"data-exchange-custom-processor",
"legacy-erp-touchpoint"
],
"requiredEvidence": [
"installed-extension-contract",
"configured-trigger",
"supported-hosting-model"
],
"selectionOwner": "integration-lead"
},
"identity": {
"logicalKeyFields": [
"storeCode",
"orderReference",
"operation"
],
"reuseKeyAcrossRetries": true,
"receiverRequiresAtomicDeduplication": true
},
"outcomes": {
"accepted": "await-erp-acknowledgement",
"rejected": "stop-and-route-to-operations",
"timeout": "reconcile-before-redelivery",
"duplicateWithSamePayload": "return-prior-result",
"duplicateWithChangedPayload": "reject-conflict"
},
"operations": {
"retryOwner": "delivery-worker",
"maximumAutomaticAttempts": 3,
"reconciliationOwner": "integration-operations",
"customerStatusBeforeAcknowledgement": "received"
}
}Read the timeout rule as a recovery instruction: look up whether the ERP saved this order before sending it again. The same logical key must identify every retry. If the same key arrives with changed order data, the receiver should reject a conflict rather than treat it as a second order. The integration lead chooses the mechanism; the delivery worker and operations owner have separate recovery responsibilities.
Build a deliberately small sandbox
Before writing a production adapter, create a clean sandbox with synthetic records and a mock receiver. Exercise one supported flow end to end using current vendor documentation. Record the installed versions, required configuration, exact trigger, request shape, observable status, and cleanup behavior. Keep credentials outside sample code and never use a production endpoint to discover a contract.
The sandbox should force difficult outcomes: receiver rejection, response lost after receiver commit, duplicate dispatch, expired credentials, and a temporary service outage. If the mechanism cannot make those states observable, define a reconciliation process before production planning. An unobservable retry is a business risk, not merely a logging issue.
- Confirm the actual configured trigger rather than inferring it from code names.
- Verify authorization and server-owned routing.
- Capture only sanitized identifiers in diagnostics.
- Stop when documentation and observed behavior disagree, then seek vendor clarification.
Keep the adapter boundary small
Keep the selected Znode extension small. Receive its documented event, translate its payload into your order-delivery model, and return the result expected by that extension. Put ERP-specific field mapping, retry scheduling, and reconciliation in the services responsible for them.
For each candidate mechanism, record what starts it and what its success response proves. 'Request dispatched' and 'ERP acknowledged' are different facts even when the same connector handles both. Keep those facts separate in code and the operations view.
Sandbox checklist
Test the exact supported contract in a disposable sandbox before building a production adapter. Preserve screenshots and traces only after removing tenant identifiers, endpoints, tokens, payloads, and operational data. Recheck the integration when vendor terminology or extension documentation changes.
- Current product documentation reviewed.
- One synthetic success and each defined failure state observed.
- Retry and reconciliation ownership approved.
- Security and operational review completed.
References and further reading
Bring your next engineering question.
Planning an ERP integration or recovery path?
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.