Exchange Recovery

Exchange recovery is a process to restart the flow after an exchange step fails or times out. The recovery process restarts the first exchange step that is in the failed or the initial status.

Consider the following scenarios:

Table 1. Exchange Recovery

Scenario	Exchange Status	Exchange Sub-Step Status	Recovery Process
Dynamic logic times out	Failed	Failed (like, transform)	Restarts the first-failed exchange step and continues execution.
Exchange step (Activity, Extract, or Process) times out	Timedout	Initial (receiveNotification)	Restarts the time guard task. The time guard task checks the status of the long-running process (like an activity) using a location header. If the long-running process is complete, the time guard task marks the receiveNotification step as complete. If the long-running process is not complete, the time guard task keeps rechecking the process for a pre-defined duration after which it sets the exchange status as Timedout.
Exchange times out	Timedout	Initial	Restarts the first exchange step in the Initial status and continues the flow. NOTE: If the exchange is stuck in the receiveNotification step, the recovery process restarts the time guard task in the background and follows the recovery process of the exchange step as mentioned above.
Exchange step (Delivery step) times out	Timedout	Initial (receiveNotification)	Restarts the time guard task. Since the delivery step with pre-configured timeout doesn’t have any location header, the time guard task waits for a notification to resume the exchange. NOTE: When the delivery step timeout is missing the location header status retrieval feature, the external system must send a notification again to resume the exchange in the recovery flow.
Subflow times out	Timedout	Failed (subflowStepController)	The failed or timed-out sub-exchanges recover with the main exchange. Recovery of a sub-exchange is the same as that of a regular exchange.
Agent (delivery step) fails	Failed	Failed	Restarts the delivery by agent process. System retries to deliver the files which could not be written at the destination in the previous attempt. Files already delivered are not re-sent.
Agent (delivery step) times out	Timedout	Failed (receiveAgentNotification)	Restarts the delivery by agent process. The system retries to deliver all files. Before recovering the exchange, investigate the actual delivery result. If the exchange is recovered without checking, the recovery can fail when a file already exists at the destination, or the Agent can deliver files again. If (a subset of) files was delivered by the Agent and the files have not yet been processed downstream, manually delete the files from the destination before recovering the exchange. If (a subset of) files was delivered by the Agent and the files have already been processed downstream, go to the File Upload Results page and update uploadSuccess for those files before recovering the exchange. If the file upload result cannot be updated, raise a Service Request to have Oracle flag the delivered subset of files as successfully delivered in the file upload results table of the database before recovering the exchange.
Fusion load job status is TIMEDOUT	Failed	Failed (checkJobStatus)	Restarts polling the Fusion load job status. Oracle Insurance Gateway does not send a recovery request to Fusion as part of this recovery flow. The load job must be recovered first in Fusion before recovering the exchange in Oracle Insurance Gateway.
Fusion load job polling reaches configured timeout	Timedout	Initial (checkJobStatus)	Restarts polling the Fusion load job status from the checkJobStatus sub-step. Use this when Oracle Insurance Gateway stopped waiting because the configured polling timeout was reached before the load job reached an end state. NOTE: For Fusion job recovery scenarios, recovery in Oracle Insurance Gateway resumes polling only. It does not resubmit the job, and it does not recover the job in Fusion.

Table 2. Data Transfer Step Exchange Recovery

Exchange Sub-Step	Scenario	Exchange Status	Exchange Step Status	Error Handling	Recovery Process
Invoke Data Transfer	Data Transfer invocation fails (HTTP 4XX/5XX)	Failed	Failed	1. Fail exchange step. 2. Fail exchange. 3. Store response payload as Log Line.	Retry invoking the data transfer request.
Invoke Data Transfer	Data Transfer invocation times out	Timedout	Initial	1. Timeout exchange (step status remains initial). 2. Log Line is created by default (Exchange level time out).	Retry invoking the data transfer request.
Check Data Transfer Status	Data Transfer status check fails (HTTP 4XX/5XX)	Failed	Failed	1. Fail exchange step. 2. Fail exchange. 3. Store response payload as Log Line.	Retry the process of checking the data transfer status.
Check Data Transfer Status	Data Transfer status check times out	Timedout	Initial	1. Timeout exchange (step status remains initial). 2. Create a Log Line (exchange step timed out after the configured time allowed of <x> minutes, check <URL> for details).	Retry the process of checking the data transfer status.
Check Data Transfer Status	Data Transfer status check times out	Timedout	Initial	1. Timeout exchange (step status remains initial). 2. Log Line is created by default (Exchange level time out).	Retry the process of checking the data transfer status.
Collect Data Transfer Data	Data Transfer data collection fails	Failed	Failed	1. Fail exchange step. 2. Fail exchange. 3. Store response payload as Log Line.	Retry the collect data.
Collect Data Transfer Data	Data Transfer data collection times out	Timeout	Initial	1. Timeout exchange (step status remains initial). 2. Log Line is created by default (Exchange level time out).	Retry the collect data.

The exchange property recovery is true when the exchange is in the recovery mode. This helps when a process is supposed to operate differently in a recovery mode versus in a non-recovery mode. For instance, when a Step Post Process function dynamic logic has to process a notification and the exchange must continue after recovery, regardless of the notification status received earlier.

Stash Error Handling and Recovery

When an error occurs, processing can continue from the point at which it was interrupted. The readUnprocessed() method retrieves both unprocessed and errored items, while already processed items are skipped during recovery.

When an errored item is successfully reprocessed, the markSuccess() method clears the error message associated with that item. This allows the stash to reflect the latest successful processing state.

Stash improves recoverability, but it does not remove every duplication risk. If an external action succeeds but the stash item cannot be marked as processed, the item can be retried during recovery.