Understanding Integration Cloud and how to get the most out of your implementation

Quarterly Updates

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.)

locals {
 updateWindow = (var.use_window1) ? "OIC_UPDATE_WINDOW1" : "--NOT-WINDOW1--"
}

resource "oci_integration_integration_instance" "test_integration_instance" {
    #Required
    compartment_id = var.compartment_id
    display_name = "ExampleOIC"
    integration_instance_type = var.integration_instance_integration_instance_type
    is_byol = false
    message_packs = 1

    consumption_model = var.integration_instance_consumption_model
    custom_endpoint {
        #Required
        hostname = var.integration_instance_custom_endpoint_hostname

        #Optional
        certificate_secret_id = oci_vault_secret.test_secret.id
    }

    freeform_tags = {"${local.updateWindow}"= ""}
    idcs_at = var.integration_instance_idcs_at
    is_file_server_enabled = var.integration_instance_is_file_server_enabled
    is_visual_builder_enabled = var.integration_instance_is_visual_builder_enabled
    network_endpoint_details {
        #Required
        network_endpoint_type = var.integration_instance_network_endpoint_details_network_endpoint_type


        }
        is_integration_vcn_allowlisted = var.integration_instance_network_endpoint_details_is_integration_vcn_allowlisted
    }
    state = var.integration_instance_target_state
}

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.

Previous

November 21 – New OIC Articles

Next

December 21 – New OIC Articles

3 Comments

  1. Silvia Domínguez Peña

    Hi Phil,
    First of all, thank you for the article is so useful! I have a question: when we talk about development and production instances, I think about development things xD but I’m afraid is not the same here, What are the differences between development and production shapes here? Has some kind of impact on integrations and versioning?

    Thanks in advance

    • Silvia

      When it comes to the service shapes – the only real difference is the amount of traffic being run in the instance. This is reflected with the number of message packs you’ll have purchased. So for a dev environment you’re unlikely to want more than 1 message pack.

      HTH

      • Silvia Domínguez Peña

        so the product updates are about the instance in general right? Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

Powered by WordPress & Theme by Anders Norén