Oracle Integration Cloud: Building Integrations That Survive Production · Module 9 · Idempotency and duplicate prevention
When the target has no natural key
Lesson 97 of 175 · 2 min
Building a key from the source, storing what you sent, and the staging table that becomes the record of what has already been delivered. Some targets have no natural key and no constraint you can lean on. An API that creates a new record on every call, a partner endpoint with no notion of duplicates. The target cannot help you, so the record of what has been done has to live on your side. A STAGING TABLE IS THAT RECORD. One row per unit of work: the correlation key, when it was sent, what the target returned, and its status. Written BEFORE the call and updated after, so a run that dies between the two leaves a row saying "attempted, outcome unknown" — which is the honest state and the one you need. THE UNIQUE CONSTRAINT GOES ON THAT TABLE, and now Lesson 4 applies to something you control: insert…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Integration Cloud: Building Integrations That Survive Production, with a certificate on completion and a fourteen-day refund window.
In 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