Specifies the type of data that this ICON instance processes and stores in IDB.
- Configured in: ICON Application, [callconcentrator] Section; DAP Application, [callconcentrator] Section (for details relevant to setting the role option in the DAP Application, scroll to the end of this page)
- Default value: all
- Valid values: A comma-separated list including any of the following:
- all—Stores all types of data.
- cfg—Stores the initial configuration state and a history of configuration changes retrieved from Configuration Server.
- gcc—Stores interaction-related and party-related information—that is, T-Server and Interaction Server data that pertains to voice and multimedia interactions, and the parties associated with those interactions.
- gls—Stores T-Server and Interaction Server data that pertains to agent states and agent login sessions.
- gud—Stores T-Server and Interaction Server data that pertains to the attached data associated with calls.
- gos—In an environment with the Outbound Contact solution, stores OCS data that pertains to outbound calls and campaigns.
- lrm—In an environment with License Reporting Manager, stores license reporting data.
- Changes take effect: After restart
Any combination of the valid values can be used. Prefixing an option value with a tilde (~) excludes that type of data from ICON processing, and includes all other types. For example, the value ~cfg deactivates ICON processing of configuration data, and activates processing and storage of all other types of data.
Ensure that the role that you specify for the ICON instance is consistent with the role that you specify for the DAP (see below for DAP-specific considerations).
Examples of correct settings:
- role = cfg,gcc,gud
- role = all
- role = gcc,gud,gls,gos
- role = ~cfg
(The last two examples are equivalent.)
All types of ICON data go through the same DAP in the following cases:
- No role option is defined for the DAP.
- The role option is defined, and its value is explicitly set to all.
- You specified only one DAP Application object on the Connections tab of the ICON Application object.
- Regardless of whether a given DAP handles all types of ICON data or a subset of them, a separate database connection is opened for each type of data.
- Ensure that the role that you specify for the DAP is consistent with the role that you specify for the ICON instance.
- A DAP cannot be assigned the lrm role. If you do so, it is ignored and the default value (all) is used.
In a contact center that has a large Genesys configuration environment and/or that processes high call volumes, possibly with large amounts of attached data, you can improve Interaction Concentrator performance by deploying multiple ICON instances, each of which collects data only of a certain type.
The following are the possible types of data that you can request a given ICON instance to store, in any combination:
- Configuration information—An ICON instance stores the initial contact center configuration state and a history of configuration changes that it retrieves from Configuration Server. Depending on the deployment scenario, the ICON instance can store configuration information about the contact center as a whole or, in a multi-tenant configuration environment, about individual tenants.
- Interaction-related and party-related information—An ICON instance can store T-Server data that pertains to calls and the parties (connections) associated with those calls. In a multimedia deployment, ICON stores similar Interaction Server data about multimedia interactions (e-mail, chat, and 3rd Party Media).
- The role that enables ICON to capture interaction-related and party-related information is the gcc role (for more information, see the description of the role option). Regardless of whether you have configured the ICON instance to perform this role, if T-Server or Interaction Server is present on the Connections tab of the ICON Application object, ICON will perform aspects of the gcc role, which is required for internal processing in connection with other roles. However, for an ICON instance to be able to store interaction and party information from T-Server or Interaction Server, it must have the gcc role defined.
- Agent state and login session state information—An ICON instance can store T-Server and, if applicable, Interaction Server data that pertains to agent states and agent login sessions.
- Attached data information—An ICON instance can store T-Server and, if applicable, Interaction Server data that pertains to the attached data that is associated with interactions.
- Outbound calls information—In an environment with the Genesys Outbound Contact, an ICON instance can store OCS data that pertains to outbound calls and campaigns.
- License reporting information—In an environment with License Reporting Manager, you can configure a specific instance of ICON to store license reporting data.
In the example shown in the figure above, the ICON instance named ICON 1 handles only the history of configuration changes (configuration data) from Configuration Server. The instance named ICON 2 handles the business data that agents attach to calls and that T-Server includes in TEvents that pertain to those calls (attached data), as well as any other CTI-related data from the same T-Server or Interaction Server. Finally, the instance named ICON 3 handles OCS data only.
Genesys recommends the following role assignments in an environment with multiple ICON instances:
- Do not distribute call-related and party-related information, agent state and login-session state information, and attached data information among separate ICON instances. Assign a single ICON instance to write these three data types from a single T-Server.
- In large configuration environments, Genesys recommends dedicating one of the ICON instances to process configuration data (role = cfg) and disabling configuration data processing in the other ICON instances (role = ~cfg). This improves ICON performance on startup, because the initial configuration loading stage can take quite a long time.
- If multiple ICON instances are writing data to the same IDB, ensure that you assign only one ICON instance to write configuration data to the IDB. See Rules and Restrictions.
- It is preferable not to combine the lrm role with any other in the same instance of ICON. If necessary, you can combine the lrm and cfg roles, but do not combine the lrm role with any other than cfg.
When you assign ICON roles, observe the following restrictions:
- Two or more instances of ICON that perform the same role(s) cannot store information from the same data source(s) to the same IDB(s).
- For example, if you have two ICONs, each configured to perform the gcc, gud, and gls roles, they can write to the same IDB only if they are connected to different T-Servers or Interaction Servers.
- Conversely, if you have two ICONs, each configured to perform the gcc, gud, and gls roles, they can be connected to the same set of T-Servers or Interaction Servers only if they write to different IDBs.
- Two or more instances of ICON that perform the cfg role cannot store configuration information to the same IDB(s).
- Be aware that the default value of the role option is all.
- If you have more than one instance of ICON writing to the same IDB, you must configure the ICON applications so that only one ICON performs the cfg role.