OIC Gen3 - configuring an allowlist to restrict access to an OIC instance from OCI console

Restrict the networks that have access to your Oracle Integration instance by configuring an allowlist (formerly a whitelist). Only users from the specific IP addresses, Classless Inter-Domain Routing (CIDR) blocks, and virtual cloud networks that you specify can access the Oracle Integration instance.

Steps to Configure an Allowlist

• Navigate to the OIC Instance
• Log in to the OCI Console.
• Go to "Developer Services" > "Application Integration" > "Integration".
• Select your OIC instance from the list.
• Network access > Edit
• Select restrict network access
• Add rules with protocol and type
• Enable loopback so that any oracle integration instance of your region can access your instance.

Screenshot:

Reference:

https://docs.oracle.com/en/cloud/paas/integration-cloud/oracle-integration-oci/restrict-access-instance.html

OIC Gen3 - How to see the integration processing time statistics

Use Case Overview:

To demonstrate the use case of viewing integration processing time statistics in OIC Gen3, we can follow this structured approach:

Objective:

To showcase how users can view and analyze integration processing time statistics in Oracle Integration Cloud (OIC) Gen3.

Key Features:

1. Processing Time Insights - View the time taken by integrations to execute.
2. Performance Monitoring - Identify bottlenecks or performance issues.
3. User-Friendly Dashboard - Leverage OIC Gen3's monitoring tools for real-time analysis.

Step-by-Step Demonstration:

1. Navigate to OIC Monitoring Dashboard: 
1. Log in to Oracle Integration Cloud (OIC) Gen3.
2. Go to the obserbability in the OIC Console.
2. Select Integration Statistics:
1. Under the observability section, choose Integrations.
2. You'll see a list of all deployed integrations.
3. View Processing Time:
1. Click on a specific integration to view detailed statistics.
2. Look for the Processing Time metrics. This typically includes:
1. Average Time: Average execution duration of the integration.
2. Minimum/Maximum Time: Shortest and longest execution durations.
3. Standard deviation
3. Trend Analysis: Graphs showing how processing times vary over a period.
4. Filter and Analyze Data: Use filters to narrow down the data:Time Period: Last hour, last day, last week, etc. Analyze the trends to identify any performance issues.
5. Export Statistics (Optional): If needed, export the statistics for reporting or analysis. Use the Export feature in the dashboard.

Show a comparison of processing times before and after an optimization to highlight the value of monitoring.

Business Benefits:

• Performance Optimization: Quick identification of slow-running integrations.
• Proactive Monitoring: Prevent issues before they escalate by observing anomalies.
• Operational Efficiency: Improved decision-making with real-time data.

Steps screenshots:

OIC - Input Validation: Ensuring Mandatory Fields Are Filled, else reject the payload

Use Case: 

Validating Mandatory Fields in REST Service Payload

Requirement:

The objective is to validate the mandatory fields received from the REST-exposed service. If any mandatory fields are missing, the payload should be rejected, and a custom fault should be thrown. This fault will then be handled in the global fault mechanism as per the defined business logic.

Implementation steps:

1. After the trigger setup, take throw new fault activity and provide as following
1. Code as "BUSINESS_ERROR"
2. Reason as "Mandatory fields are missing from the request payload"
3. Details: concat mandatory field names and request wrapper using get-content-as-string() function.
4. Add skip condition : add for all the mandatory fields like channelid !='' etc
2. In the global fault, define the business logic like here, 
1. we are sending the fault details to third party Saas software Datadog from there, it will emit alerts notification to desired support team
2. Also, added a return action and send the error details to the caller or invoker of this service.

Detailed screenshots:

OIC - when to use client credential flow vs Authorization code flow

In OpenID Connect (OIDC), the choice between the Client Credentials and Authorization Code flows depends on the type of application and the use case. Here's a breakdown of when to use each:

Client Credentials Flow - When to Use:

• The application is a server-to-server application (e.g., backend service or API).
• No user interaction is required.
• The application needs to authenticate itself to access resources or APIs on behalf of itself, not a user.

Examples:

• Machine-to-machine API calls.
• Backend microservices communicating with each other.

Key Characteristics:

Only the client_id and client_secret are used to obtain an access token.

No user context is involved.

Authorization Code Flow - When to Use:

• The application requires user interaction and wants to access user-protected resources.
• Typically used by web applications and native applications that act on behalf of the user.
• The application needs a high level of security, such as obtaining a refresh token or delegating user-specific actions.

Key Characteristics:

• Involves a user logging in and consenting to the application accessing their data.
• Includes a code exchange process where the application gets an authorization code and exchanges it for an access token.
• Ensures sensitive information (e.g., client_secret) isn't exposed in the browser.

Summary of Use Cases

If your application involves users logging in and granting permissions, go with the Authorization Code flow. 

If it's just a backend system communicating with another system, the Client Credentials flow is the right choice.

Example of security policy: Oauth Client credential added to OIC connection:

Connextion name: Conn_REST_<target>_TriggerInvoke_OAuth

OIC - Handling Two Different Types of REST Responses in a REST API Call

Usecase:

When integrating with REST APIs using Oracle Integration Cloud (OIC), it's common to encounter scenarios where the API returns different response structures based on the outcome of the operation. 

For example:

Success Response: 

{ 

"success": 1,

"trans_suc_time":"" 

}

Failure Response: 

{ 

"success": 0, 

"error_code": "201"

 }

Managing such variations in response payloads can be challenging, but OIC provides several ways to handle this seamlessly. Here, we will explains how to effectively handle multiple response types in a single REST API integration.

Solution:

Create a unified Json payload using the above two types of response.

The unified json payload used:

{ 

"success": 0, 

"tranc_suc_time":"",

"error_code": "201"

 }

POC execution steps:

1. Create REST Connections: Set up REST trigger and REST OIC self trigger invoke connections in OIC. 
2. Build Integration 1.0.0: Create a REST-based integration with specific request and response payloads.
3. Create new version 1.0.1 and Modify: Copy version 1.0.0, modify the response payload, and activate as version 1.0.1.
4. Design an Invoker Integration: Create a new integration to use a unified payload and dynamically call either version (1.0.0 or 1.0.1), keeping only one active at a time.

Detailed poc screenshots:

OIC Gen 3 - installing a Connectivity agent

Workflow for using the connectivity agent:

1. Create an agent group
2. Download the agent installer
3. Download the agent group config file
4. Install jdk 17 and install agent
5. Create an adapter connection and select the agent group
6. Design an integration that uses the connection.

Step1: Create an agent group

Navigation: Design >> agents >> create >> provide agent name >> create

An Oauth client app will be auto created in OCI IDCS.

Step2: Download the agent installer

Navigation: Design >> agents >> doenload >> connectivity agent

It will download a .zip file(oic_conn_agent_installer.zip)

The zip has following files

• Agent home
• Connectivityagent.jar
• Cpi_upgradeutility.jar
• InstallerProfile.cfg

Step3: Download the agent group config

Navigation: Design >> agents >> select ellipsis(...) of the created agent group >> download config.

It will download the InstallerProfile.config file, filled with  all the Oauth details like client id, cliwnt secret, scope, idcs url, oic url, agent group identifier etc.

Step4: Ensure that you have installed jdk 17 and set $JAVA_HOME and update $PATH to include $JAVA_HOME/bin

Step5: Install agent

Go to command prompt >> cd the agent installer unzipped path >> run the below command

java -jar connectivityagent.jar

To run in the background: 

nohup java -jar connectivityagent.jar &

Step6: Associate the connection with agent group

Restarting the agent:

Stop the agent on host machine:

CTRL + C or kill -9 pid

Run the agent with same cmd:

java -jar connectivityagent.jar

Agent monitoring:

Observability >> agents

Post-Installation: Examining the Files

• Located in the agenthome/agent/config directory:
• CpiAgent.properties: Contains infrastructure information.
• logging.properties: Specifies logging severity levels.
• Located in the agenthome/logs directory:
• Agent diagnostic log files: Used for troubleshooting information.

OIC Gen3 - Provision an OIC instance and assign OIC Service roles

Usecase: 

Here, we will demonstrate how to provision an OIC instance and assign OIC service roles to a group of users.

Note: To provide people acccess to the oracle integration, create users, assign them to groups and then assign preconfigured roles to the groups, assign policies to groups to give access to resources.

Resource Type: integration-instance

Verb: MANAGE

Permission:INTEGRATION_INSTANCE_CREATE

 

Detailed steps with screenshots:

Login to OCI console >> Navigation >> developer services >> application integration >> integration

Select compartment >> create instance

Provide instance name>> select edition >> select shape >> create

Once instance gets activated, copy service console url and open in browser to login.

Here we will see how to add users to group and add servicedeveloper role to that group.

Identity & Security >> Domains 

Domains >>default or create new domain

Groups>> create group

Open the group and add users

Identity & Security >> Domains >> dafault >> Oracle cloud services

Select the created instance

Application roles >> serviceDeveloper >>assigned groups >> add the group

Reference:

https://docs.oracle.com/en/cloud/paas/integration-cloud/oracle-integration-oci/iam-policies-oracle-integration.html

OIC - How to import prebuilt integrations from oracle market place | Oracle Utility CCS

Usecase: 

Here, we will see thw steps how to dwonload prebuilt integrations from oracle market place and import to OIC.

Steps to follow:

All integration points are shipped as part of single project (.car) file.

To import a pre-built integration from Oracle Cloud Marketplace:

1.Launch the Oracle Cloud Marketplace portal.

https://cloudmarketplace.oracle.com/marketplace/en_US/homePage.jspx

2.Click Applications.

3.Search for “Oracle Utilities Customer Cloud Service”.

4.Browse through the list of applications and select the pre-built integration project to import.

5.Click GetApp.

6.Review and accept “Oracle Standard Terms and Restrictions”.

7.Click Next. MyOracle Support portal opens.

8.Download the integration project from MyOracle Support.

9.When prompted, select the server where the pre-built integration file should be uploaded.

The pre-built integration is imported as a project file that is visible on the Project page in Oracle Integration Cloud.

10.On the Integrations page, the individual integrations of the imported project file that are designated with a BUILT BY ORACLE message are displayed.

Important! This note is applicable only for existing customers. Make sure to take a backup of the existing project and lookups, and perform the clean up before proceeding with the new project import. The clean up includes deactivating the existing flows in this package and deleting the project, connections, lookups and libraries used in the integration.

To import a project in Oracle Integration Cloud:

1.Login to Oracle Integration Cloud.

2.Navigate to Projects.

3.Click Import.

4.Select the .car file downloaded from Oracle Cloud Marketplace.

5.Verify if the project is imported is successfully.

References:

Prebuilt integrations main page:

https://docs.oracle.com/en/industries/energy-water/cloud-integrations/index.html

steps to download and import:

https://docs.oracle.com/en/industries/energy-water/cloud-integrations/24b/ccs-erp-configuration-guide/index.html#page/CCS-ERP-CONFIGURATION-GUIDE/CCS-ERP_Import-Configure-Test_Connections.07.2.html#ww1025695

Oracle Cloud Marketplace: 

https://cloudmarketplace.oracle.com/marketplace/en_US/homePage.jspx

OIC Gen3 - Oracle Integrations 3 Editions

OIC Gen3 - Understanding of OIC Service roles

In Oracle Cloud Infrastructure (OCI) Gen 3, service roles are specialized permissions that allow users to perform specific operations within the Oracle Integration Cloud (OIC) service. These roles help manage user access at a granular level, ensuring only authorized users can perform certain tasks within OIC. Here’s an overview of the key service roles:

1. Service Administrator

• This role grants full access to the OIC service.
• Users with this role can configure, monitor, and manage integrations, processes, and visual applications.
• They have permissions to access and modify all aspects of the OIC environment, including integration flows, settings, connections, and monitoring tools.
• Ideal for IT administrators or DevOps personnel responsible for end-to-end management of the integration platform.

2. Service Developer

• Designed for users who need to create and manage integrations, process flows, and visual applications.
• Developers can create connections, build integrations, set up orchestrations, and configure REST/SOAP services.
• However, they typically lack permissions for high-level administrative tasks that alter the environment or user access.

3. Service Monitor

• This role is focused on monitoring and viewing capabilities.
• Service Monitors can track the status of integrations, view performance metrics, and analyze logs.
• They cannot make changes to the configurations or deploy new integrations.
• Ideal for support staff or business analysts who need insights into integration performance without administrative rights.

4. Service User(service viewer + service invoker)

• This is the most limited role, often given to end-users who interact with OIC applications or APIs.
• Users with this role may only access integrations that are exposed to them but do not have permissions to modify or configure services.
• Useful for business users or consumers of APIs who need to access OIC features without any administrative control.

5. Service Viewer (OCI Role)

• The Service Viewer role in OCI generally grants view-only access to the resources and configuration of a service.
• In OIC, this type of role would allow users to view configurations, integrations, and monitoring dashboards without the ability to create, edit, or execute integrations.
• However, OIC itself does not explicitly use a “Service Viewer” role; instead, the Service Monitor role serves a similar purpose for monitoring within OIC.
• For broader access at the OCI platform level, Service Viewer can be useful for administrators who need a read-only view into multiple OCI services, including OIC.

6. Service Invoker (OCI Role)

• The Service Invoker role allows users or services to invoke actions within a service, typically through API calls.
• In OIC, this type of role could correspond to allowing a user or a process to invoke integrations or access APIs exposed by OIC.
• Though OIC does not have a dedicated Service Invoker role, permissions for invoking integrations or APIs are often managed through the Service User role or specific policies granting invoke access.
• At the OCI level, Service Invoker can be applied to service principals (e.g., functions, other cloud services) to allow automated interactions with OIC.

Configuring OCI Roles for OIC Access

To grant Service Viewer or Service Invoker-like access to OIC in an OCI tenancy, you can create IAM policies in OCI that assign these roles to specific users or groups.

For example, you could write policies like:

Allow group Viewers to read integration-instances in compartment <compartment_name>

Allow group Invokers to use integration-instances in compartment <compartment_name>

OIC gen3 - using the OCI Object Storage Action | Create bucket | Upload an object to the bucket

Usecase: 

Here, we will create a bucket and upload an object to OS bucket.

In Oracle Integration Cloud (OIC), we can use the OCI Object Storage action to interact with Oracle Cloud Infrastructure (OCI) Object Storage, allowing integration workflows to upload, download, and manage files stored in OCI.

Supported Operations

Under Manage objects:

• Upload Object: Store files in a specified bucket, enabling integration processes to archive data or manage backups.
• Download Object: Retrieve files from a bucket, useful for processing files stored in Object Storage as part of workflows.
• List Objects: Get details on files within a bucket, useful for fetching metadata or initiating further actions based on file availability.
• Delete Object: Remove files from a bucket, which is helpful for cleaning up temporary data or managing lifecycle policies

Under manage buckets:

• Create bucket
• List buckets
• Delete buckets

Bucket creation:

Steps to follow:

1. Create an Application and configure rest trigger to pass the Bucket name as query param or template or body.
2. Drag and drop the OCI object storage and configure
1. Choose manage buckets
2. Choose create.bucket
3. Choose the compartment
3. Map the bucket name to be created.

Screenshots:

Upload an object to the Bucket:

Steps to follow:

1. Create an Application and configure rest trigger to pass the following 
1. the Bucket name and object name as query param
2.  Binary object as request body
2. Drag and drop the OCI object storage and configure
1. Choose manage objects
2. Choose upload objects
3. Map the bucket name, object name and stream reference of the object.

Screenshots: