Global Interaction Database (GIDB) tables
The tables in the Info Mart database that store low-level interaction data consolidated from one or more Interaction Concentrator databases, or Interaction Databases (IDBs).
Contents
Data Lineage: Voice of Data
This page describes how Genesys Info Mart tracks data, enabling you to understand what data is collected and how it is processed. This information can be used for reporting and to assess data accuracy (data validation).
About data lineage in Genesys Info Mart
Data lineage provides information that records the history of job execution and data transformation for each piece of data. Data stored as part of data lineage allows for bi-directional data tracking and enables you to answer the following questions:
- What process created the piece of data?
- What was the source of the data?
- What data was created by a specified job?
- What data in the system was created based on specified source data?
There are two aspects of data lineage:
- Voice of Data — This feature pertains to data-quality validation and troubleshooting. It enables you to trace a particular data item in a source system based on data in the target system (in other words, from data to source), and also to trace data in the opposite direction (from source to target).
- Voice of Process — This feature provides data-processing history, tracing which ETL process created or updated this piece of data (in other words, from data to process). It also traces in the opposite direction (from process to data).
Voice of Data
Voice of Data functionality enables you to trace data origins or targets.
To use Voice of Data, you must be familiar with which GIDB tables provide which kind of data. This information, called static mapping, cannot be derived from the schema. The following table summarizes the connections, which are discussed in more detail below.
| Genesys Info Mart | GIDB | ||
|---|---|---|---|
| Table | Field | Table | Field |
| INTERACTION_FACT | MEDIA_SERVER_IXN_GUID | GIDB_G_CALL_V GIDB_G_CALL_MM |
CALLID |
| INTERACTION_RESOURCE_FACT | INTERACTION_RESOURCE_IDa | GIDB_G_PARTY_V GIDB_G_PARTY_MM |
PARTY_KEY |
| INTERACTION_RESOURCE_FACT | PARTYGUID | GIDB_G_PARTY_V GIDB_G_PARTY_MM |
PARTYGUID |
| MEDIATION_SEGMENT_FACT | MEDIA_SERVER_IXN_GUID | GIDB_G_CALL_V GIDB_G_CALL_MM |
CALLID |
| MEDIATION_GUID | GIDB_G_PARTY_V GIDB_G_PARTY_MM GIDB_VIRTUAL_QUEUE_V GIDB_VIRTUAL_QUEUE_MM |
PARTYGUID VQID
| |
| RESOURCE_ | RESOURCE_CFG_DBID RESOURCE_CFG_TYPE_ID |
GIDB_GC_AGENT GIDB_GC_ENDPOINT GIDB_GC_SCRIPT |
ID (dbid) |
| GROUP_ | GROUP_CFG_DBID | GIDB_GC_GROUP | ID |
| PLACE | PLACE_CFG_DBID | GIDB_GC_PLACE | ID |
| SKILL | SKILL_CFG_DBID | GIDB_GC_SKILL | ID |
|
a. The PARTY_KEY of the last party in the INTERACTION_RESOURCE_FACT (IRF) record is used as the INTERACTION_RESOURCE_ID. Primary keys can match in a many-to-one relationship. | |||
The information in the Data Mapping table is a starting point that enables you to:
- Trace a record back to the source records that triggered its creation, or trace data from its origin to its final target.
- Select an interaction in Genesys Info Mart and pull out from the Interaction Concentrator database (IDB) all corresponding records.
- Trace the information in IDB records back to the source application logs (for example, the T-Server, SIP Server, or Interaction Server logs).
How to use Voice of Data
The basic concept of Voice of Data is that each interaction can be traced from its initial entry into your environment through its conclusion by way of specific linking IDs, which enable you to trace, in either direction, the processing records from IDB to the Genesys Info Mart database via GIDB tables.
To accomplish this, you can trace each of the interaction records in the Info Mart fact tables back to source tables in GIDB using keys that indicate from which records in the source tables a particular record was created. Multiple links enable you to trace the interaction records in the fact tables to GIDB tables, from where you can find records in IDBs and ICON application logs.
For example, the IRF table stores the PARTYGUID of the handling party. A simple join between GIDB_G_PARTY with either G_PARTY or PARTYGUID links the IRF table with the corresponding party record in GIDB/IDB.
Use cases
The following examples show some specific ways to use Voice of Data. The examples provide only a small sampling of the sorts of questions you can answer using Voice of Data:
How do I know where specific GIDB data comes from?
To identify the source for GIDB data, join the GIDB table of interest with the CTL_DS table using DATA_SOURCE_KEY, CTL_DS. The value for DS_DBID in the resulting data set provides the value of the data source DBID (for example DBID of the T-Server for voice call data).
We use multiple instances of ICON. Which one created this specific record?
To identify the instance of ICON that was the source of a particular record in GIDB, use the GSYS_SYS_ID field in the GIDB record. This field contains the DBID of the ICON application as defined in the Configuration Layer.