Skip to main content

Upgrading from v5.1 or v5.1.x to v5.2.4

This section discusses how you can upgrade from Adeptia Automate v5.1, v5.1.1, 5.1.2, or 5.1.3 to v5.2.4

errorAs v5.2.4 requires you to implement the upgraded RabbitMQ, any data in queued or running state during the upgrade will be lost.

Pre-upgrade configurations​

Step 1 — Perform the following pre-upgrade tasks​

  1. If you are using MySQL DB, take its backup, and then upgrade its version to v8.4.
  2. Take a backup of the cacerts file present in the /shared/truststore folder.
  3. Ensure that no Process Flows or Templates/Automations are in queued or running state.
  4. Deactivate the dedicated deployments (if any).
  5. Scale down the following microservice deployments:
    • api-publisher-gateway
    • event
    • listener
    • runtime
  6. If you have set the provisioningMode to staticin your existing environment, follow the steps below. This is required because Adeptia Automate v5.2.4 uses an upgraded RabbitMQ.
    1. Clean up the existing RabbitMQ installation before upgrading.
      1. Scale down the RabbitMQ StatefulSet.
      2. Delete RabbitMQ PVCs.
      3. Delete RabbitMQ PVs.
      4. Recreate RabbitMQ PVs. These steps are required as the Adeptia Automate v5.2.4 uses an upgraded RabbitMQ.
    2. Create three Redis PVs (This step is required only when your existing environment does not have Redis deployed in it.)

Step 2 — Uninstall the existing RabbitMQ Operator (If already deployed in existing environment)​

Code

helm list -n <Existing RabbitMQ Operator namespace>

Code

helm uninstall <Release name> -n <Existing RabbitMQ Operator namespace> 

Step 3 — Install the new RabbitMQ Cluster Operator​

Install the new RabbitMQ Cluster Operator required for the upgraded RabbitMQ deployment. For installation steps, see Installing the RabbitMQ Cluster Operator

Step 4 — Update the values.yaml file​

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

  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.4

  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 value of the ipfamily property under the global > config section in the values.yaml file to ipv6 if your cluster supports the IPv6 protocol. IPv4 is supported by default.

  6. Ensure that the values for the following variables are set as mentioned in the table below: | Variable | Section in values.yaml | Value | | --- | --- | --- | | EXECUTE_STATIC_JOB | global > static | true | | EXECUTE_MIGRATION_JOB | global > migration | true |

  7. 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:

    • global > webappGateway > customActuatorSecrets
    • global > apigateway > customActuatorSecrets If you do not want to specify credentials for enabling authentication to download heap dumps, setcreatetofalseand provide your secret name in thesecretNameparameter in the above sections. Refer to the table below for details: | Parameter | Description | | --- | --- | | create | Determines 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. | | secretName | The name of the Kubernetes Secret that stores the credentials. Pods refer to this Secret for authentication. |9. Do the following configurations for Mapping Agent:
    1. Set the LLM provider.

Parametervalues.yaml pathAccepted values
LLM Providerglobal > acagent > llm > provider
• azure_openai
• openai
• anthropic
• ollama

  1. Enter the LLM provider credentials.

    Set the following secrets under global > acagent > secretValues based on your chosen LLM provider.

    ProviderRequired Secrets
    Azure OpenAI
    • azureOpenAiApiKey
    • azureOpenAiEndpoint
    • azureOpenAiDeploymentName
    OpenAI
    • openAiApiKey
    • openAiBaseUrl
    • openAiModel
    Anthropic
    • anthropicApiKey
    • anthropicModel
    Ollama
    • ollamaBaseUrl
    • ollamaModel

  2. Set the required environment variables.

    Set the following variables under global > acagent > environmentVariables:

    VariableAccepted valuesDescription
    AI_AGENT_BACKEND_URLUser-definedConnection string for the backend database.



    Use the format:
    mssql+pyodbc://<host>:<port>/<Backend Database Name>?driver=ODBC+Driver+17+for+SQL+Server
    AUTH_TYPE
    • jwt
    • api-key    		Authentication method used by the Mapping Agent.

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

Step 5 — Configure RabbitMQ​

Configure the RabbitMQ settings in the values.yaml file. For details, see Configuring RabbitMQ Parameters.

Upgrading to v5.2.4​

  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.4  -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. Import the certificates that were manually added to cacerts before the upgrade.
  3. Execute the following query in the backend database:

Code

UPDATE AU_RULESET_RULE_LINK SET RULE_SEVERITY = 1 WHERE RULE_SEVERITY = 0;
  1. Execute the following query in the log database:

Code

CREATE INDEX IDX_AU_RULE_RESULTS_BRE_ID
ON AU_RULE_RESULTS (AU_BUSINESSRULE_EXECUTION_ID);

CREATE INDEX IDX_AU_RULE_EXEC_BRE_ID
ON AU_RULE_EXECUTIONS (AU_BUSINESSRULE_EXECUTION_ID);

  1. Restart all microservices.

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

  3. Open the agent deployment by running the command in the following format:

    kubectl edit deployment <Name of the deployment for the agent microservice> -n <Namespace where you have deployed the application>

  4. On the deployment that opens, add the variable ORCHESTRATOR_BATCH_SIZE and set its value to '5' as shown in the screenshot below: 

    WarningSteps 9 through 12 are optional. Skip them if they were already completed during a previous version's setup, or if you do not wish to deploy the Amazon DynamoDB CData driver.

  5. Download and Deploy the Amazon DynamoDB CData driver.

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

  7. 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.

  8. If you have performed s tep 11, you need to restart the following services:

    1. Event
    2. Webrunner
    3. Runtime