Jump to: navigation, search

Genesys Interactive Insights

Also known as GI2. A presentation layer that extracts data from the Genesys Info Mart database, and presents it in readable reports to enable business and contact center managers to make better business decisions for streamlining operations, reducing costs, and providing better services.

For Genesys Cloud customers, depending on the release of Genesys Cloud that you are using, historical reporting is available through either the Genesys Interactive Insights (GI2) interface, or through Genesys CX Insights.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Reporting And Analytics Aggregates

Also known as RAA. An optional Genesys Info Mart process that creates and populates predefined aggregation tables and views within an Info Mart database. RAA aggregation tables and views provide the metrics that summarize contact center activity to facilitate reporting, and serve as the primary source of data for the GI2 and Genesys CX Insights reports. RAA is required for GI2 and Genesys CX Insights environments.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

How Do I Manage the Aggregation Process?

This page describes how to manage the aggregation process apart from Genesys Info Mart Manager. To learn how to manage the aggregation process within the Genesys Info Mart Manager—operating in Integrated mode—refer to the Genesys Info Mart Operations Guide.

Should I Run the Aggregation Process?

Reporting and Analytics Aggregates (RAA) provides an aggregation engine that must be run in order to populate the aggregation tables on which Genesys Interactive Insights (GI2) relies. However, if your deployment does not include GI2, running this process is optional, unless you have some other reason to require aggregated data.

Tip
Running the aggregation process creates the AG2_* / AGT_* (and supporting) tables and database constructs—if they do not already exist—within Info Mart database.

How Do I Configure Continuous Aggregation?

You can invoke aggregation so that it will run on an ongoing basis.

Genesys recommends that you save the aggregation command in the Genesys Info Mart root directory (though it is possible to execute it from another location). All instructions in this document pertaining to invoking this process presume that the command is within the Genesys Info Mart root directory.

Running Continuous Aggregation

To invoke aggregation in Integrated mode, refer to the discussion about Job_AggregateGIM in the Genesys Info Mart Operations Guide.

To invoke the aggregation process in Autonomous mode from the Genesys Info Mart root directory and have it run continuously until it is stopped, open a console window, and then issue the appropriate command:

  • On UNIX Platforms: from the Genesys Info Mart root directory, issue the following command:
java -jar agg/GIMAgg.jar -user=<dbo> -pass=<password> -jdbcurl=<URL>
	[OtherParams]
  • On Microsoft Windows platforms: from the Genesys Info Mart root directory, issue the following command:
java -jar agg\GIMAgg.jar -user=<dbo> -pass=<password> -jdbcurl=<URL>
	[OtherParams]
  • where:
    • GIMAgg.jar is the name of the Java archive that contains the aggregation engine.
    and user, pass, and jdbcurl are mandatory runtime parameters:
    • <dbo> is the user name of the database owner.
    • <password> is the password of the database owner.
    • <URL> is the jdbc URL, including the host, port, system ID (SID, for Oracle), and database name (for Microsoft SQL).
    • [OtherParams] are optional runtime parameters that you can specify to affect aggregation results.

Refer to the Reporting and Analytics Aggregates Deployment Guide for descriptions of all runtime parameters and command-line syntax.

Using the -conf Runtime Parameter

Optionally, you can use the -conf runtime parameter to reference a configuration file that stores one or more runtime parameters. If you specify this one parameter, you don’t have to specify every other parameter on the command line.

To invoke a continuous aggregation using this parameter, issue the following command from the Genesys Info Mart root directory:
java -jar agg/GIMAgg.jar -conf <file>
where <file> is the name of the file that contains the full listing of runtime parameters that are not specified at the command line. This specification must include the file’s absolute path if the file is not located in the same directory as the aggregation java archive.

Aggregation Examples

The following are examples of how to invoke aggregation in Autonomous mode for two different platforms:

Oracle on UNIX:
java -jar agg/GIMAgg.jar -user=Administrator -pass=Adm1n2046
-jdbcurl=jdbc:oracle:thin:@whale:1521:orcl 
-levelOfLog=.AGG:FINE
Microsoft SQL Server on Microsoft Windows:
java -jar agg\GIMAgg.jar -user=dbo -pass=Adm1n2046 
-jdbcurl=jdbc:jtds:sqlserver://octopus:1433;DatabaseName=Widgets
-levelOfLog=.:FINE

Before it runs, the aggregation engine checks to see whether another aggregation process is already running. If there is one running, instead of starting a new process, the aggregation engine logs an error similar to the following:
Failed to acquire lock ... ... Unable to get aggregation lock

How Do I Reaggregate Data?

You can submit a request in Autonomous mode for certain data chunks to be queued for aggregation.

Reaggregating Data over a Certain Time Range

To reaggregate data over a specified time range, add the -insertPendingAgg runtime parameter to the command line. This command does not invoke aggregation. Instead, the queued request is processed if aggregation is already running (in either Integrated or Autonomous mode) or the next time that the process is started.
The following formats are supported:

java -jar agg\GIMAgg.jar -user=<dbo> -pass=<password> -jdbcurl=<URL> 
	-insertPendingAgg <AGR_SET>:<START>:<END>

OR

java -jar agg\GIMAgg.jar -user=<dbo> -pass=<password> -jdbcurl=<URL> 
	-insertPendingAgg <AGR_SET>:DATES_FROM:<FACT_TABLE>

Where:

  • <AGR_SET> indicates what set to aggregate (ALLSETS, or an aggregate set name). Aggregate set name is formatted as follows:
    <HIERARCHY_NAME>-<AGG_LEVEL>[.Flavor].
    Where:
    • <HIERARCHY_NAME> is the name of the hierarchy to be aggregated.
    • <AGG_LEVEL> is the aggregation level (SUBHOUR, HOUR, DAY, MONTH, QUARTER, YEAR).
    • [.Flavor] indicates what data to include (Online or Offline).
  • <START> is a value in the format YYYY-MM-DD
  • <END> is a value in the format YYYY-MM-DD
  • <FACT TABLE> is the name of the fact table from which to retrieve start and end time values. The start and end values are retrieved from the MIN and MAX values of the START_DATE_TIME_KEY field in the specified fact table.

Examples:

  • To reaggregate all available data for a one-year period:
java -jar GIMAgg.jar -conf XXX.properties -insertPendingAgg ALLSETS:2017-01-01:2017-12-31
  • To reaggregate a particular aggregate set for a particular day:
java -jar GIMAgg.jar -conf XXX.properties -insertPendingAgg H_ID-DAY:2017-01-01:2017-01-01
  • To reaggregate all available data over a period corresponding to the MIN and MAX values form START_DATE_TIME_KEY field of the INTERACTION_RESOURCE_FACT table :
java -jar GIMAgg.jar -conf XXX.properties -insertPendingAgg ALLSETS:DATES_FROM:INTERACTION_RESOURCE_FACT
  • To reaggregate only one flavor (online- or offline- data):
java -jar GIMAgg.jar -conf XXX.properties -insertPendingAgg H_I_AGENT-SUBHOUR.Online:2017-01-01:2017-01-01
Important
A request to reaggregate data for a specific time range first deletes aggregated data from that time range (to prevent duplicate data from being written to Info Mart). Before you issue such a request, make sure that the Genesys Info Mart facts for your selected time range exist and have not been purged. Otherwise, you could be left with no data at all for that time range.

Reaggregating Data when DATE_TIME Changes

When you first initialize the Genesys Info Mart database, set a time zone for the DATE_TIME table, and avoid changing it thereafter. If your environment time zone changes after data has been aggregated and written to the Info Mart database, then in order to maintain consistency (between data written to Info Mart before and after the time zone change) within the aggregate tables, you must truncate existing data from all AGT_* tables before requesting reaggregation. This procedure is described in the Changing DATE_TIME Options section of the Reporting and Analytics Aggregates Deployment Guide. Note that the time range for reaggregation must include the beginning of the month in which the time-zone switch occurred plus two more days as illustrated in the following example:

Example: On January 10, 2015, you change the time zone in your contact center environment from Eastern Standard Time to Pacific Standard Time. To set reaggregation to repopulate AGT_* tables properly, you must set the reaggregation interval from December 30, 2014 to January 11, 2015, inclusive. This is in addition to executing all of the requisite steps in Genesys Info Mart to effect the time-zone change.

How Do I Stop the Aggregation Process?

You may have to perform multiple steps to stop the aggregation process, depending on whether it is scheduled.

To stop aggregation

Job schedules are controlled by the values of options in the [schedule] configuration section of the Genesys Info Mart Application object. If aggregation is scheduled:

  • To halt aggregation, you must explicitly reset or stop the job schedule. If you attempt to stop aggregation manually within the Genesys Info Mart Manager only, and without changing the job schedule, the Genesys Info Mart Server automatically restarts the job so long as it is scheduled to be running.
  • Conversely, if the job is scheduled to be not running, the Genesys Info Mart Server will not permit you to start the job from the Genesys Info Mart Manager.
    The method you use to stop the aggregation process depends on the mode of its operation:
    • Stopping Aggregation in Integrated Mode: Once started in Integrated mode, the aggregation process runs continuously, aggregating new facts until the process (Job_AggregateGIM) is scheduled to be stopped. Refer to the Genesys Info Mart Deployment Guide or the Genesys Info Mart Deployment Procedure for more information about the options pertinent to aggregation, and the procedure for stopping aggregation that is operating in Integrated mode.
    • Stopping Aggregation in Autonomous Mode: Although you can manually stop the aggregation process when it is operating in Autonomous mode, the Genesys Info Mart Server will restart the process in Integrated mode if the process is scheduled to be running. Therefore, to stop the aggregation process:
      • Deactivate the job schedule as described in the Genesys Info Mart Deployment Guide.
      • Stop the aggregation job by typing ^C within the console window in which aggregation was invoked, or by stopping the aggregation process.

How Do I Purge Aggregate Data?

RAA provides the ability to purge aggregate tables on a scheduled basis. To use this functionality, you must configure purging rules, and schedule and enable purging:

Configuring Purging Rules

You create purging rules in a file (purge.ss), which you must store in the folder where aggregation or Genesys Info Mart is running. Each line of the purge.ss file must consist of a single purge rule, consisting of the purge statement with the following syntax:
(purge <agg-set-selector> keep <value> <unit> delay <value> <unit>)

RAA evaluates the rules as follows:

  • Rules are evaluated in order, beginning from the top of the file.
  • If more than one rule applies to an aggregate set, the first rule that matches is the effective purging rule.
  • If more than one aggregate set shares storage (such as sub-hour level aggregates for compatible time zones), and are impacted by separate purging rules, the most conservative rule is used to purge the shared storage. If there is at least one such aggregate set which matches no purging rule, the shared storage is not purged.
  • Purging rules are evaluated in the time zone of the hierarchy to which the aggregate sets belong.
  • Purging rules are applicable only to aggregates that are stored as tables (where AGT tables exist). For aggregates that are defined only as Views, purging rules do not apply and are ignored. Aggregates that are defined only as Views inherit their purging from underlying aggregates that are stored as tables.

The table Purging Rule Parameters describes the purging rules and parameters.

Parameter Description
Purging Rule Parameters
<agg-set-selector> This parameter specifies the hierarchy or query to purge, the aggregate level to urge, and (optionally) the flavor of media to purge, with the following syntax:

<HIERARCHY|QUERY>-<AGG_LEVEL>[.Flavor]
where:
<HIERARCHY|QUERY> - the hierarchy or query to purge. Accepts the wildcard *: enter * to purge all heirarchies or queues, or *-* to purge all heirarchies and all queues.
Usage Examples:

  • H_QUEUE-HOUR - selects hourly aggregation level from the H_QUEUE hierarchy.
  • H_GMT_QUEUE-HOUR - selects hourly aggregation level from the H_GMT_QUEUE hierarchy (if H_GMT_QUEUE exists).
  • QUEUE-HOUR - selects hourly aggregation levels from both hierarchies.
  • <AGG_LEVEL> - the aggregation level to purge (SUBHOUR, HOUR, DAY, WEEK, MONTH, QUARTER, YEAR).

Enter * to purge all aggregation levels.

  • [.Flavor] - the flavor of media to purge:
    • Online to purge only data from online media (such as voice call or chat)
    • Offline to purge only data from offline media (such as email or tasks).

To purge both online and offline data, exclude this attribute. Note that flavor applies to all aggregates, with the exception of SESS_STATE, STATE_RSN, AGENT_CAMPAIGN, and CAMPAIGN aggregates (which are said to be plain, or flavorless).

keep <value> <unit> This parameter specifies the number of complete units of time for which to retain data, where:
  • <value> - an integer
  • <unit> - DAY, WEEK, MONTH, QUARTER, or YEAR

The delay parameter must have a value lower than that of the keep parameter.

delay <value> <unit> This parameter specifies the period of time to wait before purging, where:
  • <value> - an integer
  • <unit> - HOUR, DAY, WEEK, MONTH, QUARTER, or YEAR

The delay parameter must have a value lower than that of the keep parameter.

Examples

The following examples show how you can use use purge rules in various ways:

Rule Result
(purge H_ID-* keep 1 YEAR delay 7 DAY) In this rule, the 1 year keep value causes purge to retain all data in the H_ID hierarchy for the entire year (January 1st to December 31st). The delay value works as follows:
  • If evaluated during the first week of 2018, retain data from 2016-01-01 to 2017-12-31; (two years of data, because the 7 day delay after the end of the keep period has not yet passed).
  • If evaluated after January 8th of 2018, retain data from 2017-01-01 to 2017-12-31; (one year of data, the minimum specified by the keep parameter, because the 7 day delay after the end of the keep period has passed).
(purge H_ID-* keep 365 DAY delay 0 HOUR) This rule retains 365 days of all data in H_ID hierarchy, aligned to DAY boundaries. Delay is as near zero as possible. So, if evaluated on January 5th of 2018, this rule retains all data from 2017-01-05 to 2018-01-04
(purge *-*.Online keep 3 WEEK delay 1 DAY) The rule retains at least 3 whole weeks of online data in all hierarchies. If evaluated on the first day of the week, then four weeks of data is retained.
(purge QUEUE-*.Offline keep 3 YEAR delay 1 MONTH) This rule keeps 3 whole years of offline data in all hierarchies based on QUEUE query. If evaluated before February 1st in a given year, then four years of data is retained.

Enabling and Scheduling Purge

To enable purging, you must add the suffix <hour(X-Y)=purge> to the writerSchedule option of the aggregation command, and set the purging schedule using the hour parameter. For example, to enable purging, and schedule it to occur between 1 am and 2 am:

writerSchedule=default=flex(7:3),hour(1-2)=purge

For more information about scheduling purging, see Reporting and Analytics Aggregates Deployment Guide.

How Do I Configure Aggregation Across More than One Time Zone?

Genesys Info Mart enables you to create custom calendars for dimensioning data. You can configure RAA to recognize these calendars and aggregate data accordingly.

Recognizing Custom Calendars

To configure RAA to recognize custom calendars:

  • Declare each calendar to RAA.
  • Run aggregation.
  • Create schemas within Info Mart to restrict user access to the appropriate data.
  • Update tenant aliases.

The complete procedure is provided in the Genesys Interactive Insights User Guide.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on May 18, 2018, at 09:54.