Supported Deployment Scenarios
The architectural choice for your contact center depends on your resources and reporting requirements. In fact, you can tailor the basic scenarios described in this section so that they fit the needs of your contact center at the lowest cost. For example, you can deploy a single instance of ICON for a subset of T-Servers (as opposed to one instance of ICON for each instance of T-Server). Alternatively, you can keep data for a certain site in a separate IDB, if it is not necessary to include data from this site in a consolidated report.
The downstream reporting application might affect your choice of deployment architecture. For example, in deployments that include both voice and multimedia interactions, Genesys Info Mart requires that you use separate ICON applications to process each type of data, and that you store voice and multimedia data in separate IDBs.
For additional considerations that may affect your choice of deployment, see See Recommended Role Assignment.
Interaction Concentrator does not support deployments in which two ICON instances are configured for the same role, connect to the same T-Server or set of T-Servers, and write data to the same IDB. For more information about the rules governing role assignments, see See Rules and Restrictions.
Database Sizing Recommendations
The Interaction Concentrator 8.1 Database Size Estimator, an interactive Microsoft Excel spreadsheet, helps you estimate the required size of IDB based on details you provide about projected agent activity, outbound activity, ICON server and database settings, and user data.
For additional information, see also the Interaction Concentrator and Genesys Info Mart chapters in the Genesys Hardware Sizing Guide.
Basic Architecture
Interaction Concentrator is a Genesys product that collects and stores detailed data from various sources in a contact center that is empowered with Genesys software. Downstream reporting systems can access Interaction Concentrator data in near real time.
Operating on top of Genesys Framework, the Interaction Concentrator product consists of a server application called Interaction Concentrator (ICON) and a database called Interaction Database (IDB). The server receives data from the data sources such as Configuration Server, T-Server, or particular Genesys applications; it then stores this data into IDB through Genesys DB Server.
The figure below depicts the basic ICON architecture, omitting most of the Framework components for the sake of simplicity.
Single-Site Deployments
In a single-site contact center, the following approaches to Interaction Concentrator deployment are typical:
- A single ICON and a single IDB
- Multiple instances of ICON with different roles writing to a single IDB
- Multiple instances of ICON with different roles writing to multiple instances of IDB
One ICON and One IDB
The simplest deployment scenario, which is suitable for smaller, single-site contact centers, consists of a single ICON instance that stores all data into a single IDB instance. Deployments with multiple instances of ICON and multiple instances of IDB are straightforward extensions of this model.
The graphic below illustrates the deployment for voice interactions. This type of deployment is also suitable for multimedia environments—the Interaction Server occupies the same position in the architecture as T-Server.
Multi-Site Deployments
In a multi-site contact center, approaches to Interaction Concentrator deployment vary, depending on network delays between sites, the need for across-the-sites reporting, and other considerations. The following is the basic list of deployments to consider:
- A single ICON instance and a single IDB instance per site (see See One ICON and One IDB per Site)
- A single ICON instance and a single, centralized IDB for the entire contact center (see See One ICON and One IDB per Contact Center)
- Multiple ICON instances and a single, centralized IDB for the entire contact center (see See Multiple ICONs and One IDB per Contact Center)
One ICON and One IDB per Site
In a multi-site deployment with a single instance of ICON and a single instance of IDB in each site, each IDB is populated independently from the others with CTI-related data from the T-Server that serves that site.
The graphic illustrates the deployment for voice interactions. This type of deployment is also suitable for multimedia environments—the Interaction Server occupies the same position in the architecture as T-Server. Genesys recommends that you include only one Interaction Server in your deployment.
Although the data for a particular site is readily available, this deployment does not provide across-the-sites reporting data for the entire contact center. Merging of data between IDBs is the responsibility of the downstream reporting application. Reporting of multi-site calls is also limited by the visibility of those calls at a particular site.
One ICON and One IDB per Contact Center
In a multi-site deployment with a single ICON instance and a single, centralized IDB instance, call details from all contact center sites come into the same database through the same ICON.
This scenario helps you avoid the need to merge data from different databases. However, note the following considerations:
- You must regularly run the Interaction Concentrator intra-IDB merge stored procedure to ensure correct reporting of multi-site calls (see the information about gsysIRMerge and gsysIRMerge2 in the chapter about special stored procedures in the Interaction Concentrator 8.1 User’s Guide).
- Network delays might impact the timeliness of data availability.
- ICON performance is negatively affected during high-peak hours, when each T-Server handles high call volume.
Multiple ICONs and One IDB per Contact Center
In a multi-site deployment with a separate ICON instance at each site and a single, centralized IDB instance, interaction details from all contact center sites come into the same database through separate ICONs.
Like the scenario of one ICON and one IDB for the contact center (see See Multi-Site Deployment: A Single ICON and a Centralized IDB Instance), this deployment provides the benefit of recording all contact center data in the same database.
However, this scenario provides the additional benefit of improved ICON performance, because a single ICON instance does not require a connection to every T-Server in the contact center. In addition, because T-Server and ICON instances are co-located at a particular site, network delays between these components are minimal.
Nevertheless, the effectiveness of data storage to IDB still depends on network delays between a given ICON instance and IDB, as well as on the performance of your RDBMS. Also, to ensure data correctness for multi-site calls, you must regularly run the Interaction Concentrator intra-IDB merge stored procedure (see the information about gsysIRMerge and gsysIRMerge2 in the chapter about special stored procedures in the Interaction Concentrator 8.1 User’s Guide).
Network Deployments
In a network configuration, a number of Premise T-Server applications are connected to a Network T-Server. The ICON instance connects to the Premise T-Server and Network T-Server applications.
Interaction Concentrator supports the following Network T-Server deployments:
- A single ICON connected to a single Network T-Server for each network switch
- A single ICON connected to multiple Network T-Servers for each network switch, operating in load-balancing mode
One Network T-Server per Network Switch
This configuration is applicable for both single- and multi-site deployments, in which there are single or multiple Network T-Servers, and each Network T-Server is connected to a separate switch (in other words, the network switch and Network T-Server are not working in load-balancing mode). Each ICON instance can be connected to multiple Network T-Server applications and multiple Premise T-Server applications.
Multiple Network T-Servers per Switch (Load-Balancing Configuration)
If the switch and multiple Network T-Servers have been configured to work in load-balancing mode, ICON supports deployments in which a single ICON instance connects to multiple Network T-Servers that serve the same switch.
When multiple Network T-Servers serve the same switch in load-balancing mode, the ICON instance creates and maintains a separate connection for each Network T-Server. ICON monitors interaction activity on the switch through the notifications it receives from each Network T-Server.
A configuration option, switch-multi-links-enabled (renamed in release 8.1 from load-balancing-on-network-switch) , must be set on the Switch object in the Configuration Layer in order for ICON to identify whether the switch and related Network T-Servers are operating in load-balancing mode. For more information about this option, see See switch-multi-links-enabled.
Deployments with Network T-Servers in load-balancing mode or with IVR T-Servers in load-balancing mode (described below) are the only configurations in which ICON supports separate connections to multiple T-Servers serving the same switch.
Multiple IVR T-Servers per Switch (Load-Balancing Configuration)
If a switch and multiple IVR T-Servers in an “in-front” configuration have been configured to work in load-balancing mode, ICON supports deployments in which a single ICON instance connects to multiple IVR T-Servers that serve the same switch.
In such a deployment, the ICON instance creates and maintains a separate connection for each IVR T-Server. ICON monitors interaction activity on the switch through the notifications it receives from each IVR T-Server.
A configuration option, switch-multi-links-enabled, must be set on the Switch object in the Configuration Layer in order for ICON to identify whether the switch and related IVR T-Servers are operating in load-balancing mode. For more information about this option, see See switch-multi-links-enabled.