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