Data Exchanges or a legacy ERP touchpoint: choose the right starting point
Start by naming the integration problem, then verify the current supported mechanism in a sandbox before committing to implementation structure.
In this guide
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 a one-page decision record for each flow. Capture the source event, destination, payload owner, authentication boundary, expected delivery timing, retry policy, operational owner, and reconciliation evidence. Separate a flow that accepts a customer order from a flow that proves the ERP completed it. That distinction prevents a storefront from promising completion when it only recorded an outbound request.
A legacy touchpoint can carry historical constraints that matter for an existing deployment. A Data Exchange path may be appropriate for a current supported capability. Neither label relieves the team from proving extension points, data transformations, and failure handling in the target environment.
This is an application-owned JSON contract for the project runbook and automation. Its field names are defined here; it is separate from Znode configuration and API request formats.
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"
}
}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
Implement the selected Znode extension as a thin adapter: accept its documented trigger, translate the supported payload into your command contract, and report its supported result. Keep retry scheduling, correlation, and ERP-specific transformations in the layer that owns those responsibilities.
The same delivery contract can help compare two mechanisms without assuming they have the same lifecycle. Record the actual trigger and completion semantics for each candidate. An ERP acknowledgement and a successfully dispatched request should remain separate states in code and in 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.