Oracle Integration Cloud: Building Integrations That Survive Production · Module 9 · Idempotency and duplicate prevention
Choosing a correlation key
Lesson 95 of 175 · 2 min
The identifier that says "this is the same work". Choosing it is the whole of idempotency, and choosing it badly is worse than not trying. A SEMANTIC LABEL IS NOT AN IDENTITY. "Invoice for supplier X, March" describes a category, not a thing — and two genuinely different invoices can share it. A key that can be true of two different pieces of work will merge them, which is a data loss rather than a duplicate prevented. WHAT MAKES A GOOD KEY: it comes from the SOURCE, it identifies exactly one piece of work, and it is stable — the same work resent carries the same key, and different work never does. WHAT HAPPENS WHEN THE KEY IS NOT UNIQUE is the failure to fear, because it is silent and it goes the wrong way. The second record is treated as a repeat of the first and SKIPPED: no duplicate,…
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