Jump to: navigation, search

user-data-gen-dim

Section: agg-feature
Default Value: No default value
Valid Values: none. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart
Introduced: 8.5.011

When enabled, this feature adds the USER_DATA_GEN_KEY1 and USER_DATA_GEN_KEY2 dimensions to the following aggregate tables: ID, AGENT, AGENT-CAMPAIGN, AGENT_GRP, QUEUE, QUEUE_GRP, AGENT_QUEUE, QUEUE_ABN, QUEUE_ACC, and CAMPAIGN. The aggregate tables take values from USER_DATA_GEN_DIM_KEY_1 and USER_DATA_GEN_DIM_KEY_2 of the IRF_USER_DATA_KEYS table.

post-call-survey

Section: agg-feature
Default Value: No default value
Valid Values: none. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA
Changes Take Effect: After restart


Instructs RAA to enable the post-call-survey columns in the AGENT, AGENT_GRP, AGENT_QUEUE, and ID tables. To disable these columns, remove this option from the section.

RAA can populate these columns only after you run the optional Genesys Info Mart script make_gim_post_call_survey.sql.

eServicesSM

Section: agg-feature
Default Value: No default value
Valid Values: none. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect:


Instructs RAA to map IRF_USER_DATA_KEYS.GEN_ES_KEY to USER_DATA_KEY1 in the H_ID, H_AGENT, H_AGENT_GRP, and H_AGENT_QUEUE hierarchies, and populate aggregated data for social-media measures in some of the aforementioned hierarchies.

enable-sdr-survey

Section: agg-feature
Default Value: No default value
Valid Values: none. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 8.5.001.48

Instructs RAA to enable SDR Survey tables: SDR_SURVEY_ANS, SDR_SURVEY. To have RAA exclude SDR Survey data, remove this option from this section.

enable-sdr-bot

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 9.0.001.03

Instructs RAA to enable the AGT_SDR_BOT table. To have RAA exclude bot data, remove this option from this section.

enable-sdr

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 8.5.001.30

Instructs RAA to enable SDR aggregate tables: SDR_ACTIVITY, SDR_SESS_MILESTONE, SDR_SESSION and SDR_SESS_BLOCK . To have RAA exclude SDR aggregate data, remove this option from this section.

enable-media-neutral

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process.
Introduced: 8.5.008

Enables the aggregate table I_MN_SESS_STATE, which provides aggregate information to support reporting on agent states irrespective of media channel.

To have RAA exclude media-neutral data, remove this option from this section. The table is not presented if feature is not enabled.

The I_MN_SESS_STATE table contains the following columns: DATE_TIME_KEY, GROUP_COMBINATION_KEY, RESOURCE_KEY, TENANT_KEY, ACTIVE_TIME, READY_TIME, NOT_READY_TIME, BUSY_TIME, WRAP_TIME, READY, NOT_READY, BUSY, WRAP

enable-gpr-fcr

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process.
Introduced: 8.5.002.00
Modified: 8.5.011.03

Enables the aggregate table ID_FCR (AG2_ID_FCR), which provides aggregate information to support reporting on Genesys Predictive Routing (GPR).

To have RAA exclude Predictive Reporting data, remove this option from this section. The table is not presented if feature is not enabled.

enable-gpr

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process.
Introduced: 8.5.002.00

Enables Genesys Predictive Routing (GPR) - related columns in four aggregate tables (AG2_ID, AG2_I_AGENT, AG2_QUEUE, and AG2_QUEUE_GRP).

To have RAA exclude Predictive Reporting data from these tables, remove this option from this section. The columns are not presented if feature is not enabled.

enable-cobrowse

Section: agg-feature
Default Value: No default value
Valid Values: none. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process.
Introduced: 8.5.006

Instructs RAA to enable the Co-browse table (AGT_COBROWSE_AGENT). To have RAA exclude Co-browse data, remove this option from this section.

enable-chat-thread

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 8.5.009

Instructs RAA to enable the AGT_CHAT_THREAD table (AGT_CHAT_THREAD_STATS in release 9.0.011 and earlier). To have RAA exclude chat thread data, remove this option from this section.

enable-chat

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 8.5.003
Modified: 8.5.011.02, 8.5.011.04

Instructs RAA to enable the AGT_CHAT_STATS table. To have RAA exclude chat data, remove this option from this section.

enable-callback

Section: agg-feature
Default Value: No default value
Valid Values: none. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 8.1.405.02

Instructs RAA to aggregate the AGT_CALLBACK table.

enable-bgs

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart of the aggregation process
Introduced: 8.5.003

Instructs RAA to enable the Bot Gateway Server (BGS) table: AGT_BGS_SESSION. To have RAA exclude BGS data, remove this option from this section.

enable-available-features

Section: agg-feature
Default Value: No default value
Valid Values: None. This option takes no values—its presence alone within the [agg-feature] section issues the described instructions to RAA.
Changes Take Effect: After restart
Introduced: 8.5.011

Enables all available features in the [agg-feature] section, with the exception of enable-gpr-fcr, which is enabled by this option only in release 8.5.011.02.

Prerequisites: Before you begin installation

Disclaimer
Genesys is committed to diversity, equality, and inclusivity. This includes using appropriate terms in our software and documentation. Therefore, Genesys is removing non-inclusive terms. For third-party products leveraged by Genesys that include such terms, Genesys uses the following as replacements.
  • For the terms master/slave, Genesys uses “primary” and “secondary” or “primary” and “replica,” with exceptions for their use in third-party commands.
  • For the terms blacklist/whitelist, Genesys uses blocklist/allowlist.
  • For the term master, when used on its own, Genesys uses main wherever possible.

There are several supported deployment methods for Genesys CX Insights:

  • Kubernetes using descriptors — Prerequisites for this deployment type are described in detail on this page. Complete the steps on this page as required in your environment, and then proceed to deploy GCXI as described later on this page.
  • Kubernetes using Helm — Prerequisites for this deployment type are described in detail on this page. Complete the steps on this page as required in your environment, and then see Deploying GCXI using Helm.
  • OpenShift using Helm — Prerequisites and information about how to install OpenShift, are provided on the Red Hat OpenShift site. For GCXI deployment instructions, see Deploying GCXI using OpenShift.
  • Docker ComposeInstalling Genesys CX Insights - Docker Compose, which is suitable for testing or development, or for very small production environments. Prerequisites for this deployment method are described on the Installing Genesys CX Insights - Docker Compose page, which also describes deployment steps.

This page describes prerequisites that must be met before you can install Genesys Customer Experience Insights (Genesys CX Insights) in a Kubernetes production environment. For example, you must prepare a suitable Linux server environment, and install Kubernetes, you must plan how you will handle the meta database, and you must identify the compatible releases of the software you will need.

1. Ensure that your system meets minimum hardware and system requirements

  • Required number of machines — These could be real machines, virtual machines, or cloud machines such as EC2 instances in AWS, and must be configured as required to support the indicated Linux version. Ensure, for example, that IPV6 is enabled.
    • In non-High-Availability (HA) deployments, at least two machines (nodes), each with a supported version of Linux with the systemd suite installed. Genesys recommends Red Hat Enterprise Linux 7.5 (or a later 7.x release) / CentOS Linux 7.5 (or a later 7.x release). Other clones of Red Hat Enterprise Linux 7, such as Oracle Linux 7.5, should also work correctly.
      • In a two-machine configuration, the Control plane node hosts mstr-01, and a worker node hosts PostgreSQL and mstr-02.
      • Optionally, add a third machine if you prefer to deploy each mstr service on a separate node.
        High -Availability (HA) Deployment Architecture
    • In High-Availability (HA) deployments, the following minimums apply:
      • Small/medium customers — Two nodes for MicroStrategy, plus one node for custom cluster PostgreSQL installation.
      • Large customer — Two nodes with MicroStrategy, plus external custom cluster PostgreSQL installation.
      In HA deployments with Kubernetes, Genesys recommends:
      • A 3-node Control plane cluster, which can be either:
        • Three tiny Control plane Kubernetes nodes (meeting minimum Kubernetes requirements), plus two worker nodes (meeting Genesys CX Insights minimum requirements).
        OR
        • One tiny node for standalone Kubernetes Control plane node, plus two worker nodes that also host Kubernetes Control plane nodes.
        See About HA deployments for more information.
    • In all scenarios:
      • Identify one machine that you designate the mstr-01; other machine(s) are designated as mstr-02, mstr-03, and so on.
      • Ensure that you have access to an account with root access.
  • Specifications of each machine — In general, you can deploy MicroStrategy and Genesys CX Insights on any Linux platform with appropriate resources to deploy and run Kubernetes and Docker. However, MicroStrategy / Genesys CX Insights can require significant resources, so note the following minimums for each machine:
    • 64-bit compatible CPU architecture. (2 or more CPUs).
    • 10 GB for each GCXI container, and 2 GB for the PostgreSQL container. If your deployment scenario involves more than one container on a machine, then the memory requirements/recommendations increase accordingly; for example, if you were to deploy the GCXI container and PostGreSQL on a single host, a minimum of 10 GB + 2 GB = 12 GB is required. Deployment of a GCXI container on a machine with less than 10 GB is not recommended, and requires changes in the gcxi.yaml file. Production deployments commonly reserve 16 – 64 GB RAM for each container.
    • 40 GB of available disk space if loading images from a repository, 80 GB if loading from a local drive.
      Some deployments use a separate machine for PostgreSQL and gcxi_control, which requires a minimum configuration of 2GB RAM + 1 CPU. The recommended configuration varies depending on the load in your environment, but generally is 4 GB + 2 CPUs. This reflects the requirements for PostGreSQL, as gcxi_control doesn't demand significant resources.
    For information about requirements to install Kubernetes, see Installing kubeadm.

About HA deployments

Because a Genesys CX Insights environment consists of several interoperating components, there are several levels of HA configuration that you can optionally deploy. Each type of HA configuration is independant from the others -- you can configure any, all, or none of the following components as HA:

  • GCXI HA — In a Gensys CX Insights HA deployment, MicroStrategy clusters are used to distribute workers (at least 2, but not more than 8) across multiple machines. The MicroStrategy containers in an HA cluster use an active-active model, so if any container fails, Genesys CX Insights continues to operate normally.
  • Kubernetes platform HA — In a Kubernetes HA deployment, redundant infrastructure is used to run the Kubernetes management infrastructure on several nodes, configured in such a way that the failure of any single node does not interfere with normal Kubernetes operation. Each redundant node stores all Kubernetes state information (etcd). Genesys CX Insights requires no configuration changes to work with HA Kubernetes.
    Kubernetes supports a wide variety of HA options, the simplest consisting of three Kubernetes Control plane nodes. For more information about specific HA deployment options, see Kubernetes HA topology. Note that each MicroStrategy instance that is part of an HA cluster must use a unique path to store log files. The creation of MicroStrategy clusters can fail in scenarios where more than one MicroStrategy instance tries to write logs into a common folder, such as /mnt/log.
  • PostgreSQL HA — PostgreSQL is used for GCXI server metadata; in an HA PostgreSQL deployment, Genesys CX Insights can continue to operate when PostgreSQL container fails. Genesys documentation describes only single node (non-HA) PostgreSQL. To configure HA for the server metadata, use standard PostgreSQL database administration procedures to configure an external database, and point Genesys CX Insights Kubernetes to it. Genesys CX Insights requires no configuration changes to work with HA PostgreSQL.

2. Plan to accommodate the meta database

Depending on whether you choose to deploy an external PostgreSQL server for the meta database, one of the following statements applies:

  • If you use an external PostgreSQL server to store the MicroStrategy meta database, ensure that your PostgreSQL server is configured with a compatible release:
    • For release 9.0.013 and earlier, PostgreSQL 9.6, or a later 9.x release, is supported for the meta database.
    • For release new installations of release 9.0.014 and later, PostgreSQL 11 is required for the meta database. Upgrades to release 9.0.014.02 continue to work with existing PostreSQL releases.
  • If you wish to avoid deploying and managing a PostgreSQL server, use the prepackaged PostgreSQL server provided in the Installation Package. For more information about this option, see Installing Genesys CX Insights in production environments.

3. Identify compatible software releases

Genesys CX Insights requires that your environment contain supported releases of the following components.

  • Genesys recommends that you use the latest supported version wherever possible.
  • See Genesys CX Insights Product Alert for detailed information about supported releases.

4. Pre-installation configuration

Complete the following configuration changes, referring to the operating system documentation for more information if needed:

  1. Configure shared memory settings — MicroStrategy requires that you preconfigure shared-memory settings on the host operating system. See the MicroStrategy website for steps appropriate to your system.
    Important
    Changes to shared memory configuration can impact all applications and the operating system itself. These steps provide an example; follow them only if you are certain they apply to your environment.

    Complete the following steps on each machine:

    1. Log in as root, or execute the following command to switch to root:
      sudo -i bash
    2. Execute one of the following commands:
      Release 9.0.014 and later:
      echo "kernel.sem = 250 1024000 250 4096" >> /etc/sysctl.conf
      Earlier releases:
      echo "kernel.sem = 250 32000 32 4096" >> /etc/sysctl.conf
    3. Execute the following command:
      echo "vm.max_map_count = 5242880" >> /etc/sysctl.conf
    4. Reboot the machine.
  2. Set up DNS — Set up DNS for each machine in your cluster and (using, for example, 'ping', 'host', and 'hostname --fqdn' commands) verify that each machine can resolve itself and each other by DNS name.
  3. Ensure that all machines in the Kubernetes cluster have access to the shared folder, which is used for internal purposes by MicroStrategy.
    • The shared folder must be accessible to each machine in the Kubernetes cluster. It can use SMB, NFS, a Kubernetes shared volume, or whatever other method of network share your environment permits. For HA deployments, you must create the shared folder on both node and replica hosts, share the folder on the node host, and mount to the previously created folder on the replica host, as read-only.
    • By default, the containers expect the shared folder to be located at /genesys/gcxi/shared on the host. Optionally, you can use another location for the shared folder. To do so, complete the following steps prior to container startup: Open the gcxi.yaml file for editing, find all instances of the string genesys/gcxi/shared, and replace them with the new folder path.
  4. Configure RAA — Some Genesys CX Insights reporting features and the associated objects (including certain folders and reports) are not needed in all deployments, or may require additional configuration steps. Beginning with Genesys CX Insights release 9.0.010, the Genesys CX Insights deployment routine automatically enables these reporting features based on the features you enable in RAA. If an RAA feature in the following table is enabled when you deploy Genesys CX Insights (or restart the container), the corresponding feature is enabled in Genesys CX Insights, and relevant folders and reports are visible. To enable or disable one of these features in Genesys CX Insights, you can enable or disable the the corresponding option in RAA, and:
    • In release 9.0.010, restart the Genesys CX Insights container to enable or disable the indicated feature.
    • In release 9.0.011 or later, wait one hour, and Genesys CX Insights automatically commits your changes, enabling or disabling the indicated feature.
    If you disable a feature that has been enabled for a period of time, and there is data in the tables that you wish to retain (for example, to use in reports), copy the tables into the Custom folder before restarting the container (9.0.010) or before an hour has passed (9.0.011).
    In RAA release 8.5.011.02 and later, a new configuration option, enable-available-features, in the [agg-feature] section, enables all features that are supported in the current RAA release, except, in some releases, enable-gpr-fcr, as noted below. If you set the enable-available-features option, you do not also need to set the individual options here.
    If this RAA feature is enabled: These objects appear in GCXI:
    Configure these RAA options to automatically enable GCXI features
    enable-bgs Chat Bot folder and reports
    enable-callback Callback folder and reports
    enable-chat Chat folder and reports
    enable-chat-thread Chat folder > Chat Thread Report
    enable-cobrowse Co-browse folder and reports
    enable-gpr Predictive Routing folder and reports
    enable-gpr-fcr The Predictive Routing folder, and the following reports: Predictive Routing AB Testing Report, Predictive Routing - AHT & QUEUE. This option is enabled by enable-available-features only in release 8.5.011.02. In later releases, it is not enabled by enable-available-features, and must be enabled manually.
    enable-media-neutral In the Agents folder: Agent Omnichannel Activity Report
    enable-sdr Designer folder and reports
    enable-sdr-bot In the Designer folder: Bot Analytical Dashboard and Final Disposition Dashboard
    enable-sdr-survey In the Designer folder: Survey Answer Report and Survey Statistics Report
    eServicesSM In the Agents folder: Agent Social Engagement Report
    post-call-survey All reports in the Agent folder except details and interval-based reports, and all reports in the Business Results folder.
    user-data-gen-dim All reports in the Agent folder except details and interval-based reports, and all reports in the Business Results, Outbound Contact, and Queue folders.

    For information about enabling features in RAA, see the Reporting and Analytics Aggregates Options Reference guide.

Installing Docker and Kubernetes

In most scenarios, you can deploy Docker and Kubernetes by accessing the installation packages and other files directly from the internet (online scenarios). However, it is also possible to deploy the software in environments where it is not possible to access the internet or other external networks from the machines / network where you plan to install Genesys CX Insights (offline scenarios). Choose one of the following options:

This page was last edited on March 12, 2021, at 17:37.
blog comments powered by Disqus