OIC Integration Patterns: Build for the Failure, Not the Happy Path
Integrations work fine in testing and break in production at 3am. The difference is whether you designed for the failure modes or ignored them.
Any fool can build an integration that works when everything's perfect. The craft is building one that behaves when the target system is down, the data's malformed, or the file arrives twice. Oracle Integration Cloud gives you the tools; whether you use them for the failure path is what separates a robust integration from a 3am phone call.
Design idempotency in from the start
If the same payload arrives twice, it must not create two records or pay someone twice. Idempotent design, where reprocessing is safe, is not optional for anything touching payroll or money. Build it in, don't bolt it on after the first double-payment.
Handle errors deliberately, log them usefully
When something fails, where does it go? A dead-letter queue, an alert, a retry with backoff? Silent failures are the worst kind, the integration 'worked' but three records vanished. Configure fault handling that surfaces problems loudly and logs enough to diagnose them.
Don't hammer the target system
Throttling, batching, and respecting rate limits keep you from taking down the very system you're integrating with. An integration that DDoSes your payroll provider is not a feature.
Real scenario: a client's HR-to-payroll integration had no idempotency. A network blip caused a retry, and a batch of employees got duplicate element entries, some got paid twice. We rebuilt it with idempotent keys and proper fault handling. The next network blip? A safe retry, zero duplicates. Design for the failure and the failure becomes a non-event.