#1011 OIC 24.02 New Features - Observability / REST API

Some nice new features coming with 24.02 - 

1. Activity Stream now shows which user triggered an integration flow - 

2. New REST API attributes for min/max execution duration.

Let's try this out on the following flows - 

So the 3 flows executed as follows - 

• 10.26 seconds
• DUg3ptn3Ee69UfUKGnU7wg
• 5.14 seconds
• KgPdvtn3Ee6_QJ3NwcOM1g 

• 2.03 seconds
• INMd3tn3Ee69UfUKGnU7wg

I run the api with minDuration=1000 msecs - 

https://design.integration.us-phoenix-1.ocp.oraclecloud.com/ic/api/integration/v1/monitoring/instances?integrationInstance=myOICInstance&q={timewindow:'1h', code:'AA_ORDERPROCESS', minDuration:'1000'}

Count = 3 is returned.

 I run again with minDuration = 5000 msecs - This time only 2 are returned - 

those with the following instance ids -

- KgPdvtn3Ee6_QJ3NwcOM1g (5.14 secs)

- DUg3ptn3Ee69UfUKGnU7wg (10.26 secs)

So this returns those instances that took at least 5000 msecs to execute.

Next test is with maxDuration = 3000 msecs -

This returns only 1 flow - that with the instance id INMd3tn3Ee69UfUKGnU7wg (2.03 secs)

I try again with max set to 6000 msecs - 

This returns 2 flows - 

- KgPdvtn3Ee6_QJ3NwcOM1g (5.14 secs)

- INMd3tn3Ee69UfUKGnU7w (2.03 secs)

i.e. those instances that executed within 6 seconds.

 

#1006 Rapid Adapter Builder Part 3

Continuing the series of posts on this compelling new feature. The previous posts covered my basic adapter for RabbitMQ. If you remember, the connection creation was as follows -

So all I could decide upon was the security policy to be used.

Naturally we need more - let's look again at the url I used, when testing in Postman - https://crow-01.rmq.cloudamqp.com/api/queues/{{account}}/{{queue}}/get

Note the 2 variables - account and queue. Wouldn't it be useful for the integration developer to be able to enter that data, when she is configuring the invoke?

Also how about giving the connection creator the ability to enter the connection type and relevant base url. This could be, in my case, https://crow-01.rmq.cloudamqp.com/api/queues.

So let's do this.

Firstly, adding the ability to select connection type and base url.

Note the use of type = CHOICE for the connection type. This will generate a list of options. I then add the 2 options below - REST API Base URI and Open API (1.0/2.0/3.0)

The next property is the connection URL; as you can see, I have added a default value here. This is purely to save me typing it in again and again. You will not do this in real life.

 

The result is as follows - 

btw. coinín is the Irish for rabbit. 

Next step, we want the person configuring the invoke to be able to specify the account and queue.

I only require this for the GET operation, remember my Rabbit MQ adapter allows me to PUT and GET messages.

So this only applies to the GET - therefore we add these to the configuration section of the GetMessageAction - 

Note again, I set the defaults, just to save me typing.

Now all we need to do is construct the uri for the GET operation. It will have the following format - 

connectionURL /rabbitMQAccount/ queue/get

I construct it as follows - 

"uri": "${.connectionProperties.connectionURL+ \"/\"+.configuration.rabbitMQAccount+ \"/\"+.configuration.queue+\"/get\"}"

Note the . notation and how I address the connectionURL as part of connectionProperties etc.

I set this here - in the section for the Get Message actions.

Now let's try it out - I delete the older version of the adapter in OIC - 

Remember, you will only be able to delete, if there are no connections defined in OIC, based on the adapter.

I delete the connection in OIC and then click Delete ADD - 

I publish the adapter again and then test in OIC - 

Connection Properties are displayed with their default values.

I will drop the RabbitMQ invoke after the Assign action - 

Now to the values I need to add - account and queue - 

I put a message on the queue - 

Then I get the message via OIC - 

I check the Logger action - 

#1005 OIC 24.02 New Features - Testing Feature

 

This is a compelling new feature coming with the 24.02 release.

Let's see how this works - here is my integration -

I click the Test icon - 

As you can see, activation is happening under the hood.

I click Run - 

Note the 2 buttons - Run again and End test.

I click End test - 

 

#1003 - OIC - Create your own adapter with the Rapid Adapter Builder

In a recent post,  I discussed invoking RabbitMQ from OIC using the REST adapter. OIC doesn't have a dedicated RabbitMQ adapter, but RabbitMQ does have a rich REST api, hence my usage of that adapter.

A very BIG thank you to my colleague Madhav P. here.

So taking this example, let's use the OIC Rapid Adapter Toolkit to create a RabbitMQ adapter. This toolkit allows you to bundle REST api requests as a custom adapter, which can be then published to your OIC instance.

The input is a postman collection of the api calls I want to bundle with the adapter. The magic happens in VS Code. The result is a new adapter in my OIC adapter list.

Let's go through this step by step - 

Prepare Postman Collection

I set the authentication at Collection level - 

Note, I have executed the 2 calls and saved the results, by clicking Save as example.

Then export the collection - 

VS Code setup

Download VS Code, the version should be at least 1.8.x.

The Rapid Adapter Builder (RAB) extension will be available on the VS Code marketplace going forward - 

 

You download the extension and then import it into VS Code.

Creating your adapter project

Create a new folder on your file system and navigate to it in VS Code - 

Then click View --> Command Palette. Enter RAB: Initialize Workspace. 

Check out the directory structure - 

Essentially we're going to do the following - 

Import our Postman collection to the /api directory.

We will use this to generate an adapter definition file which will be stored in the /definitions directory. publisher.yaml contains details of my OIC instance and the security credentials to connect to it. This information will be used when publishing the adapter to OIC.

Import the postman collection  

You can export again from Postman and save directly to the /api directory.

Edit publisher.yaml

As you can see, you will require the following - 

• active - name of active profile
• profiles - 
• name - profile name - identifies the OIC instance
• publisher id - yourOwnId - I chose ncommisk
• host - the OIC host
• integration instance - OIC instance name
• auth -
• tokenUrl - IDCS token url
• clientId - from IDCS app
• clientSecret - from IDCS app
• scope - from IDCS app

So the idea is I can have multiple Profiles, identifying multiple OIC instances, and then decide for each Publish run, which is active, i.e. publish the new adapter to test and then to prod.

  

So you may need to create an IDCS app to get the client id and secret. 

Note: only Client Credentials is required.

Add the scopes for your OIC instance.

Activate and note client id and secret.

Next step is to assign an OIC role to this app. This you do via the Oracle Cloud Service app, auto-crated for your OIC instance - 

Update publisher.yaml - 

Create the adapter definition file

Here we click RAB: Convert Document.

 

 

The following file is generated - 

You will need to edit some of these values, at least the displayName, as this is what will appear in your OIC adapter list.

Also note the version value, this needs to be incremented when you are updating an adapter definition.

 Validate the adapter definition

Click RAB: Validate

Final step is to publish - 

Check out the new adapter in OIC

Note the default logo used. this is taken from the /resources directory - 

So, net, net, I can add my own logo, if required.

I create a new Connection - 

Note the only security available is basic auth - 

I could have edited the adapter definition file to specify more - 

I enter my credentials and test the connection - 

Now to a simple scheduled integration which will use this connection - 

Note, the 2 operations, GetMessage and PutMessage, are displayed. I select the former.

I just need to edit the Map and then I'm ready to go.

I set ala Postman payload.

I add a Log Action to log the payload -

I run and validate the result -