OIC failures fall into three groups: connectivity and authentication to the target system, payload and mapping errors where data does not match the expected structure, and timeouts on long-running or high-volume calls. The instance tracking view shows where the flow stopped and with what fault, which is where diagnosis begins rather than in the target application.
What problem does this solve?
The most damaging OIC failure is the silent one. An integration stops processing and nobody notices until a reconciliation reveals missing transactions days later.
Authentication failures after a period of working are common, and usually mean a rotated credential or an expired certificate that nobody tracked as an expiry date.
Mapping errors surface when the source system changes a field, sends an unexpected value, or introduces a new record type the mapping was never designed for.
How the solution works
We treat monitoring and reprocessing as part of the integration, not as an operational afterthought — every interface needs an alert on failure and a documented way to reprocess.
Faults are read from instance tracking, which identifies the failing activity and the fault message, before anyone inspects the target system.
- 1Use instance tracking to locate the failure and identify the activity that faulted.
- 2The fault usually distinguishes connectivity, authentication, mapping and timeout immediately.
- 3For connectivity or authentication faults, test the connection independently of the flow.
- 4For mapping faults, compare the actual payload against what the mapping expects.
- 5For timeouts, review batch size and whether the target can respond within the window.
- 6Correct the cause and reprocess the failed instances rather than leaving them.
Limitations & prerequisites
- Failed instances are retained for a limited period; beyond that, reprocessing requires resubmission from the source system.
- Reprocessing is only safe where the integration is idempotent — otherwise it creates duplicates in the target.
- OIC cannot compensate for an unavailable target system; retries help with transient faults, not with an outage.
- Credential and certificate expiry is a scheduled failure waiting to happen unless expiry dates are tracked as operational tasks.
- High-volume loads may need redesign rather than tuning; increasing timeouts on a fundamentally synchronous design postpones rather than solves the problem.
FAQ
Typically one of three: connectivity or authentication to the target, a mapping or payload mismatch, or a timeout on a long-running call. The fault message in instance tracking distinguishes them immediately, so start there rather than in the target application.
Establish whether the target is slow or the payload is too large. Reducing batch size often resolves it. Where a synchronous design is fundamentally too slow for the volume, increasing the timeout postpones the failure rather than fixing it.
Alert on failure, not just on success, and monitor for absence of expected runs. A schedule that stops firing produces no errors at all, which is why silent stoppage is the most damaging failure mode.
Within the retention window, yes — provided the integration is idempotent. If reprocessing can create duplicates in the target, that must be designed for before reprocessing becomes routine.
A rotated credential or an expired certificate. Both are predictable and both are usually untracked. Record expiry dates as operational tasks with lead time rather than discovering them through failure.
Decide up front what happens to a failed record: retry, route to an error queue, or alert a named owner. Integrations built without that decision fail silently, and the cost appears at reconciliation.
Tell us the module, the release and the exact symptom.
Send the module in scope, your Fusion release or EBS version, and the exact error text or symptom with a screenshot where you have one. We reply with a written assessment: the likely cause, what we would check first, and whether it is a configuration fix, a data fix, or a defect that needs an Oracle service request. When Swedish Technology can help, we scope the remediation with effort and sequence before you commit to anything.
Request an Oracle AssessmentSources & evidence
- Oracle Help Center — Cloud Applications documentation — module setup, subledger accounting and period-close reference
- Oracle Help Center — all product documentation — database, middleware and infrastructure reference used for error diagnosis
- My Oracle Support — patches, known-issue notes and service requests; Oracle account required
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.