Oracle Integration Cloud: Building Integrations That Survive Production · Module 8 · Error handling, faults and retries
Errors that are not failures
Lesson 90 of 175 · 2 min
A record rejected by a business rule is a VALID OUTCOME, not an incident. Separating the two is what keeps the incident queue meaningful. The target understood the request perfectly and said no: the invoice is a duplicate, the period is closed, the credit limit is exceeded, the employee is not eligible. Nothing is broken. The integration worked exactly as designed and the business rule did its job. TREATING THAT AS A FAILURE HAS TWO COSTS AND BOTH ARE REAL. It fills the incident queue with things that need no technical action, so the queue stops being read — and the genuine failures are buried among them. And it sends the record to the wrong person: a rejected invoice needs a finance user, not an integration consultant, and routing it to a dead letter means the person who could resolve it never sees it. SO ROUTE BUSINESS REJECTIONS SOMEWHERE 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.
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