August is a special month for OIC as we see the launch of Generation 3 of the product. The biggest differences are under the hood, with the core engine moving from a WebLogic basis to running on top of Cloud Native OCI services. As a result, the solution will be able to more efficiently leverage other OCI features to deliver enhancements. Not all of the Gen2 features are running on Gen3, we can expect things to follow quickly. When looking at documentation you’ll need to watch out for references to Oracle Integration Generation 2 vs. Integration Generation 3.
Not only do we have Integration Generation 3, but a new independent Process Automation solution was launched in March.
To help differentiate the articles, where we can we’ll continue to refer to the Process automation that resides within OIC as PCS using the legacy name. Anything referring to the new Process Automation service we’ll identify as OPA. Differentiating Integration Generation 2 or 3 will be OIC2 or OIC3, respectively. If there is no generation number, then at this stage, you can assume the answer is quickly true to both generations.
July’s big news is the connectivity between OCI and Azure for Oracle to streamline Azure users accessing Oracle databases (here), and more importantly, for OIC users is the addition of new Sovereign nation regions (here). For OIC users this means the possibility of handling data that is more sensitive to where the data resides.
– The activity around Integration Cloud has been fairly quiet, but a fair bit of content has been written on the related subject of Oracle’s Digital Assistant. There is a natural connection between the two products, that may not leap out. But the backend data sources needed to answer user interactions need to be accessed. Ideally, this would be through an API specification (giving clarity of data and interface behaviour) and serviced by OIC or microservices to ensure the abstraction/decoupling layer is protected. So any change to the backend is masked from the client systems.
I had an interesting conversation today, where it was pointed out to me that our book Implementing Oracle Integration Cloud Service, the first ever Oracle PaaS book is five years old today (according to Amazon). This website was also five years old back in August last year.
While some parts of the UI have become more sophisticated than shown in the book, and the choice of adaptors has grown significantly the core fundamentals of the book still hold true.
December is always a quiet month having had updates in November, but this month has been particularly so. One bit of good news, the handy resource links have been updated with a lot more additional resources – see right of the page.
The update regime for Integration Cloud is well established in its quarterly pattern, but within that pattern are two update cycles, separated by two weeks. It is possible to choose which cycle your OIC instance update will be executed in. If you don’t specify which cycle then by default you will be put into the second cycle.
For production deployments of OIC that makes a lot of sense. But we would recommend that your non-production instance be part of the 1st update cycle. This allows you two weeks to validate and fix any issues in the event that the upgrade breaks any of your integrations. While that shouldn’t happen if you are exploiting an undocumented behaviour or something reported as a bug there is always a risk.
So the obvious question is how to define which update cycle should be used. For OCI Gen 2 (the majority of users should have migrated to now), the control is achieved by setting a freeform tag on the OIC instance. The tag needs to be called OIC_UPDATE_WINDOW1 (note – if you don’t read the Oracle documentation carefully you could end up omitting the numeral) and the value can be left blank. The tags are set on the OCI view for your OIC instance, which has a tabbed view as you can see below. Once the value is set then the OCI view will show an Updating status – this is not to be confused with the OIC instance being updated with the latest quarterly changes.
All of this shows up in blog (here and script fragment here) and a documentation (here). What is less apparent is the lead time needed for the tag to be in place. This is in the order of 7 or more weeks. This means you need to have your OIC dev instance in place almost a full quarter before the opportunity is available, and spinning up a new OIC instance and expecting it to immediately adopt the latest version during the maintenance window isn’t going to solve any problems.
How to confirm the instance version
The related question is where to look for the version of OIC is running. The information is only provided in the instance console rather then the OCI View of OIC. The version information is available as part of the drop down visible on the question mark icon at the top right of the UI, as the following screenshots show:
We do hope that Oracle will shorten this in the months to come.
If you’re building your OIC deployment(s) using Terraform, then you could pass a variable into your Terraform module (hence the reference to var. or read from a configuration file in which case you will want a data block and the value becomes data.)
As you can see in my example I have hardwired more values than the example provided by the Oracle Terraform documentation (here) as it helps show the legal values. Here to keep the declarations simple – I have set a freeform tag regardless, but changed in the local variable value to be used by the freeform tag depending on if a variable ( use_window1) is set.