Difference between revisions of "PEC-REP/Current/GIMPEGuide/ConfigureGIM"

From Genesys Documentation
Jump to: navigation, search
 
(5 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
|ComingSoon=No
 
|ComingSoon=No
 
|Section={{Section
 
|Section={{Section
|sectionHeading=Override Helm chart values
+
|sectionHeading=GIM Helm chart overrides
 +
|anchor=GIM_HelmOverrides
 
|alignment=Vertical
 
|alignment=Vertical
|structuredtext=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.
+
|structuredtext=Genesys Info Mart requires some configuration for deployment that you can make only by modifying the Helm chart, which you do by creating override entries in the GIM '''values.yaml''' file.
  
For general information about overriding Helm chart values, see {{SuiteLevelLink|helmoverride}} in the ''{{Link-AnywhereElse|product=PrivateEdition|version=Current|manual=PEGuide|display text=Genesys Multicloud CX Private Edition Guide}}''.
+
Download the '''gim''' and '''gim-monitoring''' Helm charts from your image repository, using the appropriate credentials.
  
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 [[{{FULLPAGENAME}}#Security|Configure security]], below.
+
To learn how to download the Helm charts, see [[Draft:PrivateEdition/Current/PEGuide/ManageServices|Downloading your Genesys Multicloud CX containers]]. To find the correct Helm chart version for your release, see [[Draft:ReleaseNotes/Current/GenesysEngage-cloud/GIMHelm|Helm charts and containers for Genesys Info Mart]]. For general information about Helm chart overrides, see [[Draft:PrivateEdition/Current/PEGuide/HelmOverrides|Overriding Helm chart values]] in the ''[[Draft:PrivateEdition/Current/PEGuide|Genesys Multicloud CX Private Edition Guide]]''.
  
To enable S3-compatible storage for the Data Export packages, see [[{{FULLPAGENAME}}#Storage|Configure S3-compatible storage]], below.
+
At minimum, you must create entries in the '''values.yaml''' file to specify system information, as described in the following sections.
 
 
<!--{{Editgrn_open}}You can also specify values in the '''values.yaml''' to override the default values of configuration options that control GIM behavior. For more information, see [[{{FULLPAGENAME}}#Options|Configure GIM behavior]].{{Editgrn_close}}
 
-->
 
At a minimum, you must override the following key entries in the GIM '''values.yaml''' file:
 
 
 
*<tt>image:</tt>
 
*:<tt>registry</tt> — ''the registry from which Kubernetes will pull images (''<tt>pureengage-docker-staging.jfrog.io</tt> ''by default)''
 
*:<tt>tag</tt> - ''the container image version''
 
*<tt>tenant_id</tt> - ''the TenantID of the tenant in use''
 
* <tt>imagePullSecrets:</tt>
 
*:<tt>pureengage-docker-dev</tt> or <tt>pureengage-docker-staging</tt> — ''the secret from which Kubernetes will get credentials to pull the image from the registry''
 
* <tt>kafka:</tt>
 
*: <tt>bootstrap</tt> - ''the Kafka address to align with the infrastructure Kafka''
 
*: <tt>password</tt> - ''the Kafka password, if Kafka requires authentication''
 
*<tt>db</tt> - ''the applicable details for the Info Mart ETL database you created (see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=PlanningGIM|anchor=CreateDB|display text=Create the Info Mart database}})''
 
 
 
'''Note:''' <tt>tenant_id</tt> and <tt>kafka:password</tt> (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 <tt>kafka:topic</tt> parameter values to match. For more details about the required Kafka topics, see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=PlanningGSP|anchor=Kafka|display text=Kafka configuration}}.
 
  
 
{{NoteFormat|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.}}
 
{{NoteFormat|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.}}
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
|sectionHeading=Configure Kubernetes
+
|sectionHeading=Image repository and pull secret
 +
|anchor=GIM_ImagePull
 
|alignment=Vertical
 
|alignment=Vertical
|structuredtext=
+
|structuredtext={{AnchorDiv|GSP_ImageRegistry}}
{{AnchorDiv|Secrets}}
+
===Image registry===
===Secrets===
+
To specify the location of the image registry, create an entry in the GIM '''values.yaml''' file. This is the repository from which Kubernetes will pull images.
GIM requires the following secrets:
+
 
* <tt>docker-registry</tt> — Credentials to pull the image from the JFrog repository
+
The location of the image registry is defined when you set up the environment for the GIM, and is represented in the system as the <code>docker-registry</code>. In the GIM Helm chart, the repository is represented as <code>image: registry</code>, as shown in the following example.  You can optionally set a container version for the image.
* <tt>kafka-secrets</tt> — Credentials to access Kafka
+
 
* <tt>gim-secrets</tt> — Credentials to access the Info Mart database
+
<source lang="bash">
* <tt>s3-storage-secrets</tt> — Credentials to access optional S3-compatible storage (for Data Export)
+
image: # The repository from which Kubernetes will pull images
 +
  registry: <your_container_registry>  # The default registry is pureengage-docker-staging.jfrog.io
 +
  tag: <image_tag>   # the container image tag/version
 +
</source>
  
Except for <tt>docker-registry</tt>, which you must create manually (see the environment setup instructions on {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=DeployGIM}}), Helm creates the secrets based on values you specify in the '''values.yaml''' file.
+
{{AnchorDiv|GSP_Config_PullSecret}}
 +
===Pull secret===
 +
When you set up your environment, you define a pull secret for image registry (<code>docker-registry</code>). You must include the pull secret in the GIM '''values.yaml''' file for Kubernetes to be able to pull from the repository.
  
{{AnchorDiv|ConfigMaps}}
+
<source lang="bash">
===Config Maps===
+
imagePullSecrets:
Helm creates a number of Config Maps based on option values you specify in the '''values.yaml''' file<!-- (see [[{{FULLPAGENAME}}#Options|Configure GIM behavior]])-->. There are no Config Maps you can configure directly.
+
  docker-registry: {<pull-secret>} # The credentials Kubernetes will use to pull the image from the registry
 +
</source>
 +
 
 +
Other services use a different syntax to configure the repository pull secret, as follows:
 +
<source lang="bash">
 +
imagePullSecrets:
 +
  name: docker-registry
 +
</source>
 +
Genesys Info Mart, GIM Stream Processor, and GIM Configuration Adapter helm charts all support advanced templating that allow the helm to create the pull secret automatically; hence the variation in syntax.
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
|sectionHeading=Configure security
+
|sectionHeading=Kafka
|anchor=Security
+
|anchor=GIM_Kafka
 
|alignment=Vertical
 
|alignment=Vertical
|structuredtext=The security context settings define the privilege and access control settings for pods and containers.
+
|structuredtext={{AnchorDiv|GSP_KafkaSecret}}
 +
===Kafka secret===
 +
If Kafka is configured with authentication, you must configure the Kafka secret so the GIM service can access Kafka. The Kafka secret is provisioned in the system as <code>kafka-secrets</code> when you set up the environment for Info Mart. Configure the Kafka secret by creating a Helm chart override in the '''values.yaml''' file.
  
By default, the user and group IDs are set in the GIM '''values.yaml''' file as <tt>500:500:500</tt>, meaning the '''genesys''' user.
 
 
<source lang="bash">
 
<source lang="bash">
securityContext:
+
kafka:
   runAsNonRoot: true
+
   password: <kafka-password> # Credentials for accessing Kafka. This secret is created during deployment.
  runAsUser: 500
+
</source>
  runAsGroup: 500
 
  fsGroup: 500
 
  
containerSecurityContext: {}
+
{{AnchorDiv|GSP_KafkaBootstrap}}
 +
===Kafka bootstrap===
 +
To allow the Kafka service on Info Mart to align with the infrastructure Kafka service, make a Helm override entry with the location of the Kafka bootstrap.
 +
<source lang="bash">
 +
kafka:
 +
  bootstrap: <kafka-bootstrap-location> # the Kafka address to align with the infrastructure Kafka
 
</source>
 
</source>
===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.
 
  
<source lang="bash">
+
{{AnchorDiv|GSP_Config_KafkaTopics}}
securityContext:
+
===Custom Kafka topic names===
  runAsNonRoot: true
+
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 GIM Helm chart override entry, using the <code>kafka:topic</code>  parameter.
  runAsUser: null
 
  runAsGroup: 0
 
  fsGroup: null
 
  
containerSecurityContext: {}
+
For a list of the Kafka topics that GSP produces and consumes, including which of those support customized naming, see {{Link-AnywhereElse|product=PEC-REP|version=Current|manual=GIMPEGuide|topic=PlanningGSP|anchor=GSP_KafkaTopics}}.
</source>
 
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
|sectionHeading=Configure S3-compatible storage
+
|sectionHeading=Data export and S3-compatible storage
|anchor=Storage
+
|anchor=GIM_DataExport
 
|alignment=Vertical
 
|alignment=Vertical
|structuredtext=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:
+
|structuredtext=If the Genesys Info Mart Data Export feature is part of your deployment, you can export your data to S3-compatible object storage.
* <tt>s3_storage_enabled:</tt> true
+
 
* <tt>s3_storage:</tt>
+
You provision the storage when you set up the environment for Genesys Info Mart, and make override entries in the '''values.yaml''' file to enable the storage.
*:<tt>account:</tt>
 
*:&nbsp;&nbsp;&nbsp;<tt>accessKey</tt> — ''the access key created when you created the bucket''
 
*:&nbsp;&nbsp;&nbsp;<tt>secretKey</tt> — ''the secret created when you created the bucket''
 
*:&nbsp;&nbsp;&nbsp;<tt>region</tt> — ''the region in which the bucket was created''
 
*:&nbsp;&nbsp;&nbsp;<tt>entryPoint</tt> — ''URL to access bucket storage''
 
* <tt>gim_export:</tt>
 
*: <tt>output_directory</tt> — ''the bucket name''
 
The <tt>s3_storage</tt> parameters are used to construct the '''s3_storage_secrets''' secret.
 
  
<!--{{Editgrn_open}}<font color=red>'''Writer's note:''' The examples are not in the PAT team instructions.</font>{{Editgrn_close}}<br/>-->
 
====OpenShift example====
 
 
<source lang="bash">
 
<source lang="bash">
gim_export:
 
  ...
 
  output_directory:                      "gim-3f7ac1ab-03b9-445b-ba12-137d4bbc3c38"
 
  ...
 
 
s3_storage_enabled: true
 
s3_storage_enabled: true
 
s3_storage:
 
s3_storage:
 
   account:
 
   account:
     accessKey: "<Access Key>"
+
     accessKey: <access-key> # The access key created when you created the storage bucket
     secretKey: "<Secret Key>"
+
     secretKey: <secret-key> # The secret created when you created the bucket
     region: "<Region>"
+
     region: # The region in which the bucket was created
     entrypoint: "s3.openshift-storage.svc"
+
     entryPoint: # The URL for accessing bucket storage
 +
gim_export:
 +
  output_directory: # The bucket name
 
</source>
 
</source>
 +
 +
The <code>s3_storage</code> parameters are used to construct the '''s3_storage_secrets''' secret.
  
 
====GKE example====
 
====GKE example====
Line 130: Line 114:
 
</source>
 
</source>
 
|Status=No
 
|Status=No
}}<!--{{Section
+
}}{{Section
 
|sectionHeading=Configure GIM behavior
 
|sectionHeading=Configure GIM behavior
 
|anchor=Options
 
|anchor=Options
 
|alignment=Vertical
 
|alignment=Vertical
|structuredtext={{Editgrn_open}}<font color=red>'''Writer's note:''' Placeholder pending Q&A. This section will be suppressed for GKE Q1 publication.</font>{{Editgrn_close}}
+
|structuredtext=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.
 +
<!--GIM-14211, GIM-13618-->
 +
For information about the options you can configure including the default and valid values, see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=GIMConfigOptions}}.
 +
 
 +
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 {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=GIMConfigOptions|anchor=ConfigLevel|display text=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:
 +
<source lang="bash">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"
 +
</source>
 +
 
 +
===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.
 +
<!--Writer: Update the following link or remove it:
 +
If you want to change calendar options during runtime, see [[Documentation:GIM:Ops:CalendarDim|Changing Calendar Dimensions]] in the ''Genesys Info Mart Operations Guide,'' which provides information about additional steps that are required to maintain reporting consistency.
 +
-->
 +
|Status=No
 +
}}{{Section
 +
|sectionHeading=Config Maps
 +
|alignment=Vertical
 +
|structuredtext=Helm creates a number of Config Maps based on option values you specify in the '''values.yaml''' file (see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=ConfigureGIM|anchor=Options|display text=Configure GIM Behavior}}). There are no Config Maps you can configure directly for Info Mart.
 
|Status=No
 
|Status=No
}}-->
+
}}
 
|PEPageType=9c3ae89b-4f75-495b-85f8-d8c4afcb3f97
 
|PEPageType=9c3ae89b-4f75-495b-85f8-d8c4afcb3f97
 
}}
 
}}

Latest revision as of 13:31, March 10, 2023

This topic is part of the manual Genesys Info Mart Private Edition Guide for version Current of Reporting.

GIM Helm chart overrides

Genesys Info Mart requires some configuration for deployment that you can make only by modifying the Helm chart, which you do by creating override entries in the GIM values.yaml file.

Download the gim and gim-monitoring Helm charts from your image repository, using the appropriate credentials.

To learn 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 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 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 repository and pull secret

Image registry

To specify the location of the image registry, create an entry in the GIM values.yaml file. This is the repository from which Kubernetes will pull images.

The location of the image registry is defined when you set up the environment for the GIM, and is represented in the system as the docker-registry. In the GIM Helm chart, the repository is represented as image: registry, as shown in the following example. You can optionally set a container version for the image.

image: # The repository from which Kubernetes will pull images
  registry: <your_container_registry>  # The default registry is pureengage-docker-staging.jfrog.io
  tag: <image_tag>    # the container image tag/version

Pull secret

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

imagePullSecrets:
  docker-registry: {<pull-secret>} # The credentials Kubernetes will use to pull the image from the registry

Other services use a different syntax to configure the repository pull secret, as follows:

imagePullSecrets:
  name: docker-registry

Genesys Info Mart, GIM Stream Processor, and GIM Configuration Adapter 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 the GIM service can access Kafka. The Kafka secret is provisioned in the system as kafka-secrets when you set up the environment for Info Mart. Configure the Kafka secret by creating a Helm chart override in the values.yaml file.

kafka:
  password: <kafka-password> # Credentials for accessing Kafka. This secret is created during deployment.

Kafka bootstrap

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

kafka:
  bootstrap: <kafka-bootstrap-location> # 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 GIM 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.

Data export and S3-compatible storage

If the Genesys Info Mart Data Export feature is part of your deployment, you can export your data to S3-compatible object storage.

You provision the storage when you set up the environment for Genesys Info Mart, and make override entries in the values.yaml file to enable the storage.

s3_storage_enabled: true
s3_storage:
  account:
    accessKey: <access-key> # The access key created when you created the storage bucket
    secretKey: <secret-key> # The secret created when you created the bucket
    region: # The region in which the bucket was created
    entryPoint: # The URL for accessing bucket storage
gim_export:
  output_directory: # The bucket name

The s3_storage parameters are used to construct the s3_storage_secrets secret.

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.

Comments or questions about this documentation? Contact us for support!