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
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 persistent cache enables ICON to synchronize configuration data in IDB with current Configuration Server information. 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 renamed. 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 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
- ctive
- failsafe-store-processing
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.
Populating Interaction Data
This section describes aspects of basic ICON functioning to capture information about voice calls.
- For information about how to capture information about multimedia interactions, see Chapter 4 on page 55.
- For information about the way in which ICON handles attached data for voice calls, see “Attached Data Processing for Voice Calls” on page 64.
T-Server TEvents
ICON connects to T-Server and receives notifications, in the form of TEvents, about voice call processing. ICON provides two tracks for operational reporting: call-based and party-based.
Real-time interaction data, such as voice-specific interactions, is stored in the following IDB tables:
| G_IR | G_CALL_ACTIVE | G_CALL_USERDATA |
| G_IR_ACTIVE | G_CALL_HISTORY | G_CALL_USERDATA_CUST |
| G_IR_HISTORY | G_CALL_STAT | G_CALL_USERDATA_CUST1 |
| G_IS_LINK | G_PARTY | G_CALL_USERDATA_CUST2 |
| G_IS_LINK_HISTORY | G_PARTY_HISTORY | G_USERDATA_HISTORY |
| G_ROUTE_RESULT | G_PARTY_STAT | G_SECURE_USERDATA_HISTORY |
| G_CALL |
For detailed information about the tables in IDB in which ICON stores interaction data, see the Interaction Concentrator 8.1 Physical Data Model document for your particular RDBMS.
Extracting Interaction Data
Genesys recommends the following approach to extracting interaction data from IDB:
- Use records in the G_IR table as the base records for data extraction. Use the value of the IRID field as an identifier to determine which records to extract from the G_IR_HISTORY and G_CALL tables.
- After data extraction from the G_CALL table, use the value of the CALLID field as an identifier to determine which records to extract from the other interaction-related tables.
- After data extraction from G_PARTY, use the value of the PARTYID field as an identifier to determine which records to extract from the G_PARTY_HISTORY and G_PARTY_STAT tables.
Stuck Records
Stuck records can result when ICON restarts if, during the time that ICON was shut down:
- A change occurred in agent session data (for example, an agent logged in or out).
- Outbound campaign processing completed.
- A call was distributed from a virtual queue.
- A call or party was deleted.
Starting in release 8.1, Interaction Concentrator stores data on active voice interactions in the G_CALL_ACTIVE and G_IR_ACTIVE tables. After restarting, any interactions remaining in either table will be marked as terminated, with the termination timestamp being the time that Interaction Concentrator restarted.
Stuck calls or parties can also result from stuck calls or parties on the T-Server or Interaction Server side. The disconnection of ICON from T-Server or Interaction Server does not in itself result in stuck calls. ICON can retrieve a snapshot of the active calls and compare this to the calls in memory.
Stuck Call Resolution Procedure
When data is incomplete, ICON uses an internal stored procedure to resolve stuck calls and to determine whether to process the available data. This procedure is based on a timeout mechanism. It allows for continued data processing in the event of partial data loss. Within IDB, ICON marks the records it detects to be incomplete as having low reliability. For more information, see the G_IR.GSYS_EXT_VCH2 field description in the Interaction Concentrator 8.1 Physical Data Model document for your particular RDBMS.
Identifying the DNIS for Outbound Softphone Calls
By default, Interaction Concentrator takes the value of the DNIS (dialed number information service, which is the number that initiates a call) from the AttributeDNIS field in T-Server events and stores it in the CallDNIS field of the G_CALL table. However, because various switches operate differently, the value of the DNIS might be distributed in other attributes and/or in different TEvents. In some cases, the standard AttributeDNIS field may be empty or not present. By appropriately configuring the value of the gts-dnis-detection configuration option in the Application object for the associated switch, you can choose to have ICON take the value of the DNIS from a related subset of TEvents.