Historical Reporting Architecture

Recommended Architecture

To collect historical reporting data from the Genesys applications in a SIP Cluster environment and ensure redundancy, all components of Historical Reporting are deployed at two data centers as shown in the diagram below. One or several supported RDBMS instances are deployed at each data center to host Genesys databases.

At each active data center, multiple instances of Interaction Concentrator collect data regarding contact center activity in the Cluster environment as this data comes in the form of events from SIP Servers that operate in cluster mode. A separate instance of Interaction Concentrator for each data center in the Cluster collects data regarding contact center configuration from Configuration Server Proxy that is located in the respective data center. Another instance of Interaction Concentrator for each data center collects data regarding virtual queue (VQ) DN activity from the VQ SIP Server that is located in the same data center. All data is stored in Interaction Database (IDB), one per Interaction Concentrator server (ICON). Each IDB uses a separate, dedicated database schema hosted at the same data center as the corresponding ICON server. A single Genesys Info Mart server instance extracts data from all available IDBs and stores the data into a single Info Mart database. A single Genesys CX Insights (GCXI) instance provides historical reports for end users.

A second instance of Genesys Info Mart can be deployed in the second data center for Disaster Recovery purposes. The two Genesys Info Mart instances must have the same configuration, including connections to all the IDBs in the Cluster deployment. A standby instance of GCXI can be deployed against the second instance of Genesys Info Mart for Disaster Recovery purposes, but this GCXI instance must not be active during normal operations. See Historical Reporting and SIP Business Continuity.}

Data Flow Between Components

This section notes the key differences in data flow between components that are specific to a Cluster environment.

Data from SIP Server to Interaction Concentrator

One SIP Server / One Interaction Concentrator / One IDB

In a Cluster environment, one instance of Interaction Concentrator is connected to each SIP Server in the Cluster in order to receive agent and call data, as shown in the diagram below.

ICON recognizes a SIP Server that operates in cluster mode based on the settings in the SIP Server Application object.

IProxy and T-Controller are separate interfaces within SIP Server from which ICON collects call data and agent activity data, respectively. By default, a single ICON handles both data types, as shown in the diagram above, and then writes all data, along with respective user data, to a single IDB. Depending on the call flow, SIP Server in one SIP Cluster node may process call data while SIP Server in another SIP Cluster node maintains agent activity data for the same call. In this case, two different ICONs that belong to respective SIP Cluster nodes independently write data for a single call into two different IDBs, one storing call data and the other, agent activity data.   The VQ SIP Server should also have a dedicated instance of Interaction Concentrator (ICON server and IDB) associated with it. This ICON processes data in the same way as in a non-Cluster environment.   See Configure and install the Interaction Concentrator (ICON) application on the Enabling Historical Reporting topic for the necessary configuration procedure.  

Because an ICON that is connected to a SIP Server in a Cluster uses different connection parameters and expects different data than in a non-Cluster environment, keep in mind the following requirements:

• An ICON that is connected to a SIP Server that is a part of a Cluster must not connect to any T-Server or non-Cluster SIP Server.
• Each ICON application must populate its own IDB. In other words, consider each ICON-IDB pair a unit (Interaction Concentrator instance).
• No other ICON should write data to the IDB that is used by the ICON connected to a SIP Server that operates in Cluster mode.

Data Flow from IDBs to Genesys Info Mart

Genesys Info Mart retrieves data from IDBs in a Cluster environment in the same way that it retrieves data in a non-Cluster environment. Using the same extraction logic as applies to any high availability (HA) environment, Genesys Info Mart selects the IDB with better data quality out of the two IDBs in each HA pair. Genesys Info Mart associates call, agent activity, and user data with a given call in the case these types of data come from different IDBs that store events from different SIP Cluster nodes. A single Info Mart database stores the data extracted from all IDBs in the Cluster deployment.

Data Flow from Info Mart Database to GCXI Reports

The data for GCXI reports is available from the Info Mart database through the Reporting and Analytics Aggregates (RAA) module, in the same way as in a non-Cluster environment.