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	Restarts the delivery by agent process. The system retries to deliver all files. NOTE: Since the notification of the Agent was not received within time initially, the system has no knowledge of the actual end result. Before recovering the exchange, you must investigate the actual end result. If the exchange is recovered without checking, you run the risk of an error in case the file still exists at the destination or the risk of the Agent delivering the file again. If (a subset of) files were 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 were delivered by the agent and the files have already been processed downstream, 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.

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.