gim-etl Section
- aggregation-engine-class-name
- days-to-keep-active-facts
- days-to-keep-cfg-facts
- days-to-keep-deleted-annex
- days-to-keep-discards-and-job-history
- days-to-keep-gdpr-history
- days-to-keep-gidb-facts
- days-to-keep-gim-facts
- delayed-data-threshold
- etl-start-date
- extract-data-cfg-facts-chunk-size
- extract-data-chunk-size
- extract-data-max-conn
- extract-data-stuck-threshold
- extract-data-thread-pool-size
- extract-last-second
- job-run-watchdog-timeout
- link-msf-userdata-mm
- link-msf-userdata-voice
- max-call-duration
- max-camp-group-session-duration-in-hours
- max-camp-group-state-duration-in-hours
- max-chain-processing-duration-in-hours
- max-chunks-per-job
- max-msfs-per-irf
- max-parties-per-call
- max-session-duration-in-hours
- max-state-duration
- max-thread-duration-after-inactive-in-days
- max-time-deviation
- memory-threshold
- merge-chunk-size
- merge-failed-is-link-timeout
- partitioning-ahead-range
- partitioning-interval-size-gidb
- partitioning-interval-size-gidb-mm
- partitioning-interval-size-gidb-ocs
- partitioning-interval-size-gim
- purge-thread-pool-size
- purge-transaction-size
- q-answer-threshold-voice
- q-short-abandoned-threshold-voice
- short-abandoned-threshold
- sm-resource-state-priority
- user-event-data-timeout
Use this configuration section to set general options.
aggregation-engine-class-name
Default Value: none
Valid Values: Any string
Changes Take Effect: On restart
Dependencies: None
Specifies the class name of the aggregation package, if it is installed. If your deployment uses the Genesys historical reporting presentation layer—Genesys CX Insights (GCXI)—or the separately installed Reporting and Analytics Aggregates (RAA) package, specify the following value: "GIMAgg.GimInterfaceImpl.AggregationImpl"
For more information, see the Reporting and Analytics Aggregates Deployment Guide.
days-to-keep-active-facts
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.
The following description applies to behavior starting with release 8.1.1. For the benefit of Genesys Info Mart 8.1.0 customers, Appendix E in the Genesys Info Mart 8.1 Deployment Guide provides information about purge behavior in previous 8.x releases.
Artificial Termination of Long-Living Interactions
This functionality is intended primarily to prevent problems in deployments that include aggregation—for example, when updates to long-living multimedia interactions trigger unnecessary re-aggregation, which results in overflow errors.
If an interaction is still active when the days-to-keep-active-facts period expires, the transformation job terminates the interaction artificially in fact tables. Any activity that is related to this interaction that occurs after termination is discarded.
Genesys Info Mart generates log message 55-20123 when it terminates an interaction artificially. You can set an alarm on this message.
Purging
Starting with release 8.5.015.19, this option plays no role in determining purge thresholds. In releases earlier than 8.5.015.19, the relationship of days-to-keep-active-facts to days-to-keep-gidb-facts affects the purge threshold for multimedia fact data in GIDB. In releases earlier than 8.5.015.19:
- If days-to-keep-active-facts is smaller than days-to-keep-gidb-facts, Genesys Info Mart terminates the interaction artificially when the days-to-keep-active-facts interval expires, then subsequently purges the terminated interaction from GIDB when the days-to-keep-gidb-facts interval expires and from the dimensional model when the days-to-keep-gim-facts interval expires.
- If days-to-keep-active-facts is greater than or equal to days-to-keep-gidb-facts but smaller than days-to-keep-gim-facts, Genesys Info Mart terminates the interaction artificially when the days-to-keep-active-facts interval expires, then purges the terminated interaction from GIDB in the next run of the maintenance job and from the dimensional model when the days-to-keep-gim-facts interval expires.
Starting with release 8.1.2, Genesys Info Mart requires days-to-keep-active-facts to be smaller than days-to-keep-gim-facts. For earlier releases, Genesys strongly recommends that you configure days-to-keep-active-facts to be smaller than days-to-keep-gim-facts.
days-to-keep-cfg-facts
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-deleted-annex
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.
For example, with the default value (2 days), if Job_MaintainGIM is running on August 4, 2014, the job will purge *_ANNEX records that terminated (in other words, the configuration setting on the object’s Annex tab was deleted) before August 2, 2014.
The default value of days-to-keep-deleted-annex is small, because there is likely little reason to retain deleted data for significant periods of time. The major reason that Genesys Info Mart provides *_ANNEX data is to support GCXI visibility controls, and GCXI uses only active *_ANNEX data for this purpose.
days-to-keep-discards-and-job-history
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.
The discard tables are Staging tables that store operational data that the transformation job was unable to process—for example, voice interaction data with unresolved IS-Links, or Configuration details records with missing configuration objects. The audit and history tables are Control tables that store information about data lineage and about ETL processing activity. Information in the discard, audit, and history tables is useful for troubleshooting.
Records in the discard, audit, and history tables are purged based on the timestamp of the ETL processing event—ETL_TS for the discard (Staging) tables and CREATED_TS for the audit and history (Control) tables. 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.
For example, if Job_MaintainGIM is running on August 23, 2011 (day 235 of the year) and days-to-keep-discards-and-job-history=600, Job_MaintainGIM will purge all records in the discard, audit, and history tables that were written by instances of the ETL jobs that ran before January 1, 2010 (day 1 of the previous year).
days-to-keep-gdpr-history
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-gidb-facts
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.
days-to-keep-gim-facts
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.
For voice and multimedia interactions in release 8.1.1, this option specifies the retention period for completed 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.
- Genesys Info Mart does not enforce a limit on the length of the retention period. However, Genesys strongly recommends against setting days-to-keep-gim-facts, and likewise days-to-keep-active-facts, to an excessively large value (for example, thousands of days). To avoid performance issues or job failures when Genesys Info Mart operates against an excessively large Info Mart database, be realistic about your requirements and available database resources, and apply best practices and recommendations from your RDBMS vendor. If you choose a very long retention period, you must carefully choose and tune the storage used for the Info Mart database; also carefully consider settings for partition size and other database- and performance-related configuration options, as well as parameters on the RDBMS side.
- By definition, all voice interaction data in the dimensional model relates to completed interactions. In release 8.1.1, as the Dimensional Model (releases earlier than 8.1.2) example shows, active multimedia interactions can delay the purging of completed interactions if the period of time for which multimedia interactions can remain active in your deployment (days-to-keep-active-facts) is greater than days-to-keep-gim-facts.
- Starting with release 8.1.2, Genesys Info Mart no longer permits this configuration. In 8.1.1 deployments, Genesys strongly recommends against this configuration, particularly in deployments that include RAA.
How Purge Options Work
To illustrate how various days-to-keep-* options combine to determine when data will be purged, the following tables provide examples of different scenarios for GIDB and the dimensional model, respectively. There are separate examples for releases before and after 8.1.2, because of significant behavioral differences.
Purge examples for 8.1.2 and later releases
| Scenario | Start Time of Facts to Be Purged |
|---|---|
|
Voice interactions, agent activity, Outbound Contact facts: November 21, 2020, or earlier Multimedia interactions:
|
| Scenario | Start Time of Facts to Be Purged |
|---|---|
|
All facts: November 1, 2019, or earlier The oldest timestamp for artificially terminated multimedia interactions is November 5, 2020. |
Purge examples for releases earlier than 8.1.2
| Scenario | Start Time of Facts to Be Purged | |
|---|---|---|
| ||
| 1 | A previously active e-mail interaction, which started on May 5, 2012, was artificially terminated on June 4, 2012. Other e-mail interactions, which started on May 6, 2012, and later, remain active. | Voice interactions, agent activity, Outbound Contact facts: May 21, 2012, or earlier Multimedia interactions: |
| 2 | The earliest active fact relates to an e-mail interaction that started on May 27, 2012. | All facts: May 5, 2012, or earlier |
| Scenario | Start Time of Facts to Be Purged | |
|---|---|---|
| ||
| 1 | The oldest previously active e-mail interaction, which started on May 5, 2012, was artificially terminated on June 4, 2012. | All facts: May 1, 2011, or earlier |
Important The following configuration is not supported starting with release 8.1.2 and is strongly discouraged in earlier releases.
| ||
| 1 | The oldest previously active e-mail interaction, which started on October 12, 2010, was artificially terminated on June 4, 2012. | Agent activity, Outbound Contact facts: May 1, 2011, or earlier Voice and multimedia interactions: |
| 2 | The earliest active fact relates to an e-mail interaction that started on June 20, 2011. | All facts: May 1, 2011, or earlier |
delayed-data-threshold
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.
For more information about appropriate actions, see the Troubleshooting information in the Genesys Info Mart Operations Guide.
etl-start-date
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.
The option, which was introduced in release 8.1.103.07, is used only when Job_InitializeGIM initializes the database. If the etl-start-date option is not specified, the earliest starting point for Genesys Info Mart processing is IDB data that has timestamps 30 days prior to the Info Mart database initialization.
The main purpose of the option is to pre-empt performance and maintenance issues when Genesys Info Mart is introduced into a deployment with much older existing IDB data. Specifying the ETL start date enables users to:
- Shorten the backlog of IDB data if they do not need to include all of the old data in their reporting.
- In deployments with a partitioned Info Mart database, specify the starting point for creating partitions, which is important for proper partitioning.
Starting with release 8.1.4, Genesys Info Mart ignores this option value for Configuration details; after the database has been initialized or re-initialized, Genesys Info Mart extracts all cfg data going back as far as 2010, regardless of the value of etl-start-date.
extract-data-cfg-facts-chunk-size
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.
For example, if you set the value of this option to 90000, Genesys Info Mart extracts 25 hours (90,000 seconds) of available configuration relationship fact data. When any nonpositive value is set (for example, 0 or -1), data for all available time intervals is extracted in one chunk.
This option enables you to configure a larger extraction window for configuration relationship data than for other types of data. This increases the likelihood that all available configuration relationship data will be extracted and transformed in one extraction cycle, so that the configuration relationship data is available to support the transformation of other data.
This option does not affect extraction and transformation of configuration object data. All available configuration object data is extracted in a single extraction cycle.
extract-data-chunk-size
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.
The extraction job processes only one chunk of data during each extraction cycle. In other words, the value of this option sets the batch size for an iteration of the ETL cycle.
extract-data-max-conn
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.
For example, if Genesys Info Mart uses DAP1 to access IDB1 and DAP2 to access IDB2, and if extract-data-max-conn=128, then the extraction job will open up to 128 connections through DAP1 and up to 128 connections through DAP2 (in other words, up to a total of 256 connections), as required, for concurrent extraction of data from both IDBs.
Increasing the value of this option reduces the amount of time that is required for the extraction job, but it increases CPU and memory requirements, especially if database links are not used. The optimal value of this option depends on the operating system, hardware (such as RAM and the number of CPUs), and the number of IDBs in the environment. You must also consider ICON requirements for RDBMS resources when you set this limit.
extract-data-stuck-threshold
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.
The value of this option sets the stuck data timeout for the extraction windows for the Voice, Multimedia, and Outbound Contact data domains. However, the actual time ranges of the extraction windows and HWMs for each data domain might be different.
Setting this parameter to too high a value can affect performance and cause delay of data that is available for reporting. For example, if data from a T-Server is not available—for example, because of network delays in a multi-site deployment or, even in a single-site deployment, if there is a problem within ICON so that, say, user data from the gud provider is behind call data from the gcc provider—Genesys Info Mart does not transform data until data from that T-Server becomes available or until this timeout has expired.
On the other hand, setting this parameter to too low a value might cause data to be skipped if, after the stuck data threshold expires, the extraction high-water mark (HWM) advances past data that was delayed.
While delayed data from an active data source does not delay extraction of data from other data sources in that domain, missing data from a delayed data source can delay transformation. It is important, therefore, to identify and fix extraction delays as soon as possible. See the description of the delayed-data-threshold option for related information.
extract-data-thread-pool-size
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.
Increasing the value of this option reduces the amount of time that is required for the extraction job, but it increases CPU and memory requirements. (At a rough estimate, each additional worker thread requires an additional 180 MB of RAM.) The optimal value of this option depends on the operating system, hardware (such as RAM and the number of CPUs), and the number of IDBs in the environment.
extract-last-second
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Dependencies: None
Discontinued: 8.1.4
Warning! This option must be set to false in a production environment.
Specifies whether Genesys Info Mart extracts data from the last second of the specified time interval into the extracted data chunk. In a lab environment, setting this option to true speeds up data validation. If you are extracting the last second of data in a lab environment, make sure that all data from the executed test scenario is stored into IDB before Genesys Info Mart runs the extraction job.
In a production environment, setting this option to true might result in lost data. For example, the ETL might be extracting data at time t1 for the time interval [t0–t1], while the data source is still producing events that have a timestamp of t1; at the next extraction, Genesys Info Mart will consider that all data that has t1 timestamps has been extracted, and the last t1 data will be lost.
The option was discontinued in release 8.1.4 because of issues with missing data. To speed up data validation in a lab environment, you can achieve a similar result by setting the ICON NoData timestamp (specified by the ICON dss-no-data-tout option) to a small value, thus minimizing the processing delays that Genesys Info Mart provides to account for data-source inactivity.
job-run-watchdog-timeout
Default Value: 1
Valid Values: A positive integer (meaning hours) or duration in ISO 8601 format without specifying year and month.
Changes Take Effect:
Introduced: 8.5.116.53
Specifies the timeout in hours after which Genesys Info Mart logs alarmable message with stack trace if job continues to run.
An example valid value: in ISO 8601 format, PT1H30M means 1 hour and 30 minutes.
link-msf-userdata-mm
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Introduced: 8.5.003
Related Options: link-msf-userdata (DN) and link-msf-userdata (Script)
Specifies whether associated user data will be stored in mediation segment facts (MSFs) for multimedia interactions that are in mediation.
- true—MSFs for multimedia interactions will store associated user data.
- false—MSFs for multimedia interactions will not store associated user data.
Setting this option to true enables user data storage for all mediation resources for multimedia interactions. The value of the link-msf-userdata option, if specified on individual DN or Script objects, overrides this application-level link-msf-userdata-mm option.
link-msf-userdata-voice
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.003
Related Options: link-msf-userdata (DN)
Specifies whether associated user data will be stored in mediation segment facts (MSFs) for voice interactions that are in mediation.
- true—MSFs for voice interactions will store associated user data.
- false—MSFs for voice interactions will not store associated user data.
Setting this option to true enables user data storage for all mediation resources for voice interactions. The value of the link-msf-userdata option, if specified on individual DN objects, overrides this application-level link-msf-userdata-voice option.
max-call-duration
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.
This option controls the following timeouts:
- The stuck-link threshold for merge processing of voice interactions — The option specifies the amount of time that the merge operation will wait for IS-Link information from another site, before it considers the IS-Link to be stuck. An unpaired link is considered to be stuck if the link initiation timestamp in the G_IS_LINK merge table record exceeds the stuck-link threshold calculated from the earliest extraction high-water mark.
- The stuck data threshold for merge processing of voice interactions — The option determines the amount of time that the merge operation will wait for G_IR and G_CALL records. To ensure that the merge procedure does not finalize merge processing prematurely with missing data, the stuck data threshold for merge is double the stuck-link threshold (2 * max-call-duration).
- ImportantFor voice interactions, Genesys Info Mart extracts Interaction Records (IRs) only for completed calls. Resolution of stuck calls is controlled by the ICON application.
- The limit for waiting for After Call Work (ACW) before transforming voice interaction data.
- For user data with propagation rules other than CALL, the limit for linking user data to IRFs for multimedia interactions — The option specifies the amount of time, starting from the beginning of the IRF, that the transformation job allows for user data to link to the IRF.
- In an HA deployment in which geolocation is a consideration, the amount of time that Genesys Info Mart will wait after a good ICON provider session has been re-established on the local IDB following a data disruption, before the ETL switches back to extract Voice details from the local IDB.
Because this option affects a number of aspects of Genesys Info Mart functioning during extraction and transformation of voice and multimedia interactions, be aware that there are potential data implications if you change the option value.
max-camp-group-session-duration-in-hours
Default Value: 168
Valid Values: 1-10000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the amount of time, in hours, after which Genesys Info Mart ends active campaign group sessions if the transformation process encounters a campaign session row in IDB’s GO_Campaign table that has no terminated time.
If you change the value of this option, the new option value is not applied to previously loaded facts.
max-camp-group-state-duration-in-hours
Default Value: 168
Valid Values: 1-10000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the amount of time, in hours, after which Genesys Info Mart ends campaign group states if the transformation process has not extracted a stopped row that brackets a previously extracted started row from the IDB GO_CampaignHistory table.
If you change the value of this option, the new option value is not applied to previously loaded facts.
max-chain-processing-duration-in-hours
Default Value: 8
Valid Values: 0 or any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None. Applies only when the Info Mart database is partitioned.
Specifies the maximum expected duration, in hours, of the processing of a single chain by Outbound Contact Server (OCS). Chain processing starts when the chain is loaded from the OCS database and ends when the chain is unloaded. For more information, see the section about the Chain Model in the chapter about integrating with Outbound Contact in the Interaction Concentrator 8.x User’s Guide.
The option affects Genesys Info Mart behavior only when the Info Mart database is partitioned.
On partitioned databases, Genesys Info Mart will not create CONTACT_ATTEMPT_FACT (CAF) records for activity that occurs after the maximum expected duration of chain processing. If the value of this option is 0 (zero), Genesys Info Mart will use the value of max-camp-group-session-duration-in-hours.
The max-chain-processing-duration-in-hours option was introduced in release 8.1.2, and the default value was set to be consistent with Genesys Info Mart behavior in previous 8.x releases. You can safely increase the value of this option up to the maximum length of campaigns in your deployment (the value of max-camp-group-session-duration-in-hours). However, increasing the value means that Genesys Info Mart will have more Outbound Contact data to process in each ETL cycle. Therefore, for performance reasons, the optimal value for max-chain-processing-duration-in-hours is the smallest value that matches actual patterns of activity in your deployment (in other words, the smallest value that does not result in missing CAF records).
max-chunks-per-job
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.
max-msfs-per-irf
Default Value: 50
Valid Values: 10-10000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.1.401.02
Specifies the limit for the number of MSF records that are associated with a given multimedia interaction that will be represented in the Info Mart database. When the number of MSF records associated with a single IRF record exceeds the limit, the transformation job processes only the first n mediation DNs and the last n mediation DNs in the interaction, where n = max-msfs-per-irf/2. In this way, ETL performance avoids being degraded by huge numbers of MSF records for unsuccessful routing attempts for "stuck strategy" scenarios.
The first n mediation records for a given interaction are processed by the transformation job and populated in the MSF table as they occur. The last n records are postponed until an associated IRF record has been created.
The option does not affect the mediation durations that are reported in the IRF (QUEUE_DURATION, ROUTING_POINT_DURATION, MEDIATION_DURATION, and PREVIOUS_MEDIATION_DURATION); all these metrics correctly report the full overall mediation time.
Log message number 55-20120 is generated when the max-msfs-per-irf limit is exceeded, triggering the behavior to abbreviate the representation of unsuccessful routing attempts in the Info Mart database. You can set an alarm on the log message, to prompt you to investigate strategies that might be inappropriate for your deployment.
max-parties-per-call
Default Value: 100
Valid Values: 50-10000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.1.103.03
Discontinued: 8.1.4
Specifies the limit for the number of parties or virtual queues that were associated with the same multimedia interaction that will be represented in the Info Mart database. The option limits the amount of data that will be selected for transformation from the GIDB party and virtual-queue tables. When the number of parties or virtual queues in an interaction exceeds the limit, the transformation job processes only the first n parties or virtual queues and the last n parties or virtual queues in the interaction, where n = max-parties-per-call/2. In this way, the transformation job avoids being overwhelmed by huge numbers of party and virtual-queue records for unsuccessful routing attempts for “stuck strategy” scenarios.
The option was discontinued in release 8.1.4 because improvements in incremental transformation removed the need to enforce a limit on the number of records to be read in each chunk.
The option enables you to control behavior that was not configurable before release 8.1.103.03. Log events (message numbers 55-20120, 55-20121, or 55-20122) identify when excessive numbers of Party, Party History, or Virtual Queue records, respectively, trigger the behavior to limit the number of parties or virtual queues to process. The default value of max-parties-per-call triggers the behavior at lower limits than in releases earlier than 8.1.103.03. In the earlier 8.1 releases, the limits were 1000 parties and 500 virtual queues. (The maximum number of Party History records is a much higher, theoretical limit.)
Genesys recommends that you set an alarm on the log messages, to prompt you to locate and fix inappropriate routing strategies that result in huge numbers of records in IDB tables.
Starting with release 8.1.4, while Genesys Info Mart continues to abbreviate the representation of unsuccessful routing attempts in the Info Mart database, log message numbers 55-20120, 55-20121, and 55-20122 are no longer generated.
max-session-duration-in-hours
Default Value: 24
Valid Values: 1-10000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.1.3 (minimum valid value changed)
Specifies the maximum duration, in hours, for a resource session in the SM_RES_SESSION_FACT table. Genesys Info Mart will end a resource session for an agent/media type after this timeout elapses if the session end has not been extracted from the IDB GX_SESSION_ENDPOINT table.
For related information, see the description of max-state-duration. See also the discussion about long-duration sessions or states on the Populating Agent Activity Data page in the Genesys Info Mart User’s Guide.
If you change the value of this option, the new option value is not applied to previously loaded facts.
In releases earlier than 8.1.3, the minimum valid value of this option was 0.
max-state-duration
Default Value: 14400
Valid Values: Any integer greater than 900
Changes Take Effect: On the next ETL cycle
Dependencies: No direct dependency, but it would not be meaningful to set max-state-duration > (value of max-session-duration-in-hours expressed in seconds)
Introduced: 8.1.3
Specifies the maximum duration, in seconds, for an agent state in the SM_RES_STATE_FACT table. Genesys Info Mart ends the agent state if the IDB data does not show the agent transitioning to a different state by the time that the maximum duration (the state timeout) expires. The option enables you to:
- Improve performance of agent-activity transformation by reducing the amount of active data that Genesys Info Mart must maintain and by limiting the period of time for which lookups must be performed for agent-activity data.
- Recognize in a timely manner when an agent session has gone inactive.
The option was introduced in release 8.1.3.
In releases earlier than 8.1.3, when agents forgot to log out, the reported durations of sessions and states might be misleadingly high. While the max-session-duration-in-hours option puts a limit on the overall session duration, max-state-duration provides the ability to detect when a session has gone inactive. If a state times out and there are no other active states, Genesys Info Mart can conclude that there really is no agent activity within the session.
The default value of 14400 seconds (4 hours) for max-state-duration strikes a balance between considering long periods of idleness (no agent state transitions) to be normal behavior and realizing the performance benefits mentioned above.
Consider increasing the value of max-state-duration if it is normal for many of your agents to remain idle (no agent state transitions at all) for significant periods of time, and you do not want long periods of idleness to indicate that the agent session has gone inactive.
Consider decreasing the value of max-state-duration if it is not normal for your agents to remain idle for significant periods of time, and you want to recognize that a session has gone inactive after a shorter period of idleness. Additionally, decrease the value if you prefer to realize more of the performance benefits.
Particularly in large contact centers with hundreds or thousands of agents, Genesys recommends that you set the value of max-state-duration to the smallest value that is consistent with patterns of agent behavior and session-reporting requirements in your deployment.
For related information, see the discussion about long-duration sessions or states in the chapter about populating Genesys Info Mart data in the Genesys Info Mart User’s Guide.
If you change the value of this option, the new option value is not applied to previously loaded facts.
max-thread-duration-after-inactive-in-days
Default Value: 31
Valid Values: Any positive integer greater than days-to-keep-active-facts
Changes Take Effect: On the next ETL cycle
Dependencies: populate-thread-facts=true
Introduced: 8.1.1
Specifies the maximum duration, in days, of an interaction thread after all of the interactions that belong to the thread have terminated. After the timeout expires, Genesys Info Mart considers the thread to be closed.
If a new, related interaction (for example, an InboundCustomerReply to an agent’s OutboundReply) begins after the timeout has expired, the interaction is considered to be the root interaction for a new thread. If a new, related interaction begins before the timeout has expired, the thread remains active; Genesys Info Mart will not consider the thread to be closed until the configured amount of time passes after all interactions in the thread (including this new interaction) have terminated.
This option affects how Genesys Info Mart identifies which interactions are associated with the same threads and, therefore, affects the thread-related data that is reported in IF and IRF records. For performance reasons, Genesys recommends that you set this option to the smallest value that is consistent with interaction patterns in your deployment, so that Genesys Info Mart does not have to maintain memory of inactive threads for unnecessarily long periods of time.
This option does not affect the chat thread reporting feature introduced in release 8.5.014.09 for Genesys Engage cloud deployments with Advanced Chat.
For more information about how interaction threads are identified, see the subsection about interaction threads, in the section about populating interaction data, in the Genesys Info Mart User’s Guide for your release.
max-time-deviation
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.
Genesys recommends the following relationship between the value of this option and the Advanced Disconnect Detection Protocol (ADDP) timeout, which is the Local Timeout parameter configured for ADDP connections to data sources on the Connections tab of the ICON Application:
[(ADDP Local Timeout) * 2] + (actual maximum difference in time synchronization between hosts) <= max-time-deviation
In HA deployments, max-time-deviation is used for reliable analysis of the “no data” information in IDB; (NoData – max-time-deviation) is considered to be reliable for all data sources for a particular ICON provider. For more information about the ICON NoData indicator, see the section about determining IDB availability in the Interaction Concentrator User’s Guide.
In releases earlier than 8.1.4, the minimum valid value of this option was 0.
memory-threshold
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.
merge-chunk-size
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.
Consider the following guidelines:
- The option value should be large enough that it does not require transformation of an unnecessarily large number of data chunks and, therefore, does not interfere with normal processing of one chunk of extracted data. As a rule of thumb, allow 200000 rows for a call rate of 100 calls per second (cps).
- The option value should be small enough that it protects the transformation job from running out of memory. For example, for an environment with 8 GB of RAM dedicated to Genesys Info Mart, allow a number of rows that corresponds to 1 million root G_IR records. (Every root G_IR record corresponds to one interaction fact.)
merge-failed-is-link-timeout
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.
The default value (0), which preserves legacy behavior, means that the merge operation will process unpaired failed links immediately, without waiting for the other side of the failed IS-Link. As a result of the partial merge, the transformation job might encounter dangling links.
partitioning-ahead-range
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.
Example
If partitioning-interval-size-gidb=86400 (1 day), partitioning-interval-size-gim=604800 (1 week), and partitioning-ahead-range=14, Job_MaintainGIM will create as many additional partitions as necessary to provide partitions for GIDB, Control (in release 8.1.2 and later), and Info Mart fact tables up to 14 days ahead. If Job_MaintainGIM runs daily, this means that:
- For GIDB tables, each run of Job_MaintainGIM will create one new partition of size 1 day, for the fourteenth day. (Previous runs will have created partitions for the other days.)
- For Info Mart fact tables, as well as for Control tables, the maintenance job will create one new partition of size 7 days at the start of each week. (A previous run will have created a partition for the other week.)
- If the value of partitioning-ahead-range is not a multiple of partitioning-interval-size-gim, the maintenance job will create a new partition only when the last day of the partitioning ahead range falls in a week for which a partition has not yet been created. For example, if partitioning-interval-size-gim=604800 (7 days) but partitioning-ahead-range=10, two new partitions will be created on the very first run of Job_MaintainGIM, and the next partition will be created on the fifth run.
To guarantee that partitions are always available for use by the ETL, ensure that run-maintain is set to true (the default value).
This option applies only in deployments that use partitioning.
partitioning-interval-size-gidb
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).
This option applies only in deployments that use partitioning.
partitioning-interval-size-gidb-mm
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).
Transformation performance is optimal when, on the one hand, partitions are large enough that data that is being actively used is in the fewest number of partitions while, on the other hand, the partitions are small enough that their indexes can fit into the cache.
partitioning-interval-size-gidb-ocs
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).
Transformation performance is optimal when, on the one hand, partitions are large enough that data that is being actively used is in the fewest number of partitions while, on the other hand, the partitions are small enough that their indexes can fit into the cache.
partitioning-interval-size-gim
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).
This option applies only in deployments that use partitioning.
purge-thread-pool-size
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
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.
For example:
- If there are 150,000 records in a particular table that are eligible for purging and purge-transaction-size=100000, Job_MaintainGIM will delete and commit 100,000 records in one transaction and 50,000 records in a separate transaction.
- If there are 90,000 records in one table, 10,000 records in another table, and purge-transaction-size=100000, Job_MaintainGIM will delete and commit 90,000 records from the first table in one transaction and 10,000 records from the second table in a separate transaction.
q-answer-threshold-voice
Default Value: 60
Valid Values: 1-10000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the default duration, in seconds, that is used on all configured queues as a target time to answer voice interactions that were distributed by virtual queues or ACD queues.
Genesys Info Mart uses this value unless, in the interface you use for configuration, you configure an option that has the same name on an individual Virtual Queue or ACD Queue DN object or on the Switch object.
For more information about setting queue-specific thresholds, see Configuring a DN for ICON and Genesys Info Mart reporting in the Genesys Info Mart Deployment Guide.
If you change the value of this option, the new option value is not applied to previously loaded facts.
For similar options that control equivalent thresholds for multimedia interactions, see the gim-etl-media-chat Section and the gim-etl-media-email Section.
q-short-abandoned-threshold-voice
Default Value: 10
Valid Values: 1-1000
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.5.003
Specifies the maximum duration of mediation, in seconds, that is used on all configured queues to indicate that an interaction that was abandoned while in a queue should be considered a “short” abandon. Genesys Info Mart uses this value to determine the state of SHORT_ABANDONED_FLAG in the MEDIATION_SEGMENT_FACT (MSF) row for voice interactions that are abandoned in a virtual queue or ACD queue.
Genesys Info Mart uses this value unless, in the interface you use for configuration, you configure an option that has the same name on a Switch object or, starting with release 8.5.003, an individual virtual queue or ACD queue DN object. In releases earlier than 8.5.003, this value could not be set on an individual DN object.
If you change the value of this option, the new option value is not applied to previously loaded facts.
For similar options that control equivalent thresholds for multimedia interactions, see the gim-etl-media-chat Section and the gim-etl-media-email Section.
short-abandoned-threshold
Default Value: 10
Valid Values: 0-60
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies the minimum duration, in seconds, of an abandoned voice interaction in order for it to be considered truly abandoned. Genesys Info Mart uses this value to determine the state of SHORT_ABANDONED_FLAG in the IRF row.
If you change the value of this option, the new option value is not applied to previously loaded facts.
For similar options that control equivalent thresholds for multimedia interactions, see the gim-etl-media-chat Section and the gim-etl-media-email Section.
sm-resource-state-priority
Default Value: ACW, NOT_READY, BUSY, READY
Valid Values: ACW, BUSY, NOT_READY, READY (all four in any order)
Changes Take Effect: On the next ETL cycle
Dependencies: populate-sm-resource-activity
Modified: 8.5.002
Specifies a list of the state names—BUSY, ACW, NOT_READY, or READY—in order of decreasing priority. When an agent simultaneously has different states on different DNs for a given media type, Genesys Info Mart uses this list to determine which state has the highest priority when determining a summarized state to store in the SM_RES_STATE_FACT or SM_RES_STATE_REASON_FACT table. Starting with release 8.5.002, Genesys Info Mart uses this list to evaluate the priority for media-neutral states (the agent's state across all media types), as well, if the populate-media-neutral-sm-facts option is set to true.
If you change the value of this option, you must specify all four values, in the changed order. If you do not specify all the values, Genesys Info Mart considers the option value to be invalid and uses the default value instead.
If you change the value of this option, the new option value is not applied to previously loaded facts.
user-event-data-timeout
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.
The option value also has a role in:
- Enabling complete ACW information in IRF records.
- Starting with release 8.5.014, controlling the amount of time for which Genesys Info Mart will wait for Focus Time information for multimedia interactions after the agent leaves the interaction.
Therefore, consider your interaction topologies carefully before modifying the value of this option.
The behavior of this option changed between release 8.1.0 and release 8.1.1. In release 8.1.0, the timeout was calculated from the start of the call.
This option is not applicable to UserEvent data related to Genesys Callback.