Setup Overview

An Integration setting comprises the following details:

Field Description Mandatory?

Field	Description	Mandatory?
Type	The identifying type of integration. The types depend on the localization. One type that is available in all installations is Integration.	Yes
Code	The unique code of the integration	Yes
Description	Free text describing the specifics of the integration.	Yes
Schedule	Specifies the schedule in cron format for timed integrations. Example: 0 40 10 * * *, means that the integration runs every day at 10:40 AM. The cron format is 'seconds', 'minutes', 'hour', 'day of month', 'month', 'day of week'	No
Time Allowed	The time allowed for an exchange to finish, If an integration specifies a value for this attribute, then after the allowed time, an incomplete exchange, is marked as timed-out. This is checked at the start of every exchange sub-step and the value is specified in minutes. NOTE: This does not apply to blocking invocation.	No
Remove Data Files After Completion?	When enabled, removes all Data Files for Exchanges of this Integration after the Exchange completes saving database disk space. Enable this feature only if the Data Files are no longer needed after the Exchange completes. The Data File Set metadata remains in place. Field Files Deleted Date on the Exchange shows when the Data Files for the Exchange were removed.	No
Input Parameter Extraction Dynamic Logic	A Dynamic Logic function to parse the integration invocation (trigger) message (payload) and extract integration parameters.	No
Error Destination	REST Destination to send a workflow event in case of a technical/business error or exchange timeout.	No
Error Payload Dynamic Logic	A Dynamic Logic function to construct a payload in case there are technical errors or timeout and a notification needs to be sent to action on it.	No
Enabled?	A sign of whether the integration is enabled or not. If the value of the flag is `false`, then any external event or the scheduler cannot invoke the integration.	Yes
Version	The version number of the integration. `NULL` is the lowest version. In case there are multiple versions for an integration, the application picks up the highest-enabled version for the integration code. You can invoke an exchange for a specific integration version. Refer to the Exchange Integration Point for more details. NOTE: Correlation of versions is per integration code. The application considers an update to the integration code as a new integration with its own versioning lifecycle. We recommend creating a new version for structural updates, such as deleting or adding an integration step. We recommend you to avoid creating new versions for attribute updates - such as the integration description. Having many versions for an integration decreases performance in both UI and processing.	No
Access Restriction	Access restriction of type Integration. The invocation of exchange gets restricted to users that have access grants to this access restriction. NOTE: This does not apply to event-based and scheduled invocation.
Integration Parameters	List of named parameters needed for invoking an integration.	No
Integration Steps	List of integration steps. Please refer to the section Integration Steps for details.	Yes

Type

The identifying type of integration. The types depend on the localization. One type that is available in all installations is Integration.

Yes

Code

The unique code of the integration

Yes

Description

Free text describing the specifics of the integration.

Yes

Schedule

Specifies the schedule in cron format for timed integrations. Example: 0 40 10 * * *, means that the integration runs every day at 10:40 AM. The cron format is 'seconds', 'minutes', 'hour', 'day of month', 'month', 'day of week'

Time Allowed

The time allowed for an exchange to finish, If an integration specifies a value for this attribute, then after the allowed time, an incomplete exchange, is marked as timed-out. This is checked at the start of every exchange sub-step and the value is specified in minutes.

NOTE: This does not apply to blocking invocation.

Remove Data Files After Completion?

When enabled, removes all Data Files for Exchanges of this Integration after the Exchange completes saving database disk space. Enable this feature only if the Data Files are no longer needed after the Exchange completes. The Data File Set metadata remains in place. Field Files Deleted Date on the Exchange shows when the Data Files for the Exchange were removed.

Input Parameter Extraction Dynamic Logic

A Dynamic Logic function to parse the integration invocation (trigger) message (payload) and extract integration parameters.

Error Destination

REST Destination to send a workflow event in case of a technical/business error or exchange timeout.

Error Payload Dynamic Logic

A Dynamic Logic function to construct a payload in case there are technical errors or timeout and a notification needs to be sent to action on it.

Enabled?

A sign of whether the integration is enabled or not. If the value of the flag is false, then any external event or the scheduler cannot invoke the integration.

Yes

Version

The version number of the integration. NULL is the lowest version. In case there are multiple versions for an integration, the application picks up the highest-enabled version for the integration code. You can invoke an exchange for a specific integration version. Refer to the Exchange Integration Point for more details.

NOTE: Correlation of versions is per integration code.

The application considers an update to the integration code as a new integration with its own versioning lifecycle. We recommend creating a new version for structural updates, such as deleting or adding an integration step. We recommend you to avoid creating new versions for attribute updates - such as the integration description. Having many versions for an integration decreases performance in both UI and processing.

Access Restriction

Access restriction of type Integration.

The invocation of exchange gets restricted to users that have access grants to this access restriction.

NOTE: This does not apply to event-based and scheduled invocation.

Integration Parameters

List of named parameters needed for invoking an integration.

Integration Steps

List of integration steps. Please refer to the section Integration Steps for details.

Yes

Integration Steps

Integration comprises many configurable steps of different types, being: Data Collection Step, Invoke Process Step, Transform Step, Delivery Step, and Subflow Step.

Data Collection Step supports the following features:

Extract: collects data as an extract from the OHI application by invoking Extracts Integration Point.
Query: performs queries using Query API from OHI applications.
Custom: executes custom dynamic logic to collect data from OHI or non-OHI systems.

Invoke Process Step triggers a process, such as starting an activity in an OHI component.

Invoke Activity: Out of the box mechanism to invoke OHI Activity Endpoint to start or monitor an activity.
Invoke Process (other than activity): Invokes endpoint as specified by the destination.

Transform Step transforms the payload into another format.

Delivery Step optionally transforms the data collected in the previous steps and delivers it to the configured destination. This step supports several delivery options, including REST, SFTP, or inbuilt for FileUpload (based on OHI Data File Set IP), Fusion, and Documaker.

Subflow Step refers to a subflow, which comprises one or more of the steps above. Subflow represents a set of integration steps that are performed again and again in the integration, either in a sequence or in parallel.

The order and number of each step depend on the integration. An integration setup can include multiple steps of the same type. For example, consider a scenario in which:

A single data extract gets transformed in multiple ways and subsequently delivered to different locations. Such as, a tax office extract gets delivered both to the tax office as a file, and to the individual members as a PDF file. Such Integration would have one data collection step of type Extract, followed by two Delivery steps.
A data extract gets built up in a series of steps, each step retrieving information from another source system before it gets finally delivered to a destination. For example, to construct monthly liability vs income report, configure two Extract steps, namely 1) extract member - claim data from the Claims system and 2) extract member - premium data from the policy system. This data transforms into a single file and delivers using one Delivery step.

For more details on each of these integration steps, refer specific section of the chapter Integration Steps in the Configuration Guide.

Integration Invocation

An integration is scheduled for invocation or gets invoked by an external actor.

Scheduled: A cron parameter controls the integration invocation schedule. The integration process kicks in as soon as the scheduled time arrives.

External actor: An external actor can invoke Integration using Exchange Integration Point or through an Agent.

Invocation of integration results in creation of an exchange. Exchange is a single instance of or execution of an integration. For details on this run time model, refer to the chapter Exchange in the Operations Guide.

Exchange Integration Point

For details, refer to the chapter "Exchange Integration Point" in the Developer Guide.

Agent

OHI Agent is a component that complements an Oracle Insurance Gateway instance that runs in the Oracle Cloud by providing access to on-premises resources that are not available to the Oracle Insurance Gateway in a cloud deployment.

The following picture provides a high-level overview of the operating context for OHI Agent:

For more details on configuring and running an agent refer to Oracle Health Insurance Agent chapter of the Developer Guide.

Integration Parameters and Exchange Properties

When the integration gets invoked, a map of properties gets available to the runtime instance - Exchange. This property map refers to as Exchange Properties. The properties map is a way for integration steps to share information and parameterizing the steps with information at runtime. It contains the following information:

The parameters with which the integration was invoked
The header values with which the integration was invoked (except the Authorization header)
All properties that were added to the properties map in dynamic logic in the previous steps or current step.
Internal framework properties that were added during the exchange flow.

In any step configuration, properties can be used as bind parameters. The below configuration shows a query on the claims resources wherein the query string is a condition on the value of the property correlation ID. This is signified by putting open and close curly braces around the parameter name, for example {correlationId}. The value of correlationId parameter gets replaced at the time of query step invocation from the values in exchange properties. If there is no value present for parameter correlationId in the exchange properties, an error is thrown.

{
  "typeConfig" : {
      "resourceName": "claims",
       "q": "correlationId.eq({correlationId})",
       "fields"  : "claimLineList.claimLineMessageList.message.message"
  }
}

For more details on properties, refer to Gateway Dynamic Logic Bindings

Integration Parameters Configuration

Integration Parameters are a detail list of the Integration and can be setup along with the Integration.

Oracle Insurance Gateway uses this configuration: 1. To set default values when the integration gets invoke using Oracle Insurance Gateway scheduler. 2. To set up validation rules, specify a certain parameter when invoking the integration 3. For the user interface invoke exchange page to show the list of applicable parameters when a user selects an integration to invoke.

Field Description Mandatory?

Field	Description	Mandatory?
Name	Name of the parameter	Yes
Data Type	1) Char 2) Number 3) Date and 4) Boolean	Yes
Mandatory?	true or false Shows that this parameter must have a value at the time of integration invocation, either through a default value during configuration or by overriding it. Default is set to `false`	Yes
Default Value	The integration is invoked with the specified value (as the input parameter value) if an overriding value is not provided at the time of integration invocation.	No

Name

Name of the parameter

Yes

Data Type

1) Char 2) Number 3) Date and 4) Boolean

Yes

Mandatory?

true or false

Shows that this parameter must have a value at the time of integration invocation, either through a default value during configuration or by overriding it. Default is set to false

Yes

Default Value

The integration is invoked with the specified value (as the input parameter value) if an overriding value is not provided at the time of integration invocation.