OIC Gen3 - using Projects - Create a hello world integration with rest trigger.

Usecase:

Here we will see the following:

• Create a project
• Create a rest trigger 
• Create a application integration
• Configure rest trigger and map the response using concatenation function.
• Add tracking
• Activate and test
• Check the instances in the observe section.

Detailed with screenshots:

 

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: