MSAMM
Back to course

Oracle Integration Cloud: Building Integrations That Survive Production · Module 10 · Business events and publish/subscribe

Ordering, and why you cannot rely on it

Lesson 105 of 175 · 2 min

EVENTS ARRIVE OUT OF ORDER. Not occasionally — as a property of how they are delivered, and a design that assumes sequence will corrupt data. The damaging case is concrete: two events about the same record, an update and then a correction, delivered in the wrong order. Your flow applies the correction, then applies the earlier update on top of it, and the record ends up in the older state. Nothing failed. The target is simply wrong, and it will stay wrong until somebody notices. THE DEFENCE IS TO MAKE A LATER UPDATE APPLIED BEFORE AN EARLIER ONE HARMLESS, and there are three ways. ONE: CARRY A VERSION OR TIMESTAMP AND REFUSE TO GO BACKWARDS. Compare what you are about to write against what is there, and ignore anything older. This is the strongest and it needs the target to hold the value — a field, a version number, a

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.

Get the free lessons by email

We will email you a link to every free lesson in this course. No account needed, and one message only.

In this module: Module 10 · Business events and publish/subscribe

  1. 1Event-driven versus polling
  2. 2Fusion business events, in practice
  3. 3Subscribing without losing events
  4. 4Ordering, and why you cannot rely on it
  5. 5At-least-once delivery
  6. 6OIC events between integrations
  7. 7What breaks: three event failures
  8. 8Lab briefing · Subscribe, drop, and catch up