Oracle Fusion Technical: Reports, Data, Integrations and Extensions · Module 10 · REST and SOAP: calling Fusion, and being called
Idempotency and retries
Lesson 106 of 177 · 2 min
EVERY INTEGRATION IS RETRIED EVENTUALLY, by a scheduler, by an operator, or by somebody who thought it had failed. Designing so the second attempt is safe is the difference between a duplicate invoice and a no-op. The mechanism is a key you control. Send a unique reference with every request — your own identifier for the thing being created — and check for it before creating. Then a retry finds the existing record and does nothing, which is exactly what you want. Where the API supports an idempotency key or a source reference, use it: the server does the check, which is stronger than a check-then-create in your own code, because that pair has a gap between the two calls and two retries can both pass the check. THE TIMEOUT IS THE CASE PEOPLE DESIGN FOR LAST AND MEET FIRST. The call times out on the caller and SUCCEEDS on…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Fusion Technical: Reports, Data, Integrations and Extensions, with a certificate on completion and a fourteen-day refund window.
In this module: Module 10 · REST and SOAP: calling Fusion, and being called
- 1What Fusion exposes, and what it does not
- 2REST vs SOAP: choosing without arguingFree preview
- 3Authentication and the service account
- 4Reading the REST API catalogue
- 5Your first call, and its error
- 6Payloads, child resources and partial updates
- 7Bulk operations and rate limits
- 8Fusion calling out: business events
- 9Idempotency and retries
- 10Versioning and surviving a quarterly update
- 11What breaks: five integration failures
- 12Lab briefing · Read, write and break an integration