MSAMM
Back to course

Oracle Integration Cloud: Building Integrations That Survive Production · Module 8 · Error handling, faults and retries

Alerting a human

Lesson 88 of 175 · 2 min

Who gets told, how quickly, and how much detail. And an alert that fires on everything stops being read, which is the same as no alert. WHO: a role rather than a person, and a monitored destination rather than an individual's mailbox. The person who built it will not be there in a year, and the person on leave is not reading anything. HOW QUICKLY depends on what stopped. A payment interface that fails at 2am needs somebody now; a reference data sync that fails needs somebody tomorrow. Set the urgency from the business consequence rather than from the technical severity — they are frequently different, and an integration that alerts on everything at the same urgency has effectively set them all to the lower one. HOW MUCH DETAIL: enough to triage without opening the console. Which integration, which run, what failed, and how many records. "Integration X failed" makes

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 8 · Error handling, faults and retries

  1. 1The four kinds of failure
  2. 2Faults versus errorsFree preview
  3. 3Scope and fault handlers
  4. 4What to do with a caught fault
  5. 5Retry: how many, how far apart
  6. 6The dead letter, and who reads it
  7. 7Partial failure in a batch
  8. 8Compensation, and its limits
  9. 9Alerting a human
  10. 10Resubmission: doing it safely
  11. 11Errors that are not failures
  12. 12What breaks: five error-handling failures
  13. 13Lab briefing · Break it five ways