ICS Best Practices : Before going live and post go-live

Integration Cloud Service, Oracle’s flagship iPaaS product, is increasingly being adopted by customers as their strategic integration platform, for implementing various Cloud-to-Cloud as well as Cloud-to-OnPrem integration projects.

With every release of the product more and more features are being added, and there’s plenty of documentation available on using ICS for designing and developing various integration patterns.

In this blog, however, I will talk about ICS from an operational perspective. I will go over some of the best practices that should be followed so that the Development, Code Migration, go-live, and post go-live maintenance goes as smoothe as possible.

These practices may be implemented either via the ICS UI, or the REST APIs; however, using the APIs provides a great degree of automation. I will refer to the specific ICS APIs below as needed.
These APIs can be scripted using any client programming language, although if Python is being used then Christian’s blog here provides a great set of starter scripts.

The best practices are as follows. I have split them in two sections, Pre Go-Live and Post Go-Live considerations.

Pre Go-Live Considerations

  1. a. Version Control the Integration IARs
    1. Although ICS integration IARs are binary zip files, it is still a good practice for developers to check in in the IARs periodically, just like checking in any code. They can export the integrations manually from ICS UI and import it to their git repository, or have this task automated by a CI/CD system that uses the ICS export REST API, described here to export the integration, and check it into their Version Control System on a nightly/periodic basis.
      Doing so ensures that the code is never lost. It also helps with code migration, as explained below.
  2. b. Code Migration via ICS REST APIs
    1. In typical development scenario, customer may provision separate ICS pods for Dev, Test and Prod environments.
      In such cases, code promotion (from, say Dev to Test) can be automated using ICS REST APIs, if the IARs are version controlled.
      Using their own CI/CD and Git infrastructure, customers can import the code from the Git Repository to ICS using the Import REST API .
      Also, if the customer has a subscription to Developer Cloud Service , the redthunder blog here provides in-depth detail of deploying IARs to ICS from Developer Cloud Service.
  3. c. Volume Considerations
    1. Just like any Managed Cloud platform, ICS has prescribed limits. A given ICS pod is sized for a maximum of 10 connections, with 100K messages per connection per day. This means the maximum suggested volume is 1M messages per day.
      Although this limit is not strictly enforced, crossing this limit may cause service interruptions.
      Hence, it is recommended to estimate the daily volumes of messages, and ensure they are well within the limits of the pod.

      Moreover, if the volume requirements are higher, customer can split their workload across multiple ICS pods.

Post Go-Live Considerations

  1. a. Monitoring integrations at runtime
    1. At runtime, one of the primary operational requirements is to monitor ICS integrations, ensure that messages are flowing in, they are executing successfully, and that the total number of daily messages is well within the expected limits. Customers may also want to integrate this information with their custom monitoring dashboards.
      All of this can be accomplished by using the Integration Monitoring API . It can be used as follows, for example, to query the successful and failed messages for all the integrations in the last hour.
      Request:

      curl -X GET "https://<server_name>.integration.us2.oraclecloud.com/icsapis/v2/monitoring/integrations?q={timewindow : '1h'}"

      Response:

      {
          "items": [
              {
                  "code": "Sample_Integration",
                  "id": "Sample_Integration|01.00.0000",
                  "links": [
                      {
                          "href": "https://<servername>.integration.us2.oraclecloud.com:443/icsapis/v2/monitoring/integrations/Sample_Integration%7C01.00.0000",
                          "rel": "self"
                      },
                  ],
                  "name": "Sample_Integration",
                  "noOfErrors": 17,
                  "noOfMsgsProcessed": 19,
                  "noOfMsgsReceived": 19,
                  "noOfSuccess": 2,
                  "successRate": 10,
                  "version": "01.00.0000"
              },
      		.....]
      	}

      In the example above, since the success rate for ‘Sample_Integration’ is just 10%, it makes sense to deactivate the integration(using the deactivate API) immediately and figure out what’s going on. This also ensures that failed messages don’t fill up the ICS database fast.

  2. b. Monitor Overall Pod status
    1. The Status Check API /icsapis/v2/status may be used to periodically monitor the overall ICS server status. If the status of each component in the response is ‘Available’, then everything is good.

    Sample Response :

    	{
        "components": [
            {
                "name": "HEALTH_CHECK_RUNTIME_SERVER",
                "status": "Available",
                "statusCode": 1
            },
    		......
        ],
        "systemStatus": "Available",
        "systemStatusCode": 1
    	}
    	
  3. c. Pod Database Management
    1. As we know, under the hood ICS is a single-tenant SOA FMW infrastructure, backed by a database.

      The database is one of the key components of the ICS pod, as all of ICS integrations, runtime messages, logs, metrics, etc. are stored in the database.

      ICS provides a number of ways to monitor and manage the database growth. For nominal load monitoring the database may not be needed, but if nearing the 1 Million messages per day limit, or if the overall errored instances percentage increases (error instances generate higher database activity), customers may need to manage the database growth.
      These database management and monitoring techniques are described below.

      1. 1. ICS automatically purges any data more than 3 days old, on a nightly basis. Moreover, the default retention period of 3 days can be modified via the ICS UI by navigating to dashboard->Settings->Database->Retention period.
        ICS Database Configuration Screen
      2. 2. Sometimes, due to a temporary surge in volume or an increase in errored instances, the database may grow at an abnormal rate.
        To tackle this, ICS provides a notification mechanism that warns the system admins when the tablespace usage goes beyond 70%.
        The notification can be configured by providing the system admin’s email address at dashboard->Settings->Notifications->Distribution List. All the admin has to do is enter her email address in the distribution list.
        ICS Notification Configuration
        Admins can also choose to continuously monitor the database growth by using the Tracking DB API, which provides the current tablespace usage.
      3. 3. Finally, if the tablespace usage goes beyond 80%, then ICS ‘quiesces’ the database, and temporarily deactivates all the integration endpoints. When this happens then the administrator can run the ‘Purge Now’ procedure at dashboard->Settings->Database->Purge Now, providing the retention period as a parameter. Once the purge procedure is complete and the tablespace usage is under 80%, all the integrations are automatically re-activated.
        The purge procedure can also be initiated via the Purge API, as listed in the sample curl command below.

        curl -k -v -X POST -u ashish.b.singh@oracle.com:<PWD> -H 'Content-Type:application/json' -H 'X-HTTP-Method-Override: PATCH' -d '{"retentionPeriod":{"unit": "DAYS","value": 3}}' https://<server_name>.integration.us2.oraclecloud.com/icsapis/v2/environment/trackingdb/purge

      The image below provides a sample scenario of how the ICS database and tablespaces could grow over a few days and how they shrink after running the purge procedure.
      Sample database growth

      The database used by ICS is none other than Oracle’s own Database Schema Service.

  4. d. Pod Filesystem Monitoring
    1. Similar to the database monitoring features above, ICS provides ways to monitor the filesystem usage as well. The current filesystem usage can be viewed by navigating to ICS dashboard->Monitoring->System Health -> FileSystem Status.
      Filesystem overage is rarely an issue because data files are deleted immediately after instance execution. Hence this dashboard is for monitoring purpose only.
      ICS Filesystem usage

Finally, though not an operational tip per se, customers should periodically monitor the “What’s New” section of ICS documentation to remain updated on new features being released.
They may discover brand new features, a new SaaS adapter, an enhancement that significantly reduces the complexity of their integrations, API enhancements, operational enhancements etc.
These could ease the development and maintenance of the current as well as future integration projects.

Add Your Comment