Skip to main content

Upgrading to v5.2.3

This section discusses how you can upgrade from Adeptia Automate v5.2 or v5.2.1 to v5.2.3.

Pre-upgrade configurations​

Step 1 — Perform the following pre-upgrade tasks​

  1. Ensure that no Process Flows or Templates/Automations are in queued or running state.
  2. Deactivate the dedicated deployments (if any).
  3. Scale down the following microservice deployments:
    • api-publisher-gateway
    • event
    • listener
    • runtime

Step 2 — Update the values.yaml file​

  1. Go to the Adeptia Automate ArtifcatHUB page for Adeptia Automate v5.2.3. https://artifacthub.io/packages/helm/adeptia-automate/adeptia-connect/5.2.3

  2. Click DEFAULT VALUES.

  3. On the Default values screen, click the (download) icon to download the global values.yaml file for Adeptia Automate v5.2.3.

  4. In the global values.yaml, update the following configurations:

    • Image Pull Secret
    • Database credentials
    • Docker image URLs as per the repository (applicable if you are using a private repository to host the Adeptia Docker images)

  5. Set the values for the following variables as mentioned in the table below: | Variable | Section in values.yaml | Value | | --- | --- | --- | | EXECUTE_STATIC_JOB | global > static | false | | EXECUTE_MIGRATION_JOB | global > migration | false | | EXECUTE_CLEANUP_JOB | global > cleanup | false |

  6. If you are switching from HA mode of RabbitMQ to non-HA mode or vice-versa, ensure that the values for the following variables under the global > cleanup section of the values.yaml file are set to true to delete the existing RabbitMQ resources before the upgrade.

    WarningEnsure that there are no messages in running or queued state before proceeding.
VariableDescription
EXECUTE_CLEANUP_JOBSet to true to enable the cleanup job.
DELETE_RABBITMQ_STATEFULSETSet to true to remove the existing RabbitMQ StatefulSet.
DELETE_RABBITMQ_PVCSet to true to remove the existing RabbitMQ Persistent Volume Claims.
DELETE_RABBITMQ_ClusterSet to true to remove the existing RabbitMQ Cluster resources.
DELETE_RABBITMQ_CONFIG_SECRETSet to true to remove the existing RabbitMQ configuration secret.

  1. In the following sections of the values.yaml file, set the username and password for enabling authentication to download heap dumps. To authenticate using these credentials, ensure that the createparameter in these sections is set to true:

    1. global > webappGateway > customActuatorSecrets

    2. global > apigateway > customActuatorSecretsIf you do not want to specify credentials for enabling authentication to download heap dumps, set create to false and provide your secret name in the secretName parameter in the above sections. Refer to the table below for details:

      ParameterDescription
      createDetermines whether the Helm chart creates a Secret in the target namespace. Set to true (default) for Helm to create the Secret from the username and password you provide. Set to false if you want the pods to reference an existing Secret created outside Helm — for example, by HashiCorp Vault, External Secrets Operator, a CI/CD pipeline, or a platform-managed Kubernetes Secret.
      secretNameThe name of the Kubernetes Secret that stores the credentials. Pods refer to this Secret for authentication.

  2. Ensure that all the remaining settings in the values.yaml file, except those discussed in this guide, remain as per the previous configuration.

Upgrading to v5.2.3​

  1. Add the Helm repo:

Code

helm repo add <Repo name> https://adeptia.github.io/adeptia-automate-helm-package/charts/
  1. Update the application Helm repository:

Code

helm repo update
  1. Upgrade the application:

Code

helm upgrade -i <Release name> <Repo name>/adeptia-connect --version 5.2.3  -f <Path of the values.yaml> -n <Namespace>

Post-upgrade steps​

Follow the post-upgrade steps given below:

​

  1. Scale up the microservice deployments that were scaled down before the upgrade.

  2. Reactivate the dedicated deployments that were deactivated before the upgrade.

  3. Download and Deploy the Amazon DynamoDB CData driver.

  4. After you deploy the database driver, ensure that the Amazon DynamoDB driver is present at Configurations > Setup > Account > Database Driver.

  5. If you are using connection pooling in the Database Info activity for databases other than MySQL, Oracle, SQL Server, and PostgreSQL, you need to verify that the driver JAR is present in Configurations > Setup > Custom Libraries > Ext. Additionally, ensure that a validation query compatible with the driver is set in the abpm.database.validationQuery property under Settings > Application Settings > Common > Database Connection.

    For example, in the case of Redshift, ensure that the Ext folder contains the redshift-jdbc42-<version>.jar file and that the property is set to SELECT 1.

  6. If you have performed s tep 5, you need to restart the following services:

    1. Event
    2. Webrunner
    3. Runtime