Deploy CX Contact

From Genesys Documentation
Jump to: navigation, search
This topic is part of the manual Outbound (CX Contact) Private Edition Guide for version Current of Outbound (CX Contact).

Learn how to deploy CX Contact into a private edition environment.


  • The instructions on this page assume you are deploying the service in a service-specific namespace, named in accordance with the requirements on Creating namespaces. If you are using a single namespace for all private edition services, replace the namespace element in the commands on this page with the name of your single namespace or project.
  • Similarly, the configuration and environment setup instructions assume you need to create namespace-specific (in other words, service-specific) secrets. If you are using a single namespace for all private edition services, you might not need to create separate secrets for each service, depending on your credentials management requirements. However, if you do create service-specific secrets in a single namespace, be sure to avoid naming conflicts.
Review Before you begin for the full list of prerequisites required to deploy CX Contact.

CX Contact is a shared service and is deployed in each region, as required. After deployment, it will be fully functional only in the tenant's primary region.

Prepare cluster resources

To prepare your cluster resources, create a storage class.

Creating the storage class is optional. If you have an existing storage class, you can use it and a different provisioner, but the storage class must have ReadWriteMany (RWX) capabilities.

Create the Storage Class

  1. Log in to the cluster using the Command Line Interface (CLI).
  2. Go to Storage, and click Storage Claim > Create Storage Class.
  3. Click Edit YAML.
  4. Update the values in the template using the example below that works with the setup of your environment.
    • If your cluster is on-premises (NFS-based storage):
      kind: StorageClass
        name: cxc-storage
      provisioner: cluster.local/nfs-vce-c00ds-vol1-nfs-subdir-external-provisioner
      reclaimPolicy: Delete
      volumeBindingMode: Immediate
    • If your cluster is in the cloud (Azure files-based storage):
      kind: StorageClass
        name: cxc-storage
      reclaimPolicy: Delete
      volumeBindingMode: Immediate
  5. Click Create.

Deploy CX Contact

Complete the following procedure using Kubectl and the Helm tools:

  1. Create a new project or a namespace.
    • For Kubernetes, enter
      kubectl create namespace cxc
    • For GKE, enter
      kubectl create ns cxc
    • For AKS, enter
      kubectl create namespace cxc
  2. Create the pull secret.Use the following code snippets as examples of how to create the default pull secret:
    • For generic Kubernetes:
      oc create secret docker-registry mycred --docker-server=<docker repo> --docker-username=<username> --docker-password=<API key from jfrog>
    • For GKE :
      kubectl create secret docker-registry mycred --docker-server=<docker repo> --docker-username=<username> --docker-password=<API key from jfrog> --docker-email=<emailid>
    • For AKS:
      kubectl create secret docker-registry mycred --docker-server=<docker repo> --docker-username=<username> --docker-password=<API key from jfrog> --docker-email=<emailid>
  3. Download latest version of the CX Contact installation Helm Charts from the artifactory. See the JFrog Platform Artifactory.
  4. Extract parameters from chart to see multiple (default) values used to fine-tune the installation.
    helm install cxc ./cxcontact-<chart_version>.tgz > values.yaml
    You can apply multiple override values to customize your setup. However, Genesys recommends using minimal overriding values in the installation:
    For example, override_values.yaml
      user_name: cloudcon
      user_password: cloudcon
      replicas: 2
        level: info
        cdp_url: false
          gcloud_id: false
          gcloud_secret: false
    #  override:                #if connecting to Nexus. Otherwise Dial Manager is off
    #    dial-manager:
    #      enabled: false
    #      nexus:
    #        host: ..
    #        port: ..
    #      api_key: ..          #required
      enabled: true
      dashboards: false
      alarms: false
      pagerduty: false
      enabled: true
      cluster: true
      # can be comma-delimited list of redis nodes, for e.g.
      # nodes: redis://redis-node1:6379,redis://redis-node2:6379,redis://redis-node3:6379
      nodes: redis://infra-redis-redis-cluster.infra.svc.cluster.local:6379
      #use_tls: false
      requirepass: true
      password: <redis_password>
      enabled: true
      host: http://elastic-es-http.infra.svc.cluster.local
      port: 9200
      # secret in plain text
      client_id: cx_contact
      client_secret: cx_contact
      # GWS Ingress URL
      frontend_host: https://gauth.apps.<your_cluster>
      frontend_port: 443
    #  Services. Will be used for connection to GWS if GWS Internal Ingress URL is disabled (empty values)
          host: http://gauth-auth.gauth
          port: 80
          host: http://gauth-environment.gauth
          port: 80
          host: http://gws-service-proxy.gws
          port: 80
          host: http://gws-service-proxy.gws
          port: 80
          host: http://gws-service-proxy.gws
          port: 80
          host: http://gws-service-proxy.gws
          port: 80
          host: http://gws-service-proxy.gws
          port: 80
      enabled: true
      #tls_enabled: false
      cxc_frontend: cxc.apps.<your_cluster>
    #    !!!Ingress Session Stickiness is required.
    #    Default annotations: cookie "Lax" "cxc-session-cookie" "0"
      tls: []
      #  - hosts:
      #      - chart-example.local
      #    secretName: chart-example-tls
    # Additional ingress to expose internal backend endpoints.
    # If disabled  - all endpoints will be exposed on ingress.cxc_frontend
      enabled: true
      tls_enabled: false
      cxc_backend: cxc-int.apps.<your_cluster>
    #    Default annotations: "0" 'false'
      tls: []
      #  - hosts:
      #      - chart-example.local
      #    secretName: chart-example-tls
      # Persistent Volumes Claim Configuration
        enabled: true
        create: true
    #    Instructs Helm to skip deleting PVC when a helm operation (such as helm uninstall, helm upgrade or helm rollback)
    #    would result in its deletion. However, this resource becomes orphaned. Helm will no longer manage it in any way.
    #    If PVC is already orphaned and you want to re-use it - set `storage.pvc.create` to `false`.
        keepAfterDeletion: false
        size: 10Gi
        name: cxc-claim
        storageClassName: cxc-storage
  5. Validate the Helm chart and provided values, enter:
    $ helm template cxc ./cxcontact-<chart_version>.tgz -f override_values.yaml
  6. Install the CX Contact chart, using the override values file that you prepared in step, enter:
    $ helm install cxc ./cxcontact-<chart_version>.tgz -f override_values.yaml
  7. If errors occur, verify the input values, YAML files syntax, and your Kubernetes context. enter:
    $ kubectl config get-contexts
    $ kubectl get pods -n cxc
    $ kubectl describe pod <pod name> -n cxc
  8. If troubleshooting is necessary, try adding the --dry-run command line parameter in helm install .. for verbose error output.
  • To see the full set of available parameters, extract the default helm values from helm package:
    $ helm show values cxcontact-<chart_version>.tgz > values.yaml
  • For persistent volume claims in production, Genesys recommends 100-200 GB.

This completes the CX Contact shared service installation.

Next steps:

Validate the deployment

  1. Watch the helm output at the end of installation. It provides the status and additional information about where to log in to the CX Contact UI. See the following sample output:
    Release "cxc" has been upgraded. Happy Helming!
    NAME: cxc
    LAST DEPLOYED: Tue Jul 13 10:18:07 2021
    NAMESPACE: cxc
    STATUS: deployed
    TEST SUITE: None
    Please be patient while CXContact <release_number> is being deployed
    UI: http://cxc.apps.<your_cluster>/ui/cxcontact/#!/campaign/list
    API basepath: http://cxc.apps.<your_cluster>/cx-contact/v3/
    API swagger doc: http://cxc.apps.<your_cluster>/cx-contact/v3/explore
    CXC backend basepath: http://cxc-int.apps.<your_cluster>/
  2. Check the status of the Events and Pods. Pods should be up and running—8 CX Contact components in total (7, if you have not defined Nexus for digital outbound).
  3. Check the amark-app and other pods logs, primarily for errors related to connectivity to Redis and Elasticsearch.
  4. If you have provisioned tenants for CX Contact, log in to the CX Contact UI (use URL from the Helm output above) using the tenant's administrator credentials. If you can log in successfully, that confirms that CX Contact works with the Redis cluster:
    • Check the CX Contact About > Versions page for the health status of the CX Contact components. They should be all green.
    • Check the Analytics page. It should show your successful log in, and confirm that CX Contact works with Elasticsearch.
    • Try to create a test Contact list. If you succeed, CX Contact will display a success confirmation message.

Configure monitoring and logging

CX Contact monitoring is enabled by default.

See monitoring details and how to configure logging parameters in Observability in Outbound (CX Contact).

Retrieved from " (2024-05-26 12:35:29)"
Comments or questions about this documentation? Contact us for support!