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.

Do you need separate IDBs for voice and multimedia data?

The downstream reporting application might affect your choice of deployment architecture.

• Genesys Info Mart releases earlier than 8.5.007: In deployments that include both voice and multimedia interactions, you must use separate ICON applications to process each type of data and store voice and multimedia data in separate IDBs.
• Info Mart releases 8.5.007 and higher: You are not required to use separate ICON and IDB instances. However, Genesys continues to recommend that you use separate ICON applications and IDBs. Given the different durations for typical voice and multimedia interactions, having separate ICONs and IDBs enables you to tailor the decisions you make about application management, data retention policies, data recovery processes, and so on.

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.

Basic Architecture
Single-Site Deployments
Multi-Site Deployments
Network Deployments
Multimedia Deployments

[+] 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 in the Interaction Concentrator User's Guide.

• 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 How ICON Works.
• Solution Control Interface (SCI) or Genesys Administrator, via 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:

• If you are running Genesys Info Mart 7.6 or earlier, or running Interaction Concentrator without Genesys Info Mart, you must regularly run the Interaction Concentrator intra-IDB merge stored procedure to ensure correct reporting of multi-site calls (see The Merge Stored Procedure).
• 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 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, if you are running Genesys Info Mart 7.6 or earlier, or running Interaction Concentrator without Genesys Info Mart, to ensure data correctness for multi-site calls, you must regularly run the Interaction Concentrator intra-IDB merge stored procedure (see The Merge Stored Procedure).

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.

Multimedia Deployments

In a multimedia environment ICON connects to one or more Interaction Servers. When ICON connects to multiple Interaction Servers, they each must be associated with a single tenant. The basic functionality works the same way in both single-tenant and multi-tenant environments. The only significant difference is that in single-tenant environments, the tenant name is not specified.

This functionality also works when you are using the T-Server application type to connect to Interaction Server (necessary in all releases of ICON prior to 8.1.502.04).

Tenant-Related Considerations

ICON processes data only from the Interaction Servers associated with tenants included in ICON's Tenants list.

Each Interaction Server should be associated with only one tenant. If ICON finds that an Interaction Server is associated with more than one tenant, it generates a standard-level error message (20010 Configuration error. Class [errclass] : [errtxt].) and does not connect to that Interaction Server.

Important

To use an Interaction Server associated with more than one tenant, connect to Interaction Server indirectly via T-Server Application objects, as described in Special Connection Procedure for Releases 8.1.500.04 and Earlier, on the Multimedia tab of the Special Configuration Requirements page.

Switch-Related Considerations

Each tenant assigned to an Interaction Server should have only one multimedia switch. Although ICON can complete the connection to Interaction Server if it finds multiple switches of the “Multimedia switch” type assigned to a tenant, this architecture is not considered to be supported and data results might be inconsistent. In this scenario, ICON generates a standard error message (20010 Configuration error. Class [errclass] : [errtxt].), chooses the oldest created Switch (the one with the smallest DBID), and proceeds to connect to the Interaction Server(s) associated with that tenant.

If ICON finds that the tenant of an Interaction Server does not have a multimedia type switch, ICON generates a standard-level error message (20010 Configuration error. Class [errclass] : [errtxt].) and does not connect to that Interaction Server.

Login Session Consideration

If there are multiple Interaction Servers for one tenant, agents must never have two login sessions from the same place to different Interaction Servers at the same time. If ICON gets a login session from an Interaction Server on a Place when there is another open login session on the same Place, the earlier session will be considered as “stuck.”

If you do want to support agents having login sessions to different Interaction Servers at the same time, deploy the Interaction Servers in a cluster. There are two options:

• Option 1: Use Interaction Server Proxy

  Connect the ICON(s) to Interaction Server Proxy as described for Interaction Server Cluster in the eServices Deployment Guide, particularly the Suggested Deployment Configuration section.

• Option 2: Only one ICON records agent login session information

  If your deployment includes Genesys Info Mart release 8.5.016.04 or later, connect the ICON(s) to individual Interaction Servers in the cluster, with at least one ICON (or ICON HA pair) having the gcc and gud roles and only one ICON (or ICON HA pair) having the gls role, and with the Genesys Info Mart populate-sm-busy-from-mm-ixns configuration option set to true. For more information, see the Genesys Info Mart 8.5.016.04 release note.

Interaction ID Consideration

If an interaction might be handled by multiple Interaction Servers, the interaction ID must be unique across all Interaction Servers that might handle a single interaction.

Support for Dynamic Changes

ICON supports tracking dynamic changes to Interaction Server properties and connections in the same way as it does for T-Server.

This means that after a host/port change, ICON keeps its connection to the original Interaction Server until there is a disconnection. Interaction Server is required to restart after a host/port change, so ICON will then connect to the new host/port.

ICON will connect to new Interaction Server applications after they are added to ICON.