fiscal-year-start
Section: date-time
Default Value: No default value
Valid Values: Any valid combination of month and day, in M-d format
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: fiscal-year-week-pattern is set to a valid pattern
Introduced: 8.1.1
Specifies the month and day that the fiscal year starts. For example, 1-1 means January 1; 10-1 means October 1. This functionality was introduced in release 8.1.1.
- If simple-week-numbering=true, every fiscal year starts on the fixed date that is specified by this option.
- If simple-week-numbering=false, the fiscal year starts on the first day of the week that contains the date that is specified by this option; however, the actual start date depends on the value of the first-day-of-week option.
fiscal-year-week-pattern
Section: date-time
Default Value: none
Valid Values: none, 544, 454, 445
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the pattern for the number of weeks in each month of a fiscal quarter. For example, 544 means 5 weeks in the first month, 4 weeks in the second month, and 4 weeks in the third month of each quarter. A value of none means that the calendar will not be a fiscal one.
min-days-in-first-week
Section: date-time
Default Value: 1
Valid Values: 1-6
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: simple-week-numbering=false
Specifies the minimum number of days from the new year that must be in the first week of the year, if simple week numbering is not used and there are no partial weeks in the calendar year. The ISO 8601 standard does not use simple week numbering.
The ISO 8601 definition of the first week in the year is the week that has the first Thursday in it. To conform to the ISO 8601 standard, set simple-week-numbering=false, first-day-of-week=2, and min-days-in-first-week=4.
first-day-of-week
Section: date-time
Default Value: 1
Valid Values: 1-7 (Sunday-Saturday)
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the day of the week that is considered to be the start of the week. For example, 1 (Sunday) is usually the first day of the week in the United States; for countries that use the ISO 8601 standard, 2 (Monday) is the first day of the week.
simple-week-numbering
Section: date-time
Default Value: true
Valid Values: true, false
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies whether the calendar year and the week-numbering year coincide. For simple week numbering, Week 1 always begins on the first day of the calendar year (for Gregorian calendars, January 1; for fiscal calendars, the day that is specified in the fiscal-year-start option). As a result, the first and last weeks of the year might be partial weeks, because the first week will not necessarily start with the day that is specified by the first-day-of-week option. To comply with ISO 8601 week numbering, set the value of this option to false.
date-time-max-days-ahead
Section: date-time
Default Value: 366
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies, in number of days, how far ahead the calendar dimension table will be populated. The default value specifies that the calendar dimension will be populated up to a year in advance (365 days + 1 day for leap years). Genesys does not recommend that you populate the calendar tables more than a year in advance, in case there are changes to DST or other international time standards that might invalidate the prepopulated data.
Note: Ensure that you populate the calendar far enough ahead to meet the requirements of your reporting intervals.
date-time-min-days-ahead
Section: date-time
Default Value: 183
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies, in number of days that remain in the prepopulated calendar, when the calendar table will be updated with the next batch of days ahead. The default value specifies that the maintenance job will update this calendar approximately 6 months before it expires.
date-time-start-year
Section: date-time
Default Value: 2012
Valid Values: 1970-2038
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Modified: 8.1.1 (in release 8.1.0, the default value was 2010)
Specifies the year that the calendar starts. When you are setting this option, ensure that you choose a start year that provides sufficient buffer to prevent inconsistencies or unexpected missing dimensions around the start of the calendar. Genesys recommends that you set the value so that the calendar starts at least one year prior to any date that might be encountered in the data. Be aware that Genesys Info Mart uses GMT for internal time references, and this affects exactly when the calendar starts.
date-time-tz
Section: date-time
Default Value: GMT
Valid Values: Any valid Java time zone
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the time zone for the calendar. You can use any valid time zone that is supported by the version of the Java Runtime Environment (JRE) that runs the Genesys Info Mart Server. For more information about supported time zones, see the documentation about calendar time zones on the Java developer website or other public resources.
date-time-table-name
Section: date-time
Default Value: DATE_TIME
Valid Values: Any string that is a valid table name for your RDBMS
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the name of the table in the Info Mart database schema. You must manually modify the script that creates the custom calendar table, to specify this value as the table name.
partitioning-ahead-range
Section: gim-etl
Default Value: 14
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies, in terms of number of days, how far ahead Job_InitializeGIM (in the first instance) and Job_MaintainGIM (on an ongoing basis) will create partitions for GIDB, Control, and Info Mart fact tables that are partitioned. Starting with release 8.1.2, these jobs add partitions for the number of days ahead of the time that the job is running. (Job_InitializeGIM also adds partitions from etl-start-date up to the time that the job is running.) In earlier releases, Job_MaintainGIM adds partitions for the number of days ahead of the extraction high-water mark (extractHWM). The number of partitions that Job_MaintainGIM actually creates during each run depends on the partition sizes and the job frequency.
partitioning-interval-size-gim
Section: gim-etl
Default Value: 86400
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the size of partitions, in seconds, for Info Mart fact and Control tables that are partitioned. Job_MaintainGIM creates partitions of the specified size in the Info Mart database in preparation for future ETL cycles. Starting with release 8.1.1, the default size of Info Mart fact table partitions is 1 day (86400 seconds). In release 8.1.0, the default size was 7 days (604800 seconds).
In PostgreSQL deployments, the recommended size of partitions for dimensional-model data depends on your plans for data retention in the Info Mart database. For PostgreSQL, Genesys recommends setting the size of fact table partitions to:
- One month (2592000 seconds) if data retention is under three years (days-to-keep-gim-facts is less than 1095)
- Two or three months (5184000 or 7776000 seconds) if data retention is more than three years (days-to-keep-gim-facts is greater than 1095).
partitioning-interval-size-gidb-ocs
Section: gim-etl
Default Value: 86400 or partitioning-interval-size-gidb
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Introduced: 8.1.402.07
Specifies the size of partitions, in seconds, for partitioned GIDB tables that store Outbound Contact–related data. When this option is set, Job_MaintainGIM creates partitions of the specified size in the Info Mart database in preparation for future ETL cycles. If the option is not specified, the value of partitioning-interval-size-gidb, which has a default value of 24 hours (86400 seconds), is used.
In PostgreSQL deployments, Genesys recommends setting the size of GIDB table partitions to one week (604800 seconds).
partitioning-interval-size-gidb-mm
Section: gim-etl
Default Value: 86400 or partitioning-interval-size-gidb
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Introduced: 8.1.402.07
Specifies the size of partitions, in seconds, for partitioned GIDB tables that store multimedia interaction data. When this option is set, Job_MaintainGIM creates partitions of the specified size in the Info Mart database in preparation for future ETL cycles. If the option is not specified, the value of partitioning-interval-size-gidb, which has a default value of 24 hours (86400 seconds), is used. Genesys recommends increasing the size of GIDB partitions for multimedia interactions, which typically live longer than voice interactions but generate a smaller volume of data.
In PostgreSQL deployments, Genesys recommends setting the size of GIDB table partitions to one week (604800 seconds).
partitioning-interval-size-gidb
Section: gim-etl
Default Value: 86400
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the size of partitions, in seconds, for GIDB tables that are partitioned. Job_MaintainGIM creates partitions of the specified size in the Info Mart database in preparation for future ETL cycles. The default size of GIDB table partitions is 24 hours (86400 seconds).
In PostgreSQL deployments, Genesys recommends setting the size of GIDB table partitions to one week (604800 seconds).
purge-thread-pool-size
Section: gim-etl
Default Value: 32
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the maximum number of concurrent purging transactions. The optimum value for this option depends on the characteristics and capacity of your deployment. Consider increasing the value of this option if you think that there is scope to improve performance of the purge operation.
purge-transaction-size
Section: gim-etl
Default Value: 100000
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the number of deleted records per table that will be committed in a single transaction.
days-to-keep-discards-and-job-history
Section: gim-etl
Default Value: 600
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the number of days to retain data in the discard tables and audit and history tables.
days-to-keep-deleted-annex
Section: gim-etl
Default Value: 2
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Specifies the number of days to retain deleted records in the *_ANNEX dimension tables.
days-to-keep-gdpr-history
Section: gim-etl
Default Value: 15
Valid Values: An integer in the range 0-30
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Introduced: 8.5.010
Specifies the number of days to retain data in the CTL_GDPR_HISTORY table.
The table stores the actual personally identifiable information (PII) that relates to a General Data Protection Regulation (GDPR) request. For Right of Access (export) requests, the table stores the data that was requested for export. For Right of Erasure ("forget me") requests, the table stores the data that was redacted.
To ensure that this data is ephemeral, the retention period for records in the CTL_GDPR_HISTORY table is restricted to a maximum of 30 days.
days-to-keep-active-facts
Section: gim-etl
Default Value: 30
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_TransformGIM or Job_MaintainGIM
Dependencies: None in releases 8.1.0 and 8.1.1; starting with release 8.1.2, days-to-keep-gim-facts
Modified: 8.5.015.19 (plays no role in determining purge thresholds); 8.1.2 (dependencies introduced); 8.1.1 (behavior and default value changed)
Starting with release 8.1.1, specifies the maximum number of days to retain active multimedia interactions in GIDB and the dimensional model, including certain Staging tables, after which the interactions become eligible for artificial termination.
days-to-keep-gim-facts
Section: gim-etl
Default Value: 400
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None
Starting with release 8.1.1, specifies the number of days to retain fact data in the dimensional model. Facts that have a start time that is earlier than the retention period are eligible to be purged. Job_MaintainGIM does not purge active fact data, dimension data, or aggregate tables (if aggregation is enabled).
Starting with release 8.1.2, Genesys Info Mart enforces days-to-keep-active-facts < days-to-keep-gim-facts and days-to-keep-gidb-facts < days-to-keep-gim-facts.
days-to-keep-cfg-facts
Section: gim-etl
Default Value: 400 or days-to-keep-gim-facts
Valid Values: Greater than, or equal to, days-to-keep-gim-facts
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: days-to-keep-gim-facts
Introduced: 8.5.003
Specifies the number of days to retain deleted configuration fact data in GIDB and relevant fact tables. Facts that have an end time that is earlier than the retention period are eligible to be purged. The value of the days-to-keep-cfg-facts configuration options must always be greater than, or equal to, days-to-keep-gim-facts.
For a list of the tables for which this option controls the purge threshold, see Info Mart Tables Purged by the Maintenance Job in the Genesys Info Mart Operations Guide.
days-to-keep-gidb-facts
Section: gim-etl
Default Value: 14
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_MaintainGIM
Dependencies: None in releases 8.1.0 and 8.1.1; starting with release 8.1.2, days-to-keep-gim-facts
Modified: 8.5.015.19, 8.1.2 (behavior changed with respect to multimedia interactions)
Related Options: days-to-keep-active-facts
Starting with release 8.1.1, specifies the number of days to retain fact data in GIDB. Facts that have a start time that is earlier than the retention period are eligible to be purged.
Starting with release 8.5.015.19, the retention period for multimedia facts in GIDB is determined solely by the value of days-to-keep-gidb-facts. For releases 8.5.015.19 through 8.5.016.01, be aware that, if days-to-keep-gidb-facts is less than days-to-keep-active-facts, user data for active multimedia interactions older than days-to-keep-gidb-facts might not be transformed correctly (see the Known Issue for GIM-13320 in the Genesys Info Mart 8.5.x Release Note).
For multimedia interactions in releases earlier than 8.5.015.19, this option, together with days-to-keep-active-facts, specifies the retention period for facts in GIDB: The retention period is the greater of the days-to-keep-gidb-facts and days-to-keep-active-facts option values.
In 8.1.1 releases, days-to-keep-gidb-facts specifies the retention period for completed multimedia facts, provided that there are no active facts that have the same (or earlier) start timestamps. If there are active facts with the same (or earlier) start timestamps, the eligible completed facts will not actually be purged until these active interactions have been terminated and, therefore, also become eligible to be purged, as described in days-to-keep-active-facts.
For a list of the tables for which this option controls the purge threshold, see Info Mart Tables Purged by the Maintenance Job in the Genesys Info Mart Operations Guide.
use-export-views
Section: gim-export
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.009.20
Controls whether Genesys Info Mart will export data using export views, which represent a snapshot of the Info Mart schema at the time the export views were created.
- false—Genesys Info Mart will export data using the current schema. The export might include schema changes, such as new or renamed tables or columns, that occurred as part of a recent Info Mart migration.
- true—Genesys Info Mart will export data using export views. The export will include the same tables and columns as the previous export(s), regardless of any schema changes resulting from migration(s) that may have occurred in the interim.
thread-pool-size
Section: gim-export
Default Value: 10
Valid Values: Any positive integer
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies the maximum number of worker threads that are used to export data concurrently.
start-date
Section: gim-export
Default Value: No default value
Valid Values: Any date after 1970 in the format yyyy-mm-dd hh:mm:ss
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: days-to-keep-discards-and-job-history ≥ days-to-keep-gim-facts
Introduced: 8.5.005
Specifies the earliest date for which Job_ExportGIM exports data, and then continues with incremental exports. If no date is specified (the default), Job_ExportGIM starts exporting from the beginning of the Info Mart data.
Important:
- This option applies only when the directory in which the exported files will be stored — in other words, the directory specified by the output-directory option — is empty.
- This option is not supported when audit log retention time is shorter than facts retention time.
retry-delay-seconds
Section: gim-export
Default Value: 30
Valid Values: Any non-negative integer
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies the amount of time, in seconds, that the job waits in the case of intermittent failure before attempting to run again.
output-files-encoding
Section: gim-export
Default Value: utf8
Valid Values: Character encoding supported by Java
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies the character encoding for exported files. For Java-supported encodings, see Supported Encodings.
output-directory
Section: gim-export
Default Value: output
Valid Values: Valid directory path (might not exist)
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies the directory where exported files are stored.
max-retries
Section: gim-export
Default Value: 3
Valid Values: Any non-negative integer
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies the maximum numbers of retries the job does in the case of intermittent failures before failing the job.
days-to-keep-output-files
Section: gim-export
Default Value: 14
Valid Values: Any positive integer
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies how many days to store exported files before deleting them.
chunk-size-seconds
Section: gim-export
Default Value: 86400
Valid Values: Any positive integer
Changes Take Effect: On the next run of Job_ExportGIM
Dependencies: None
Introduced: 8.5.005
Specifies the size of the time interval, in seconds, for which data is exported in each job.
kafka-idle-timeout
Section: gim-transformation
Default Value: 10 (seconds)
Valid Values: A number (of seconds) or duration in ISO 8601 format
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.011.23
Specifies the idle timeout for polling Kafka records. If polling does not return any records within the timeout, Genesys Info Mart stops polling Kafka until the next ETL cycle.
In releases earlier than 8.5.011.23, the timeout was hard-coded, with a value of 2 seconds. In high-latency networks, the hard-coded value sometimes caused Genesys Info Mart to skip transformation of Kafka records, even if data was available.
g:topic:<topic-name>
Section: kafka-<cluster-name>
Default Value: No default value
Valid Values: Any Genesys Info Mart–defined <mapping-id>, as listed in the option description
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.011.18
Specifies a Kafka topic to consume and how messages in this topic will be mapped. The <topic-name> in the option name identifies the topic Genesys Info Mart will look for in Kafka message headers and matches the topic name configured in the producer application. The option value identifies the ID in the CTL_XML_CONFIG table that Genesys Info Mart will use to map that topic into the database schema.
Configure a separate g:topic:<topic-name> option for each topic to which the Kafka producers publish reporting data. A particular kafka-<cluster-name> section might contain multiple g:topic:* options, some of which might have the same <mapping-id> value, depending on the data source.
Genesys Info Mart supports the following <mapping-id> values:
| Producer application | <mapping-id> | Supported since Genesys Info Mart release |
|---|---|---|
| Bot Gateway Server (BGS) | BGS_K | 8.5.011.18 |
| Genesys Co-browse (GCB) | COBROWSE | 8.5.011.18 |
bootstrap.servers
Section: kafka-<cluster-name>
Default Value: No default value
Valid Values: Any valid host:port combination that identifies a Kafka server in the cluster
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.011.18
Specifies the location of the Kafka broker(s) in the cluster, in the form of host:port. If there are multiple servers, use a comma-separated list.
bootstrap.servers is a standard Kafka consumer option. The option is mandatory for Genesys Info Mart, as a Kafka consumer, to know where to connect for the initial connection to the Kafka cluster. In high availability (HA) deployments, Genesys recommends that you list all the brokers in the cluster.
For more information about the bootstrap.servers option, see the Apache Kafka documentation (https://kafka.apache.org/documentation#consumerapi).
sources:extra
Section: elasticsearch-<data-source-id>
Default Value: None
Valid Values: A comma-separated list of any valid identifiers (IDs) of the data sources for the Elasticsearch database
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.011.14
In an environment where a single Elasticsearch database stores data from multiple sources, this option enables you to configure a number of data sources in a single section. Specify the ID of the main data source as the suffix in the section name, such as sdr1 in elasticsearch-sdr1. Specify IDs of any additional data sources as a comma-separated list in the option value. Do not list an ID for the same data source more than once, whether explicitly or implicitly. For example, for Genesys Info Mart to retrieve the data that sdr1, ocs1, and ocs2 data sources store on node1 of the ElasticSearch cluster, add the following configuration:
Example:
- [elasticsearch-sdr1]
- sources:extra=ocs1,ocs2
- client=rest(http://node1:9200)
g:tenant-prefix
Section: elasticsearch-<data-source-id>
Default Value: No default value
Valid Values: A string identifying the tenant on a shared Elasticsearch cluster
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.011.15
In Genesys Engage cloud deployments, the option defines a cloud tenant prefix for Elasticsearch indexes on an Elasticsearch cluster shared across multiple cloud tenants. The tenant prefix enables Genesys Info Mart to identify Elasticsearch indexes related to the particular cloud tenant.
If specified, the option value overrides the index-pattern and index-regexp values from the XML source metadata, and the tenant prefix is included in index pattern and regexp strings.
Example
The following table illustrates the effect of specifying a tenant prefix, where the source type is sdr and the source ID is sdr0.
| [elasticsearch-sdr0].g:tenant-prefix | index-pattern | index-regexp |
|---|---|---|
| Not defined | ‘sdr’-yyyy.MM.dd | sdr-* |
| -my-tenant | ’sdr-my-tenant’-yyyy.MM.dd | sdr-my-tenant-* |
g:index-interval
Section: elasticsearch-<data-source-id>
Default Value: No default value
Valid Values: Duration in days or ISO8601 duration format
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.013.06
Specifies the maximum expected interval, or range of data, stored in a single Elasticsearch index. The option enables you to override the default Elasticsearch index interval.
If the data source uses indices that can have different intervals, set the value of this option to the largest possible interval. For example, if the data source uses an index that sometimes contains three days of data and sometimes contains five days of data, set g:index-interval=5.
client
Section: elasticsearch-<data-source-id>
Default Value: off
Valid Values: off or any valid location of the cluster node(s) of the Elasticsearch cluster, properly formatted
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.009.20
This option specifies one or more nodes in the Elasticsearch cluster that Genesys Info Mart uses to retrieve data from an Elasticsearch database version 5.0 or higher. Genesys Info Mart uses the REST API client to communicate with the Elasticsearch cluster. You must specify the REST API URL address(es) for the REST client in the following format:
- rest(http://<es-node>:<port>[,http://<es-node>:<port>]*)
ud-io-parallelism
Section: gim-transformation
Default Value: 5
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None
Starting with release 8.1.1, specifies the number of parallel threads for user-data transformation. The optimal value of this option depends on DBMS tuning and available resources.
irf-io-parallelism
Section: gim-transformation
Default Value: 4
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None
Specifies the number of parallel reading processes for IRF transformation. The optimal value of this option depends on DBMS tuning and available resources.
chunk-size
Section: gim-transformation
Default Value: 7200
Valid Values: Any nonnegative integer
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None
Introduced: 8.5.013.06
Modified: .5.015.19 (behavior changed with respect to Elasticsearch data)
Specifies the maximum size of the time interval, in seconds, for which transformed data is committed in one transaction.
- For data that comes through ICON and IDB, the option applies to transformation of Multimedia and Outbound Contact details.
- A value of 0 means that the transformation job takes chunks from GIDB based on extraction high-water marks (HWMs) and audit keys generated by the extraction job. In this case, the transformation chunk size does not exceed the chunk size for extraction, as specified by the extract-data-chunk-size option.
- A value greater than 0 means that the transformation job takes chunks from GIDB based on the value of chunk-size and the previous transformation HWM, without regard to audit keys set by the extraction job.
- For data that comes through Elasticsearch:
- In releases earlier than 8.5.015.19, the transformation job always uses the value of extract-data-chunk-size to set the chunk size for transformation.
- Starting with release 8.5.015.19, the transformation job uses the smaller of extract-data-chunk-size and chunk-size to determine the chunk size to use for Elasticsearch data transformation.
- For data that comes through Kafka, starting with release 8.5.015.19 the chunk size logic is similar to the logic applied to Elasticsearch data.
For data that comes from IDB, Genesys expects that the value of chunk-size (default value 2 hours) will usually be greater than the value of extract-data-chunk-size (default value 15 minutes). When Genesys Info Mart extraction and transformation are running normally with frequent ETL cycles, the amount of data available for transformation is smaller than the chunk-size option, and all available data is transformed. In cases where there is a transformation backlog, a chunk-size value greater than extract-data-chunk-size will enable transformation to catch up with extraction quickly.
However, attempting to transform a large amount of data in one chunk can lead to performance issues or OutOfMemory errors. In cases where there is a very large backlog or where a very large quantity of data has been extracted (for example, because extract-data-chunk-size has been set to a large value and/or "runaway strategy" scenarios have occurred), temporarily reducing the value of the chunk-size option, even to a value smaller than extract-data-chunk-size, enables Genesys Info Mart to process abnormally large amounts of data more efficiently, eventually catching up with extraction.
merge-chunk-size
Section: gim-etl
Default Value: 200000
Valid Values: Any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the maximum number of root G_IR rows in a chunk of merged data, for the purpose of transformation. By limiting the size of the data chunks produced by the merge process, this option enables you to manage situations in which there is a very large amount of merged data. The optimal value of this option depends on the characteristics of your deployment.
max-chunks-per-job
Section: gim-etl
Default Value: 10
Valid Values: 1-100
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.5.116.29 (scope extended)
Specifies the number of extracted data chunks that the transformation job processes in one ETL cycle. As long as it seems practical from the performance perspective, increase the option value to transform a larger amount of data in a single cycle.
Starting with release 8.5.116.29 in deployments using the Data Export feature, the option also controls the maximum number of export chunks that can be created by the export job during each job run. In situations where the time range to be exported exceeds the export chunk size (for example, if there is a backlog because data is being re-exported), a larger number of export chunks reduces the time required to process a large export backlog.
extract-data-thread-pool-size
Section: gim-etl
Default Value: 32
Valid Values: Any positive integer, as appropriate for your environment
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the maximum number of worker threads that are used to extract data concurrently. This option does not set a strong limit on the total number of threads that will be used in extraction processing, because certain extraction algorithms create additional helper threads. Instead, this option specifies the maximum number of logical partitions for concurrent extraction of subsets of data.
extract-data-max-conn
Section: gim-etl
Default Value: 128
Valid Values: Any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Discontinued: 8.5.014.26
For each DAP that Genesys Info Mart uses to extract data, specifies the maximum size of the connection pool for connections between the Genesys Info Mart Server and the IDB. Ensure that you configure your RDBMS to handle a sufficient number of concurrent connections.
extract-data-chunk-size
Section: gim-etl
Default Value: 900
Valid Values: Any integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the size of the time interval, in seconds, for which data is committed in one transaction. The data from this period is considered to be one data chunk, for the purpose of extract and transform. For example, if you set the value of extract-data-chunk-size to 900, Genesys Info Mart extracts 15 minutes (900 seconds) of available data.
extract-data-cfg-facts-chunk-size
Section: gim-etl
Default Value: 90000
Valid Values: Any integer
Changes Take Effect: On the next ETL cycle for the DAP with role=ICON_CFG
Dependencies: None
Specifies the size of the time interval, in seconds, for which configuration relationship data is committed in one transaction. The data from this period is considered to be one data chunk, for the purpose of extract and transform.
geo-location
Section: gim-etl
Default Value: “”
Valid Values: Any string
Changes Take Effect: For an extraction DAP, at the next run of the extraction job for the particular data domain; for the Info Mart DAP, on restart of the Genesys Info Mart Server.
Introduced: 8.1.2
On the extraction DAP, specifies the location of the IDB. On the Info Mart DAP, specifies the location of the Info Mart database. Genesys Info Mart compares the string value of the option on the Info Mart DAP against the value of the geo-location option in redundant extraction DAPs. If the values are the same, the IDB for which the extraction DAP provides the connection information is considered to be local; if the values are not the same, the IDB is considered to be remote.
In an HA environment, Genesys Info Mart uses geolocation as a tie-breaker to determine the best IDB from which to extract data: If data-quality criteria do not identify one IDB as the best, Genesys Info Mart gives preference to the local IDB.
pipeline-timeout-in-hours
Section: gim-transformation
Default Value: 1
Valid Values: Any positive integer
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None
Introduced: 8.1.3
Specifies the maximum expected duration, in hours of single execution transformation pipeline. If timeout is exceeded, GIM will try to abort pipeline and fail transformation job.
user-event-data-timeout
Section: gim-etl
Default Value: 3600
Valid Values: 0 or any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.1.1 (behavior changed)
Specifies the maximum time, in seconds, after the end of a call, during which an agent who handled that call can send UserEvent-based key-value pair (KVP) data. If the call has ended and the UserEvent-based KVP data is sent after this timeout, the transformation job does not process the UserEvent-based KVP data.
merge-failed-is-link-timeout
Section: gim-etl
Default Value: 0
Valid Values: 0 or any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.1.1
Specifies the time interval, in seconds, for which the merge of failed Inter Server Call Control (ISCC) links (IS-Links) will be delayed to enable Genesys Info Mart to receive both sides of the links. If the value of this option is greater than the value of max-call-duration, which specifies the timeout for stuck links, then max-call-duration controls the timeout for the merge of failed IS-Links as well.
memory-threshold
Section: gim-etl
Default Value: 0
Valid Values: 0-99
Changes Take Effect: Immediately
Dependencies: None
Specifies the percentage of available memory that must be exceeded before Genesys Info Mart logs a message (55-20101) that indicates that the memory threshold has been exceeded. If the value of this option is set to 0, the feature will be disabled.
max-time-deviation
Section: gim-etl
Default Value: 30
Valid Values: 1-120
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.5.015.19 (scope extended); 8.1.4 (minimum valid value changed)
Specifies the maximum time deviation, in seconds, to take into account for time synchronization inaccuracy between host system clocks. Starting with release 8.5.015.19, this option also specifies the maximum acceptable delay the transformation job will accommodate in scenarios in which ICON creates delayed records in the GM_F_USERDATA table in IDB.
If the maximum time deviation or delay is exceeded, Genesys Info Mart results become unreliable.
max-call-duration
Section: gim-etl
Default Value: 3600
Valid Values: 0 or any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the maximum duration, in seconds, of voice interactions in the deployed environment, as well as a number of important timeouts for both voice and multimedia interactions.
extract-data-stuck-threshold
Section: gim-etl
Default Value: 28860
Valid Values: Any integer equal to or greater than 1800
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the time, in seconds, that Genesys Info Mart waits for stuck data to become available in IDB. For example, if new data is available until 3:00 PM and the value for extract-data-stuck-threshold is set to 28860 (8 hrs 1 min.), Genesys Info Mart extracts data that has a timestamp from 6:59 AM to 3:00 PM. IDB data from the time intervals before 6:59 AM is not, and will never be, extracted.
delayed-data-threshold
Section: gim-etl
Default Value: 900
Valid Values: 60-3600
Changes Take Effect: On the next ETL cycle
Dependencies: None
When expected data is delayed, specifies the amount of time, in seconds, before Genesys Info Mart logs message 55-20110. The log message includes detailed information about the data sources and IDB tables from which data was expected.
Starting with release 8.1.3, Genesys Info Mart applies the delayed-data-threshold to extraction delays, when there is no data available to be extracted from an active data source. In previous releases, Genesys Info Mart applied the delayed-data-threshold to transformation delays, when Genesys Info Mart was unable to process a data chunk because dependent data was not available (in other words, had not been extracted yet).
Genesys recommends that you set an alarm on log message 55-20110, so that you can investigate the reasons for data delays in a timely manner and take appropriate action.
standard
Section: log
Default Value: network
Valid Values: network
Changes Take Effect: Immediately
Dependencies: verbose
Specifies the location of the log output.
verbose
Section: log
Default Value: standard
Valid Values: none, standard, trace
Changes Take Effect: Immediately
Dependencies: standard
Specifies the minimum level of logging.
file-pattern-layout
Section: log4j
Default Value: %d{ISO8601} %-5p %-12t %m%n
Valid Values: Any valid pattern string
Changes Take Effect: Immediately
Dependencies: None
For information about this option, refer to the Apache logging site: http://logging.apache.org/index.html
console-pattern-layout
Section: log4j
Default Value: %d{ISO8601} %-5p %-12t %m%n
Valid Values: Any valid pattern string
Changes Take Effect: Immediately
Dependencies: None
For information about this option, refer to the Apache logging site: http://logging.apache.org/index.html
max-backup-index
Section: log4j
Default Value: 10
Valid Values: Any positive integer
Changes Take Effect: Immediately
Dependencies: None
Specifies the maximum number of backup log files that are kept in addition to the active log file.
max-log-file-size
Section: log4j
Default Value: 50MB
Valid Values: Any number, followed by a scale (KB for kilobytes, MB for megabytes, or GB for gigabytes)
Changes Take Effect: Immediately
Dependencies: None
Specifies the maximum size of the active log file before it is considered full and renamed as a backup file.
log-file-name
Section: log4j
Default Value: gim_etl.log
Valid Values: filespec
Changes Take Effect: Immediately
Dependencies: None
Specifies the path and file name of the log file. If you do not specify a path, the log files will be created in the installation directory.
logging-level
Section: log4j
Default Value: info
Valid Values: debug, info, warn, error, none, all, off
Changes Take Effect: Immediately
Dependencies: None
Determines whether local logging is enabled, and specifies the minimum level of events to log. The DEBUG, INFO and WARN values correspond to the Genesys Management Layer DEBUG, TRACE, and STANDARD logging values, respectively.
log4j.appender.ConsoleLogger.Threshold
Section: log4j
Default Value: info
Valid Values: trace, debug, info, warn, error, all, off
Changes Take Effect: Immediately
Dependencies: None
For information about this option, refer to the Apache logging site: http://logging.apache.org/index.html
error-policy-irf-exception-resumable
Section: error-policy
Default Value: Exception
Valid Values: Any valid Java regular expression
Changes Take Effect: On the next ETL cycle
Dependencies: error-policy-irf-exception=log_db_resume or resume
The value defines a filter, which enables you to fine-tune the job level behavior (as specified by the error-policy-irf-exception option) by controlling which exceptions that might be triggered during interaction transformation can be considered to be discardable. If the specified regular expression matches the name of the exception class or the name of the exception super classes, then the exception is considered to be noncritical; the results of the interaction transformation (IRFs and MSFs) will be discarded, but Job_TransformGIM will continue. If the specified regular expression does not match the name of the exception class or the exception super class, the job will be aborted.
error-policy-irf-exception
Section: error-policy
Default Value: log_db_resume
Valid Values: log_db_resume, resume, exception
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when an exception is encountered during transformation of some interaction thread.
- log_db_resume (default)—Instructs the transformation logic to discard the problematic interaction thread, write corresponding information into the STG_TRANSFORM_DISCARDS table, and resume processing.
- resume—Instructs the transformation logic to discard the problematic interaction thread and resume processing, without writing corresponding information into the database.
- exception—Instructs the transformation logic to fail the job.
error-policy-party-parent-missing
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when the party refers to a parent, but party records that have the referenced PARTYID do not exist.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to ignore the missing data and continue processing.
error-policy-party-created-missing
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when G_PARTY_HISTORY does not contain a record that has ChangeType=1(party_created) for some party.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to construct a party created record, based on assumptions from the first party history record that it reads.
error-policy-party-created-duplicated
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when G_PARTY_HISTORY contains multiple records that have ChangeType=1(party_created) for some party.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to treat the first record that it reads as the party created record and to ignore the other party created records.
error-policy-islink-source-party-missing
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when the source call for the IS_LINK for a dial-out attempt does not have a remote dialed party. As a result, the transformation job does not have sufficient information to build the order for Interaction Resource Facts (IRFs).
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to build the order for IRFs randomly as it processes the interaction.
error-policy-islink-multiple-vertices
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when there are more than two bidirectional IS_LINKs that have the same LINKID. The option is similar to error-policy-islink-multiple-targets and error-policy-islink-multiple-sources, but it applies to bidirectional links. This data inconsistency occasionally occurs with older T-Servers.
error-policy-islink-multiple-targets
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when there are multiple (>1) target IS_LINKs that have the same LINKID.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to choose one of the target records randomly and ignore the other target records.
error-policy-islink-multiple-sources
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when there are multiple (>1) source IS_LINKs that have the same LINKID.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to choose one of the source records randomly and ignore the other source records.
error-policy-islink-dangling
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when information for only one side of an IS_LINK is available.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to process the interaction as if the missing IS-Link information were for a remote site that is not monitored by ICON. For example, an internal transfer will be transformed as an inbound or outbound interaction.
error-policy-ipurpose-numberformat
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when the IPurpose attached data key-value-pair (KVP) is present and the value of IPurpose is not a number. The error usually arises because of incorrect configuration.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to process the data as if the IPurpose KVP were not attached. In this case, whether the IVR is treated as a handling resource or a mediation resource depends on the value that is configured for the default-ivr-to-self-service option.
error-policy-campaign-group-missing
Section: error-policy
Default Value: exception
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when an Outbound Contact campaign record refers to a campaign group, but group records that have the referenced GROUPID do not exist.
- exception—Instructs the transformation logic to fail the job.
- resume—Instructs the transformation logic to ignore the missing data and continue processing. In all campaign-related records that are associated with the missing group(s), the tenant is identified as unknown (the TENANT_KEY field in campaign-related fact tables is populated with -1).
error-policy-call-mergecall-missing
Section: error-policy
Default Value: resume
Valid Values: exception, resume
Changes Take Effect: On the next ETL cycle
Dependencies: None
Policy on handling the situation when the MERGECALLID field in the GIDB_G_CALL_V table refers to missing records in the table.
- exception—Instructs the transformation logic to interrupt transformation of the interaction with an exception, which is handled as specified by the error-policy-irf-exception option.
- resume—Instructs the transformation logic to ignore references to the missing data and continue with transformation. The transformation job logs the following error message:
Interaction(...):call(...): merge call(...) is missing.
on-demand-migration
Section: schedule
Default Value: false
Valid Values: true, false
Changes Take Effect: When Genesys Info Mart next enters the migration state
Dependencies: None
Introduced: 8.5.007
Controls whether Genesys Info Mart will run Job_MigrateGIM automatically if the Info Mart database schema is not up to date following migration of the Info Mart server.
- true — Genesys Info Mart will launch Job_MigrateGIM automatically if the schema is not up to date.
- false — Genesys Info Mart will not launch Job_MigrateGIM automatically if the schema is not up to date and Genesys Info Mart enters the migration state.
export-schedule
Section: schedule
Default Value: 20 0/8
Valid Values: A valid CRON expression
Changes Take Effect: Immediately
Dependencies: run-export
Introduced: 8.5.005
Defines the time intervals at which Job_ExportGIM will run. The job will start and then run periodically in accordance with this schedule when the run-export option is set to true. By default, the job runs at 00:20, 08:20, and 16:20 every day.
The default schedule, run in conjunction with the default chunk-size-seconds option in the [gim-export] section, is designed to keep daily disruptions or delays from carrying over to the next day.
Job_ExportGIM can run in conjunction with the ETL jobs, but not in conjunction with Job_MaintainGIM.
The schedule is defined in the format of a CRON expression that represents a set. The expression comprises two fields, which are separated by whitespace:
- The first field specifies minutes. Valid values are 0–59 and optional special characters (see below).
- The second field specifies hours. Valid values are 0–23 and allowed special characters.
The following special characters are allowed in the CRON expression:
- , (comma)—Separates items in a list.
- - (hyphen)—Defines a range.
- * (asterisk)—Indicates that the CRON expression will match for all values of the field.
- / (forward slash)—Describes increments.
run-export
Section: schedule
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Dependencies: None
Introduced: 8.5.005
Specifies whether Job_ExportGIM will run. When the value of this option is set to true, the scheduler will start and run the job at the time and intervals specified by the export-schedule option.
update-stats-schedule
Section: schedule
Default Value: 0/10 *
Valid Values: A valid CRON expression
Changes Take Effect: Immediately
Dependencies: run-update-stats
Defines the time intervals at which Job_UpdateStats will run. The job will start and then run periodically in accordance with this schedule. By default, the job runs every 10 minutes throughout the day. Job_UpdateStats can run in conjunction with the ETL jobs, but not in conjunction with Job_MaintainGIM.
The schedule is defined in the format of a CRON expression that represents a set. The expression comprises two fields, which are separated by whitespace:
- The first field specifies minutes. Valid values are 0–59 and optional special characters (see below).
- The second field specifies hours. Valid values are 0–23 and allowed special characters.
The following special characters are allowed in the CRON expression:
- , (comma)—Separates items in a list. For example, specifying the first field (minutes) as 0,30,45 means the 0th, 30th, and 45th minutes of the hour.
- - (hyphen)—Defines a range. For example, specifying the first field (minutes) as 30-35 means every minute between the 30th and 35th minute of the hour, inclusive; this is the same as specifying 30,31,32,33,34,35.
- * (asterisk)—Indicates that the CRON expression will match for all values of the field. For example, specifying the second field (hours) as * means every hour in the day.
- / (forward slash)—Describes increments. For example, specifying the first field (minutes) as 0/10 means the 0th minute of the hour and every 10 minutes thereafter.
run-update-stats
Section: schedule
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Dependencies: None
Specifies whether Job_UpdateStats will run in PostgreSQL deployments, at the time and intervals specified by the update-stats-schedule option.
maintain-start-time
Section: schedule
Default Value: 03:00
Valid Values: 00:00-23:59
Changes Take Effect: Immediately
Dependencies: run-maintain
Specifies the time of day, in 24-hour format, when Job_MaintainGIM is started. This job is scheduled to start at this time when the run-maintain option is set to TRUE. The value that you specify must be outside the range that is specified by etl-start-time and etl-end-time.
run-maintain
Section: schedule
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Dependencies: None
Specifies whether to run Job_MaintainGIM at the scheduled time, as specified by the maintain-start-time option.
aggregate-duration
Section: schedule
Default Value: 5:00
Valid Values: 00:00-24:00
Changes Take Effect: Immediately
Dependencies: run-aggregates, aggregate-schedule
Specifies the amount of time, in 24-hour format, that Job_AggregateGIM will run after it is launched. When the run-aggregates option is set to TRUE, the scheduler will stop the aggregation job when this interval expires. The aggregation job is launched in accordance with a schedule defined by the aggregate-schedule option. After the aggregation job is launched, it runs continuously until the aggregation-duration interval expires.
aggregate-schedule
Section: schedule
Default Value: 0 1
Valid Values: A valid CRON expression
Changes Take Effect: Immediately
Dependencies: run-aggregates
Specifies the daily schedule for Job_AggregateGIM to start. The job will start in accordance with this schedule when aggregation is being controlled by the scheduler (in other words, the run-aggregates option is set to true). Between them, the aggregate-schedule and aggregate-duration options define daily time intervals within which Job_AggregateGIM will run continuously.
The schedule is defined in the format of a CRON expression that represents a set. The expression comprises two fields, which are separated by whitespace:
- The first field specifies minutes. Valid values are 0–59 and optional special characters (see below).
- The second field specifies hours. Valid values are 0–23 and allowed special characters.
The following special characters are allowed in the CRON expression:
- , (comma)—Separates items in a list. For example, specifying the first field (minutes) as 0,30,45 means the 0th, 30th, and 45th minutes of the hour.
- - (hyphen)—Defines a range. For example, specifying the first field (minutes) as 30-35 means every minute between the 30th and 35th minute of the hour, inclusive; this is the same as specifying 30,31,32,33,34,35.
- * (asterisk)—Indicates that the CRON expression will match for all values of the field. For example, specifying the second field (hours) as * means every hour in the day.
- / (forward slash)—Describes increments. For example, specifying the first field (minutes) as 0/10 means the 0th minute of the hour and every 10 minutes thereafter.
run-aggregates
Section: schedule
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Dependencies: None
Specifies whether the scheduler will manage the aggregation job, to run the aggregation engine inside the Genesys Info Mart process.
etl-end-time
Section: schedule
Default Value: 22:00
Valid Values: 00:00-23:59
Changes Take Effect: Immediately
Dependencies: run-scheduler, etl-start-time
Specifies the time of day, in 24-hour format, when the last ETL cycle can start running. If the value that you specify is before the ETL start time, the end time is for the next day (past midnight).
If etl-start-time=etl-end-time, the ETL cycle will run continuously.
etl-start-time
Section: schedule
Default Value: 06:00
Valid Values: 00:00-23:59
Changes Take Effect: Immediately
Dependencies: run-scheduler
Specifies the time of day, in 24-hour format, when the first ETL cycle starts running.
etl-frequency
Section: schedule
Default Value: 1
Valid Values: 0-1440
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the number of minutes that pass between the start times of each ETL cycle. If the amount of time that it takes to complete a cycle is shorter than the specified value, the next cycle is delayed until the time elapses. If the amount of time that it takes to complete a cycle is longer than the specified value, the next cycle is started immediately.
run-scheduler
Section: schedule
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Dependencies: None
Specifies whether to stop or start the scheduler. If the value of this option was set to true, so that the scheduler is currently scheduling jobs, and you change the value of this option to FALSE, the scheduler pauses, with no effect on any jobs that might already be running. If you then reset the value to TRUE, the scheduler resumes at the point at which it stopped.
timezone
Section: schedule
Default Value: GMT
Valid Values: Any valid Java time zone
Changes Take Effect: Immediately
Dependencies: None
Specifies the time zone in which the schedule is defined. Internally, Genesys Info Mart maintains the schedule in UTC time. For convenience, you can use this option to specify a local time zone that makes it easier for you to plan and manage the schedule. You can use any valid time zone that is supported by the version of the JRE that runs the Genesys Info Mart Server.
etl-start-date
Section: gim-etl
Default Value: Initialization date minus 30 days
Valid Values: Any date after 1970 in the format yyyy-mm-dd hh:mm:ss
Changes Take Effect: On database initialization
Dependencies: None
Introduced: 8.1.103.07
Modified: 8.1.4
Specifies the earliest date for which Genesys Info Mart considers IDB data for extraction in a new deployment or when the Info Mart database is re-initialized. IDB data that has timestamps earlier than the ETL start date is never extracted.
Operations-Related Options for Genesys Info Mart
Genesys Info Mart behavior and functionality are controlled by configuration option settings on the Genesys Info Mart Application and other supporting objects, such as DNs and Scripts.
The tables on this page list the configuration options that affect the operations of the Genesys Info Mart components. These options control the ETL process, and most of them apply in any environment. The tables group the options by functional area.
Review the options to identify the ones that are relevant to the Genesys Info Mart operation in your environment. In particular, decide:
- For new deployments, from which date you want Genesys Info Mart to start extracting data after the Info Mart database is initialized (see Startup).
- How you want Genesys Info Mart to schedule launching of ETL jobs (see Scheduling).
- How you want Genesys Info Mart to process error conditions during data transformation (see Transformation error handling).
- What logging level is sufficient for Genesys Info Mart Server (see Logging).
- How you want to adjust ETL behavior to meet requirements for data quality and data availability, given the characteristics of your environment and interaction flows (see Miscellaneous).
- Which, if any, of the redundant IDBs in an HA set you want to identify as preferred for the purposes of extraction (see Miscellaneous).
- How you want Genesys Info Mart to optimize Genesys Info Mart Server performance (see Performance tuning).
- What connection and other data source–related information Genesys Info Mart needs to extract data that comes through data streams other than Interaction Concentrator (see Alternative data streams).
- If you use the Data Export functionality, whether you need to modify the parameters of the export job (see Data export).
- What data-retention policies and other purge-related strategies you want to implement (see Database maintenance).
- What calendar dimensions you need for your reports (see Calendar maintenance).
Related Information
In addition to the operations-related options on this page, you might be interested in the following:
- Data-Processing Options for Genesys Info Mart — Affect the content and quality of data that is stored in the Info Mart database.
- Genesys Info Mart Aggregation-Related Options for GCXI and RAA — Enable aggregation in your deployment, if GCXI or RAA is installed.
Operations-Related Options Summary Tables
The following tables summarize the Genesys Info Mart operations-related options:
- Startup
- Scheduling
- Transformation error handling
- Logging
- Miscellaneous
- Performance tuning
- Alternative data streams
- Data export
- Database maintenance
- Calendar maintenance
Startup
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [gim-etl] | etl-start-date=Initialization date minus 30 days | In the Application object, configure the options on the Options tab. |
Scheduling
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [schedule] | timezone=GMT run-scheduler=false etl-frequency=1 etl-start-time=06:00 etl-end-time=22:00 run-aggregates=false aggregate-schedule=0 1 aggregate-duration=5:00 run-maintain=true maintain-start-time=03:00 run-update-stats=false update-stats-schedule=0/10 * run-export=false export-schedule=20 0/8 on-demand-migration=false |
In the Application object, configure the options on the Options tab. |
Transformation error handling
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [error-policy] | error-policy-call-mergecall-missing=resume error-policy-campaign-group-missing=exception |
In the Application object, configure the options on the Options tab. |
Logging
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [log4j] | log4j.appender.ConsoleLogger.Threshold=info logging-level=info |
In the Application object, configure the options on the Options tab. |
| [log] | verbose=standard standard=network |
Miscellaneous
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [gim-etl] | delayed-data-threshold=900 extract-data-stuck-threshold=28860 |
Note: The primary purpose of these options is to control aspects of Genesys Info Mart behavior that affect data quality or data availability. However, these options also have an impact on operating performance (for example, because they influence the size of merge tables or staging tables).
In the Application object, configure the options on the Options tab. |
| [gim-transformation] | pipeline-timeout-in-hours=1 | In the Application object, configure the option on the Options tab. | |
| Info Mart and extraction DAPs | [gim-etl] | geo-location=“” | In the DAP object, configure the option on the Options tab. |
Performance tuning
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [gim-etl] | extract-data-cfg-facts-chunk-size=90000 extract-data-chunk-size=900 |
In the Application object, configure the options on the Options tab. |
| [gim-transformation] | chunk-size=7200 |
Alternative data streams
Use the following configuration options to specify data sources and to manage data that does not come through ICON.
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [elasticsearch-<data-source-id>] | client=off g:index-interval=No default value |
In the Application object, configure the options on the Options tab. Genesys Info Mart must predefine the mapping of data from Elasticsearch and Kafka. Support for data from these alternative data streams is limited to certain applications, some of which are currently available only in cloud deployments. |
| [kafka-<cluster-name>] | bootstrap.servers=No default value g:topic:<topic-name>=No default value | ||
| [gim-transformation] | kafka-idle-timeout=10 seconds |
Data export
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [gim-export] | chunk-size-seconds=86400 days-to-keep-output-files=14 |
In the Application object, configure the options on the Options tab. |
Database maintenance
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [gim-etl] | days-to-keep-gidb-facts=14 days-to-keep-cfg-facts=400 or days-to-keep-gim-facts For partitioned databases only:
partitioning-interval-size-gidb=86400 |
In the Application object, configure the options on the Options tab. |
Calendar maintenance
| Configuration Object | Section Name | Option Name and Default Value | Comments |
|---|---|---|---|
| Genesys Info Mart Application | [date-time]
For custom calendars: |
date-time-table-name=DATE_TIME date-time-tz=GMT |
In the Application object, configure the options on the Options tab. |