Release Notes 21.0.443

1. RELEASE INFO

2. CONTENT OF THE RELEASE

2.1 Highlights

• New External APIs for customers' connectivity to Deployment Management (promote, demote, deploy etc.) in SaaS Enterprise Edition (in limited preview)

• New External APIs to export load definitions from Runtime environments in SaaS Enterprise Edition (in limited preview)

• New timeslot logic as a performance tuning option for event data loading

• Data Vault: New Multi-active Satellite entity type and load SQL generation

• Generic 1:1 Load SQL generation is supported in all of the DBMS services (in public preview)

• Export Package (JSON) per Commit / Recent (uncommitted) in Designer

• New Copy from Refs. automation e.g. in case of Link entity types

2.2 Security

Security fixes

2.3 Infrastructure

Improvements

Fixes

2.4 Designer

New Features

Improvements

3rd party upgrades

Fixes

2.5 Configurability

Improvements

2.6 Deployment Management

Improvements

Fixes

2.7 Loads and Workflows

New Features

Fixes

2.8 DBMS Support

Improvements and Fixes

2.9 Dashboards

N/A

2.10 SaaS Editions

Notify API

External API

3. NOTIFICATIONS

3.1 Supported Upgrade Path

• From 20.0.365 to 20.1

• From 20.1 to 20.2.

• From 20.2 to 21.0.435 (in Private Azure mandatory, in Private AWS optional)

• From 21.0.435 to 21.0.443

• Upgrading from earlier releases

  • First to 20.1.380.patch1 and then to 20.2 and then to 21.0.

  • E.g. from 19.3.334.patch4 to 20.0.354_patch7 and then directly 20.1.380.patch1 (or any latest of 20.1), then to 20.2.396.patch5 and finally to this release.

• See earlier release notes also if upgrading from older releases.

3.2 Automatic migration mode need to be set for Deployment Management migration

• Main configuration parameter deploymentApiMigrationMode should be set to value MINIMAL.

• The migration will take place when Deployment API service starts and it will migrate the information of deployed and promoted and to-be-promoted packages into Deployment API's database.

  • Also, it will migrate the entity and config packages from build repository to new commit repository (based on the database and S3/Blob storage).

3.3 Automatic Metadata Repository Database snapshots in Private AWS edition

• When ADE update detects release change or PostgreSQL version change in main configuration, database snapshots will be created from all ADE RDS PostgreSQL instances of that environment.

• This happens by default as a post step in update and the retention time of 62 days is applied for these snapshots. This feature can be configured in main configuration if needed.

3.4 Private Azure edition: bastion hardening CentOS image has changed

• If installing ADE to Private Azure or updating bastion to apply bastion hardening, the new Centos image to be used is defined and consult our Professional Services.

• If trying to apply bastion hardening with earlier ADE release versions, it will fail. Corrected bastion hardening to this release.

• This only concerns new Private Azure installations or if otherwise needed to re-install the bastion host with the hardening. Existing hardened bastions will work.

3.5 Private Azure edition: AKS cluster version upgrade

• The AKS version will be upgraded to 1.20.9 by this release. Also AKS node pool version will be updated to the same as AKS version.

• The update of the node pool version requires re-creation of the AKS cluster.

3.6 Metadata Repository Database's PostgreSQL version upgrade

• If not yet done with earlier release, in AWS edition the PostgreSQL version will be upgraded from current 9.6 to 11. This took about 25 minutes per environment in our test environment. Dependent on the database sizes.

• In Private Azure edition, the upgrade is not done by default. It must be done by you manually. The PostgreSQL upgrade from 9.x to 11 should already be done with earlier release 20.2.

3.7 Private Azure edition: PostgresSQL version check

• ADE update in Private Azure will now check that the PostgresSQL version is 11 (The version provided by ADE release currently) and if not, an exception is thrown and update can't be continued before upgraded to 11.

3.8 packageversion token value has changed and it will get longer values than earlier

• Originally <packageversion> token has gotten the value from Jenkins build number ranging usually from 1 to 10000.

• From 21.0 onwards the token will get the value from Deployment API's commit id, which is global sequence per installation and it starts from value 1000000 for new commits and from value 500000 for migrated packages. So when using <packageversion> token with strictly limited varchar/char lengths in a column, this can cause failure or truncated value at least.

3.9 Related to Grafana upgrade, old alive session might cause problem in login

• NOTE: If having problems logging in to Grafana, it will need to clear old Grafana sessions from the web browser. Open dev tools and sessions and remove Grafana related.

3.10 Related to Grafana upgrade, AWS Cloudwatch datasource can fail in Private AWS editions

• NOTE: If having AWS Cloudwatch datasource, it might switch provider to "credential". This will fail since there is no any credential files in Grafana service. The provider should be "AWS SDK Default", it will use the granted AWS role for Cloudwatch.

3.11 There is new Run ID API and the old batch API is deprecated

There is new implementation of the Run ID API. The old one is deprecated and will not function (only getting new batchId works). Workflow Orchestration (aka. Dagger) will use the new one.

There is no user action needed unless old APIs are used by some custom implementation. The change is that the new one uses Entity IDs and Load IDs instead of Entity and Load names.

The Runtime internal service Process API serves the API as before and makes migration of Run ID history into new table structure P_RUN_ID (old is P_RUNID).

3.12 Additional options to use with update scripts

For speeding up the update process:

• packages-only: This will download ADE package and sync docker images to local machine and to target repository, but not run the installation.

  • Consider loading docker images to target ADE environment by this option beforehand. This update operation will not change anything in that environment except for adding new images to repositories.

• skip-packages: Will skip the docker image downloading and syncing to target repo. Useful if needed to iterate ADE configuration changes etc.

  • E.g: ./update_ade_design.sh the-main-conf.yaml DESIGN skip-packages