Integration flows fail. Networks drop, downstream APIs time out, payloads arrive malformed. The difference between a fragile integration and a production-grade one usually comes down to how the REST Adapter handles errors.
Why default error handling isn’t enough
Out of the box, OIC surfaces a fault when a REST call fails — but without explicit handling, that fault can cascade unpredictably: silent retries that duplicate records, or failures that go unnoticed until a business user reports missing data days later.
Three things every resilient integration needs
1. Explicit fault handling at the invoke level — wrap each critical invoke in its own fault handler. Distinguish between a 400 Bad Request (data problem — log and skip) and a 503 Service Unavailable (worth retrying).
2. Idempotency checks before retrying — before retrying a failed call, verify whether the first attempt actually succeeded. Many Fusion REST APIs support querying by a unique external reference ID. Use it. A retry that creates a duplicate invoice is worse than a failed integration.
3. Structured error logging — log the payload context alongside the error message. “NullPointerException” tells you nothing. A log capturing source record ID, endpoint called, response code, and timestamp is something you can actually debug.
A practical fault pattern
Try block:
→ Invoke REST endpoint
→ Map response to target
Catch HTTP 4xx:
→ Log payload + status code
→ Route to error notification
→ Mark record as failed in tracking table
Catch HTTP 5xx or timeout:
→ Check idempotency via GET
→ If not created: retry once with backoff
→ If still failing: raise alert to operations
Where this matters most
This pattern pays off most on O2C and P2P integrations. A failed payment submission or a dropped receipt creation in Fusion AP is a business problem that shows up in reconciliation. Catching it explicitly at the integration layer is what keeps production support calls rare.