Showing posts with label Rapid Adapter Builder. Show all posts
Showing posts with label Rapid Adapter Builder. Show all posts
Sunday, March 24, 2024
#1012 - OIC Rapid Adapter Builder Enhancements
There have been some enhancements to the Rapid Adapter Builder -
api - this is used when your input is an open api spec.
misc - this is used when your input is a postman collection.
Note, the OIC instance connect information has been externalised.
Check out the documentation here
Monday, February 19, 2024
#1008 OIC Rapid Adapter Builder resources
Friday, February 9, 2024
#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 -
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.
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 -
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.
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 -
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 -
Monday, January 8, 2024
#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.
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.
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.
Add the scopes for your OIC instance.
Activate and note client id and secret.
Update publisher.yaml -
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.
Check out the new adapter in OIC
So, net, net, I can add my own logo, if required.
Note the only security available is basic auth -
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.
Subscribe to:
Posts (Atom)
