How ICON Works
This page describes basic Interaction Concentrator functioning—how the Interaction Concentrator server (ICON) collects, processes, and stores configuration and interaction data in Interaction Database (IDB). It contains the following sections:
- ICON Processing
- Populating Configuration Data
- Populating Interaction Data
- Identifying Who Released the Call
- Determining Data Availability and Reliability
- Tracking Multi-Site Call Data Via ISCC
ICON Processing
ICON is a client of the data sources that are specified on the Connections tab of the ICON Application—T-Server, Interaction Server, Configuration Server, or Outbound Contact Server (OCS). ICON monitors events from these data sources, and it processes events for the types of data that the ICON instance has been configured to collect, as specified by the ICON role option.
Processing occurs in the in-memory queue (accumulator), as ICON prepares the data for storage in IDB. For all types of data except configuration data, ICON then writes the prepared data to the persistent queue, and from the persistent queue into IDB.
For information about how ICON completes the processing of configuration data, see “Populating Configuration Data” on page 38.
You can configure the size of the in-memory queue or the interval at which data is written from it to the persistent queue. You can also configure the maximum number of keep-in-memory interactions that concurrently reside in an interaction queue or interaction workbin. Memory optimization configuration options on the ICON Application enable this functionality, which requires Interaction Server release 7.6.1 or higher.
For more information about the persistent queue, see “Persistent Queue and Persistent Caches” on page 17. See also the equivalent section in the overview chapter in the Interaction Concentrator 8.1 Deployment Guide, which provides additional information.
For more information about the ICON configuration options, see the Interaction Concentrator Deployment Guide.
Populating Configuration Data
If configured to do so, ICON gathers information about contact center configuration objects from Configuration Server on initial startup, and keeps track of changes made to these objects throughout its operation by monitoring dynamic real-time notifications from Configuration Server.
ICON collects and stores configuration-related data if the value of the role configuration option is set to cfg or all.
Annex Tab Data
Starting in release 8.1.4, Interaction Concentrator can be configured to collect and store data about changes on the Annex tab of the following objects:
- Persons
- Agent Groups
- DNs
- DN Groups
- Switches
This information enables Genesys Interactive Insights to control visibility of certain data and reports based on attributes such as geographical location, business line, or organization structure. This functionality is available only when ICON has the cfg role and the cfg-annex option configured.
To have Interaction Concentrator track Annex tab data, set the value of the cfg-annex option to 1 (the default value is 0).
Interaction Concentrator stores data for the following occurrences:
- Option created
- Option deleted
- Option renamed
- Option value changed
- Section renamed
- Section deleted
- Configuration object deleted
When an Annex tab configuration option is deleted and then created again, the CREATED and LASTCHANGE fields in the GC_ANNEX table are set to the current timestamp.
For efficient processing, Interaction Concentrator collects and stores section and option change data only for certain sections on the Annex tab. See Table 3 for the sections that are tracked.
Monitored Annex Tab Sections
| Configuration Object | Monitored Sections |
|---|---|
| Person | Any section starting with RPT |
| Agent Group | Any section starting with RPT |
| DN | gim-etl Any section starting with RPT |
| DN Group | Any section starting with RPT |
| Switch | gim-etl Any section starting with agg- |
Occasions When ICON Collects Configuration Data
An ICON performing the cfg role collects configuration-related data: On startup—This is the first deployment of ICON, when the IDB is empty. For more information, see “Reading the Configuration Database on Startup” on page 40. When the persistent cache is unavailable. For more information, see “Persistent Cache Is Not Available” on page 41. Through real-time object change notifications. For more information, see “ICON Receives Dynamic Notifications” on page 41. Upon receipt of the Configuration Server’s history log file. For more information, see “ICON Reads the Configuration History Log” on page 41. Upon user request for resynchronization. For more information, see “User Request For Resynchronization” on page 42. ICON stores configuration-related data in the following tables in IDB: Tables prefixed with GC_—Information about the addition of new objects and the deletion or update of existing objects Tables prefixed with GCX_—Information about object relationships ICON stores information in GC_APPLICATION about the following application types only—Outbound Contact Server, CPD Server, T-Server, and Agent Desktop. For more information about the configuration tables, see the Interaction Concentrator 8.1 Physical Data Model for your RDBMS. Persistent Cache for Configuration Data The ICON instance that performs the cfg role maintains a persistent cache for configuration data. The name of this local file is cfg-sync.db, and it cannot be changed. Data in the persistent cache survives a shutdown and restart of ICON. When it receives data from Configuration Server, ICON writes the data from its in-memory queue to the persistent cache, and then from the persistent cache into the configuration tables in IDB. The persistent cache enables ICON to synchronize configuration data in IDB with current Configuration Server information. The persistent cache contains a timestamp for configuration data changes. On startup, ICON requests from Configuration Server all configuration changes that occurred after that timestamp. ICON then updates the persistent cache, transfers the configuration data to IDB, and continues to monitor real-time notifications from Configuration Server. Reading the Configuration Database on Startup Upon initial startup, or if the local cache file is not available (see “Persistent Cache Is Not Available”), ICON queries Configuration Server for all active configuration objects and active relationships. ICON loads the persistent cache with the information it gathers about these objects and relationships. It then submits the updated transactions to its persistent queue, from which it updates the configuration-related tables in IDB.
Persistent Cache Is Not Available If the persistent cache is not available during a routine startup (that is to say, not the initial startup when the IDB is empty), ICON performs a resynchronization of IDB automatically. When it restarts, ICON verifies the content of the IDB using the last processed real-time notification from Configuration Server. If there is no information about the last notification because the persistent cache is not available, ICON requests all configuration-related information from Configuration Server and recovers the persistent cache. ICON Receives Dynamic Notifications ICON is a client of Configuration Server. Whenever both applications are operating and changes are made to configuration objects or their relationships to other objects within Configuration Manager, Configuration Server immediately notifies its clients of the change. (Genesys does not support such notification if objects are changed directly within the Configuration Database.) The persistent cache is designed to always be synchronized with Configuration Database.When ICON receives the notification, it immediately sends the information to the persistent cache, and records it in the appropriate IDB table using the actual timestamps when the object was changed in Configuration Server. ICON Reads the Configuration History Log Configuration Server maintains a history log for the purpose of enabling clients to restore a session that was terminated by a service interruption and to request any changes to configuration objects that occurred during that the interruption. Dynamic changes made to configuration objects are reported directly by Configuration Server. ICON requests this information from Configuration Server every time it connects to it. With earlier releases of Configuration Server (prior to 7.6), you must ensure that the Configuration Server’s history-log-active option is set to true. If set to false, configuration changes are not recorded in the history log file. Therefore, if ICON lose connection to Configuration Server during this time, it cannot later retrieve information about configuration changes during the time of the disconnect. Setting this option to false, however, does not prevent resynchronization. In Configuration Server release 7.6 or later, you can set the following Configuration Server [history-log] configuration options to control the history log functionality: all expiration client-expiration max-records active failsafe-store-processing If failsafe-store-processing is set to false, the history log database may not be wholly preserved. Refer to the configuration history log section in the Framework Deployment Guide and the history log section in the Framework Configuration Options Reference Manual for more information about these options. User Request For Resynchronization On demand resynchronization occurs when a customer manually runs the resynchronization procedure (see “How to Resynchronize Configuration Data” on page 141 for complete step-by-step instructions). When instructed to start resynchronization, ICON requests all configuration data from Configuration Server and stores it in its persistent cache. At the same time, all other activity—such as dynamic notifications—between ICON and Configuration Server is disabled. ICON then transfers configuration data in the persistent cache to the IDB and begins to monitor real-time notifications from Configuration Server again.