2020.2 (latest)

Product Notices

On this page:

Breaking Changes

d style="text-align:left;">connectDevice Checks a device connection from Pronghorn (IAP) to a device through NSO. 2018.3 2020.2 Device Broker
isAlive getDeviceGroupsForDevices Gets the device groups for all devices. 2018.3 2020.2 Itential no longer supports NSO device groups and auth groups as brokerable constructs. Use adapter tasks instead. liveStatus Attempts to send data directly to a device. 2018.3 2020.2 adapter-nso
liveStatus liveStatusScanHosts Will search all hosts that recognize the device. 2018.3 2020.2 adapter-nso
liveStatus syncTo Syncs the device config to NSO. 2018.3 2020.2 adapter-nso
syncTo updateDeviceSetting Updates an NSO device setting. 2018.3 2020.2 adapter-nso
addDevice (with settings)

Service Broker

Item Description Deprecation Release Actual Removal Release Replacement
dryRunService Get a dryrun from adding a service instance. 2018.3 2020.2 None
dryRunXML Dryrun an XML object. 2018.3 2020.2 adapter-nso
dryRunXML
fetchData Performs a search on all currently running NSO instances (set as service types). 2018.3 2020.2 adapter-nso
fetchData
findService Retrieve service data. 2018.3 2020.2 None
getServiceModelMap Gets all the service models IAP (Itential Automation Platform) currently has access to. 2018.3 2020.2 adapter-nso
getServiceModelMap
provisionXML Provision a service with an XML object. 2018.3 2020.2 adapter-nso
provisionXML
runAction Executes an action on the adapter. 2018.3 2020.2 adapter-nso
runAction

Removal of Adapter-Mongo

To better support the use of Mongo in the workflow, adapter-mongo was deprecated and removed, and replaced with adapter-db_mongo, an open-sourced adapter. The dbManager is preferred for source code, and adapter-db_mongo is how you access Mongo from a workflow.

As a result of this removal, customers will need to instantiate their database connections for custom applications. Custom applications can continue to use MongoDB, although it is no longer required

Tags UI Moved to Admin Essentials

The Tags user interface has been removed from its previous location of <base URL>/tags and a new Tags interface has been added to the Admin Essentials home page. Users accessing the previous Tags URI will be redirected to the Admin Essentials home page to access the new Tags interface.

Platform Naming Conventions

All adapters, applications, and brokers must have method parameters and return names that adhere to the new platform naming conventions. For releases in the near future, all non-validating names will cause the adapter, application, or broker to not start in the platform and an error log message will be written to the log files and to standard output (stdout).

The platform naming conventions are also used to validate job variable names in workflows, and any non-validating names will cause the workflow to have errors and be put in "draft" mode. Users cannot start a job from a workflow if it is in "draft" mode.

What should I do?

Consult the documentation explaining the naming conventions. Ensure each job variable defined within all workflows follow the conventions. Use the Level of Effort (LOE) tool to quickly identify any violations to the naming convention.

For any custom applications, adapters, and tasks, review all method parameters and return names to ensure adherence to the naming conventions. Please remember, even though this release will not have any ill-effects and will behave the same as it does in the previous release, future releases will cause these adapters, applications, and tasks to not start.

Return Type Change for getOutOfSyncConfig() in adapter-nso

The getOutOfSyncConfig() function returns a string format configuration containing many out-of-sync configs. However, when a device is in-sync, the function returns an empty array instead of an empty string. This change modifies the return value to an empty string.

BREAKING CHANGE for 2020.1.1 -> 2020.2

RabbitMQ Properties Moved from Service Config to Profile

Upon upgrade from the 2020.1.1 maintenance patch version to the 2020.2 bundle, the RabbitMQ properties will be automatically moved from all service configs to the profile. Additionally, these settings will be changed in the database; therefore all systems that share this database connection will be affected also. Please note, if you have a disaster recovery (DR) system in your setup, the changes made to the database will take effect once the first system is updated and affect all systems using that database. This basically means that all systems will need to be upgraded at the same time.

Rollback Instructions

Since the RabbitMQ properties will be auto-migrated from the service config to the profile, if a rollback is necessary, those properties must be restored manually to each relevant service config prior to upgrade.