OIC - Gen3 - Connectivity agent basic authentication not supported | Support only OAuth 2.0 for Connectivity agent

New changes for connectivity agent:

• While using connectivity agent, basic authentication is not supported in generation 3. 
• To install and use connectivity agent, we need to use OAUTH 2.0 token based authentication in installerprofile.cfg file.
• Create an agent group and download the config which will have all the details auto generated.
•  Just then download the connectivity agent, unzip and replace the installerprofile.cfg file.

Navigation>> Go to Design >> agents

Download the agent

We can see client id and secret and scope added.

Download the config for the agent group to be used.

OIC - Split comma separated string values to Array | Use of create-nodeset-from-delimited-string() function in XSLT

UseCase: Here, we will show you how to split an input, received as comma separated string values( here, emails) into array of values using create-nodeset-from-delimited-string() function.

Logic steps:

• Create a rest trigger connection
• Create an app driven integration and configure using request and response jsons
• Map the request to response using create-nodeset-from-delimited-string() function.

Input json:

{

"Emails":""

}

output json:

{

"Emails":[{

"Email":"",

},{

"Email":""

}]

}

XSLT code:

<nstrgmpr:executeResponse>

<nstrgdf1:response-wrapper>

<nstrgdf1:Emails>

<xsl:for-each select="oraext:create-nodeset-from-delimited-string('{http://test.com/sample/xml}value',/nstrgmpr:execute/nstrgdf1:request-wrapper/nstrgdf1:Emails,',')">

<nstrgdf1:Email>

<xsl:value-of select="."/>

</nstrgdf1:Email>

</xsl:for-each>

</nstrgdf1:Emails>

</nstrgdf1:response-wrapper>

</nstrgmpr:executeresponse>

Details steps with screenshots:

Rest configure to input comma separated strings and get back response as array.

Map the rest request which is the comma separated strings to array using create-nodeset-from-delimited-string() function.

Test:

Note: we can also use oraext:create-delimited-string() XSLT function to convert nodes to delimited string.

Reference:

https://blog.deciphermiddleware.in/2020/12/create-delimited-string-or-xml-nodes.html

OIC - Gen 3 - How to Regulate access to a project | RBAC | Resource based access control

Oracle Integration Cloud Gen3: how to regulate access to a project?

A project can either be accessible to all users, depending on their service role (administrator, developer, monitoring rights, etc.), or restricted to a defined list of users.

• By managing access to projects by users or groups of users via the role-based access control (RBAC) system, it is possible to isolate a project and make it accessible only to a specific group of users. In this way, multiple users working on different projects can work on the same Oracle Integration Cloud instance. 
• This role system gives groups of users access and the right to view, edit and monitor only the resources of a project assigned to them.
• Service roles (ServiceDeveloper, ServiceMonitor, ServiceInvoker etc.) assigned to each instance user have priority over permissions delegated within a project. So, if a user only has the right to monitor the instance, he or she cannot be given the ability to edit project resources. 
• In terms of limitations, a maximum of 5 users or user groups can be defined for each project role (viewing, editing and monitoring).

Example of compartmentalizing an OIC Gen3 instance into projects

Note: 

• The rights defined on a project are not migrated at the same time as the project to another environment (test or production). 
• The user who imported the project to another environment is by default the owner of this project. It’s up to him to assign rights to project participants once again.

This permissions system enables parent integrations of a project to call child integrations:

• for the same project;
• another project, but with access defined as public
• globally accessible, i.e. not part of a project.

It is also possible to convert a package into a project.

Reference:

https://www.sqorus.com/en/new-features-oracle-integration-cloud-gen3/#:~:text=Oracle%20Integration%20Cloud%20Gen3%3A%20a%20fresh%2C%20new%20design&text=The%20navigation%20panel%20has%20also,Creating%20and%20manipulating%20an%20integration

OIC - Read latest file from SFTP server | Poll the file last time modified from a SFTP server

Usecase: Client has given a requirement that the file polling folder may have multiple files and we only need to read or poll latest file or the file last time modified.

Logic flow:

1. Create a sftp and rest connections.
2. Create an appdriven integration and configure rest to read the latest file and contents as response.
3. List the files using sftp adapter.
4. Read the latest file using sftp adapter. The tweaking, we have to do in the mapping file itself. 
1. For each file, we have to sort as descending order based on lastModifiedTine
2.  and if position =1 map the file name and ditectory
5. Then map the read file contents  and file name to rest response.

Used json:

{

"FileName":"",

"Employees":{

"Employee":[

{"Empid":1,"Fname":"","Lname":"","Dept":"","Age":"","Country":"","Skill":""},

"Empid":1,"Fname":"","Lname":"","Dept":"","Age":"","Country":"","Skill":""}

]

}

}

Map part for reading latest file:

<nstrgmpr:SyncReadFile>

<ns27:FileReadRequest>

<xsl:for-each select="$listFiles/nsmpr2:ListFileResponse/ns24:ListResponse/ns24:FileList/ns24:File">

<xsl:sort select="ns24:lastModifiedTime" order="descending"/>

<xsl:if test="position()=1">

<ns27:filename>

<xsl:value-of select="ns24:filename"/>

</ns27:filename>

<ns27:directory>

<xsl:value-of select="ns24:directory"/>

</ns27:directory>

</xsl:if>

</xsl:for-each>

</ns27:FileReadRequest>

</nstrgmpr:SyncReadFile>

Detailed screenshots:

Integration flow:

Configure rest trigger to read the latest file name and contents as response.

List the files:

Read the latest file:

Add tracking, save, activate and test

OIC - Gen3 - How to publish and subscribe events | What is oracle integration events | what is publish event action

Oracle has recently introduced a new feature called Event in Oracle integration generation-3 which is equivalent to the Publisher and Subscriber model of Oracle integration generation-2.

What is event?| what is oracle integration events? | Restrictions?

• Events are raised when something happens in the system such as employee onboarded, Order created etc. Once the events are published, multiple applications can subscribe to the events
• Starting OIC version 23.06 introduced this event concept.
• Support only JSON payload.
• The publish and subscribe feature enable us to decouple producers and subscribers.
• A maximum of 20 subacribers can subscribe to events per service instance.

Steps to follow:

1. Define event and Payload (Only JSON and xml schema supported)
2. Create Publish Integrations
3. Create Subscribe integrations

Detailed Steps with screenshots:

Create event:

Publish event from publisher integrations:

Create subscriber events

OIC - How many different scheduled integrations can run in parallel in Oracle Integration | Decoupled scheduler and Business Logic pattern.

Though OIC now provides dynamic threading model for scheduled orchestration integrations but it still has thread limitation. Thread count is internal to Oracle and may vary based on instance / subscription type.

Scheduled integration interfaces are widely used in batch integrations. Oracle Integration cloud provides feature to build scheduled integration flows, that can execute at defined frequency. However sometimes users complain about inconsistent behavior of scheduled flows like schedules are getting delayed by few minutes to few hours.

In this blog, We will discuss a common design issue that causes such incidents and solution for it.

What problem we faced and observed:

If we have a large of number of scheduled integrations running in parallel, then we will observe that few are running and others kept in queued and the backlog getting increased which delayed the processing of the backlog scheduled integrations.

For instance:

 I have created 6 scheduled integrations and run them in parallel and observed:

• 4 scheduled integrations are running in parallel. 
• whereas 2 integrations are in queued. 
• Once running ones completed, then the queued one started running. 

So what I understand for my OIC instance it has 4 scheduler threads limitation.

• o it can be made as re-usable component.

Solution:

We can decouple scheduler and integration logic into 2 different flows and let scheduled integration just invoke the child integration using Fire & Forget pattern.

1. For decoupled design, instead of creating many scheduled inegrations, we can create 1 or few  parent (Scheduled integrations) and others are Child (non-scheduled) application integration flows, simply exposed as REST endpoint.
2. Child flow exposes REST endpoint with "POST" verb and not returning any response hence making it a "One Way" flow. So it can be invoked as Fire & Forget .
3. Each Parent flow invokes its respective child flow. However since child is "one way" flow its not returning anything. So parent flow won't wait for the response after invoking child flow. It will either terminate and release the thread or move to next activity (if any).
4. Child integrations will use worker thread for processing. So this time, when one or few scheduled integration triggered at the same time, they were terminated within few seconds and there were 6 or more child integrations in "running" state, Running in parallel.

Reference:

https://www.ateam-oracle.com/post/oic-scheduler-decoupled-scheduler-and-business-logic-pattern

OIC - Best Practice - Run large number of scheduled integrations at the same time | avoid creating too many scheduled integrations

When there are too many schedule integrations configured, instances can become backlogged waiting for resources to become available or previous integration runs to complete. This can cause processing delays where some instances are in a waiting state longer than they must be and schedules may not start at the scheduled time.

Best practice:

A. Do not create too many schedule integrations that are scheduled to run at the same time. Where possible:

• Use an asynchronous REST Adapter trigger instead of a scheduled trigger when an active schedule is not absolutely required.
• Do not create any long-running schedule integrations (a schedule integration that takes longer than one hour, for example, to complete). This blocks scheduler resources impacting other scheduled runs.
• Spread schedules out over time to avoid schedule clusters.

B. We can convert a schedule integration to a REST Adapter trigger-based application integration.

If you absolutely require a large number of schedule integrations, and you encounter the previously described issue, the following design changes as a solution are recommended:

1. For each schedule integration, convert it to a REST Adapter trigger-based application integration.
2. Create a new schedule integration that only performs an asynchronous invoke of the application integration you converted in step 1 above.

   This solution enables the schedule integration to start at the scheduled time, invoke the REST Adapter trigger-based child integration asynchronously, and complete within milliseconds. This approach reduces the backlog and contention surrounding scheduler resources.

   If you have a large number of schedule integrations to convert, a staged approach starting with the following integrations is recommended.

   • Longest-running schedule integrations.
   • Schedule integrations configured with the shortest frequency (for example, integrations that run every 10 minutes or less).

   Design any new schedule integrations with the design practices described above.

Reference:

https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/common-integration-style-pitfalls-and-design-best-practices.html