#998 OIC 23.12 Release New Features

23.12 is is yet another compelling release of OIC. Without further ado, let's look at some of the new features - 

Global OIC New Features

Import / Export Support

This feature allows you to do global exports/imports of all OIC artefact metadata. This feature is heavily used by OIC Gen2 customers, so this is a must in respect of feature parity. The modus operandi is analogue to Gen 2 - 

Step 1 is set up the connection to your OCI Object Storage bucket -

This will be used as the export target -

Defining an export job is easy - instance storage defaults to what you have set up. The job name defaults to Export of instance yourInstance.

You can choose whether or not to export security artifacts (secrets).

The import definition is as follows -

Self-explanatory, I assume.

Let's try this out - I begin by creating a Bucket - 

 

Now back in OIC --> Settings - Storage - 

Note the format of the Swift Url - 

https://swiftobjectstorage.yourDatacenter.oraclecloud.com/v1/yourTenancy/yourBucket

The password you enter is not your OCI password, rather it is based on an Auth token you generate at OCI User level - 

Save the token and use as the password, when defining the storage connection in OIC - 

Note the format of username - oracleidentitycloudservice/niall.commiskey@oracle.com

Now to the Import/Export page in OIC Settings -

 Here one can do the following - yes, you guessed it - 

I click on Export - 

I check in Object Storage - 

I check back in OIC - 

Project Enhancements

Ability to copy integrations into a project

This is a very useful feature, especially for OIC gen2 customers uptaking projects. This feature allows you to copy projects from the global context (i.e. those not in a project), or from another project and "paste" into your target project.

Here's a simple example - my integration - AA-Netsuite-CreateCustomer - this leverages a "global" Netsuite connection, as well as an OIC Lookup to set the Netsuite subsidiary id.

I create a new Project - AA-Netsuite-CustomerMgt -

Note the ability to search Projects. I de-select the checkbox, in this case.

I select my source integration and then click Copy - 

The integration and its dependencies has been imported.

Again, this is extremely useful for existing OIC customers who want to adopt projects.

Publishing OIC APIS to OCI API Gateway

A major new feature of 23.12. However, this gives us more than just OIC Gen2 parity. Publishing is a feature within OIC Projects. Integrations need to be activated, before they can be published.

The publish UI is as follows - 

Note the following - 

1. the ability to choose which endpoints to publish.  Unfortunately, I only have the one, but you get the idea.

2. Choose the compartment which hosts the api gateway.

3. Select the gateway 

4. Select an existing deployment on that gateway or create a new deployment. A word or two on deployments - a deployment can host from 1 to 50 endpoints. Each gateway currently supports up to 20 deployments. That allows for up to 1000 endpoints per gateway. You can decide yourself how you want to split the apis over deployments, e.g. create a "Netsuite" deployment for all your Netsuite related apis.

So think of the deployment as a folder for related apis/OIC endpoints.

 

I publish - 

Note the ability to Undo publish - giving you full lifecycle control. If you create a deployment and have published only the api(s) from a single integration, clicking Undo publish will delete the routing rule and the deployment. 

There are some pre-requisites you need to do in order to publish from OIC to the OCI API Gateway.

This connectivity is RPST based and you need to do some setup in your identity domain to make this work.

I will document these in a separate post.

New Notification Center

The Notifications center shows the status of asynchronous operations (such as installing a project from the Integration Store). This eliminates the need to click the refresh icon to see the status.

The Announcements page, formerly accessible via the bell icon, can now be accessed via the megaphone icon.

#997 - OIC - Integration with RabbitMQ on CloudAMQP

 

CloudAMQP provides managed RabbitMQ clusters on the cloud. It is quite popular, so it was only a matter of time before I got the question - How can I use OIC to integrate with RabbitMQ. Never one to dodge a challenge, I began by subscribing to the free version of RabbitMQ - Little Lemur.

Setting up the CloudAMQP account and RabbitMQ itself is very simple, I just needed to note the following details from the setup screens - the User, vHost and Password provided. I will need these later on when constructing the REST requests to RabbitMQ in Postman.

From the CloudAMQP homepage - I  click on the RabbitMQ Manager button to create my Queue - I provide a name - NiallCQueue - and just accept all the default settings.

A very simple task - my Queue is set up, now to the api docs to check out how to write to and read from the queue -

  Here is the link.

Next step is Postman, to try out the RabbitMQ apis - I begin with the most simple request - to retrieve the queue information -

I copy the relevant curl command from the RabbitMQ api docs and paste into Postman - 

Note that the first part of the url is user:password. You can get rid of this by setting up Basic Authorization with the same user/password in Postman.

Next request is to put a message on the queue -

Here I use Basic Auth, so no username/password in the url.

Let's look at the payload - 

routing_key - set to the name of the queue

payload - yes, the payload I want to write to the queue

payload_encoding - I left this as "string". 

From the docs - The payload_encoding key should be either "string" (in which case the payload will be taken to be the UTF-8 encoding of the payload field) or "base64" (in which case the payload field is taken to be base64 encoded).

properties - I left empty, to begin with.

The routed = true response tells me the message has been successfully sent to at least one queue.

Next api is the GET - 

Note the request payload - 

count - the max number of messages to retrieve from the queue.

encoding - set to auto

from the docs - encoding must be either "auto" (in which case the payload will be returned as a string if it is valid UTF-8, and base64 encoded otherwise), or "base64" (in which case the payload will always be base64 encoded).

ackmode - ack_requeue_false 

from the docs - ackmode determines whether the messages will be removed from the queue. If ackmode is ack_requeue_true or reject_requeue_true they will be requeued - if ackmode is ack_requeue_false or reject_requeue_false they will be removed.

All is working in Postman, so now on to OIC - 

Step 1 - Create the Connection

Here we use the OIC REST adapter -

Step 2 - Create a Scheduled Integration

Here is the configuration of the REST invoke - 

I use the request and response payloads from my Postman test as the request and response JSON samples.

 

The For-Each configuration - 

The Logger action just logs the payload - 

Now to testing the integration - for this I have put 6 messages in the queue -

I run the integration and check out the activity stream - 

I check out one of the log actions - 

 

#996 OIC Healthcare: MLLP Adapter Part II

Leading on from the previous post, let's now look at outbound, i.e. OIC sending HL7 messages to a target, in my case, HL7 Inspector. 

Th following connection will be used - note the port. This is what is configured in HL7 Inspector.

The use case here is very simple, I just send back the message received. Remember the patient admission integration from the previous post? In that integration, AA-ADT01-Processor, I converted the message stream received into an xml based version of the ADT01 message.

Now I will use the OIC Healthcare action to transform this canonical version of the message back to HL7 format and forward it to HL7 Inspector.

Here is that integration before I make the changes - 

I add a new Healthcare action, after the Logger, and configure as follows - 

The Target to be mapped is as follows - 

The Source is the xml representation of the HL7 message received - 

 

I map the relevant fields, then add the MLLP Invoke.

The final integration flow - 

I activate the integration and test by sending a new ADT01 message from HL7 Inspector. This message will trigger my router/dispatcher integration, which, in turn, will invoke AA-ADT01-Processor.

I check out the HL7 Inspector Receiver - 

You will notice some new field values in the above message, i.e. this is not a simple echo.

I put in these Sender values via the map - 

<0x0b><0x1c><0x0d>MSH|^~\&|OIC^AA-ADT01-Processor^Integration|Commiskey Healthcare Inc.^Commiskey Healthcare Inc.^Clinic for the disturbed|ADT1|GOOD HEALTH HOSPITAL|198808181126|SECURITY|ADT^A01^ADT_A01|MSG00001|P|2.8<0x0d> EVN|A01|200708181123<0x0d> PID|1||PATID1234 123456789^5|||||M<0x0d> NK1|1|NUCLEAR|SPO^SPOUSE||||NK^NEXT OF KIN<0x0d> PV1|1|I|2000||||004777^ATTEND^AARON<0x0d> <0x0d>

Tip for mapping - use the OIC mapper <copy-of> function at segment level to ease the mapping chore.

BTW. the following cmd is useful, if HL7 Inspector is not receiving messages - 

netstat -ano | find "2100"

Custom Schemas

The ADT01 data I used only leverages a couple of segments, so I could define a custom schema based on the standard ADT01 definition and delete the segments I don't require. This is what I did - 

The schema designer makes it very easy to delete unwanted segments or add new custom segments and elements.

Now I can use this schema when defining a new version of the ADT01 doc - 

First I create the doc based on the ADT01 version 2.8 and then edit it to use the custom schema based on ADT01 version 2.8. 

I could then use this document definition, when invoking the MLLP adapter. 

Summa, summarum, Healthcare is a compelling addition to the OIC toolkit, looking forward to helping our customers adopt it.