Upgrading to v5.2

This section discusses how you can upgrade from AC v4.6, v4.7, v4.7.1, or Adeptia Automate v5.1 to v5.2.

	As v5.2 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.

   If you are on v4.6 with MySQL 8.0 and want to keep your existing environment intact while performing the upgrade process on a different cluster, follow the steps below: • Provision a new MySQL 8.0 instance and create a namespace for the new environment on the Kubernetes cluster. • Clone the backend DB and log DB from the existing MySQL 8.0 instance to the new instance. • Clone all PVs/PVCs to new persistent volumes. • Upgrade the new MySQL instance from 8.0 to 8.4. • Update the values.yaml file to point to the new DB host and the cloned PVCs. • Install/upgrade using the 5.2.4 Helm chart in the new environment. By following this approach, your original v4.6 deployment and the old MySQL 8.0 instance will remain intact throughout the process, serving as a rollback target until v5.2.4 is fully validated.

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. Update the license by following the steps given below:

   1. Obtain the new license JAR file for v5.2 from Adeptia.
   2. Navigate to the /shared/license directory where the existing license file is located.
   3. Rename the existing license file to license_old.jar.
   4. Place the new license file in the /shared/license directory.
   5. Rename the new license file to license.jar.

6. Scale down the following microservice deployments:

   • api-publisher-gateway
   • event
   • listener
   • runtime

7. If you have set the provisioningMode to staticin your existing environment. This is required because Adeptia Automate v5.2 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 the Adeptia Automate v5.2 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.)

8. If you previously performed this upgrade, carried out any CRUD operations in the upgraded version before rolling back, and are now upgrading again, run the following query in the database.

PL/SQL

UPDATE AU_RULE
SET au_business_rule_id = NULL
WHERE au_business_rule_id = ''
   OR (
 au_business_rule_id IS NOT NULL
        AND au_business_rule_id NOT IN (
            SELECT au_id
            FROM AU_BUSINESS_RULE
 )
 );

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. https://artifacthub.io/packages/helm/adeptia-automate/adeptia-connect/5.2.0

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

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

   	Ensure that there are no messages in running or queued state before proceeding.

Variable	Description
EXECUTE_CLEANUP_JOB	Set to true to enable the cleanup job.
DELETE_RABBITMQ_STATEFULSET	Set to true to remove the existing RabbitMQ StatefulSet.
DELETE_RABBITMQ_PVC	Set to true to remove the existing RabbitMQ Persistent Volume Claims.
DELETE_RABBITMQ_Cluster	Set to true to remove the existing RabbitMQ Cluster resources.
DELETE_RABBITMQ_CONFIG_SECRET	Set to true to remove the existing RabbitMQ configuration secret.

7. 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. |8. Do the following configurations for Mapping Agent:
   1. Set the LLM provider.

Parameter	values.yaml path	Accepted values
LLM Provider	global > acagent > llm > provider	• azure_openai • openai • anthropic • ollama

2. Enter the LLM provider credentials.

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

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

3. Set the required environment variables.

   Set the following variables under global > acagent > environmentVariables:

   Variable	Accepted values	Description
   AI_AGENT_BACKEND_URL	User-defined	Connection 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.

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

1. Add the Helm repo:

Code

helm repo add <Repo name> https://adeptia.github.io/adeptia-automate-helm-package/charts/

2. 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.0  -f <Path of the values.yaml> -n <Namespace>

---

Post-upgrade steps

Follow the post-upgrade steps given below:

1. Delete the AdeptiaAIModelfile by following the steps below:
   1. Scale down the AIMap microservice deployment.
   2. Navigate to the shared/AIMap directory to locate the AdeptiaAIModel file.
   3. Delete the AdeptiaAIModel file.
   4. Scale up the AIMap microservice deployment.
2. Scale up the microservice deployments that were scaled down before the upgrade.
3. Import the certificates that were manually added to cacerts before the upgrade.
4. Restart all microservices.
5. Reactivate the dedicated deployments that were deactivated before the upgrade.