Oracle Integration Cloud: Building Integrations That Survive Production · Module 9 · Idempotency and duplicate prevention
Why every integration is retried
Lesson 93 of 175 · 2 min · Free preview
Four ordinary events, each producing a second delivery of the same work. None of them is a defect, which is why every integration is retried eventually. ONE: A TIMEOUT THAT SUCCEEDED. The caller gave up; the target completed. Neither system is wrong and they disagree, and whatever happens next is a coin flip: retry and duplicate, or give up and lose the work. TWO: A RESTART. A run died halfway and somebody ran it again. Whatever the first run committed is committed twice unless something prevents it. THREE: A RESUBMISSION. An operator reprocessed a failed instance from the console — which re-runs the flow from the beginning, including the steps that succeeded. Module 8's lesson, arriving as a duplicate. FOUR: A PARTNER WHO RESENDS. They had an outage, they were not sure the first file arrived, somebody clicked twice. You have no control over this one at all, which is…
This lesson is free
Watch the full lesson, with its written notes, without an account. It is one of the free lessons this course opens with.
Watch the full lessonIn this module: Module 9 · Idempotency and duplicate prevention
- 1Why every integration is retriedFree preview
- 2What idempotency means here
- 3Choosing a correlation key
- 4Where to enforce it
- 5When the target has no natural key
- 6Timeouts: the ambiguous outcome
- 7Idempotency across a whole file
- 8What breaks: three duplicate scenarios
- 9Lab briefing · Make a payment flow safe to retry