Populating Genesys Info Mart Data

This page provides general information about how Genesys Info Mart populates the data in the Info Mart database. You need this information in order to create meaningful queries for business purposes, as well as to interpret query results correctly.

Bringing Data into Info Mart

Extract, transform, and load (ETL) is performed by two main jobs: Job_ExtractICON and Job_TransformGIM. Deployments in which the Genesys historical reporting presentation layer (Genesys CX Insights [GCXI] or Reporting and Analytics Aggregates (RAA) is installed also use Job_AggregateGIM.

• Job_ExtractICON extracts new and changed data from IDBs and stores the data in the GIDB tables, as discussed in Populating Low-Level Details.
• Job_TransformGIM transforms the data from GIDB into the dimensional-model (fact and dimension) tables. Depending on configuration, Job_TransformGIM also extracts and transforms reporting data from other data streams (for example, Apache Kafka) and stores the processed data in the dimensional model.
• Job_AggregateGIM calculates or recalculates metrics and stores them in the aggregate tables in the Info Mart database, based on the data that was added or changed during the last transformation run.

For more information about the Genesys Info Mart jobs, see the Genesys Info Mart Operations Guide. For detailed information about Genesys Info Mart functioning, see the Genesys Info Mart Deployment Guide. For detailed information about the aggregation process, see the Reporting and Analytics Aggregates documentation set.

Important

Genesys Info Mart extracts multimedia interaction data while the interactions are still active, and multimedia interaction records might be updated frequently and over large time intervals. Similarly, although Genesys Info Mart extracts voice interactions only after they have completed, After Call Work (ACW) might cause end timestamps in Info Mart records for call-related activity to be updated in a subsequent ETL cycle. Therefore, the timing of your reporting queries can affect reporting results.

When generating and interpreting reports, remember to allow for data updates that might occur over multiple ETL cycles because of continuing activity during long-lived multimedia interactions or because of ACW after voice or multimedia interactions end. For example, for voice interactions, allow for the maximum amount of time that can be spent on wrap-up activities (usually, the value of the user-event-data-timeout configuration option), as well as for the ETL schedule and ETL execution time. You might need to regenerate reports to guarantee final results.

Populating Low-Level Details

The Global Interaction Database (GIDB) is an area within the Genesys Info Mart database schema in which the low-level interaction data from any number of IDBs is consolidated for further processing.

To populate GIDB, Genesys Info Mart Server extracts data from one or more source IDBs. For voice-interaction records, the merge operation links all records that are related to the same interaction, in both single-site and multi-site deployments. The server loads all extracted (and, if applicable, merged) data into GIDB.

The GIDB tables represent a subset of IDB tables, to better align the lowest level of data details in Genesys Info Mart with the Interaction Concentrator model. The GIDB tables:

• Provide low-level details about a call, party, and party history for voice and multimedia interactions in the GIDB_G_CALL, GIDB_G_PARTY, and GIDB_G_PARTY_HISTORY tables, respectively.
• Store all extracted records that are necessary for Genesys Info Mart reporting purposes from various IDBs, to gather coherent reporting data at the lowest level of detail from the entire contact center in a single data warehouse.
• Use special fields to indicate from which IDB data was extracted.
• Store the data for as long as it is required by customers after Genesys Info Mart further processes (transforms) GIDB data.

Genesys Info Mart Server uses the low-level details data from GIDB tables to produce data that is suitable for end-user reports and to populate the fact and dimension tables that compose the Info Mart dimensional model.

The Genesys Info Mart Physical Data Model for each supported RDBMS provides a list of GIDB tables. The meaning of the data in each row within a given GIDB table is the same as in the corresponding IDB record. For example, GIDB_GC_PLACE table in the Info Mart database corresponds to the GC_PLACE table in IDB. Refer to the Interaction Concentrator Physical Data Model document for your RDBMS for information about the data stored in corresponding GIDB tables.

The DATE_TIME Dimension

The DATE_TIME dimension enables facts to be described by attributes of calendar date and 15-minute time interval. All interaction-related fact tables use only the DATE_TIME time dimension. No other time-dimension fields are used.

Important

Only UTC timestamps are used in the interaction-related fact tables.

By default, a single DATE_TIME table is configured, but you can set up multiple calendar tables. For example, you might need to support multiple time zones. For details on how to configure multiple DATE_TIME tables, see Creating Custom Calendars in the Deployment Guide.

For more detailed discussion of the DATE_TIME dimension, see Representing Dates and Times of Day.

The CTL_AUDIT_LOG Dimension

The CTL_AUDIT_LOG dimension table contains data for all transactions that are committed by Genesys Info Mart. Instead of service fields such as ROW_CREATED and ROW_UPDATED appearing in all tables, the CTL_AUDIT_LOG table contains audit information for all records.

All fact table records contain pointers (CREATE_AUDIT_KEY and UPDATE_AUDIT_KEY) to the relevant CTL_AUDIT_LOG table row.

Each row represents a logical transaction that is committed by Genesys Info Mart, identifying the ETL job involved in the transaction and including the minimum and maximum DATE_TIME values (which give the date-time range for the data that is committed in the transaction), and providing the processing status (an internal indicator of the kind of data that is processed).

Populating Specific Types of Data

See the following pages for detailed discussion about:

• Populating Interaction Resource Data
• Populating Interaction Data
• Populating Mediation Segments
• Populating Outbound Contact Campaign Activity
• Populating Agent Activity Data