Platform v7.2-Release Description

Orchestration Improvements

Introduced validation while uploading micro actions

SmartOps platform is enabled with the capability to validate the microactions uploaded. In case if user uploads an invalid microaction, UI will not allow user to proceed with the upload. User can either revert to "Previous" screen or refresh the screen.

Java based micro actions for MongoDB operations

Java-based micro actions are introduced for Mongo operations. These microactions will take care of mongo based operations for retrieving, inserting, updating and deleting individual/multiple records from/to Mongo.

Micro actions introduced are:

• mongodb_deletemany_documents_java

• mongodb_deleteone_document_java 

• mongodb_findmany_java 

• mongodb_findone_java 

• mongodb_insertmany_java 

• mongodb_insertone_java 

• mongodb_updatemany_java 

• mongodb_updateone_java 

PWF Enhancements

Clones upgrade container to apply changes specific to the PWF instance

SmartOps is enabled with the capability of CLONES to apply changes specific to PWF instances.

The enhancement enables to identify the PWF associated in an organization and update the roles and permission mapping accordingly. 

By default, all the smartops-frontend roles will be available in keycloak. PWF specific realm roles can be added by checking the PWF association. If no PWF is associated to the organization, then CLONES, iHub and Smartops common roles and their permission mapping will be added to the organization.  

Rule Engine Implementation in SmartOps     

A rule engine is available as part of platform, that can be leveraged by applications to configure rules for validation, classification, etc.

SmartOps Platform has introduced a new UI to create and manage rules, as required.

User will also have the privilege to view the execution history related to rules definition.

Rule Engine can be accessed through a new menu available in the "Nine Dots". Access to Rule Engine menu can be restricted based on "Permissions".

IHub Enhancements 

Context updater to maintain consistency with HA enablement

SmartOps v7.2 has introduced updates to Context Updater in Ihub. 

Requests from a client application is distributed to multiple iHub nodes by HA Proxy Load Balancer. Channel configuration related data is available in local cache of each node, for the corresponding requests to be processed. 

In case if any channel update request was raised by client application and it was processed by, say, Node 1, local cache of Node 1 records the changes and process any further requests based on the update. In such scenarios, other applicable nodes in the cluster was not aware of the updates.

This resulted in discrepancies in output data from each node.

SmartOps 7.2 is updated with enhancement to address the problem. A context updater module is introduced in iHub nodes which will pass the updates to Channel Activity table of Mongo DB. Context Updater in all other nodes will connect with Mongo DB at specified intervals and retrieve the related updates and refreshes the data in the corresponding local cache. This enables all the nodes to be synced with any updates.  

Destination routing in iHub channels - Support API call similar to iHubLite 

IHub, by default, passes data to CLONES after data transformation, and then passed to 'Automation Story'.

This feature enables to invoke user defined API after data transformation instead of publishing to CLONES queue. 

This feature is initially introduced for API and Queue channel. 

Introduction of RHub

Rhub is SmartOps component that can be deployed in customer networks to manage integration with existing systems.

Following are the key components related to RHub:

• Central Hub

• Remote Hub (Rhub core)

• Adapter

• Transformer

• Authenticator

• Flow

RHub enables to:

• Invoke API endpoints within customer network and capture the response in SmartOps

• Execute PowerShell scripts within customer network and capture the results in SmartOps

Organisation level segregation of master configuration

This feature enables to segregate the master configuration data stores for each organization associated with a PWF. This is a required step towards multi-tenancy.

Currently all organizations associated for a PWF use the same master configuration and an update in master config for any one organization will impact all organizations associated with that PWF.

Data archival implementation for MySQL data stores   

For any transactional data stored on the platform, SmartOps had the provision to archive records older than a specified date (driven by business needs) and remove them from the platform. 

SmartOps currently enables archival of transactional data stored in My SQL data stores.

Note: SmartOps v7.2 implementation includes stage two archival for MySQL data stores.

Enhancements to Support Staggered Release

Segregation of skill dumps for core platform and PWFs

As part of the support for staggered release, SmartOps will separate skill dump into a base dump for the core platform and additional dumps for each PWF that can be imported over the base dump. 

Separation of Liquibase script for different components

As part of the support for staggered release,  SmartOps is enabled to separate Liquibase script (MySQL changes) into separate ones for each of the components (in each release). 

For example: A column may be added to a PWF schema table in version 7.2 of PWF. This will be included in the core platform 7.2 upgrade liquibase. If a later release of ITOps (say, 2.0) has changes based on this table, a dependency will be called out on core platform 7.2, and included in a liquibase script that will be run on top of the core platform liquibase script. 

Migrate Keycloak role and permission mapping data from json files to DB tables

To support staggered release, keycloak role and permission mapping data is moved from json files to DB tables.

 

 

 

 

Feedback

Copyright © 2021 UST Global. All Rights Reserved.