View table: PEConfigOption

• 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 matches 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.

Examples

The following values for aggregate-schedule illustrate sample schedules:

• 0 1 means that the aggregation job launches once a day at 01:00.
• 30 0,3/2 means that the aggregation job launches every day at 00:30, 03:30, and every 2 hours after that for the rest of the day.

  This schedule assumes that the value of aggregate-duration is 02:00 or less. The scheduler does not launch a new instance of Job_AggregateGIM while an existing instance is running. For aggregation to run on the specified schedule, the value of aggregate-duration must not exceed the intervals between scheduled start times.

• 30 * means that the aggregation job launches every hour during the day on the half-hour (00:30, 01:30, 02:30, and so on), assuming that the value of aggregate-duration is 01:00 or less.

Genesys recommends against configuring a schedule that has the aggregation job running in a series of short bursts—for example, aggregate-schedule=30 * and aggregate-duration=00:15. When the time specified by aggregate-duration expires, the scheduler immediately stops the aggregation job, even if it is in the middle of processing a batch of data.

If you want Job_AggregateGIM to run continuously for 24 hours a day, without any breaks for maintenance activities (which is not recommended), set aggregate-schedule=0 0 and aggregate-duration=24:00.

• http://www.java2s.com/Tutorial/Java/0120__Development/GettingallthetimezonesIDs.htm
• http://en.wikipedia.org/wiki/Zone.tab

For example, with the default value (2 days), if Job_MaintainGIM is running on September 4, 2022, the job purges *_ANNEX records that terminated (in other words, the configuration setting on the object’s Annex tab was deleted) before September 2, 2022.

Genesys expects the value of days-to-keep-gidb-facts to be less than 30. Although many GIDB tables contain personally identifiable information (PII), Genesys Info Mart does not include most GIDB tables in General Data Protection Regulation (GDPR) processing.

By definition, all voice interaction data in the dimensional model relates to completed interactions.

How Purge Options Work

To illustrate how various days-to-keep-* options combine to determine when data is purged, the following tables provide examples of different scenarios for GIDB and the dimensional model, respectively.

Purge examples

By default, the value of etl-frequency is much smaller than the value of extract-data-chunk-size. Genesys recommends that you retain this relationship, to minimize data latency. For example, say that extract-data-chunk-size=900 (15 minutes), etl-frequency=1, and all data from the last chunk has been processed; when the next ETL cycle starts 1 minute later, there is only 1 minute’s worth of new data, and this can be processed very quickly. Alternatively, if there is a backlog of data, and it takes less than 15 minutes to process a 15-minute chunk, the next ETL cycle starts almost immediately, to continue catching up.

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.

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.

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.

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. Genesys Info Mart adjusts automatically for the floating fiscal year. For example, if simple-week-numbering=false, fiscal-year-start=3-1, and first-day-of-week=1, then:

• Fiscal year 2012 starts on February 26.
• Fiscal year 2013 starts on February 24.
• Fiscal year 2014 starts on February 23.

This option requires that fiscal-year-week-pattern be set to a valid pattern.

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, Genesys Info Mart uses max-time-deviation 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 example, if simple-week-numbering=false, first-day-of-week=2, and January 1 of the new year is on a Friday, there are 3 days from the new year in the week that starts on Monday, December 28. Therefore:

• If the value of this option is set to 1, the calendar counts the first week of the new year as starting on Monday, December 28.
• If the value of this option is set to 4, the week that starts on Monday, December 28, is assigned to the previous year, and the calendar counts the first week of the new year as starting on Monday, January 4.

The value of false preserves previous Genesys Info Mart behavior, which requires you to run Job_MigrateGIM manually before ETL functioning resumes if Genesys Info Mart has entered the migration state.

Enabling on-demand migration is suitable only if you always want to apply schema updates immediately, without review and without controlling the timing of the schema update or required system preparation.

Example

If partitioning-interval-size-gidb=86400 (one day), partitioning-interval-size-gim=604800 (one week), and partitioning-ahead-range=14, Job_MaintainGIM creates as many other partitions as necessary to provide partitions for GIDB, Control, and Info Mart fact tables up to 14 days ahead. If Job_MaintainGIM runs daily, then:

• For GIDB tables, each run of Job_MaintainGIM creates one new partition of size 1 day, for the fourteenth day. (Previous runs have created partitions for the other days.)
• For Info Mart fact tables and Control tables, the maintenance job creates 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 creates a new partition only when the last day of the partitioning ahead range falls in a week for which a partition has not been created. For example, if partitioning-interval-size-gim=604800 (7 days) but partitioning-ahead-range=10, two new partitions are created on the first run of Job_MaintainGIM, and the next partition is created on the fifth run.

To guarantee that partitions are always available for use by the ETL, ensure that run-scheduler is set to true (the default value).

This option applies only in deployments that use partitioning.

In PostgreSQL deployments, Genesys recommends setting the size of GIDB table partitions to one week (604800 seconds).

Transformation performance is optimal when partitions are large enough that data that is being actively used is in the fewest number of partitions, and the partitions are small enough that their indexes can fit into the cache.

Transformation performance is optimal when partitions are large enough that data that is being actively used is in the fewest number of partitions, but small enough that their indexes can fit into the cache.

• 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.

• If there are 150,000 records in a particular table that are eligible for purging and purge-transaction-size=100000, Job_MaintainGIM deletes and commits 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 deletes and commits 90,000 records from the first table in one transaction and 10,000 records from the second table in a separate transaction.

• When the value of this option is set to true, the scheduler starts Job_AggregateGIM at the scheduled time, as specified by the aggregate-schedule option; Job_AggregateGIM then runs continuously until the scheduler stops the job after the scheduled interval, as specified by the aggregate-duration option. The scheduler does not allow a second aggregation process to be launched while the job is running. The scheduler also does not allow any other aggregation process to be launched outside the intervals that are defined by the aggregate-schedule and aggregate-duration options.
• When the value of this option is set to false, the scheduler does not manage the aggregation job at all, leaving aggregation in whatever state it is in when the option value is set. This means that, if you change the value of run-aggregates to false while the aggregation job is running, the scheduler never stops the job.

For example, if run-aggregates=true, aggregate-schedule=0 1, and aggregate-duration=05:00, the aggregation job runs continuously between 01:00 AM and 06:00 AM daily. The scheduler does not allow you to launch a second instance of Job_AggregateGIM manually from the management GUI (Genesys Info Mart Manager or the Genesys Info Mart Administration Console) within that time period. Furthermore, if you try to launch an instance of Job_AggregateGIM manually from the management GUI outside that time period (for example, at 08:00 AM), the scheduler identifies that the job is not supposed to be running at that time and stops it. If you want to run Job_AggregateGIM manually from the management GUI outside the scheduled times, you must first set run-aggregates to false.

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 example, if Job_MaintainGIM is running on August 23, 2022 (day 235 of the year) and days-to-keep-discards-and-job-history=600, Job_MaintainGIM purges all records in the discard, audit, and history tables that were written by instances of the ETL jobs that ran before January 1, 2021 (day 1 of the previous year).

The schedule is defined in the format of a CRON expression that represents a set. The expression comprises two fields, which are separated by white space:

• 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.

The schedule that you configure for Job_UpdateStats does not need to specifically allow for a maintenance window: A running instance of Job_UpdateStats does not prevent Job_MaintainGIM from starting, and once Job_MaintainGIM has started as part of the schedule, the scheduler suspends the schedule for Job_UpdateStats until Job_MaintainGIM finishes.

For values that illustrate sample schedules, see the examples for the aggregate-schedule option.

Artificial termination of long-living interactions

This functionality is intended primarily to prevent problems with aggregation — for example, when updates to long-living digital interactions trigger unnecessary re-aggregation, which results in overflow errors.

If an interaction is still active when the max-ixn-duration-days 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.

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.

• Scenarios in which an interaction is bounced between an Interaction Queue and a strategy while an available agent is being identified
• When the show-non-queue-mediation option is set to true

If a handling resource places an interaction into more than one of its own personal workbins, all of the personal workbin time is considered to be hold, and there is no distinction between the hold time in the various workbins. For example, if Agent1 places an email interaction into a Drafts workbin, then pulls the interaction to continue handling it and subsequently places it into a FollowUp workbin, the hold duration that is reported in the IRF record for Agent1’s association with the interaction combines the time that is spent in both workbins.

The following table summarizes the results of different permutations of the populate-workbin-as-hold and populate-workbin-facts options, in combination with the specifics of the interaction flow. If the values of the populate-workbin-as-hold and populate-workbin-facts options are both set to false, the workbin activity is not represented in the dimensional model.

• true — Provided that GSP does not consider the workbin time as hold, the placement of an interaction in an Interaction Workbin is represented in the MSF table. The MSF record references a WORKBIN dimension, which identifies the type of resource that is associated with the workbin and the specific resource that is associated with the mediation. Strategy time is not included in the mediation duration, except for scenarios in which an interaction is bounced between an Interaction Workbin and a strategy as the strategy repeatedly retries busy agents. For more information, see the description of the MEDIATION_DURATION field in Populating mediation segments.
• false — The placement of an interaction in an Interaction Workbin is not represented in the MSF table.

• 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 matches 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.

Examples

The following values for aggregate-schedule illustrate sample schedules:

• 0 1 means that the aggregation job launches once a day at 01:00.
• 30 0,3/2 means that the aggregation job launches every day at 00:30, 03:30, and every 2 hours after that for the rest of the day.

  This schedule assumes that the value of aggregate-duration is 02:00 or less. The scheduler does not launch a new instance of Job_AggregateGIM while an existing instance is running. For aggregation to run on the specified schedule, the value of aggregate-duration must not exceed the intervals between scheduled start times.

• 30 * means that the aggregation job launches every hour during the day on the half-hour (00:30, 01:30, 02:30, and so on), assuming that the value of aggregate-duration is 01:00 or less.

Genesys recommends against configuring a schedule that has the aggregation job running in a series of short bursts—for example, aggregate-schedule=30 * and aggregate-duration=00:15. When the time specified by aggregate-duration expires, the scheduler immediately stops the aggregation job, even if it is in the middle of processing a batch of data.

If you want Job_AggregateGIM to run continuously for 24 hours a day, without any breaks for maintenance activities (which is not recommended), set aggregate-schedule=0 0 and aggregate-duration=24:00.

• http://www.java2s.com/Tutorial/Java/0120__Development/GettingallthetimezonesIDs.htm
• http://en.wikipedia.org/wiki/Zone.tab

For example, with the default value (2 days), if Job_MaintainGIM is running on September 4, 2022, the job purges *_ANNEX records that terminated (in other words, the configuration setting on the object’s Annex tab was deleted) before September 2, 2022.

Genesys expects the value of days-to-keep-gidb-facts to be less than 30. Although many GIDB tables contain personally identifiable information (PII), Genesys Info Mart does not include most GIDB tables in General Data Protection Regulation (GDPR) processing.

By definition, all voice interaction data in the dimensional model relates to completed interactions.

How Purge Options Work

To illustrate how various days-to-keep-* options combine to determine when data is purged, the following tables provide examples of different scenarios for GIDB and the dimensional model, respectively.

Purge examples

By default, the value of etl-frequency is much smaller than the value of extract-data-chunk-size. Genesys recommends that you retain this relationship, to minimize data latency. For example, say that extract-data-chunk-size=900 (15 minutes), etl-frequency=1, and all data from the last chunk has been processed; when the next ETL cycle starts 1 minute later, there is only 1 minute’s worth of new data, and this can be processed very quickly. Alternatively, if there is a backlog of data, and it takes less than 15 minutes to process a 15-minute chunk, the next ETL cycle starts almost immediately, to continue catching up.

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.

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.

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.