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.

Important

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 ICON roles and the rules governing role assignments, see ICON Roles.

[+] Diagram conventions used in the deployment scenario diagrams

To simplify the deployment diagrams in this section, please note the following conventions:

• DB Server, which enables a connection between ICON and IDB, is omitted from the diagrams for the various deployment scenarios, even though it is required in the overall architecture (as shown in Basic Architecture).

• Storage of configuration data is not shown, even though it is required in actual deployments.

• Storage of outbound-related call data is not shown because it is optional. It is described separately in Integrating with Outbound Contact.

• Interaction Server is not shown for deployments that include eServices. Notes in the text indicate the deployment scenarios that are suitable for multimedia environments. In these environments, the Interaction Server occupies the same position in the architecture as a T-Server.

Basic Architecture

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 ICON server interfaces with:

• T-Server or Interaction Server to collect data. For more information on this topic, see the "How Interaction Concentrator Works" chapter in the Interaction Concentrator 8.1 User's Guide.
• Solution Control Interface (Local Control Agent [LCA]), to control when the ICON server starts and stops.
• Configuration Server, to read Interaction Concentrator application configuration options and other configuration objects and options that affect Interaction Concentrator functionality. (This interface is logically separate from ICON’s connection to Configuration Server as a source of data about contact center resources.)
• Message Server, to log messages to the Central Logger.

The figure above 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.

One ICON and One IDB

The Figure above illustrates the deployment for voice interactions. This type of deployment is also suitable for multimedia environments, in which case 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
• A single ICON instance and a single, centralized IDB for the entire contact center
• Multiple ICON instances and a single, centralized IDB for the entire 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.

Multi-Site Deployment: Independent IDB Instances

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.

Multi-Site Deployment: A Single ICON and a Centralized IDB Instance

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.

Multi-Site Deployment: Multiple ICONs and a Centralized IDB Instance

Warning

This functionality is not supported for eServices (email and chat) or 3rd Party Media. Although Interaction Concentrator supports this deployment scenario, Genesys Info Mart does not. Genesys Info Mart requires that each instance of ICON must store data only in an instance of IDB not connected to any other ICON instance.

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 and IVR 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
• A single ICON connected to multiple IVR T-Servers for each IVR 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.

Network Deployment: A Single Network T-Server per Network Switch

Important

This Figure does not show the interconnections among T-Server objects that are required for a Network T-Server deployment.

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.

Multiple T-Servers per ICON-IDB Pair Deployment: Multiple Network T-Servers per Switch (Load-Balancing Configuration)

Important

This Figure does not show the interconnections among T-Server objects that are required for a Network T-Server deployment.

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 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 switch-multi-links-enabled.

Important

Deployments with Network T-Servers in load-balancing mode (as described in Multiple Network T-Servers per Switch (Load-Balancing Configuration), above, or with IVR T-Servers in load-balancing mode are the only configurations in which ICON supports separate connections to multiple T-Servers serving the same switch.