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

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 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
exchange-status

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'

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-status.jpg

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: 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.

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.