Simplified OAuth Config for Oracle Integration Cloud REST API using Postman !!!

This blog will be discussing very specific use case requirement which is more developer oriented and providing a quicker and efficient solution to invoke Oracle Integration REST API using OAuth access_token for testing purpose.

As an integration developer time to time you need to invoke Oracle Integration REST API to test API functionality. All the REST API in OIC needs a header parameter called “Authorization” which must needs to hold a valid access_token value in this format “Bearer access_token“.

In above format, “Bearer” is static world, However, access_token is the token value which we get after successfully OAuth Authentication from Oracle Identity Cloud Service.  Getting access_token from IDCS using code credentials flow is multi steps and cumbersome process.

However, developer can leverage Postman environment and variable features to simplify the process of getting access_token. That’s what, I will be covering in this blog.

Before I proceed further, I must redirect you to read my colleague blog which has greater in-depth explanation about what is IDCS, how IDCS govern security aspect of all Oracle PaaS products such as Oracle Integration Cloud, Analytics Cloud, Digital Assistant and so on and OAuth client and token generation process etc. I am recommending you to read his blog because I will be using few artefacts e.g. IDCS URL, Client ID, Client Secret etc which we need to get from IDCS OAuth Client Application as per the process given in his blog.

So, I believe once you go through Callan blog, you already understand the concept of OAuth client application, client id, secret code and scope etc. and either you or Your Identity Administrator already created an OAuth Client Application with proper privilege. Now, either your Identity Administrator will provide you all these artefacts or you can login into IDCS and get those artefacts by yourself assuming OAuth Client Application already been created by your Identity Administrator.

So, here are simple steps to capture IDCS URL, Client Id, Client Secret and Scope for given OAuth Trusted client application.

Getting OAuth Trusted Client Application Artefacts

IDCS URL –

login to your Cloud Account Dashboard >>  Navigate to Account Management >> Users >> Identity

From user management home page, click “Identity Console”

This will take to you IDCS console where you can IDCS URL and also find OAuth Clint trusted application which you administrator has created –

Browser URL will show IDCS URL e.g.
idcs-url = https://idcs-56c3577bb024452b89496a0db95XXXX.identity.oraclecloud.com

Client Id and Client Secret-

Under application find out the OAuth Client application which you administrator has created for you, click on that, further click configuration tab page to get Client ID, Client Secret and Scope value.

e.g. client id = 0650C696C98345D4A07548xxxxxx38D5C_APPID

client-secret = 6b296da5-459d-4fbxxxxxd749a65a53

Scope –

For scope click on resource option. Scope value is the concatenated value of two separate values a) Primary Audience and b) scope

Copy and paste these values in notepad subsequently to make scope value finally.

e.g.  https://0650C696C98345D4A0xxvvxvxv67838D5C.integration.ocp.oraclecloud.com:443urn:opc:resource:consumer::all

OIC Artefacts-

In addition to IDCS URL, Client ID, Client Secret. We also need OIC URL, OIC Username and Password which I assume you must be knowing already.

Invoking /oauth2/v1/token” REST API

Once  all the attributes values are ready, jump to postman and create a new environment with all these variable, so that we can refer these variable values programmatically in postman.

Now, Invoke the “/oauth2/v1/token” API and pass above parameter as per given snap –

Authorization tab – select basic auth and provide {{clientId}} and {{clientsecret}} for username and password fields.

Under body tab specify all other parameters such as grant_type=password, scope={{scope}}, username={{username}}, password={{password}}

During run time postman will fetch the static values assigned to these environment variables.

Make sure header is properly selected

finally, hit the send button and you will get auth_token back from IDCS

So, now you got the access_token code, its JWT base64 encoded string value, if you want to see decoded value of this encoded string, you may use https://jwt.io/ debugger site to decode that code.

Now, since we already got the access_token, next steps to invoke actual OIC REST API endpoint. It could be any OIC REST API. In my case I was calling Connection REST API, to fetch connection metadata.

In order to call connection REST API, we need to pass the access_token which we have got in previous step, coping access_token manually and passing in header could be error prone steps. Again, Postman is saviour here.

We can leverage “Test” tab page of Postman where we write small java script to hold the access_token value into a variable called “Authorization” and use this variable while invoking any OIC REST API.

Here, is that tiny java script code –

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("authorization", "Bearer " +jsonData.access_token);

Invoking OIC Connection REST API-

Now, once you hit /oauth2/v1/token API, this java script code will store access_token value into a variable called “Authorization” which you can use while invoking OIC Connection REST API.  Just specify authorization variable (holding access_token value) and hit send button to connection REST API.

That’s it. You should be able to invoke any OIC REST API using above method, its one-time effort but save you lot in future.

I hope, this blog will help you to understand how easily and simply you can invoke OIC REST API.

Stay tuned for more useful blog!!!

Happy Blogging 

Advance XSL Mapping inside Oracle Integration Cloud !!!

Recently, I came across one issue while working with one Customer where they were facing bit of challenges to update existing working Integration with new JSON field input.

So, in this use case, two integration orchestration process flow are involved, Master Integration and Child Integration both working well in production. However, time to time developer gets requirement from business to enrich this working flow by adding more fields into Child Integration which was interacting with Oracle Responsys System. The Master Integration getting data from NetSuite, passing Child Integration same data which was interacting with Responsys and completing business flow.

Here is flow diagram with existing working flow Vs flow with new requirements and highlighted problem area.

 

Problem Statement:

 

Once developer add new fields into Child OIC orchestration flow, saved, activated and tries to refresh the Parent OIC orchestration flow, it breaks existing mapping. Behind the scene obviously since Child Integration orchestration flow input payload got changed it has cascading impact on calling Integration flow and calling Integration flow fails to deduct those changes and breaks existing mapping and wiped out existing mapping. see the relevant snaps -

Adding new JSON field into REST Adapter Configuration -

Edit Integration Invoke activity from Parent Integration flow which given warning of major changed deducted and then wipes out previous mapping -

Once clicked on update button, it wiped out previous mapping for that child OIC flow-

And Customer needs to put mapper activity back and create mapping again which takes 4 to 5 hours as they were having almost 100 fields to map.

Solution

 

The solution what I have found for this problem is using export/import feature of OIC. Fortunately, OIC offers you export option for Integration, which means all the artefacts of that particular integration will be exported into .iar file, user can unzip that file which will create a folder called "icspackage" and its contains all the important configuration file generated while we designing Integration flow using webUI.

Here is explanation of some of important files and folders -

To fix this mapping problem we need to find and update relevant .xsl (mapping file) and most importantly relevant .wsdl or .xsd file. In my case I have noticed the xsd definition was inline declared inside .wsdl file itself. 

So, open the relevant .xsl file and add newly extra fields and its associated mapping which you expecting to do using UI based mapper. In my case it was something like this -

Once update the .xsl file, find out relevant .wsdl file and declare particular JSON field there. In my case it was "newAddress"

That's it, your mapping (xsl) file as well as xsd definition file both got updated with newly created JSON field.

Now, create an archive out of this folder e.g. "icspackage.zip" then simply rename this zip file to its actual OIC project name. in my case it was CUSTOMER_CONTROL_01.00.0000.iar and import it back into OIC console using import feature.

You will see newly updated fields inside mapper.

I hope, this blog will help you to understand how easily and simply we can do advance xsl mapping using exported project artefacts and deploy it back to see the changes.

Stay tuned for more useful blog!!!