In the world of B2B integration, flexibility and efficiency are key. B2B for Oracle Integration Cloud offers two primary deployment patterns to meet diverse business needs: the Standalone model and the Trading Partner model. Understanding these patterns is crucial for optimising your integration processes.
In this post, we’ll dive into the features and benefits of each model to help you decide which one suits your business best.
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.
Terraforming …
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.
Oracle Integration Cloud is rich in adaptors for technology and major SaaS services both Oracle (E.g., HCM, ERP, CX) and non Oracle (e.g., Salesforce, ServiceNow). But the more observant may have noticed a new addition to the list of Oracle industry (vertical) adaptors joining the Utilities vertical is a new adaptor for Hospitality.
OPERA, and it’s integration service OHIP have been developing to bring first of all its 3000+ APIs upto date as RESTFUL and self service enabled as the OPERA product becomes a SaaS delivered solution. Not to mention provide a good developer experience with Apiary and resources such as Postman collections (more about this here).
The latest step (from 21.4.2) has been to further the simplify the development process through the use of low code integration OIC provides. You can read some initial blogs about it here, and I’m sure there will be more to come.
Today the Adaptor just supports the Property Management System (PMS) that is for us uninitiated the system element handling the hotels core operations such as rooms, housekeeping and associated tasks – the heart of a hotel based business. Areas such as marketing, cruise ships, point of sale (PoS) etc fall out side of PMS and are not covered today.
Why OHIP and OIC
OHIP and OIC really comes into its own because it is very easy to wire the hotel management solution to common services such as ERP and HCM functions.
For example if you’re operating a group of hotels, then each hotel will use an OPERA instance, but the group may well make use of ERP Cloud for the overall accounting, taking the costs etc identified in the hotel operations via OPERA and then those figures are put into the group ERP to provide the overall financial controls and picture.
Adaptor Foundations
The OIC Adaptor builds on top of the OHIP APIs, as a result the same restrictions on invocations, security needs exist as going to the native API. Like all OIC integration development we need to establish a connection definition which needs the URL of you OHIP instance, plus the same credentials you would use for a rest connection.
Time flies, with a 1/4 of a year behind us already including the first quarterly release. Last month we’ve seen a lot of attention around Oracle Hospitality Integration Platform (OHIP) which brings together different Hospitality cloud services as well as using technologies such as Integration Cloud to make it easy to interface 3rd party solutions.