Configure GIM

Learn how to configure GIM.

Related documentation:

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

RSS:

• For private edition

Override Helm chart values

Download the gim and gim-monitoring Helm charts from JFrog using your credentials. You must override certain parameters in the gim values.yaml file to provide deployment-specific values for certain parameters.

For general information about overriding Helm chart values, see Overriding Helm chart values in the Genesys Multicloud CX Private Edition Guide.

If you want to use arbitrary UIDs in your OpenShift deployment, you must override the securityContext settings in the GIM values.yaml file, so that no user or group IDs are specified. For details, see Configure security, below.

To enable S3-compatible storage for the Data Export packages, see Configure S3-compatible storage, below.

At a minimum, you must override the following key entries in the GIM values.yaml file:

• image:

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

  tag - the container image version

• tenant_id - the TenantID of the tenant in use
• imagePullSecrets:

  pureengage-docker-dev or pureengage-docker-staging — the secret from which Kubernetes will get credentials to pull the image from the registry

• kafka:

  bootstrap - the Kafka address to align with the infrastructure Kafka

  password - the Kafka password, if Kafka requires authentication

• db - the applicable details for the Info Mart ETL database you created (see Create the Info Mart database)

Note: tenant_id and kafka:password (optional) are currently not included in the values.yaml file. Either add these parameters to your customized values.yaml file or else specify them in the command line when you install the Helm chart.

If topic names in your Kafka configuration have been customized, you must also modify the kafka:topic parameter values to match. For more details about the required Kafka topics, see Kafka configuration.

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.

Configure Kubernetes

Secrets

GIM requires the following secrets:

• docker-registry — Credentials to pull the image from the JFrog repository
• kafka-secrets — Credentials to access Kafka
• gim-secrets — Credentials to access the Info Mart database
• s3-storage-secrets — Credentials to access optional S3-compatible storage (for Data Export)

Except for docker-registry, which you must create manually (see the environment setup instructions on Deploy GIM), Helm creates the secrets based on values you specify in the values.yaml file.

Config Maps

Helm creates a number of Config Maps based on option values you specify in the values.yaml file. There are no Config Maps you can configure directly.

Configure security

The security context settings define the privilege and access control settings for pods and containers.

By default, the user and group IDs are set in the GIM values.yaml file as 500:500:500, meaning the genesys user.

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

containerSecurityContext: {}

Arbitrary UIDs in OpenShift

If you want to use arbitrary UIDs in your OpenShift deployment, you must override the securityContext settings in the GIM values.yaml file, so that you do not define any specific IDs.

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

containerSecurityContext: {}

Configure S3-compatible storage

If you are using S3-compatible object storage on OpenShift or GCP to store the Data Export packages, modify the following entries in the values.yaml file:

• s3_storage_enabled: true
• s3_storage:

  account:

     accessKey — the access key created when you created the bucket

     secretKey — the secret created when you created the bucket

     region — the region in which the bucket was created

     entryPoint — URL to access bucket storage

• gim_export:

  output_directory — the bucket name

The s3_storage parameters are used to construct the s3_storage_secrets secret.

OpenShift example

gim_export:
  ...
  output_directory:                       "gim-3f7ac1ab-03b9-445b-ba12-137d4bbc3c38"
  ...
s3_storage_enabled: true
s3_storage:
  account:
    accessKey: "<Access Key>"
    secretKey: "<Secret Key>"
    region: "<Region>"
    entrypoint: "s3.openshift-storage.svc"

GKE example

gim_export:
  ...
  output_directory:                       "test-example-bucket-one"
  ...
s3_storage_enabled: true
s3_storage:
  account:
    accessKey: "<Access Key>"
    secretKey: "<Secret Key>"
    region: "<Region>"
    entrypoint: "storage.googleapis.com"

Configure GIM behavior

You can specify values in the values.yaml file to control options that override aspects of the default configuration, thereby modifying GIM behavior and customizing the way data is stored in the Info Mart database. For information about the options you can configure including the default and valid values, see GIM configuration options.

To configure options, edit the GIM values.yaml file. Under the gim_config object in the, 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:

gim_config: ""

log:
  level:                                 "info"
  console_pattern_layout:                "%d{ISO8601} %-5p %-12t %m%n"
  appender:
    ConsoleLogger:
      Threshold:                          "info"

gim_etl:
  days_to_keep_active_facts:              "27"
  days_to_keep_deleted_annex:             "2"
  days_to_keep_discards_and_job_history:  "60"
  days_to_keep_gidb_facts:                "27"
  days_to_keep_gim_facts:                 "400"
  etl_start_date:                         ""
  max_chunks_per_job:                     "10"
  max_time_deviation:                     "30"
  memory_threshold:                       "0"
  partitioning_ahead_range:               "31"
  partitioning_interval_size_gidb:        "604800"
  partitioning_interval_size_gidb_mm:     "604800"
  partitioning_interval_size_gidb_ocs:    "604800"
  partitioning_interval_size_gim:         "2592000"
  purge_thread_pool_size:                 "32"
  purge_transaction_size:                 "100000"

date_time:
  date_time_max_days_ahead:               "400"
  date_time_min_days_ahead:               "183"
  date_time_start_year:                   "2020"
  date_time_tz:                           "GMT"
  first_day_of_week:                      "1"
  fiscal_year_start:                      ""
  fiscal_year_end:                        ""
  fiscal_year_week_pattern:               "none"
  min_days_in_first_week:                 "1"
  simple_week_numbering:                  "true"

schedule:
  aggregate_duration:                     "23:00"
  aggregate_schedule:                     "30 0"
  etl_end_time:                           "23:30"
  etl_frequency:                          "1"
  etl_start_time:                         "00:00"
  export_schedule:                        "0/30 *"
  maintain_start_time:                    "23:40"
  run_aggregates:                         "true"
  run_export:                             "true"
  run_maintain:                           "true"
  run_scheduler:                          "true"
  run_update_stats:                       "true"
  on_demand_migration:                    "true"
  timezone:                               "UTC"
  update_stats_schedule:                  "0/10 *"

gim_export:
  chunk_size_seconds:                     "86400"
  days_to_keep_output_files:              "30"
  max_retries:                            "3"
  output_directory:                       "gim-export"
  output_files_encoding:                  "utf8"
  retry_delay_seconds:                    "30"
  start_date:                             ""
  thread_pool_size:                       "10"
  use_export_views:                       "true"

Custom calendars

GIM permits you to create custom calendars by creating a section in the values.yaml file that similar to the date-time section, and has the same options; name the section by using the date-time- prefix:

• Job_InitializeGIM populates data in all configured calendars when it initializes the Info Mart database.
• Job_MaintainGIM then maintains the calendars in accordance with options that are specified in the [date-time] and custom [date-time-*] configuration sections. The maintenance job automatically adjusts for special requirements such as daylight saving time (DST) and fiscal years that do not start on the same day every year (floating fiscal years).

Consider the settings for the date-time options carefully before the calendar dimension tables are populated for the first time. You can subsequently change the values of the date-time-min-days-ahead and date-time-max-days-ahead options at any time.

However, changing any of the other date-time options during runtime can introduce inconsistencies into the calendar data and affect reporting results adversely. For example, if you change the timezone option (date-time-tz) after Genesys Info Mart has been initialized, your reports can mix the results for different time zones within the same reporting interval.

Config Maps

Helm creates a number of Config Maps based on option values you specify in the values.yaml file (see Configure GIM Behavior). There are no Config Maps you can configure directly for Info Mart.