OIC Gen3 - Retrieve CRM account details uaing Oracle CX Sales and B2B service adapter

Usecase:

Here,we will get CRM account details for an account id using Oracle CX sales & B2B service cloud application comnection.

Steps:

• Create an connection to an Oracle CX Sales & B2B service Cloud application.
• Create an integration and configure the rest trigger
• Implement logic to retrieve an account object from fusion cloud
• Implement the response mapping.

Detailed screenshots:

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