Oracle Integration: How to replace a Connection by one with a different role?

In this blog article I describe how to replace an OIC Connection by one with a different Role (e.g. Trigger and Invoke by Trigger), which “officially” is not supported.
 

An issue I quite often encounter is that OIC developers made mistakes with the Role of the Connections they create. A bit unfortunate, but the default Role is Trigger and Invoke, which in 90% of the cases is the wrong choice to make. It should be either Trigger or Invoke except the few cases where you not only want to actively invoke API’s or services of an application but want to be triggered by “event” from that application. Connections to SaaS applications are a typical example of this, when you want to use API’s and services and also want to subscribe to event. 

The argument for making the Role either as Trigger or Invoke is separation of concerns regarding security settings. At some point you probably must configure security in such a way that for the Integration's trigger (that for REST often started as Basic Authentication or OAuth 2.0 Or Basic Authentication) only OAuth 2.0 is allowed, if not on the OIC Development instance then at least on OIC Acceptance and Production instances. For an Integration's invokes you will have to configure the connections to comply with the security as required for the target applications. For Oracle SaaS applications this often implies using a Confidential Application with Client Credentials.

After having developed some 100 Integrations or more using a Connection with the wrong Role, it's not funny to find out that you cannot simply fix this issue by replacing the Connection by one with the proper Role, as in Integration Designer replacing a Connection by one with a different Role is not supported.

What is also not funny is when you started to use a Trigger and Invoke connection that was created using Basic Authentication for several integrations and then someone decided to change the security configuration to OAuth 2.0, for example like this:

When you try to create a new Integration using this as a Trigger, you will find you cannot do so

So, what might have looked like valid change, strictly speaking corrupted all integrations using this as a Trigger. I have not tried it out, but wonder if you will be able to reactivate them and what would happen when you migrate to Gen3.

So how to get out of this situation? The following describes how you can work around this restriction of not being able to replace a connection by one using a different Role. 

In short, the trick is (with many thanks to my colleague Marc Smeenge who actually discovered this):

• Temporarily create new Connections with (still) the wrong Role
• Change the Integration to use those new ones
• Export the integrations
• Replace the wrong Connections by new ones with same identifiers but this time the proper Role
• Import the Integrations
• Replace the Connections by the proper ones

The following describes this in detail.

Setup

The setup is as follows:

I have 2 Connections that are configured wrongly:

• SMP_OIC_REST_Trigger_Invoke Connection that is used for all Integrations with a trigger based on the REST Adapter, which should have been Trigger only
• SMP_ERP_REST_Trigger_Invoke Connection that is used to call Fusion ERP REST API's, which should have been Invoke only

 I have 2 Connections that are properly configured:

• SMP OIC REST Trigger
• SMP ERP REST Invoke

I have 2 integrations that both use the wrongly configured Connections:

• SMP Purchase Orders
• SMP Accounts

As you can see in the following picture, I'm not able to replace the SMP_OIC_REST_Trigger_Invoke by the SMP OIC REST Invoke, as replacing Connections with different Roles is not supported:

Now for the sake of example, let's assume I want to do the replacement for the SMP Purchase Orders integration only, as the other one is not mine to fix.

The recipe to handle this is as follows:

1. Put all integrations to fix in package (putting integration best practice anyway). In my example I have put the SMP Purchase Orders Integration in a samples package.

2. Clone the wrong connections, for example to ones that are post-fixed by TEMP. These have still the wrong Role and you can give them any security policy as long as they are configured before you move on. In my example I have created a SMP_OIC_REST_TEMP and SMP_ERP_REST_TEMP connections.

 

3. Create new 2.0 version of all Integrations to fix and put them in a package of their own. In my example I have put the 2.0 version of SMP Purchase Orders to package name package.fixing.

 

4. Replace the wrong connections by their clones. In my example I have replaced 

• SMP_OIC_REST_Trigger_Invoke by SMP_OIC_REST_TEMP 
• SMP_ERP_REST_Trigger_Invoke by SMP_ERP_REST_TEMP

 

5. Export the package with the 2.0 versions. In my example that is the sample.fixing package.
6. Delete the 2.0 versions of the Integrations to fix.
7. Delete and recreate the cloned connections 1 by 1 with the proper Role. In my example I now have:

• SMP_OIC_REST_TEMP with Role Trigger
• SMP_ERP_REST_TEMP with Role Invoke.

8. Import the package. In my case this is the samples.fixing package. As you can see this went without issues:

9. Replace the cloned, wrong Connections the by proper ones. I can now replace:

• SMP_OIC_REST_TEMP with Role Trigger by the proper SMP OIC REST Trigger 
• SMP_ERP_REST_TEMP with Role Invoke by the SMP ERP REST Invoke.

 

 

10. Delete the 1.0 versions of the Integrations to fix. In my case that is only the SMP Purchase Orders 1.0 version.
11. Version the 2.0 Integrations back to to 1.0 ones with the original package name. In now have a SMP Purchase Orders 1.0 version in the samples package.

As you can see in the following picture, the sample package now uses both the old, wrong Connections as I did not replace it for the SMP Accounts Integration, but also the new, proper Connections:

Problem fixed!