iPaaS@ORACLE.CLOUD: #1116 OIC Project Deployments

Monday, February 9, 2026

#1116 OIC Project Deployments

Introduction

OIC Project deployments enable us to move OIC artifacts (integrations etc.) from one environment to another, e.g. from Test to Prod. Take my simple ERP Orders Project - it contains 4 integrations -

These are simply dummy integrations, with only one, getOrder, actually using the Fusion ERP adapter.

The project has the following and a lookup -

So these are the artifacts I will be progressing from Test to Production.

This is very easy with project deployments, which can contain all or just some of your automation artifacts.

In this simple demo, I will create an initial deployment that contains all 4 integrations. I will then add a new integration - processForeignOrders - and for this I will create a second deployment. We will then try out a few variations on this theme. Hopefully, you will then be totally au fait with Project Deployments. If not, then feel free to ping me.

Initial Project Deployment

I click Create -

Note how all integrations are pre-selected -

Also note the other artifacts that can be included -

AI Agents
RPA Robots
Human in the Loop
Decisions
B2B

Note, connections, lookups, OIC Events, libraries are included if the deployment contains integrations that use such. In my case, the lookup, CountryCodes, is currently not used in any integration.

Note also, the integration selection defaults to the current versions, we will see how this can be leveraged later.

I export the Deployment -

Note the 2 options - export to CAR file or to repository. You need to configure a Git repository connection to avail of the latter -

I'll stick to CAR file for this post.

I go to my Prod OIC instance and import the CAR -

Open the project -

The 4 Integrations are present -

The 2 connections are present -

Note the Fusion ERP connection is in draft state. That's because the export/import does not include the connection configuration data, as you will normally be using different Fusion ERP instances for Test and Prod.

The lookups are empty, as no integration currently uses our CountryCode lookup.

Clicking on the Deploy tab -

I see the V1 deployment - note the menu options here -

I click Activate -

This will attempt to activate the 4 integrations - I expect one to fail - getOrders - as the Fusion ERP connection is still in draft mode.

So the pre-check fails for 1 integration, but the other 3 are activated.

I fix the Fusion ERP connection and retry project activation -

First, I need to deactivate and then activate -

Now to the menu options - all are self explanatory, except maybe for Delete.

The deployment is deleted, but the project integrations etc. are still present.

I create the deployment again, just for completeness sake.

Update to Project in Test

Here I can include only new and updated integrations in each subsequent project deployment.

The line of business folks tell us we need a new integration to process foreign orders -

It uses the countryCode lookup.

Now we create a new deployment -

Deploy and import to Prod -

New integration is now surfaced in the Prod project -

As well as the lookup -

How do we ensure changes made to integrations in Prod are not overwritten?

Net, net - this is OOTB - no existing integrations are overwritten. Let's try this out by adding a new LOG action to the processForeignOrders integration in Prod -

Back in Test, I make a change to the same integration - I add a Wait action and then create a new deployment for this updated integration.

I export and import -

The deployment, V3, surfaces in Prod -

However, the integration has not been updated -

This may seem somewhat confusing to begin with, but consider we are dealing with 2 separate artifacts here - the deployment and its contents. The deployment, V3, didn't previously exist in the Prod project, so it is imported successfully. However, when importing the contents, we ensure that integrations with the same version nr are not overwritten. in respect of the processForeignOrders integration it is still tagged as version 1.0.0.

I now delete V3 in Prod.

So how do we get the update from Test to Prod? Simply by incrementing the version nr, and then deploying the updated version -

I import to Prod -

Note that both version 1.0.0 and version 1.0.1 (minor versions) have the same endpoint -

/ic/api/integration/v2/flows/rest/project/AA_ERP_ORDERS/PROCESSFOREIGNORDERS/1.0/order

What's the main takeaway here? By deployment (exp/imp of projects), existing versions of integrations are not overwritten.

If I want to push changes from TEST to Prod, for existing integrations, then I need to use integration versioning.

So what's the best practice here?

What should be included in deployments? Is going the route I just described with V1, V2 and V3 the optimal way of doing things? Technically, it's possible to do it as I showed you, however, consider that deployments can be seen as a snapshot of your project. So back to my simple example - if the other 4 integrations in my TEST env haven't changed, why should I include them in project deployments V2 and V3? The reason is then you have a stable version of your project. If there were issues in V3 in Prod, then you could easily revert to V2.

Let's try this out - but firstly, let's look at our new integration in Prod -