Thursday, December 18, 2025

#1110 - Moving Integrations to Projects via Factory API

Introduction


Projects are a key feature in OIC3 and you need to start using them, in order to take advantage of all the cool new features we have.

Today you can copy your integrations from the "global space" into projects - Here's a simple example - 

 
I use the copy integration option -

As you can see, I have 3 integrations in the global space. In this case, I want to copy both ERP integrations into this projects, but as you can see, there is no multiple select option here, so I need to do this one at a time.


Now I will look at implementing a more complete solution, using the factory api.

In my simple use case, I want to move all integrations prefixed with ERP_ to my ERP Project,  AA_MY_ERP_PROJECT.

First step is to retrieve the ERP integrations - here's the api call -
https://design.integration.us-phoenix-1.ocp.oraclecloud.com/ic/api/integration/v1/integrations?q={name: /ERP_/}&integrationInstance=myOICInstance

The response is as follows -

{
    "hasMore": false,
    "items": [
        {
            "code": "ERP_CREATEORDER",
            "compatible": true,
        ...
    "id": "ERP_CREATEORDER|01.00.0000",
        ...
    "percentageComplete": 100,
            "projectType": "DEVELOPED",
        ...
    "status": "CONFIGURED",
       ...
        {
            "code": "ERP_GETORDER",
          ...
    "totalResults": 2
}

The following api call copies the integration to a project -

POST - https://design.integration.us-phoenix-1.ocp.oraclecloud.com/ic/api/integration/v1/projects/myProject/integrations/copy?integrationInstance=myOICInstance

Note the request payload - 

{"projectCode":null,"integrations":[{"code":"ERP_GETORDER","version":"01.00.0000"}]}

I check my new project - 

ERP_GETORDER is still present in the global space. 
In the meantime, I've activated the ERP_CreateOrder integration.

This will set the status accordingly. 

  "status": "ACTIVATED",


I copy this integration to the project - 

Excellent! My ERP integrations are in my ERP Project. But wait a minute, they're still in the global space. I need to delete them form there, this is, after all, a move.

Activated integrations cannot be deleted, so I need to check the status field, shown above. 

If status = ACTIVATED then I need to deactivate -

For this I use the following api -

Here I need the id field from the GET Integrations response.

https://design.integration.us-phoenix-1.ocp.oraclecloud.com/ic/api/integration/v1/integrations/ERP_CREATEORDER|01.00.0000?integrationInstance=myOICInstance

Now to deletion, here I use - 

https://design.integration.us-phoenix-1.ocp.oraclecloud.com/ic/api/integration/v1/integrations/ERP_CREATEORDER|01.00.0000?integrationInstance=myOICInstance






ERP_CREATEORDER Integration is deleted - 

Finally, let's build a UI around this; starting point is the following OIC Project -


These 3 integrations encapsulate the api calls we've already discussed.

Get Integrations: retrieves a list of integrations, based on a filter - 

 

I invoke this from a simple VB app - 

This page includes a table, I activate multiselect on its rows - 
The table gets its data from the following service connection endpoint -

Back to OIC, the next integration we'll look at is Move Integrations. This integration does the following - For the integrations list received, iterate over each integration, invoking the 3rd integration, Copy Integration, which copies the integration to the target project specified in the VB app. It then checks whether the integration status = ACTIVATED; if this is the case, the integration is deactivated. Finally, the integration is deleted from the global space.

I will now show you how to add the endpoint of Move Integrations to the VB Service Connection.

That's it - simple stuff!

Summa Summarum

The OIC UI will soon support the ability to do multi-selects on a list of integrations and then move them to a project. You can consider using the option described in this post, until the OIC UI supports such.
 

















Friday, December 12, 2025

#1109 - OIC Projects Factory API

Introduction 

Essentially this post contains some notes for myself, however, maybe interesting for others.

OIC Projects

Project Status

Projects have a status - 
Running the REST API for GET Projects, I see the following values - 

  • "status": "CONFIGURED", 
  • "status": "ACTIVE", 
  • "status": "DRAFT", 
So what do these mean?


When I execute GET Projects in postman, I see this project has the "status": "CONFIGURED".

Now I activate the 2nd integration -

I re-run the GET Projects api call - and see "status": "ACTIVE".


The following project has the status = DRAFT -

"items": [
        {
            "cloneRestrict": "NONE",
            "code": "AA_DRAFT",
            "id": "AA_DRAFT",
          ...
            "name": "AA-DRAFT",
            ...
                "lockStatus": false,
                "locked": {},
                "projectRevisionId": 6,
                "serviceInstanceId": 0,
                "status": "DRAFT",
                "updated": {
                    "by": "niall.commiskey@oracle.com",
                    "date": "2025-12-12T12:19:54.696+0000"
                }
            },
            "type": "DEVELOPED",
            "viewRestricted": false
        },

Let's check it out -

I implement and activate Do A.

I run GET Projects again - and still see 
"status": "DRAFT",

I implement and activate Do B.




Run Get Projects - and see  "status": "ACTIVE".


So the takeaways are -

Active projects are those with all their integrations marked as active.

Configured projects are those with at least one integration marked as configured.

Draft projects are those with at least one integration marked as draft.

The corollary is, a Project with the status = DRAFT, could still have "live" integrations which are being invoked by clients; the same applies to projects with the status = CONFIGURED.

Project Type

Project type can have the following values - 

  • "type": "DEVELOPED"
  • "type": "BA"
Projects that you yourself create from scratch, have the type = DEVELOPED.

Here's an extract from the postman response for such a project -

 {
            "cloneRestrict": "NONE",
            "code": "AA_DRAFT",
            "id": "AA_DRAFT",
       ...
            "name": "AA-DRAFT",
            "origin": {},
          ...
                "lockStatus": false,
                "locked": {},
            ...
            },
            "type": "DEVELOPED",
            "viewRestricted": false
        },

Now I create a project, based on a recipe -  

I check this out in the GET Projects api response - 

{
  
            "id": "ORCL-R-ACONEX_UNIF_ISSU_SYNC",
         ...
            "name": "Oracle Aconex Unifier Issues Sync",
            "origin": {
                "type": "R"
            },
            "simplifiedMode": false,
         ...
                "status": "CONFIGURED",
                "updated": {
                    "by": "niall.commiskey@oracle.com",
                    "date": "2025-12-12T12:48:37.462+0000"
                }
            },
            "type": "DEVELOPED",
            "viewRestricted": false
        },

So recipes are a flavour of type=Developed, however, the origin value, "R", indicates it's a recipe.

Let's now add a Business Accelerator -














"cloneRestrict": "NONE",
"code": "OUTL-BA-CCB_OFSC",
...
  "mcpEnabled": false,
  "name": "OU CCB OFSC",
  "origin": {},
...
  "status": "CONFIGURED",
...
"type": "BA",
"viewRestricted": false

Here we see that the origin is empty, but type is set to BA. 

Project Assets


 "state": {
   "assets": {
      "labelsRs": {
      "items": [
        {
           "code": "V1",
           "lastUpdated": "2025-12-12T12:10:36.664+0000",
          "name": "V1"
                       }
                   ]
                    }

Assets, in this context are deployments -












I add a 2nd deployment - 










MCP Enabled Project




















I enable MCP in my project AA-2312.
I execute GET Projects and see - 
{
   ...
  "code": "AA_2312",
  "id": "AA_2312",
...
"mcpEnabled": true,
  "mcpServerUrl": "https://yourOIC/ic/api/integration/v1/mcpservers/projects/AA_2312/mcp",
  "name": "AA-2312",

Simplified Mode

So what's this when its at home?

   "name": "AA-2312",
            "origin": {},
            "simplifiedMode": false,
            "state": {

Check out the project deployment docs here.

This field only applies to OIC Project Accelerators, and this value indicates the extension capabilities you have with such. Ergo, this can be ignored, unless you are using Accelerators.

Just in case you don't know what an Accelerator is - 





Tuesday, December 9, 2025

#1108 - OIC Agentic AI Basics & Demo


Introduction

My previous posts have covered exposing OIC integrations as tools. This post goes one step further and looks at creating AI Agents in OIC.

There are a couple of concepts I will cover, before getting to my simple order processing demo. 

Let's begin with the Agent Patterns - 

Agent Patterns

Patterns provide the guardrails on how agents should go about their tasks. Human agents often have a book of guidelines or a manual they need to internalize, RTFM etc. Ergo, the pattern you choose for your agents can make the difference between effectiveness and pure experimentation. Here are some common integration patterns -  

ReAct (Reason & Act)

Seems very plausible, something we should all be doing. We want our agent to think through the problem to be solved and use the tools provided to do that as effectively and efficiently as possible. Constantly reflecting on what has been done and what needs to be done, i.e. alternating between reasoning and acting.

Plan & Execute

In contrast to the reasoning loop, here the AI agent prompts the LLM to generate a complete plan, then executes that plan step by step.

These 2 patterns are currently supported by OIC - 

Check out the relevant docs here.

Next, the LLM, the agent's reasoning engine.

LLM 

Think of the LLM as the agent's brain. However, the agent is more - it can plan, it has access to tools and it has memory. It is essentially the orchestrator.  

Agent Tools

I've already discussed agent tools in previous posts, net, net, tools are used to get the job done. Think of tools that a sales person may have at their disposal e.g. SFDC for managing customers, opportunities etc.

Agents 

Human agents are autonomous complex individuals that have the ability to reason, make decisions and use tools to carry out complex tasks. AI Agents are the software equivalent of such.

Human agents work within guidelines, provided by their organization.
AI Agents adhere to guidelines, provided by the agent developer.

With those basics in mind, let's go to the simple demo.

AI Agent for Order Processing

A caveat - this is a simple example, maybe too simple; however, the goal is to show the steps required for creating such in OIC.

Starting point is the following 5 integrations - 

These integrations have been exposed as Tools - 



Regarding the tools - the names say what they do - Irish customer orders are created in Netsuite via the Create Order Netsuite tool. German orders are pushed to SAP, via the Create Order SAP tool.
The Validate Order tool logic is simple - all orders are valid, except for orders from Irish customers, which have a volume > 50k.

The Check Inventory tool has the following simple logic - all products are in stock except for our exceptional iCar.

Notify Customer sends an email to a customer.
 
Note, apart from Tools we now also have the following Agentic AI artifacts - 
  • AI Agents
  • Agent Patterns
  • Prompt Templates
Let's look at these, one by one - 

Agent Patterns 

We already discussed the 2 patterns OIC supports; for this use case we will use the ReAct pattern. ReAct = Reasoning and Acting. This pattern enables a stepwise (breaking down a complex task into a series of steps), context-aware (the agent has a memory, enabling it to make smarter and more relevant decisions) approach.

We will need an LLM as our agent's brain; the pattern contains a reference to such -

Note the Guidelines I entered for the Pattern - 

Strictly follow all guidelines. It is mandatory that you reflect on all guidelines provided.
  1. You should follow the ReAct agent pattern (Reason + Act) when generating a response.
  Pattern:
  -- Think - using your internal reasoning.
  -- Action - Invoke tools to get information, including additional human input.
  -- Observe - Process tool response using your internal reasoning.
  -- Repeat - Repeat until finished.
  2. At each step you provide your think, action, and observe rationale.
  3. You should always attempt to get the most relevant information based on tool use.
  4. Do not guess or infer tool arguments except for the following reasons:
  - You are given specific guidance by the tool on inferring a tool argument.
  - You have previous context to make a reasonable assumption.

After saving the Pattern, I notice a new integration and connection have been created in my project -

One could say the pattern is implemented by the integration generated. It's default name is - 

We will go into the logic of this integration in a later post, but, suffice to say, it is a black box for us now.

The LLM connection is still in draft mode, so I need to enter the relevant details. As you can see, I need to bring my own api key - 

Final step is to activate the pattern and then I can proceed.

AI Agent Creation

As you can see, the pattern in a pre-requisite for creating an agent. 
Let's look at my Order Processor
agent -

The inputs are as follows:

The agent role - 
The Guidelines - think of these as instructions created by a functional expert - 

You are an order processing agent responsible for validating incoming orders.

### Order Processing Steps

#### 1. Validate Order
Use the **Validate Order** tool to check if an order passes our validation rules. If the order is invalid, then use the **Notify Customer** tool to inform the customer. Also include the "message" returned by Validate Order. If an order is invalid, processing stops immediately; in such cases, detail exactly why this order failed validation.

#### 2. Check Inventory
Use the **Check Inventory** tool to check if the product is in stock. If the product is out of stock, use the **Notify Customer** tool to inform the customer. Ensure the "message" passed to the Notify Customer tool is relevant and friendly. Remember, we are razor focused on customer satisfaction. If an order's product is no longer in stock,  processing stops immediately; in such cases, detail exactly why this order's processing has been terminated.

#### 3. Create Order in one of our ERP systems
Use the **Create Order SAP** tool to create orders for German customers.
Use the **Create Order Netsuite** tool to create orders for Irish customers
 
The Tools - here I select the 5 tools available.

Prompt Templates - more about them in a later post, net, net these are reusable templates, where one can ensure consistency etc.

That's all I need now, so let's activate the agent and test it.

Run the Agent



Process the following order - customer is NiallC, customer is from Ireland. customer email address is nnnnnn@gmail.com. The order is for the following product, iBike.  Price is 4567  

I check out the response -

I check out Project Observability - firstly, the Instances tab.

Then I navigate to the Agent Instances tab - 

I check out the Activity Stream - 
Now let's try an order for an iCar - remember this should be rejected, as it is out of stock.

I check my email - 


Summa Summarum

Again, mea culpa for the simplicity of the use case. We could easily have done this without AI Agents, however, it is a good use case for demoing the mechanics for how to create and run AI Agents in OIC.  










 





Friday, December 5, 2025

#1107 - OIC Control Plane Audit Logs

Introduction 

By control plane, I am referring to the OCI Console, where you can list, create, delete, stop etc. OIC instances. Here is a simple example - I begin by just listing the OIC instances in my compartment. 

I now navigate to Observability - Logging - Audit - 

Here I immediately see that the list OIC instances has been audited. 





There are many filters available here, so let's look at them.

I can filter by user - 

I can filter on OCI Resource and Action Types - 

and finally Event type -

I now stop one of my OIC instances, NiallCDemo. So who was fool enough to stop this mission critical instance?

Back in the Audit page, I see a new entry in the Event type filter list -







 And there's our culprit! 

Summa Summarum

Brevis et suavis!