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. The next section explains this run time data model.

An Exchange has the following attributes:

Field	Description
descr	The description of the Exchange, provided at the time of Integration invocation. See Exchange Integration Point for details. When not specified in the request to the Exchange Integration Point then the description from the integration is copied to the Exchange description.
integration	Reference to the Integration for which the Exchange is created.
subflowStep	Reference to the SubflowStep for which the Exchange (sub-exchange) is created. Either integration or subflowStep is present.
properties	Collection of properties that the Exchange is invoked with or accumulates during the process. It is possible to search for Exchanges by using properties. The index that facilitates searching Exchanges by properties is updated every 15 minutes. For a query to return the Exchange, the property values must be updated in the index. As a result, it could take 15 minutes to retrieve Exchanges by recently changed property values. Alternatively, use the transactionIdentifier1 and transactionIdentifier2 attributes of an Exchange for near real-time Exchange retrieval.
transactionIdentifier1	Customer specific (business) transaction identifier that the Exchange is part of.
transactionIdentifier2	Alternate, customer specific (business) transaction identifier that the Exchange is part of.
exchangeStatus	State transition that an Exchange goes through. Please refer to the table and diagram below for various states and their respective possible transitions
exchangeSteps	Collection of Exchange Steps depicting the flow of an Exchange along with states and timestamps for Exchange Steps. Please refer to details below.
parentExchangeStep	Reference to the Parent Exchange Step that triggered this exchange. Only available if the Exchange is invoked as part of a subflow invocation.
sequence	The sequence number of the Exchange. Only available if the Exchange is invoked as part of a subflow invocation.

Exchange Status

Following exchange states are possible:

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
Started(S)	Whenever the exchange is picked up by the system to go through the various steps it will have a status of 'Started'	N	N
WaitingOnExternalSystem(W)	Whenever fulfilling the exchange is (temporarily) depending on an external system, the exchange will have a status of 'WaitingOnExternalSystem'	N	N
WaitingForAgentToSignoff(A)	Whenever fulfilling the exchange delivery through agent, the message is sent to Agent and when Agent finally delivers it, it signs off the gateway. In the interim, the status on the exchange is 'WaitingForAgentToSignoff' Possible reasons for exchange pending for WaitingForAgentToSignOff: Missing permission leading to failure of delivery of a datafile from agent to landing zone. Missing folder or incorrect agent configuration in the OUT folder. File already existing in the landing zone.	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.

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:

State	Description
Initial(I)	Whenever a request comes in for the execution of an exchange, the exchange step gets the initial status of 'I'
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.

Exchange Step Payload

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

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.

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:

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

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.

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.

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: Query	Data Collection Step of type Query	invokeQuery This refers to a (sub)step that indicates invoking a query step for data collection step.
Data Collection: Custom	Data Collection Step of type Custom	invokeCustomCollection This refers to a (sub)step that indicates invoking a custom step for data collection step.
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.
Deliver: Agent	If the destination defined in Delivery step is through agent	deliverByAgent This refers to a (sub)step that indicates delivering an integration through agent.
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.