Integration

An Integration setting consist of the following details:

Field	Description	Mandatory?
Type	The identifying type of integration. The types that are available depend on the localization. One of the types 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 * * * , it 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
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 reach out to in case of a technical or business error.	No
Error Payload Dynamic Logic	A Dynamic Logic function to construct a payload in case there are technical errors and some notification needs to be sent to action on it.	No
Enabled?	An indication whether the integration is enabled or not. If the flag is false, then any external event or the scheduler cannot invoke the integration.	Yes
Version	The version of the integration. Relevant when different versions of an integration are concurrently supported by {Oracle Insurance Gateway} (applicable for select few localization specific integrations). The payload or the file with which the integration gets invoked specifies the version information. See localization guide for more details. In case there are multiple versions, and the payload specific resolution is not present, the system picks up the latest created integration. ^Note - This field is not applicable to integrations of type "integration"^	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 is not applicable 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

Field

Description

Mandatory?

Type

The identifying type of integration. The types that are available depend on the localization. One of the types 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 * * * , it 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'

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 reach out to in case of a technical or business error.

Error Payload Dynamic Logic

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

Enabled?

An indication whether the integration is enabled or not. If the flag is false, then any external event or the scheduler cannot invoke the integration.

Yes

Version

The version of the integration. Relevant when different versions of an integration are concurrently supported by {Oracle Insurance Gateway} (applicable for select few localization specific integrations). The payload or the file with which the integration gets invoked specifies the version information. See localization guide for more details. In case there are multiple versions, and the payload specific resolution is not present, the system picks up the latest created integration.

^Note - This field is not applicable to integrations of type "integration"^

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 is not applicable 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

An integration consists of a number of 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/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/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 step(s) and delivers it to the configured destination. Several delivery options are supported by this step, 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 of one or more of the above mentioned steps. 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 nature of the integration. An integration setup can include multiple steps with 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, as well as 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, two Extract steps are configured, namely 1) extract member - claim data from claims system and 2) extract member - premium data from the policy system. This data gets transformed into a single file and gets delivered using one Delivery step

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

Integration Invocation

An integration is either 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/execution of an integration. For details on this run time model refer to the chapter Exchange in the guide.

Exchange Integration Point

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

Agent

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

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

For more details on configuring and running an agent refer to the Agent guide.

Integration Parameters and Exchange Properties

When the integration gets invoked, a map of properties gets available to the run time instance - Exchange. This property map is referred to as 'Exchange Properties'. This properties map is a way for integration steps to share information and parameterize 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. Below configuration shows a query on the claims resources wherein the query string 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 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, that a certain parameter must be specified when the integration is invoked and 3) for user interface invoke exchange page to show the list of applicable parameters when a user selects an integration to invoke.

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 Indicates that this parameter should 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

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

Indicates that this parameter should 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.