Historical Reporting Deployment Considerations
The SIP Cluster deployment must be set up and provisioned according to Deploying SIP Cluster prior to deploying Historical Reporting components. The Historical Reporting components themselves must be deployed per recommendations in this article and following the procedure described in Enabling Historical Reporting.
Historical Reporting architecture scales up with the rest of SIP Cluster deployment:
- One Interaction Concentrator instance (or HA pair) must be deployed per SIP Cluster node.
- One Interaction Concentrator instance (or HA pair) must be deployed per VQ SIP Server (or HA pair of VQ SIP Servers).
- One Interaction Concentrator instance (or HA pair) must be deployed per data center, to collect configuration details from Configuration Server Proxy.
- One Interaction Concentrator instance (or HA pair) must be deployed per OCS instance, to store Outbound details.
- One Genesys Info Mart instance must be deployed to extract data from all Interaction Databases (IDBs) in the SIP Cluster deployment.
Two SIP Server Application objects must be created per SIP Server running in Cluster mode, as described in Configuring SIP Servers for Historical Reporting, to enable ICON connections to the two different SIP Server ports. See also User Data, below.
Data Differences in IDB
Data processing logic that is specific to a Cluster environment accommodates independent processing of call data and agent activity data coming from different SIP Servers for the same voice interaction. This processing results in a number of noteworthy differences in the types of data that Interaction Concentrator produces and stores in IDB, as listed in “Table Fields That Differ in a Cluster Environment,” below. Most importantly, the G_PARTY table does not contain the agent ID value. Additionally, the value for the PartyID has a different format and is calculated differently than in a non-Cluster environment.
Table Fields That Differ in a Cluster Environment
The AgentID field in the following table contains the value 0:
The EndpointID field in the following tables contains a NULL or 0 value:
The GSYS_EXT_VCH1 field in the following tables contains the DN name:
The DestEndPointID field in the following table contains a NULL or 0 value:
The DestEndPointType field in the following table contains the value 1:
The EndPointType field in the following tables contains a value of 1:
The LoginID field in the following tables is NULL:
The PlaceID field in the following tables is NULL:
Data Differences in Info Mart
Most of the Info Mart tables and views are populated similarly in Cluster and non-Cluster environments. The Info Mart data differences in a Cluster environment result from differences in IDB data. Some dimensions (such as RESOURCE_) are populated during transformation of the voice or agent-related data while some others might be not populated at all (such as PLACE). As a result, only a subset of DN-based metrics is available in a Cluster environment.
The following subsections provide more details about the populated data. For illustration purposes, it is assumed that the T-Servers in the environment are a mix of SIP Servers that operate in Cluster mode and either non-Cluster SIP Servers or traditional T-Servers.
Global Interaction Database (GIDB) is the part of the Info Mart database that is designed to keep all records that are extracted from various IDBs. As such, the GIDB data that is available in the Cluster environment reflects the changes in the corresponding IDB data. See Data Differences in IDB, above.
Resources and Resource Groups
The resource-related tables and views are populated as described below.
Population of the RESOURCE_ table differs with regard to SIP Cluster resources (endpoint DNs). When Genesys Info Mart encounters SIP Cluster resources during voice or agent-state transformation, the transformation job creates resource records "on the fly."
In the RESOURCE_ table:
- For IVR applications that are not represented in the Configuration Layer (that is, whose configuration type equals 0), records are created based on the voice and agent-related data. Genesys Info Mart continues to identify them by the combination of the RESOURCE_NAME and TENANT_KEY.
- For the resources controlled by SIP Servers operating in Cluster mode, records are created based on the voice and agent-related data. Genesys Info Mart identifies them by the combination of RESOURCE_NAME and SWITCH_DBID.
When it creates the RESOURCE_ record, Genesys Info Mart generates an internal ID to populate the RESOURCE_CFG_DBID field. The RESOURCE_CFG_TYPE_ID field is then set to 0 (zero).
For any other resources (such as agents, queues, Routing Points, etc.), records are created based on the configuration data. Genesys Info Mart continues to identify them by the combination of configuration type and DBID (stored in the RESOURCE_CFG_TYPE_ID and RESOURCE_CFG_DBID in the RESOURCE_ table).
The GROUP_TO_CAMPAIGN_FACT table is populated based on the data from the Configuration detail IDB. In an environment where Genesys Outbound Contact is deployed, this table contains records for campaign groups, which are configured as agent groups in the Configuration Layer.
The data in the GROUP view reflects the groups of DNs and agents as configured in the Configuration Layer.
Places and Place Groups
With Place objects not being configured in a Cluster environment, the Place-related table and view are populated as described below.
The PLACE_GROUP_FACT table contains records only if Place objects are configured in the Configuration Layer. With the absence of Place objects in a Cluster environment, this table might not contain any data.
The data in the PLACE view contains records only if Place objects are configured in the Configuration Layer. With the absence of Place objects in a Cluster environment, this view might not contain any data.
For the purposes of Historical Reporting, user data configuration and processing do not differ in a Cluster environment. However, to enable Genesys Info Mart to extract user data from both I-Proxy and T-Controller channels, ICON application requires a connection configured to a special (dummy) SIP Server application that specifies connection parameters of the T-Controller.