Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

You can install Adeptia Connect microservices using Helm Charts. A Helm Chart is a collection of files and templates that describe Kubernetes resources governing the deployment of microservices.

Follow the steps below in the same order to install Adeptia Connect. 

Table of Contents
maxLevel2
excludeUninstalling|Removing|Properties

Note
Ensure that you have met all the prerequisites and system requirements before you begin to install the application.

Creating Service Accounts, ClusterRoles, and ClusterRoleBindings

Before you begin to install the application, you need to create Service Accounts, Roles, and RoleBindings. This section makes you aware of the:

  • Service Accounts required by Adeptia Connect application.
  • ClusterRoles, and ClusterRoleBindings required for the these Service Accounts.
  • Permission required by the user who is deploying the helm chart.
  • Roles and RoleBindings required by this user.
  • External secret crd yaml.
  • External secret ClusterRoleBindings.

Adeptia provides you with a roles zip file along with the Adeptia Connect Helm chart. This zip contains the YAML files required to create Service Accounts, ClusteRoles, ClusterRoleBindings, etc. The following table helps you understand the purpose of each yaml file. 

...

File Name

...

Purpose

...

Description

...

For Service Accounts required by Adeptia Connect application

...

serviceaccount-adeptia.yaml

...

It creates a Service Account with the name “adeptia”.

...

This Service Account is used by all the Adeptia core services except autoscaler. You need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

...

clusterrole-adeptia.yaml

It creates a ClusterRole with the name “adeptia-connect”.

Info
As a best practice, if you are deploying multiple instances of the application, append the namespace to the name of the ClusterRole on subsequent deployments. This prevents overwriting of the existing ClusterRole.

...

This ClusterRole contains the permission required by the above service account.

...

clusterrolebinding-adeptia.yaml

It creates a ClusterRoleBinding for the service account “adeptia” with the “adeptia-connect” cluster role.

Info
As a best practice, if you are deploying multiple instances of the application, append the namespace to the name of the ClusterRoleBinding on subsequent deployments. This prevents overwriting of the existing ClusterRoleBinding.

...

In this file, you need to update the namespace in which you will deploy the Adeptia Connect helm.

...

serviceaccount-autoscaler.yaml

...

It creates a Service Account with the name “autoscaler-runtime”.

...

This Service Account will be used by the runtime autoscaler to launch a runtime deployment whenever a queue is created within the Adeptia Connect application. For this Service Account, Role and RoleBinding will get created automatically during helm deployment by autoscaler sub chart. You need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

...

For the user, who will deploy the helm chart

...

role-deployment-user.yaml

...

It creates the Role with name “adeptia-user”

...

This Role contains the permission required by the user who will deploy the Adeptia Connect helm chart. In this file, you need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

...

rolebinding-deployment-user.yaml

...

It creates the RoleBinding with the name “adeptia-user”.

...

In this file, you need to update the namespace in which you want to deploy the Adeptia Connect helm chart. You also need to update the name of the user, who will deploy the Adeptia Connect helm chart.

...

Required for External Secret

...

serviceaccount-adeptia-es.yaml

...

It creates a Service Account with the name “adeptia- es”.

...

This Service Account will be used by external secret. You need to enter namespace in this file.

...

clusterrole-adeptia-es.yaml

...

It creates a ClusterRole with the name “adeptia- connect-es”.

...

This ClusterRole contains the permission required by the above service account used by external secret.

...

clusterrolebinding-adeptia-es.yaml

...

It creates a ClusterRoleBinding for the service account “adeptia-es” with the “adeptia-connect-es” ClusterRole.

...

In this file, you need to update the namespace in which you will deploy the Adeptia Connect helm.

...

es-crd.yaml

...

It creates the external secret component CRDs.

...

This is needed only when you will use the external secret to fetch the secrets from the external vault.

...

es-clusterrolebinding-deployment-user.yaml

...

It creates a ClusterRoleBinding to provide “system:auth-delegator” permission to the user who will deploy the Adeptia Connect helm.

...

In this file you need to update the name of the user, who will deploy the Adeptia Connect helm.

To create Service Accounts, ClusteRoles, ClusterRoleBindings, follow the steps given below.

...

Run the following command to deploy the yaml files. 

Code Block
languagecss
themeMidnight
kubectl apply -f adeptia_roles/

...

If you want to use external secret, run the following command to create Service Accounts, ClusterRoles, ClusterRoleBindings and external crd for external secret.

Code Block
languagecss
themeMidnight
kubectl apply -f es/

Enabling OCI support in the Helm 3 client

Helm 3 supports Open Container Initiative (OCI) for package distribution. Set the HELM_EXPERIMENTAL_OCI in the environment to enable OCI support in the Helm 3 client by running the following command on the Helm CLI.

Code Block
languagecss
themeMidnight
export HELM_EXPERIMENTAL_OCI=1

Installing Adeptia Connect

Follow the steps below to install Adeptia Connect.

...

Add Adeptia Connect repo using following command:

Code Block
languagecss
themeMidnight
helm repo add adeptia-connect https://adeptia.github.io/adeptia-connect-helm-package/charts/

...

Tip
You can download the sample values.yaml file for a development environment by clicking values-dev.yaml and change the values based on your requirement. 

...

Update the values.yaml as per instruction given in this section.

Run the the following command to deploy the application.

Code Block
languagecss
themeMidnight
helm install adeptia-connect adeptia-connect/adeptia-connect --version <Version number> -f <PATH_OF_VALUES.YAML> --timeout 10m
Warning
titleImportant
Use a specific version number in the version argument, else the latest version of Adeptia Connect will be installed.

This command deploys Adeptia Connect on the Kubernetes cluster.

Info

Once you've completed the deployment, you need to configure your domain specific SSL certificate by using either of the two options:

  • Use Ingress in front of the Gateway service and configure SSL on Ingress.
  • Configure SSL directly on the Gateway service.

To know more about configuring SSL, click here.

...

Update the following properties in values.yaml before you run the helm install command to install the application.

Table of Contents
maxLevel3
minLevel3

Defining the required database properties

...

Username for your backend database.

If you're using external Secrets, you need not provide a value for this property.

...

Password for your backend database.

If you're using external Secrets, you need not provide a value for this property.

...

You can install Adeptia Connect microservices using Helm Charts. A Helm Chart is a collection of files and templates that describe Kubernetes resources governing the deployment of microservices.

Follow the steps below in the same order to install Adeptia Connect. 

Table of Contents
maxLevel2
excludeUninstalling|Removing|Properties

Note
Ensure that you have met all the prerequisites and system requirements before you begin to install the application.

Creating Service Accounts, ClusterRoles, and ClusterRoleBindings

Before you begin to install the application, you need to create Service Accounts, Roles, and RoleBindings. This section makes you aware of the:

  • Service Accounts required by Adeptia Connect application.
  • ClusterRoles, and ClusterRoleBindings required for the these Service Accounts.
  • Permission required by the user who is deploying the helm chart.
  • Roles and RoleBindings required by this user.
  • External secret crd yaml.
  • External secret ClusterRoleBindings.

Anchor
4.1.3
4.1.3

Adeptia provides you with a roles zip file along with the Adeptia Connect Helm chart. This zip contains the YAML files required to create Service Accounts, ClusteRoles, ClusterRoleBindings, etc. The following table helps you understand the purpose of each yaml file. 

Warning
titleImportant!

While deploying AC v4.1.3 or above with default Kubernetes secrets, the following Service Accounts, ClusterRoles, and ClusterRoleBindings files are not included in the roles zip. The application automatically takes care of creating and configuring the Service Accounts and its privileges.

  • serviceaccount-adeptia.yaml
  • clusterrole-adeptia.yaml
  • clusterrolebinding-adeptia.yaml
  • serviceaccount-autoscaler.yaml


File Name

Purpose

Description

For Service Accounts required by Adeptia Connect application

serviceaccount-adeptia.yaml

It creates a Service Account with the name “adeptia”.

This Service Account is used by all the Adeptia core services except autoscaler. You need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

clusterrole-adeptia.yaml

It creates a ClusterRole with the name “adeptia-connect”.

Info
As a best practice, if you are deploying multiple instances of the application, append the namespace to the name of the ClusterRole on subsequent deployments. This prevents overwriting of the existing ClusterRole.


This ClusterRole contains the permission required by the above service account.

clusterrolebinding-adeptia.yaml

It creates a ClusterRoleBinding for the service account “adeptia” with the “adeptia-connect” cluster role.

Info
As a best practice, if you are deploying multiple instances of the application, append the namespace to the name of the ClusterRoleBinding on subsequent deployments. This prevents overwriting of the existing ClusterRoleBinding.


In this file, you need to update the namespace in which you will deploy the Adeptia Connect helm.

serviceaccount-autoscaler.yaml

It creates a Service Account with the name “autoscaler-runtime”.

This Service Account will be used by the runtime autoscaler to launch a runtime deployment whenever a queue is created within the Adeptia Connect application. For this Service Account, Role and RoleBinding will get created automatically during helm deployment by autoscaler sub chart. You need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

For the user, who will deploy the helm chart

role-deployment-user.yaml

It creates the Role with name “adeptia-user”

This Role contains the permission required by the user who will deploy the Adeptia Connect helm chart. In this file, you need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

rolebinding-deployment-user.yaml

It creates the RoleBinding with the name “adeptia-user”.

In this file, you need to update the namespace in which you want to deploy the Adeptia Connect helm chart. You also need to update the name of the user, who will deploy the Adeptia Connect helm chart.

Required for External Secret

This is needed only when you will use the external secret to fetch the secrets from the external vault.

serviceaccount-adeptia-es.yaml

It creates a Service Account with the name “adeptia- es”.

This Service Account will be used by external secret. You need to enter namespace in this file.

clusterrole-adeptia-es.yaml

It creates a ClusterRole with the name “adeptia- connect-es”.

This ClusterRole contains the permission required by the above service account used by external secret.

clusterrolebinding-adeptia-es.yaml

It creates a ClusterRoleBinding for the service account “adeptia-es” with the “adeptia-connect-es” ClusterRole.

In this file, you need to update the namespace in which you will deploy the Adeptia Connect helm.

es-crd.yaml

It creates the external secret component CRDs.

This is needed only when you will use the external secret to fetch the secrets from the external vault.

es-clusterrolebinding-deployment-user.yaml

It creates a ClusterRoleBinding to provide “system:auth-delegator” permission to the user who will deploy the Adeptia Connect helm.

In this file you need to update the name of the user, who will deploy the Adeptia Connect helm.

To create Service Accounts, ClusteRoles, ClusterRoleBindings, follow the steps given below.

Warning
titleImportant!
In case of deploying AC v4.1.3 or above, refer to this note.
  1. Download the roles.tgz (roles zip) file from the following link:
    https://adeptia.github.io/adeptia-connect-roles/charts/roles-4.0.tgz
  2. Unzip this file.
  3. Update the yaml files as explained in the table above.
  4. Run the following command to deploy the yaml files. 

    Code Block
    languagecss
    themeMidnight
    kubectl apply -f adeptia_roles/


    This creates the required Service Accounts, ClusterRoles, ClusterRoleBindings, Roles, and RoleBindings.

    Info

    If you want to use external secret, run the following command to create Service Accounts, ClusterRoles, ClusterRoleBindings and external crd for external secret.

    Code Block
    languagecss
    themeMidnight
    kubectl apply -f es/



Enabling OCI support in the Helm 3 client

Helm 3 supports Open Container Initiative (OCI) for package distribution. Set the HELM_EXPERIMENTAL_OCI in the environment to enable OCI support in the Helm 3 client by running the following command on the Helm CLI.

Code Block
languagecss
themeMidnight
export HELM_EXPERIMENTAL_OCI=1

Installing Adeptia Connect

Follow the steps below to install Adeptia Connect.

  1. Go to https://artifacthub.io/packages/helm/adeptia-connect/adeptia-connect to view the details of Adeptia Connect helm package.
  2. Add Adeptia Connect repo using following command:

    Code Block
    languagecss
    themeMidnight
    helm repo add adeptia-connect https://adeptia.github.io/adeptia-connect-helm-package/charts/


  3. Click DEFAULT VALUES to download the values.yaml file.
    Image Added

    This downloads the values.yaml wherein the resource configurations are as per a production environment.

    Tip
    You can download the sample values.yaml file for a development environment by clicking values-dev.yaml and change the values based on your requirement. 


  4. Update the values.yaml as per instruction given in this section.

  5. Run the the following command to deploy the application.

    Code Block
    languagecss
    themeMidnight
    helm install adeptia-connect adeptia-connect/adeptia-connect --version <Version number> -f <PATH_OF_VALUES.YAML> --timeout 10m


    Warning
    titleImportant
    Use a specific version number in the version argument, else the latest version of Adeptia Connect will be installed.

    This command deploys Adeptia Connect on the Kubernetes cluster.

    Info

    Once you've completed the deployment, you need to configure your domain specific SSL certificate by using either of the two options:

    • Use Ingress in front of the Gateway service and configure SSL on Ingress.
    • Configure SSL directly on the Gateway service.

    To know more about configuring SSL, click here.


Anchor
Updating values.yaml
Updating values.yaml
Properties in values.yaml

Update the following properties in values.yaml before you run the helm install command to install the application.

Table of Contents
maxLevel3
minLevel3

Defining the required database properties

PropertyValue for Azure SQL DatabaseValue for Oracle DatabaseValue for Azure MySQL DatabaseDescription
BACKEND_DB_USERNAME<User defined><User defined><User defined>

Username for your backend database.

If you're using external Secrets, you need not provide a value for this property.

BACKEND_DB_PASSWORD<User defined><User defined><User defined>

Password for your backend database.

If you're using external Secrets, you need not provide a value for this property.

BACKEND_AUTHTYPEBasic
  • Basic
  • Kerberos
Basic

Authentication type for your backend database.

If you're using Kerberos as the authentication type forOracle database, you also need to configure the BACKEND_KERBEROS_DB_LOGIN_MODULE_NAME environment variable.

BACKEND_KERBEROS_DB_LOGIN_MODULE_NAMENot applicable<User defined>Not applicable

Name of the login module.

This is applicable only when you're using Kerberos as the authentication type forOracle database.

This login module name is passed to the jass.config file containing the Kerberos login module parameters that you need to configure. Expand the section below to know how you can configure the login module.

Expand
titleConfiguring the login module
  • Navigate to /shared folder.
  • Open the jaas.config file.
  • Enter the required values for the Kerberos parameters as shown in the example below.
    Image Added

    Where,
    KerberosServer is the login module name.

    For the details of the Kerberos parameters, for example, principal, useKeytab, storeKey, and others., refer to /wiki/spaces/AC41/pages/15993667.


LOG_DB_USERNAME<User defined><User defined><User defined>

Username for your log database.

If you're using external Secrets, you need not provide a value for this property.

LOG_DB_PASSWORD<User defined><User defined><User defined>

Password for your log database.

If you're using external Secrets, you need not provide a value for this property.

LOG_DB_AUTHTYPEBasic
  • Basic
  • Kerberos
Basic

Authentication type for your log database.

If you're using Kerberos as the authentication type forOracle database, you also need to configure the LOG_DB_KERBEROS_DB_LOGIN_MODULE_NAMEenvironment variable.

LOG_DB_KERBEROS_DB_LOGIN_MODULE_NAMENot applicable<User defined>Not applicable

Name of the login module.

This is applicable only when you're using Kerberos as the authentication type forOracle database.

This login module name is passed to the jass.config file containing the Kerberos login module parameters that you need to configure. Expand the section below to know how you can configure the login module.

Expand
titleConfiguring the login module
  • Navigate to /shared folder.
  • Open the jaas.config file.
  • Enter the required values for the Kerberos parameters as shown in the example below.
    Image Added

    Where,
    KerberosServer is the login module name.

    For the details of the Kerberos parameters, for example, principal, useKeytab, storeKey, and others., refer to /wiki/spaces/AC41/pages/15993667.


LOG_ARCHIVE_DB_PASSWORD<User defined><User defined><User defined>

Password for your log archive database.

If you're using external Secrets, you need not provide a value for this property.

LOG_ARCHIVE_DB_USERNAME<User defined><User defined><User defined>

Username for your log archive database.

If you're using external Secrets, you need not provide a value for this property.

LOG_ARCHIVE_DB_AUTHTYPEBasic
  • Basic
  • Kerberos
Basic

Authentication type for your log archive database.

If you're using Kerberos as the authentication type forOracle database, you also need to configure the LOG_ARCHIVE_DB_KERBEROS_DB_LOGIN_MODULE_NAME environment variable.

LOG_ARCHIVE_DB_KERBEROS_DB_LOGIN_MODULE_NAMENot applicable<User defined>Not applicable

Name of the login module.

This is applicable only when you're using Kerberos as the authentication type forOracle database.

This login module name is passed to the jass.config file containing the Kerberos login module parameters that you need to configure. Expand the section below to know how you can configure the login module.

Expand
titleConfiguring the login module
  • Navigate to /shared folder.
  • Open the jaas.config file.
  • Enter the required values for the Kerberos parameters as shown in the example below.

    Image Added

    Where,
    KerberosServer is the login module name.

    For the details of the Kerberos parameters, for example, principal, useKeytab, storeKey, and others., refer to /wiki/spaces/AC41/pages/15993667.


QUARTZ_DB_USERNAME<User defined><User defined><User defined>

Username for your log quartz database. This value will be the same as that for the backend database.

If you're using external Secrets, you need not provide a value for this property.

LOGQUARTZ_DB_PASSWORD<User defined><User defined><User defined>

Password for your log quartz database.

If you're using external Secrets, you need not provide a value for this property.

LOG_ARCHIVE_DB_PASSWORD<User defined><User defined><User defined>

Password for your log archive This value will be the same as that for the backend database.

If you're using external Secrets, you need not provide a value for this property.

LOG_ARCHIVEQUARTZ_DB_USERNAME<User defined><User defined><User defined>Username for your log archive AUTHTYPEBasic
  • Basic
  • Kerberos
Basic

Authentication type for your quartz database.

If you're using external Secrets Kerberos as the authentication type forOracle database, you need not provide a value for this property.

QUARTZ_DB_USERNAME

also need to configure the QUARTZ_DB_KERBEROS_DB_LOGIN_MODULE_NAMEenvironment variable.

QUARTZ_DB_KERBEROS_DB_LOGIN_MODULE_NAMENot applicable<User defined><User defined><User defined>

Username for your quartz database. This value will be the same as that for the backend database.

If you're using external Secrets, you need not provide a value for this property.

QUARTZ_DB_PASSWORD<User defined><User defined><User defined>

Password for your quartz database. This value will be the same as that for the backend database.

If you're using external Secrets, you need not provide a value for this propertyNot applicable

Name of the login module.

This is applicable only when you're using Kerberos as the authentication type forOracle database.

This login module name is passed to the jass.config file containing the Kerberos login module parameters that you need to configure. Expand the section below to know how you can configure the login module.

Expand
titleConfiguring the login module
  • Navigate to /shared folder.
  • Open the jaas.config file.
  • Enter the required values for the Kerberos parameters as shown in the example below.
    Image Added

    Where,
    KerberosServer is the login module name.

    For the details of the Kerberos parameters, for example, principal, useKeytab, storeKey, and others., refer to /wiki/spaces/AC41/pages/15993667.


BACKEND_DB_URL

jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Backend Database Name>

jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>

jdbc:mysql://<hostName>:<portNumber>/<DBName>?useSSL=trueBackend database name and its URL. Currently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified.

BACKEND_DB_DRIVER_CLASS

com.microsoft.sqlserver.jdbc.SQLServerDriver

oracle.jdbc.OracleDriver

com.mysql.cj.jdbc.DriverDriver class name based on the backend db. Do not change the value for this pre-defined property.
BACKEND_DB_TYPE

SQL-Server

Oracle MySQLCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
BACKEND_DB_DIALECT

org.hibernate.dialect.SQLServer2008Dialect

org.hibernate.dialect.Oracle12cDialectorg.hibernate.dialect.MySQLDialectCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
BACKEND_DB_TRANSACTION_ISOLATION

1

81Transaction isolation level in database.
BACKEND_DB_VALIDATION_QUERYSELECT 1SELECT 1 from dualSELECT 1Query that can be used by the pool to validate connections before they are returned to the application.
LOG_DB_DRIVER_CLASS

com.microsoft.sqlserver.jdbc.SQLServerDriver

oracle.jdbc.OracleDriver

com.mysql.cj.jdbc.DriverDriver class name based on the log db. Do not change the value for this pre-defined property.
LOG_DB_URL

jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Log Database Name>

jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>

jdbc:mysql://<hostName>:<portNumber>/<DBName>?useSSL=trueLog database name and its URL. Currently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified.
LOG_DB_TYPE

SQL-Server

OracleMySQLCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
LOG_DB_DIALECT

org.hibernate.dialect.SQLServer2008Dialect

org.hibernate.dialect.Oracle12cDialect

org.hibernate.dialect.MySQLDialectCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
LOG_DB_TRANSACTION_ISOLATION

1


81Transaction isolation level in database.
LOG_DB_VALIDATION_QUERYSELECT 1SELECT 1 from dualSELECT 1Query that can be used by the pool to validate connections before they are returned to the application.
LOG_ARCHIVE_DB_URL

jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Log Archive Database Name>

jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>

jdbc:mysql://<hostName>:<portNumber>/<DBName>?useSSL=trueLog archive database name and its URL. Currently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified.

LOG_ARCHIVE_DB_DRIVER_CLASS

com.microsoft.sqlserver.jdbc.SQLServerDriver

oracle.jdbc.OracleDriver

com.mysql.cj.jdbc.DriverDriver class name based on the log archive db. Do not change the value for this pre-defined property.
LOG_ARCHIVE_DB_TYPE

SQL-Server

OracleMySQLCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
LOG_ARCHIVE_DB_DIALECT

org.hibernate.dialect.SQLServer2008Dialect

org.hibernate.dialect.Oracle12cDialect

org.hibernate.dialect.MySQLDialectCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
LOG_ARCHIVE_DB_TRANSACTION_ISOLATION

1


81Transaction isolation level in database.
LOG_ARCHIVE_DB_VALIDATION_QUERYSELECT 1SELECT 1 from dualSELECT 1Query that can be used by the pool to validate connections before they are returned to the application.

QUARTZ_DB_URL

jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Backend Database Name>

jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>

jdbc:mysql://<hostName>:<portNumber>/<DBName>?useSSL=trueQuartz database name and its URL. Currently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. This value will be the same as that for the backend database.
QUARTZ_DB_DRIVER_CLASS

com.microsoft.sqlserver.jdbc.SQLServerDriver

oracle.jdbc.OracleDriver

com.mysql.cj.jdbc.DriverDriver class name based on the quartz db. This value will be the same as that for the backend database.
QUARTZ_DB_TYPE

SQL-Server

OracleMySQLCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property.
QUARTZ_DB_DIALECT

org.hibernate.dialect.SQLServer2008Dialect

org.hibernate.dialect.Oracle12cDialect

org.hibernate.dialect.MySQLDialectCurrently, the MS Azure SQL, Oracle, and Azure MySQL databases are certified. Do not change the value for this pre-defined property. This value will be the same as that for the backend database.
QUARTZ_DB_TRANSACTION_ISOLATION

1


81Transaction isolation level in database.
QUARTZ_DB_VALIDATION_QUERYSELECT 1SELECT 1 from dualSELECT 1Query that can be used by the pool to validate connections before they are returned to the application.

...

Uninstalling Adeptia Connect

If you wish to uninstall the application, run the following command.

Code Block
languagecss
themeMidnight
helm uninstall <adeptia-connect>

...

Info
If you've configured external Secrets, you need to manually delete the Secrets and its deployment after you uninstall the application.