Jump to: navigation, search

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

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).
Important
The information in this User's Guide focuses on Voice of Data. For information about Voice of Process, see Job History and Status in the Genesys Info Mart Operations Guide. For detailed descriptions of the tables and views related to data lineage, see the information about Info Mart Service and Staging Tables and Administrative Views in the Genesys Info Mart Physical Data Model for your RBDMS.

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.

Data Mapping
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.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 28 March 2017, at 21:40.