An Oracle Integration flow that works once in design time is not tested. Real defects show up later: a Fusion import rejects rows, a callback never arrives, or a synchronous flow fails and cannot be resubmitted.
This guide sets out a practical test approach for Oracle Integration 3 (OIC), from design-time testing to SIT with Oracle Fusion ERP and regression after updates. Feature names come from Oracle's current documentation. Confirm screens in your own instance.
1. Design the integration so it can be tested
- Business identifiers. Oracle lets you assign up to three business identifier fields from the source payload. One must be the primary identifier, and the integration cannot be activated without it. Use business keys such as invoice number or file name.
- Fault handlers. Group invokes in a scope action. Each scope has a default fault handler, and invoke faults are added as named fault handlers. A re-throw sends the fault on to the global fault handler, if one exists, and then to Oracle's error handling for review.
- Clear outcomes. Decide, before testing, what each flow should do with good data, bad data and an unavailable target system.
2. Test connections first
Every connection has a Test action. For connections that use a WSDL, Oracle offers a full Validate and Test option as well as a quicker syntax-level test. Neither sends requests to the target operations. A connection cannot be used in an integration until the test passes and the connection is saved. Record the endpoint, integration user and last successful test date for each environment.
3. Unit test in design time
Run test from the canvas
For integrations with a REST Adapter trigger and for scheduled integrations, you can test from inside the integration canvas. Run test activates the integration, sets debug tracing and opens a test panel. You enter the request or schedule parameters. The panel shows the response, the instance ID, the activity stream and the business identifier values.
Test from outside
For other triggers, copy the endpoint URL and call it from a tool such as Postman or SOAP UI, or raise the event in the source application.
Use tracing levels with care
Production is the default and recommended level. Audit captures trigger and invoke payloads. Debug logs every activity, can expose sensitive data and affect performance, and resets after 24 hours. Use debug in development only, and mask personal data in test payloads.
Read the activity stream
The activity stream shows each action with timestamps and payloads. Instance details also show the slowest activities and let you download logs. Attach the instance ID and downloaded log to every defect you raise.
4. Test data and environments
- Separate instances. Test against a Fusion test pod, never production. Recheck connections after every pod refresh.
- Data sets per scenario. Prepare a valid record, a record with a missing mandatory field, a duplicate, an invalid reference and a large file.
- Converted data. Run SIT on migrated master data, not only on hand-keyed records.
- Repeatable data. Keep test files under version control for regression runs.
5. Test faults and resubmission
Force each failure on purpose. Stop a target endpoint, send bad data, use a wrong credential. Then confirm the fault handler does what the design says.
Oracle's resubmission rules matter for test design:
- Faulted asynchronous instances are recoverable. You can resubmit them from Observability > Errors, one at a time or in bulk.
- Synchronous flows, scheduled flows with schedule parameters and instances that have reached the retry limit cannot be resubmitted.
- Resubmission is manual, not automatic.
- A single resubmit lets you choose the tracing level. A bulk resubmit uses the tracing level set at activation.
For synchronous flows, test your other recovery route. Check that a resubmit does not create a duplicate in Fusion.
6. SIT with Oracle Fusion ERP
The Oracle ERP Cloud Adapter supports bulk import through FBDI, SOAP and REST services, BI Publisher reports and business event subscriptions. Each needs its own SIT cases.
FBDI imports and callbacks
The adapter's Import Bulk Data into Oracle ERP Cloud action loads a ZIP file into Fusion. With Enable Callback set, Fusion raises a business event when the import job finishes. A separate trigger integration receives that callback.
- Load a small file with known good rows and known bad rows.
- Confirm the import job runs in Fusion and the callback integration starts.
- Check that the callback logic reads the job status and processes errors.
- Reconcile row counts: sent, loaded and rejected.
- Repeat with a file that fails completely.
Oracle documents a 401 Unauthorized failure for older integrations still on the SOAP-based callback design. If your Response page shows Integration Flow Identifier and Version fields under Enable Callback, plan that change before SIT.
Business events
The adapter can subscribe to business events from Financials, procurement, supply chain and project modules. For each event, create the transaction in Fusion, confirm the OIC instance starts, and check the target record. Also test what happens when the target system is down.
Our OIC connection playbook for Oracle ERP Cloud lists the setup steps that SIT relies on.
7. Performance and volume
- Run the largest realistic file or batch, not a sample of ten rows.
- Run overlapping scheduled integrations together, as at month end.
- Use the slowest-activities view to find bottlenecks.
- Check Oracle's published service limits for your instance before you design large payloads.
8. Regression after quarterly updates
Oracle applies functional updates to Oracle Integration 3 every quarter. They cannot be skipped or deferred. In the commercial realm, Development instances are updated about three weeks or more before Production. Use that gap.
- Keep a regression pack of your critical integrations with fixed test data.
- Run it on the Development instance after its update.
- Run it again when Fusion itself is updated, because adapter behaviour depends on both sides.
Our quarterly update regression playbook covers the Fusion side.
9. Monitoring with Observability
- On Observability > Instances, filter by status and search by primary identifier.
- On Observability > Errors, open a failed instance from its business identifier to see the activity stream and identifier values.
- Confirm that error notifications reach a named support mailbox.
Sample test cases
| ID | Scenario | Expected result |
|---|---|---|
| TC-01 | Connection Test in each environment | Test succeeds and connection is saved |
| TC-02 | Valid payload through REST trigger | Record created in target; instance Completed |
| TC-03 | Missing mandatory field | Fault handled; error logged with business identifier |
| TC-04 | Target system unavailable | Async instance faults and can be resubmitted |
| TC-05 | Resubmit after fix | Record created once; no duplicate |
| TC-06 | FBDI file with good and bad rows | Callback received; counts reconcile; errors reported |
| TC-07 | Fusion business event raised | OIC instance starts; target updated |
| TC-08 | Month-end volume run | Completes within agreed time |
| TC-09 | Regression after quarterly update | Same results as baseline |
OIC testing checklist
- Primary business identifier set on every integration
- Scope and fault handlers designed for each invoke
- All connections tested and saved in each environment
- Debug tracing used only in development; test data masked
- Positive, negative and duplicate test data prepared
- Async resubmission tested; sync recovery route tested
- FBDI callback and row counts reconciled
- Business event subscriptions tested end to end
- Volume test run at realistic peak
- Regression pack run after each quarterly update
- Support team can find failures in Observability
Common mistakes
Testing only the happy path. Bad data and unavailable systems cause many production incidents. Test them early.
Assuming every failure can be resubmitted. Synchronous flows cannot. Design and test another recovery route.
Leaving debug tracing on. It can expose sensitive data and slow processing.
Skipping the Development update window. It is your chance to catch update issues early.
How Egisedge helps
Egisedge Technologies is an Oracle Partner, founded in 2019, with offices in Gurugram and Mahendergarh. We have delivered multiple Oracle projects across Fusion Cloud ERP, HCM and SCM, Oracle Integration Cloud and OCI. Our work includes third-party billing integration with Oracle Fusion Receivables for a telecom operator in Ghana and an aviation services company in Nigeria, delivered as part of an implementation partner's team.
We help teams design OIC integrations that can be tested, build the test pack and run SIT with Fusion. Our OIC testing playbook sets out the test cases, and our SIT and UAT playbook covers the wider test cycle.
Want help testing your Oracle Integration flows? Email info@egisedge.com or book a demo with our team.
Frequently asked questions
Can I test an Oracle Integration 3 integration without leaving the canvas?
Yes, for integrations with a REST Adapter trigger and for scheduled integrations. Run test activates the integration with debug tracing and shows the response, instance ID, activity stream and business identifier values in a test panel. Other trigger types are tested from outside, for example by calling the endpoint from Postman or SOAP UI, or by raising the event in the source application.
Which failed OIC instances can be resubmitted?
Oracle's guidance is that faulted asynchronous instances are recoverable and can be resubmitted from Observability > Errors, singly or in bulk. Synchronous flows, scheduled flows with schedule parameters and instances that have reached the retry limit cannot be resubmitted. Resubmission is not automatic.
How do I test an FBDI load from OIC into Oracle Fusion ERP?
Test the invoke that imports bulk data and the separate callback integration that receives the completion event. Load a small file with known good and bad rows, confirm the callback arrives, and check that your integration reads the job status and handles failed rows correctly.
When should I run OIC regression tests for quarterly updates?
Oracle applies functional updates every quarter. In the commercial realm, Development instances are updated about three weeks or more before Production. Use that gap to run your regression pack on the Development instance before Production is updated.
Talk to Egisedge about Integration (OIC)
Tell us where you are and we'll reply within one working day with next steps.