Integrationadvanced
Error Handling and Monitoring in Cloud Integrations
Explain best practices for building resilient, observable integrations between Fusion/EBS and external systems
Integrations fail more than in-application code does: networks, downstream outages, and data from systems you do not control.
Building resilient integrations without proper error handling and monitoring is like running a delivery service with no tracking numbers or delivery confirmations — packages might be getting lost regularly, but nobody finds out until an angry customer calls asking where their order is, rather than the system proactively flagging the problem the moment it happens.
Key Concepts
1
Designing for that is the difference between an integration that runs for years and one somebody babysits.
2
Separate transient from permanent failures.
transient network timeout, service unavailable, throttled
-> retry, with backoff
permanent invalid data, business rule violation, missing
reference
-> do not retry. It will fail identically forever.3
Retrying a permanent failure wastes time and can look like a hang. Failing on a transient one creates work
for a person where a second attempt would have succeeded.
4
Retry needs backoff.
attempt 1 -> wait 1 min -> attempt 2 -> wait 4 min -> attempt 35
Immediate retries against a struggling system add load to the thing that is already failing.
6
Idempotency is what makes retry safe. A retried call must not create a duplicate.
7
unique business key the target rejects the second create
processed flag the source marks what was sent
idempotency key sent with the request; the target
recognises a repeat8
Without one of these, a timeout on a successful call produces two records on the retry — and a timeout
never tells you whether the work happened.
9
Log enough to diagnose without rerunning. The payload, the timestamp, the correlation id, and the full
error. An integration that logs "failed" is one somebody has to reproduce.
10
Now the part that matters most, and is usually missing. Monitor business outcomes, not technical
success.
11
technical: the integration completed with no errors
business: it processed 0 of the 500 records expected12
A run that completed and processed nothing is worse than one that failed, because failure is noticed.
Success is not.
13
So alert on the count as well as the status: expected against actual, and anything at zero.
14
The scenario, and both halves of the answer. "It failed at 2 a.m. and the vendor called at 10."
15
Technical: fault handling, retry with backoff, and idempotency so the retry is safe.
16
Process: an alert when the run fails, and an alert when it succeeds while processing nothing. Ten
o'clock was not the detection time because the technology was missing — nobody was told.
17
What the interviewer is probing.1. "What does good error handling look like here?" Probing: the engineering standard.
Stalls: "Logging." Moves up: classify transient from permanent, retry the transient with
backoff, route the permanent to a reviewable error store, and alert a named owner.
18
2. "Why is idempotency essential?" Probing: the distributed reality. Stalls: "It is not."
Moves up: retries and duplicate deliveries are normal, so an integration that creates a record per
call will create duplicates.
19
3. "What should be monitored beyond failures?" Probing: the depth. Stalls: "Nothing." *Moves
up:* volume and latency against normal — an integration that silently processes zero records is a
failure that no error log reports.
20
4. "Who gets alerted and how?" Probing: the operational angle. Stalls: "The team." *Moves
up:* a defined owner with a runbook per integration — an alert nobody owns is noise, and the
business finds the problem first.