Exchange

The Exchange Integration Point can be used to invoke an integration or it can be invoked through a schedule. Once the integration is invoked that is, an Exchange gets created (an exchange is single instance /execution of an integration), an integration step is performed via several transactional sub-steps, referred to as exchange steps.

Exchange Status

Following exchange states are possible:

Table 1. Exchange Status

State	Description	Final State	Recoverable State
New (N)	Whenever a request comes in for the execution of a message exchange, this exchange will get the initial status of 'NEW'	N	N
In Progress(S)	Whenever the exchange is picked up by the system to go through the various steps it will have a status of 'In Progress'	N	N
WaitingOnExternalSystem(W)	Whenever the exchange is (temporarily) depending on an external system or waiting for Agent to write the files at the destination, the exchange will have a status of 'WaitingOnExternalSystem'.	N	N
WaitingForSubExchangesToFinish(WS)	Whenever an exchange reaches an exchange step that triggers sub-exchanges, the main exchange needs to wait before it moves to its own next step. In that case, the main exchange is put to this status.	N	N
Failed(F)	Whenever the message exchange has somehow resulted in a (temporary) error, the exchange will have a status of 'Failed'	Y	Y
TimedOut(T)	Whenever the message exchange did not meet the configured SLA, maximum time allowed it is marked as Timed Out	Y	Y
Completed(C)	Whenever the message exchange has been 'signed off' by the requesting party, it will have a status of 'Completed'	Y	N

Once an exchange is created after the invocation, it creates exchange steps as the runtime model for integration steps.

Exchange Steps

Exchange Step is the runtime model for the integration step. Each integration step gets converted into one or more exchange steps, depending on the atomic nature of the operation. Example, an extract integration step has 3 exchange steps, InvokeExtract, ReceiveNotification and CollectData.

Table 2. Exchange Step has the Following Model

Fields	Description
Integration Step	Reference to the Integration Step for which this exchange step is created. It may not be there always, for example for the trigger and signoff exchange step, there is no integration step.
Exchange Step Payload	Payload associated with this step. Can either be Raw and Datafile.
Exchange Step Status	State transition that an exchange step goes through. Please refer to the table and diagram below for various states and their respective possible transitions
Integration Sub Step	The integration sub step for the exchange step. This is directly linked to the integration step for which the exchange step is created. Please refer to mappings below for each integration step.
Step Timestamp	The timestamp when the step completes. This provides a time split of the step in the entire flow.

Exchange Step Status

Following exchange step states are possible:

Table 3. Exchange Step Status

State	Description
Initial(I)	Whenever a request comes in for the execution of an exchange, the exchange step gets the initial status of 'I'
In Progress(P)	Optional status for explicitly marked exchange steps that can take longer to run or are relevant for support. An exchange step can move from Initial to In Progress, and then to Done, Skipped, or Failed.
Skipped(S)	Steps conditionally can be skipped in which case they get this status.
Failed(F)	A failed step ~ possibly this can be recovered.
Done(D)	A step which has completed its work gets a 'Done' status.

Figure 1. Exchange step status transitions

Not every completed exchange step is expected to pass through In Progress. Only explicitly marked steps use this status. Other steps can move directly from Initial to Done, Skipped, or Failed.

The In Progress exchange step status means that OIG is actively executing the exchange step. It does not represent work that is running in an external system, or a step that is waiting for a notification or polling result. When an exchange reaches a final status, such as Failed, TimedOut, or Completed, its current exchange step cannot remain In Progress.

Exchange Step Payload

Exchange step payload represents the payload associated with the exchange step if any.

Table 4. Exchange Step Payload

Fields	Description
Payload Type	A payload can either datafileset(DataFileSetPayload-D) or raw(RawPayload-R)
Raw Payload	If the payload type is RawPayload, this attribute is filled with the String value of the payload. It can be in any character based format
Data File Set Id	If the payload type is DataFileSetPayload, this attribute is filled with the id of the Data File Set.

Exchange Logs

Each exchange step execution can produce log statements.

Table 5. Exchange Logs

Fields	Description
Log Type	Can either be System(S) or User(U)
Log Line	The log statement
Log Timestamp	The timestamp when the log was added.

Exchange Integration Selection

You can invoke an Exchange for a specific integration code and optionally for a specific integration version. The application selects the integration version with the following priority:

• Priority 1: Invocation integration version (if specified).

• Priority 2: Highest-enabled version

  • NULL has the lowest version.

Consider the following integration selection scenarios:

Table 6. Exchange Integration Selection

Scenario	Code	Version	Enabled?	Invocation Integration Version	Result	Remark
1	PROVIDER_IMPORT	NULL	Y		selected	Selection based on highest enabled version
2	PROVIDER_IMPORT	NULL	Y
	PROVIDER_IMPORT	1	Y		selected	Selection based on highest enabled version
3	PROVIDER_IMPORT	1	Y
	PROVIDER_IMPORT	2	Y		selected	Selection based on highest enabled version
4	PROVIDER_IMPORT	1	Y	1	selected	Selection based on invocation integration version
	PROVIDER_IMPORT	2	Y
5	PROVIDER_IMPORT	1	Y		selected	Selection based on highest enabled version
	PROVIDER_IMPORT	2	N
6	PROVIDER_IMPORT	1	Y
	PROVIDER_IMPORT	2	Y		selected	Selection based on highest enabled version
	PROVIDER_IMPORT	3	N
7	PROVIDER_IMPORT	NULL	Y		selected	Selection based on highest enabled version
	PROVIDER_IMPORT	1	N
	PROVIDER_IMPORT	2	N
8	PROVIDER_IMPORT	1	Y
	PROVIDER_IMPORT	2	N	2	HTTP 409 Conflict error	Invocation integration version is disabled
9	PROVIDER_IMPORT	1	N
	PROVIDER_IMPORT	2	N		HTTP 404 Not Found	No enabled integration versions found

Mapping of Integration Step and Integration Sub-Step

Table 7. Mapping of Integration Step and Integration Sub-Step

Integration Step	State	Integration Sub-Step
-	Exchange Triggered	trigger Effectively this refers to the first (sub)step that initiates a particular exchange.
Any	Integration Step defines condition invocation	conditionCheck This refers to a (sub)step that checks if the step needs invocation.
Any	Integration Step defines post process function	postProcess This refers to a (sub)step that post processes the step.
Data Collection: Extract	Data Collection Step of type Extract	invokeExtract This refers to a (sub)step that indicates invoking an extract for data collection step. receiveNotification This refers to a (sub)step that indicates that a notification is received after successful invocation of a long running process. notificationCollectData This refers to a (sub)step that indicates that data is collected after the long running process finishes and its notification is received. notificationCollectMessages This refers to a (sub)step that indicates that messages are collected after the extract finishes and its notification is received. This substep is present if downloadMessage is set to true in configuration.
Data Collection: Data Transfer	Data Collection Step of type Data Transfer	invokeDataTransfer A sub-step that triggers the data transfer process. This involves calling the data transfer API to retrieve data based on the provided configuration. Receives data transfer ID and stores the response for tracking. checkDataTransferStatus This sub-step monitors the status of the data transfer process, using a polling method. The default polling interval is one minute. To override this, configure it at the step level or with exchange property (<Integration Step Code>-pollingInterval) at runtime. datatransferCollectData Once the data transfer is complete, retrieve and store the data file or data file link depending on the environment setup. For SaaS environments: Store the file path references to Object Storage as Data File (Set). Create Data File Set and Data Files. For On-Prem environments: Download the files and store them in the database as Data File (Set). If the base views are not generated, an error indicating that the table or view does not exist occurs. In case of an exchange failure due to this error, regenerate the views in the base applications.
Delivery: Query	Data Collection Step of type Query	invokeQuery This refers to a (sub)step that indicates invoking a query step for data collection step.
Delivery: Custom	Data Collection Step of type Custom	invokeCustomCollection This refers to a (sub)step that indicates invoking a custom step for data collection step.
Delivery: Transformation	Transform Step or Data Deliver defines a transformation function	transform This refers to a (sub)step that indicates transformation of the collected in the previous step.
Delivery: Agent	If the destination defined in Delivery step is through Agent	checkAgentAvailability This refers to a pre-check (sub)step to check the availability of the Agent using the Agent Health endpoint. deliverByAgent This refers to a (sub)step to invoke the Agent, which means that the data files are ready to be picked up and the process of moving the files is to be initiated at the destination. Oracle Insurance Gateway waits for an acknowledgement from the Agent. The Agent sends the response code 201, which means the Agent is available and acknowledges the request to place the files at the configured destination folder before marking this (sub)step as complete. A reference to the files to be delivered by the Agent is stored in the file upload results table. receiveAgentNotification This refers to a (sub)step to receive a notification from the Agent with the list of files that were processed along with error details in case of a file delivery failure if any. The Agent sends a custom notification with the following details: CorrelationId in the header to match the notification with the exchange. List of files along with errors if any as part of the JSON response payload, for example Success response - {"<file name>":"true"} Failure response - {"<file name>":"error details"} Agent time out - In case the notification is not returned within the configured time limit, the (sub)step is marked as Failed with the option of recovery.
Deliver: Rest	If the destination defined in Delivery step is type Rest	deliverByRest This refers to a (sub)step that indicates delivering an integration by rest.
Deliver: Sftp	If the destination defined in Delivery step is type Sftp	deliverBySFTP This refers to a (sub)step that indicates delivering an integration by SFTP.
Deliver: FileUpload	If the destination defined in Delivery step is type FileUpload	fileUpload This refers to a (sub)step that indicates delivering through uploading the file in Oracle Health Insurance applications.
Invoke Process: Activity	Invoke process of type Activity	invokeProcessOhiActivity This refers to a (sub)step that indicates invoking an external process of type Oracle Health Insurance Activity. receiveNotification This refers to a (sub)step that indicates that a notification is received after successful invocation of a long running process. This only applies if the expect notification is set to true for the integration step. notificationCollectData This refers to a (sub)step that indicates that data is collected after the long running process finishes and its notification is received. This only applies if the expect notification is set to true for the integration step. checkRecovery This refers to a (sub)step that checks the need to recover the activity if autoRecovery is set and if the notification contains recovery links notificationCollectMessages This refers to a (sub)step that indicates that messages are collected after the activity finishes and its notification is received. This substep is present if downloadMessage is set to true in configuration.
Invoke Process: Process	Invoke process of type Process	invokeProcess This refers to a (sub)step that indicates invoking an external process. receiveNotification This refers to a (sub)step that indicates that a notification is received after successful invocation of a long running process. This only applies if the expect notification is set to true for the integration step. notificationCollectData This refers to a (sub)step that indicates that data is collected after the long running process finishes and its notification is received. This only applies if the expect notification is set to true for the integration step. checkRecovery This refers to a (sub)step that checks the need to recover the process if autoRecovery is set and if the notification contains recovery links notificationCollectMessages This refers to a (sub)step that indicates that messages are collected after the process finishes and its notification is received. This substep is present if downloadMessage is set to true in configuration.
Subflow	Invokes a subflow	subflowStepFunction This refers to a (sub)step that indicates invoking a subflow step function to collect subflow properties. subflowStepCreator This refers to a (sub)step that indicates creation of sub-exchanges. subflowStepController This refers to a (sub)step that indicates controlling a subflow step by making sure that all the sub-exchanges have reached their final state.
-	Exchange Signoff	signoff This refers to a (sub)step that indicates the (successful) end of a particular exchange.

File Upload Results

The File Upload Results page allows users to view the status of outbound file deliveries.

For OHI Agent deliveries, users can manually update the Upload Success status. This prevents duplicate file deliveries during exchange recovery, reducing downstream processing issues and operational risks.

Scenario

Consider a case where the agent delivery step times out or fails, for example, the notification arrives late or reports an error.

1. OIG sends a request to the agent with a file link. The agent downloads the files and delivers them to the destination folder.

2. OIG waits for a notification within the configured time limit. If the notification is late or missing, the exchange step (delivery by agent or receive notification) fails. OIG records no delivery outcome.

3. Before initiating recovery, investigate the actual results.

4. If the Agent delivered a subset of files and those files are processed downstream, go to the File Upload Results page and update uploadSuccess for those files. This prevents the system from delivering them again during recovery.

Both timeout and failure outcomes are considered valid conditions for permitting updates.

Feature Constraints

The feature has the following constraints:

• Updates are only allowed for agent records where the upload step failed.

• The only field that can be changed is the upload status.

• Once a file is marked as successfully uploaded, that status cannot be changed back.

Stash Processing

Each exchange sub-step is run as a transaction. If any sub-step fails, all changes are rolled back, ensuring consistency. Stash processing has one important exception: marking a stash item as processed is performed in its own autonomous transaction.

As a result, stash creation and stash processing must be separated into different exchange sub-steps. Do not create stash items and mark them as processed within the same sub-step.

It is recommended to avoid using too many stashes per exchange in order to maintain clarity and reduce complexity.