PEC-REP/Current/GIMPEGuide/ConfigureGSP

Learn how to configure GIM Stream Processor (GSP).

Related documentation:

• How Reporting works
• Suite-level guide
• All services
• Genesys Info Mart Release Notes

RSS:

• For private edition

GSP Helm chart overrides

The GSP requires some configuration for deployment that must be made by modifying the GSP's default Helm chart. You do this by creating override entries in the GSP's values.yaml file.

Download the GSP Helm charts from the JFrog registry, using the appropriate credentials.

For information about how to download the Helm charts, see Downloading your Genesys Multicloud CX containers. To find the correct Helm chart version for your release, see Helm charts and containers for Genesys Info Mart for the Helm chart version you must download for your release. For general information about Helm chart overrides, see Overriding Helm chart values in the Genesys Multicloud CX Private Edition Guide.

At minimum, you must create entries in the values.yaml file to specify key system information, as described in the following sections.

Important

Treat your modified values.yaml file as source code, which you are responsible to maintain so that your overrides are preserved and available for reuse when you upgrade.

Image registry and pull secret

Image registry

Create an entry in the GSP's values.yaml file to specify the location of the Genesys JFrog image registry. This is the repository from which Kubernetes will pull images.

The location of the Genesys JFrog image registry is defined when you set up the environment for the GSP. It is represented in the system as the docker-registry. In the GSP Helm chart, the repository is represented as image: registry, as shown below. You can optionally set a container version for the image.

• image:

  registry — the repository from which Kubernetes will pull images (pureengage-docker-staging.jfrog.io by default)

  tag — the container image version

Pull secret

When you set up your environment, you define a pull secret for Genesys JFrog image registry (docker-registry). You must include the pull secret in the GSP's values.yaml file in order for Kubernetes to be able to pull from the repository.

• imagePullSecrets:

  docker-registry — the credentials Kubernetes will use to pull the image from the registry

Note that other services use a different syntax than this to configure the repository pull secret, as follows:

• image:

  imagePullSecrets:

  - name: docker-registry

  Genesys Info Mart, GIM Stream Processor, and GIM Configuration Adaptor helm charts all support advanced templating that allow the helm to create the pull secret automatically; hence the variation in syntax.

Kafka

Kafka secret

If Kafka is configured with authentication, you must configure the Kafka secret so GSP can access Kafka. The Kafka secret is provisioned in the system as kafka-secrets when you set up the environment for GSP. Configure the Kafka secret by creating a Helm chart override in the values.yaml file.

• kafka:

  password - Credentials for accessing Kafka. This secret is created during deployment

Kafka bootstrap

To allow the Kafka service on GSP to align with the infrastructure Kafka service, make a Helm override entry with the location of the Kafka bootstrap.

• kafka:

  bootstrap — the Kafka address to align with the infrastructure Kafka

Custom Kafka topic names

Some of the Kafka topics used by the GSP support customizing the topic name. If any topic name has been customized, ensure it is represented as a Helm chart override entry, using the kafka:topic parameter.

For a list of the Kafka topics that GSP produces and consumes, including which of those support customized naming, see Before you begin GSP deployment.

S3-compatible storage

S3 storage credentials

When you set up the environment for GSP, you provision S3-compatible object storage for GSP to use as a persistent data store. In the values.yaml file, record the credentials needed by GSP to access this storage.

• gsp-s3 — Credentials for accessing S3-compatible storage

Enable S3-compatible storage

When you set up your environment for the GSP, you provision S3-compatible object storage for the GSP's persistent data store. You must enable this storage with override entries in the values.yaml file.

By default, GSP is configured to use Azure Blob Storage as the persistent data store. If you have provisioned Azure Blob Storage in your deployment, modify the following entries in the values.yaml file:

• job:

     storage:

        gspPrefix — the URI path prefix under which GSP savepoints, checkpoints, and high-availability data will be stored

        gcaSnapshots — the URI path under which GCA snapshot(s) will be stored

To enable other types of S3-compatible storage, modify the following entries in the values.yaml file:

• azure:

     enabled: false

• job:

     storage:

        gspPrefix — the bucket name where GSP savepoints, checkpoints, and high-availability data will be stored

        gcaSnapshots — the bucket name where the GCA snapshot(s) will be stored

        s3 — the applicable details defined with the OBC or GCP bucket

  Note: The host parameter is ignored.

OpenShift example

azure:
  enabled: false
..
job:
  storage:
    host: gspstate{{.Values.short_location}}{{.Values.environment}}.blob.core.windows.net
    #gspPrefix: wasbs://gsp-state@{{ tpl .Values.job.storage.host . }}/{{ .Release.Name }}/
    gspPrefix: "s3p://gim-3f7ac1ab-03b9-445b-ba12-137d4bbc3c38/{{ .Release.Name }}/"                                                                               
    #gcaSnapshots: wasbs://gca@{{ tpl .Values.job.storage.host . }}/
    gcaSnapshots: "s3p://gim-3f7ac1ab-03b9-445b-ba12-137d4bbc3c38/gca/"                                                                  
    checkpoints: '{{ tpl .Values.job.storage.gspPrefix . }}checkpoints'
    savepoints: '{{ tpl .Values.job.storage.gspPrefix . }}savepoints'
    highAvailability: '{{ tpl .Values.job.storage.gspPrefix . }}ha'
    s3:
      endpoint: "https://s3.openshift-storage.svc:443"
      accessKey: "<access key>"
      secretKey: "<secret key>"
      pathStyleAccess: "true"

GKE example

azure:
  enabled: false
...
job:
  storage:
    host: gspstate{{.Values.short_location}}{{.Values.environment}}.blob.core.windows.net
    #gspPrefix: wasbs://gsp-state@{{ tpl .Values.job.storage.host . }}/{{ .Release.Name }}/
    gspPrefix: "s3p://test-example-bucket-one/{{ .Release.Name }}/"                                                                               
    #gcaSnapshots: wasbs://gca@{{ tpl .Values.job.storage.host . }}/
    gcaSnapshots: "s3p://test-example-bucket-one/gca/"                                                                  
    checkpoints: '{{ tpl .Values.job.storage.gspPrefix . }}checkpoints'
    savepoints: '{{ tpl .Values.job.storage.gspPrefix . }}savepoints'
    highAvailability: '{{ tpl .Values.job.storage.gspPrefix . }}ha'
    s3:
      endpoint: "https://storage.googleapis.com:443"
      accessKey: "<access Key>"
      secretKey: "<secret key>"
      pathStyleAccess: "true"

Arbitrary UIDs (OpenShift)

If you have an OpenShift deployment and you want to use arbitrary UIDs, you must modify the security context settings in the values.yaml file. The security context settings define the privilege and access control settings for pods and containers.

In the values.yaml file, the default user and group IDs in the securityContext object are set to 500:500:500 (the genesys user), as shown below.

securityContext:
  runAsNonRoot: true
  runAsUser: 500
  runAsGroup: 500
  fsGroup: 500

containerSecurityContext: {}

To use arbitrary UIDs in your OpenShift deployment, you replace these values with null values, as in the following example.

securityContext:
  runAsNonRoot: true
  runAsUser: null
  runAsGroup: 0
  fsGroup: null

containerSecurityContext: {}

Kubernetes API

GSP uses Apache Flink for stateful stream processing, with communications handled via the Kubernetes API. To use the Kubernetes API, GSP must have the permissions shown below.

Verbs	On Resource	API Group	Comment
get list watch delete	jobs	batch	GSP uses these commands during upgrade and for a pre-upgrade hook to ensure that the previous version of GSP is stopped before upgrading to the new version.
create update patch get list watch delete	configmap	general ("")	GSP uses these commands to: Support Flink's Kubernetes high availability (HA) services Record the path to the savepoint (periodically taken by the take-savepoint cron job and by the upgrade hook)

Arbitrary UIDs (Openshift)

If you have an OpenShift deployment and you want to use arbitrary UIDs, you must modify the securityContext settings in the GSP's values.yaml file with an override entry. These settings define the privilege and access control settings for pods and containers.

In the default GSP values.yaml file, the user and group IDs are set to 500:500:500, (the genesys user), as shown below.

securityContext:
  runAsNonRoot: true
  runAsUser: 500
  runAsGroup: 500
  fsGroup: 500

containerSecurityContext: {}

To use arbitrary UIDs in an OpenShift deployment, replace the default values with null values, as in the example below.

securityContext:
  runAsNonRoot: true
  runAsUser: null
  runAsGroup: 0
  fsGroup: null

containerSecurityContext: {}

Configure GSP behavior

You can specify values in the values.yaml file to override the default values of configuration options that control GSP behavior and to customize user data and Outbound field mappings.

You can override aspects of the default configuration to modify GSP behavior and customize the way data is stored in the Info Mart database.

You can customize the following:

• Configuration options, to modify data-related aspects of GSP behavior
• User data mappings, to map custom key-value pairs (KVPs), which are attached to event and reporting protocol data, to tables and columns in the Info Mart database
• Outbound record field mappings, to map custom CX Contact record field data to Outbound-related tables and columns in the Info Mart database

Customize configuration option settings

For full information about the options you can configure, including the default and valid values, see GSP configuration options.

Alexey/Kostya, I've combined and extrapolated from info in e-mails and Jira tickets. Please esp. confirm the syntax in this subsection and in the extended example at the bottom of the page.

To configure options, edit the GSP values.yaml file. Under the cfgOptions object, specify the option and value in JSON format, noting the following:

• Options are separately configurable by tenant and, where applicable, by media type or even at the level of individual queues (DNs or scripts).
• Where an option can be configured at various levels, you can override a value set at a higher level (for example, for a particular media type in general) to set a different value for a particular lower-level object (for example, for that media type for an individual DN).
• See the note about configuration levels for information about the available configuration levels for certain options.

The entries in the values.yaml file are structured as follows:

cfgOptions:
    "<tenant_id>": |
      standard:
        <option 1>: <value>
      media:
        <media type 1>:
          <option 2>: <value 1>
          <option 3>: <value 1>
        <media type 2>:
          <option 2>: <value 2>
          <option 4>: <value 1>
      dn:
        <dn_id>:
          media:
            <media type 1>:
              <option 2>: <value 3>
      script:
        <script_id>:
          media:
            <media type 2>:
              <option 2>: <value 4> 
      ...

For an example, see below.

Reviewers! For the review request relating to GIM-14206, skip the next two sections and jump to the cfgOptions part of the example at the bottom of the page (link). Then please go to the GSP configuration options page.

Customize user data mapping

Genesys Info Mart uses a wide range of user-data KVPs from a number of upstream services to populate data in the Info Mart database. For full information about user data in Genesys Info Mart, see [[PEC-REP/Current/GIMPEGuide/UserData|]].

As described on [link TBD], you can extend storage of user data in the Info Mart database to include additional user-data KVPs you want to capture as custom user-data facts or dimensions.

To configure user-data mapping, edit the GSP values.yaml file. Under the udeMapping object , specify the mapping between your custom KVPs and the custom user-data database table(s) and column(s), noting the following:

• The mapping, which is specified in JSON format, is configured separately by tenant.
• In addition to specifying the database table and column in which the KVP value will be stored, you also specify the propagation rule that Genesys Info Mart will use to determine what value to store if more than one value is extracted for the same key in the same interaction. See Propagation rules for more information.
• You can specify a default value to use if the KVP value is null. You must provide a default value for dimensions.
• You map custom user-data dimensions via the IRF_USER_DATA_KEYS table, where you specify the foreign key reference(s) for the user-data dimension table(s).

Genesys Info Mart provides the following sample tables in the Info Mart database schema for storage of custom KVPs:

• USER_DATA_CUST_DIM_1 — for low-cardinality user data to be stored as dimensions
• IRF_USER_DATA_CUST_1 — for high-cardinality user data to be stored as facts

The structure of the entries to specify in the values.yaml file is:

Questions:

1. Can you customize the table names (USER_DATA_CUST_DIM_1, IRF_USER_DATA_CUST_1) and column names (DIM_ATTRIBUTE_1, CUSTOM_DATA_1, etc.; also CUSTOM_KEY_1 in IRF_USER_DATA_KEYS)? i.e., Is it OK to show these as <variables>?
2. Alexey, the example at the bottom of the page is taken from an example you sent me. Why are these particular IRF_USER_DATA_GEN_1 entries listed? In GIM Classic, we say these particular mappings are predefined by default. Do they need to be overtly specified here, or should we change the example to show non-standard KVPs?

udeMapping:
  "<tenant_id">: |
    IRF_USER_DATA_KEYS:
      columns:
        <CUSTOM_KEY_1>:
          type: dim
          table: <USER_DATA_CUST_DIM_1>
          attributes:
            <DIM_ATTRIBUTE_1>:
              kvp: <KVP>
              rule: <propagation_rule>
              default: <default_value>
            ...
    <IRF_USER_DATA_CUST_1>:
      columns:
        <CUSTOM_DATA_1>:
          type: value
          kvp: <KVP>
          rule: <propagation_rule>
          default: <default_value>
        ...

For an example, see below.

Customize Outbound Contact field mapping

Writer's note: In GIM Classic, we've been religious about using the phrase "Outbound Contact" to refer to OCS data. For PE and Multicloud in general, confirm we should use just "Outbound". And for PE, only CX Contact applies.

Genesys Info Mart stores data about every outbound contact attempt, based on Record Field data it receives from the CX Contact (CXC) service. As described on [[PEC-REP/Current/GIMPEGuide/Outbound|]], some of the mapping between Field data and the Info Mart database tables and columns is predefined, and some is custom.

To customize outbound mapping, edit the GSP values.yaml file. Under the ocsMapping object, specify the mapping between your custom record fields and the tables and columns provided in the Info Mart database for custom record field data, namely:

• In the CONTACT_ATTEMPT_FACT table:
  • 10 floating-point numbers: numeric(14,4)
  • 20 integers: integer
  • 30 strings: varchar(255)
• In the RECORD_FIELD_GROUP_1 and RECORD_FIELD_GROUP_2 tables:
  • 10 strings each: varchar(255)

Placeholder for something to say about rpcValue and conversionValue (see question 2).

Questions:

1. Per the CXC documentation (Create and Manage User-defined Field Labels), by default "all user-defined fields in a contact list are labelled as Other1, Other2, Other3, and so on." In our example below, should I change all instances of "GenRecordField" to "Other"? -- e.g., CAF.RECORD_FIELD_1 populated by field: Other1, RECORD_FIELD_GROUP_1.RECORD_FIELD_1_STRING_1 populated by field: Other1String1, etc.
2. I cannot find any reference to OCS-equivalent right_person and conversion configuration in the CXC documentation. Are rpcValue and conversionValue applicable for PE?

The mapping, which is specified in JSON format, is configured separately by tenant. The structure of the entries is:

ocsMapping:
  "<tenant_id>": |
    CONTACT_ATTEMPT_FACT:
      columns:
        RECORD_FIELD_1:
          field: <numericFieldName>
          rpcValue:
          conversionValue:
        ...
        RECORD_FIELD_11:
          field: <intFieldName>
          rpcValue:
          conversionValue:
        ...
        RECORD_FIELD_31:
          field: <stringFieldName>
          rpcValue:
          conversionValue:
        ...
    RECORD_FIELD_GROUP_1:
      columns:
        RECORD_FIELD_1_STRING_1:
          field: <stringFieldName>
          rpcValue:
          conversionValue:
        ...
    RECORD_FIELD_GROUP_2:
      columns:
        RECORD_FIELD_2_STRING_1:
          field: <stringFieldName>
          rpcValue:
          conversionValue:
        ...

For an example, see below.

Example

cfgOptions:
    "eb0c9f3a-5dca-498f-98d5-7610f5fd1015": |
      standard:
        completed-queues: iWD_Completed,iWD_Processed_ext
        populate-workbin-as-hold: false
      media:
        voice:
          q-answer-threshold: 30
      media:
        email:
          q-short-abandoned-threshold: 20
      dn:
        eb0c9f3a-5dca-498f-98d5-7610f5fd1015_MM_VQ:
          media:
            email:
              q-answer-threshold: 90
              q-short-abandoned-threshold: 40
      script:
        eb0c9f3a-5dca-498f-98d5-7610f5fd1015_ixn_queue:
          media:
            chat:
              q-answer-threshold: 20
      script:
        eb0c9f3a-5dca-498f-98d5-7610f5fd1015_dev.IQ:
          standard:
            populate-ixnqueue-facts: false

udeMapping:
  "eb0c9f3a-5dca-498f-98d5-7610f5fd1015": |
    IRF_USER_DATA_KEYS:
      columns:
        CUSTOM_KEY_1:
          type: dim
          table: USER_DATA_CUST_DIM_1
          attributes:
            DIM_ATTRIBUTE_1:
              kvp: BusinessLine
              rule: CALL
              default: retail
            DIM_ATTRIBUTE_2:
              kvp: RULE_PARTY
              rule: PARTY
              default: none
            DIM_ATTRIBUTE_3:
              kvp: RULE_IRF
              rule: IRF
              default: none
            DIM_ATTRIBUTE_4:
              kvp: RULE_IRF_INITIAL
              rule: IRF_INITIAL
              default: none
            DIM_ATTRIBUTE_5:
              kvp: RULE_IRF_FIRST_UPDATE
              rule: IRF_FIRST_UPDATE
              default: none
    IRF_USER_DATA_CUST_1:
      columns:
        CUSTOM_DATA_1:
          type: value
          kvp: RULE_CALL
          rule: CALL
          default: none
        CUSTOM_DATA_2:
          type: value
          kvp: RULE_PARTY
          rule: PARTY
          default: none
        CUSTOM_DATA_3:
          type: value
          kvp: RULE_IRF
          rule: IRF
        CUSTOM_DATA_4:
          type: value
          kvp: RULE_IRF_FIRST_UPDATE
          rule: IRF_FIRST_UPDATE
        CUSTOM_DATA_5:
          type: value
          kvp: RULE_IRF_INITIAL
          rule: IRF_INITIAL
        CUSTOM_DATA_6:
          type: value
          kvp: RULE_IRF_ROUTE
          rule: IRF_ROUTE
    IRF_USER_DATA_GEN_1:
      columns:
        CASE_ID:
          type: value
          kvp: CaseID
          rule: Call
          default: none
        CUSTOMER_ID:
          type: value
          kvp: GIM_GRP
          rule: Call
          default: none

ocsMapping:
  "eb0c9f3a-5dca-498f-98d5-7610f5fd1015": |
    CONTACT_ATTEMPT_FACT:
      columns:
        RECORD_FIELD_1:
          field: GenRecordField1
          rpcValue:
          conversionValue:
        RECORD_FIELD_2:
          field: GenRecordField2
          rpcValue:
          conversionValue:
        ...
        RECORD_FIELD_60:
          field: GenRecordField60
          rpcValue:
          conversionValue:
    RECORD_FIELD_GROUP_1:
      columns:
        RECORD_FIELD_1_STRING_1:
          field: GenRecordField1String1
          rpcValue:
          conversionValue:
        RECORD_FIELD_1_STRING_2:
          field: GenRecordField1String2
          rpcValue:
          conversionValue:
        RECORD_FIELD_1_STRING_3:
        ...
    RECORD_FIELD_GROUP_2:
      columns:
        RECORD_FIELD_2_STRING_1:
          field: GenRecordField2String1
          rpcValue:
          conversionValue:
        RECORD_FIELD_2_STRING_2:
        ...