OIC – Retry Mechanism
Introduction:
Oracle Integration Cloud – Version: 24.3.1
Implementing Retry Mechanism in an OIC Integration
Why we need to do:
OIC retry mechanism automatically retries failed requests when errors are temporary (such as network issues, timeouts, server unavailability, or record locks). This improves integration reliability by reducing failures that would otherwise require manual reprocessing. It is effective only for transient errors, not for data validation or business rule errors.
How do we solve:
Step 1: Initialize Retry Variables
Create the following variables:
RetryFlag – Controls whether the retry loop continues (Y/N).
RetryCount – Tracks the number of retry attempts.
RetryMaxCount – Defines the maximum number of retries allowed.
Step 2: Add a While Loop
Create a While loop with the condition:
RetryFlag = ‘Y’
The loop continues executing as long as the retry flag remains Y.
Step 3: Add a Scope
Inside the While loop, add a Scope and place the action that needs retry logic, such as the Create AP Invoice REST API call.
Step 4: Handle Successful Execution
Immediately after the API call, add an Assign action to set:
RetryFlag = ‘N’
This exits the While loop when the API call succeeds.
Step 5: Configure the Fault Handler
Add a Fault Handler to the Scope and include a Switch activity.
Condition:
RetryCount <= RetryMaxCount
If the condition is true:
Add a Wait activity (for example, 30 seconds).
Increment the retry counter:
RetryCount = RetryCount + 1
The While loop will execute the API call again.
Step 6: Handle Maximum Retries
In the Otherwise branch of the Switch:
Add a Rethrow Fault action.
This propagates the exception once the maximum retry count has been reached, allowing the integration to fail gracefully.
Conclusion:
If the API call fails, the integration enters Route 1 of the fault handler. It waits for 30 seconds before incrementing the retry counter and attempting the API call again. This process is repeated until the configured maximum retry count (3) is reached.
On the fourth failure, the condition RetryCount <= RetryMaxCount evaluates to false, causing the flow to move to the Otherwise branch. The Rethrow Fault action is then executed, propagating the exception to the outer Scope Fault Handler, where the error can be logged, notified, or handled according to the integration’s error-handling strategy.
