start-cfg-sync
Section: callconcentrator
Default Value: -1
Valid Values: -1, 0, 1
Changes Take Effect: Immediately
Specifies whether ICON performs synchronization of configuration data between Configuration Database and IDB. By default, ICON ignores this option.
To start data synchronization, first set the option value to 0; then, change the option value to 1. This action prompts ICON to start the synchronization process. Once started, the synchronization process completes regardless of the subsequent changes to the option value.
- To perform data synchronization, ICON must have a connection to Configuration Server from the moment you change the option value from 0 to 1 until the moment when data synchronization is complete.
Valid Values:
- -1 - ICON ignores this option even when it is defined in the configuration.
- 0 - ICON acknowledges that this option is specified in the configuration and waits for a notification about the option value change from 0 to 1.
- 1 - ICON starts the data synchronization between Configuration Database and IDB under the condition that the value changed first to 0 and then from 0 to 1 during ICON run time. The value of 1 at ICON startup does not trigger the synchronization of configuration data.
start-cfg-sync
Section: callconcentrator
Default Value: -1
Valid Values: -1, 0, 1
Changes Take Effect: Immediately
Specifies whether ICON performs synchronization of configuration data between Configuration Database and IDB. By default, ICON ignores this option.
To start data synchronization, first set the option value to 0; then, change the option value to 1. This action prompts ICON to start the synchronization process. Once started, the synchronization process completes regardless of the subsequent changes to the option value.
- To perform data synchronization, ICON must have a connection to Configuration Server from the moment you change the option value from 0 to 1 until the moment when data synchronization is complete.
Valid Values:
- -1 - ICON ignores this option even when it is defined in the configuration.
- 0 - ICON acknowledges that this option is specified in the configuration and waits for a notification about the option value change from 0 to 1.
- 1 - ICON starts the data synchronization between Configuration Database and IDB under the condition that the value changed first to 0 and then from 0 to 1 during ICON run time. The value of 1 at ICON startup does not trigger the synchronization of configuration data.
role
Section: callconcentrator
Default Value: all
Valid Values: A comma-separated list of valid roles
Changes Take Effect: After restart
Specifies the type of data that this ICON instance processes and stores in IDB. The option value must be lowercase. If you use uppercase letters in the option setting, the role defaults to all.
Valid Values:
- 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.
- lrm - In an environment with License Reporting Manager, stores license reporting data.
- gos - In an environment with the Outbound Contact solution, stores OCS data that pertains to outbound calls and campaigns.
Prefixing an option value with a tilde (~) excludes that type of data from ICON processing, and includes all other types.
Resynchronizing Configuration Changes
Under certain conditions, Interaction Database (IDB) data can fall out of synchronization with Configuration Server data. If this happens, Interaction Concentrator (ICON) instances and downstream reporting applications that rely on ICON data can produce results that are difficult to interpret. Under such conditions, you might consider resynchronizing IDB with the current configuration data.
This page describes the conditions under which you might consider invoking a forced resynchronization of IDB data, and the steps required to resynchronize your IDB. This chapter also describes how to restore Configuration Database should you need to recover its data from a crash. It includes the following sections:
- How Resynchronization Works
- How Long Does Resynchronization Take?
- When to Resynchronize IDB
- How to Resynchronize Configuration Data
- Recommendations for Resynchronization
- Restoring the Configuration Database from Backup
How Resynchronization Works
ICON stores configuration data in two types of tables, one for configuration objects and the other for configuration object relationships. Each configuration data record is therefore defined by a pair of attributes: configuration object type and database identifier (DBID).
During resynchronization, ICON requests all configuration data from Configuration Server and stores it to the local cache. For each pair of attributes (object type and DBID), ICON checks whether it exists in the IDB:
- If it does not exist, a new record is added to the IDB.
- If it does exist, ICON checks if any stored properties are different for this object, and if so, the IDB record is updated.
During resynchronization, ICON suspends receipt of real-time notifications about new configuration object updates from Configuration Server. Configuration Server queues the notifications and delivers them after synchronization completes.
The following table shows some of the information that ICON records in IDB for new, updated, and deleted configuration objects when resynchronization occurs:
- The Field column indicates the column in the targeted GC_* IDB table that ICON will write to when ICON transfers data to IDB.
- Values in the GSYS_EXT_INT1 field indicate the reliability of the timestamps flag (see Reliability Flag for a description of the values).
IDB Stores Object Changes
Field | New Object | Updated Object | Deleted Object |
---|---|---|---|
STATUS | 1 (for active) | 1 (for active) | 2 (for inactive) |
CREATED | sync time | ||
DELETED | null | null | sync time |
LASTCHANGED | sync time | sync time | sync time |
GSYS_EXT_INT1 | 1 | 2 or 3 |
Where no value is provided in the table above, ICON makes no change to the pre-existing value for the associated field.
The following table shows some information that ICON records in IDB for new, updated, and deleted object relationships when resynchronization is run. LASTCHANGED information does not pertain to relationships and thus is not included in the table.
IDB Stores Object Relationship Changes
Field | New Object Relationship | Updated Object Relationship | Deleted Object Relationship |
---|---|---|---|
STATUS | 1 (for active) | 1 (for active) | 2 (for inactive) |
CREATED | sync time | ||
DELETED | null | null | sync time |
GSYS_EXT_INT1 | 1 | 2 or 3 |
Reliability Flag
ICON uses a reliability flag to provide downstream reporting applications (such as Genesys Info Mart) the ability to extract the most reliable data from two separate instances of IDB. The GSYS_EXT_INT1 field stores a value, in all IDB configuration records, which indicates the reliability of the data , as shown in the following table.
Reliability Flag Values
Value | What Value Indicates |
---|---|
0 | The creation or deletion timestamp is reliable. The timestamp was provided by either real-time Configuration Server notifications or the configuration history log. |
1 | The creation timestamp is not reliable. The timestamp corresponds to the initial data load or resynchronization time. |
2 | The deletion timestamp is not reliable. The timestamp corresponds to the initial data load or resynchronization time. |
3 | Neither the creation nor the deletion timestamp is reliable. Both timestamps correspond to the time of the initial data load or resynchronization. |
How Long Does Resynchronization Take
The amount of time required for the synchronization process to complete depends on a number of factors including:
- Performance of Configuration Server
- Network performance
- Size of the Configuration Database
- Performance of the database that hosts the IDB.
Under normal conditions, synchronization should take several minutes.
When to Resynchronize IDB
In some cases, ICON recognizes that the configuration data in the IDB is suspect and produces a special log message (09-25131) to that effect. In most cases, however, no such message will be generated and the decision to resynchronize configuration data is left to your discretion.
The following exceptional circumstances are guidelines you can use to determine if resynchronization is required:
- The RDBMS for the Configuration Database has crashed and you must recover it from backup. See Restoring the Configuration Database from Backup.
- Unavoidable events have prevented ICON from running for a period of time, while Configuration Server was operating and changes were made to configuration objects or their relationships to other objects.
- Configuration tracking for ICON was mistakenly turned off for a period of time while changes were made to configuration-related data.
- ICON ran configuration tracking against the wrong Configuration Database. (This is a user-driven error.)
- ICON has detected an inconsistency in configuration data and logged a message accordingly. (However, the first inconsistency message logged following IDB upgrade is normal and should be ignored.)
- Your downstream reporting application (such as Genesys Info Mart) has detected missing or inconsistent configuration data in IDB. For Genesys Info Mart users, refer to the Genesys Info Mart documentation for more information on this exceptional circumstance.
Setting an Alarm Condition
ICON generates the following Standard-level log event if it suspects that the configuration data in the IDB is inconsistent:
- 09-25131: Configuration data inconsistency is detected; reason: [reason]. Waiting for customer command...
ICON will then stop monitoring configuration changes and move to a waiting state where it will remain until it receives the user command to start resynchronization.
To avoid any loss of data, Genesys strongly recommends that you set an alarm condition using Genesys Administrator Extension. For information about alarm conditions and how to set them, see Alarm Conditions in the Genesys Administrator Extension Help.
Although there is no corresponding Cancel (or clearing) event, ICON generates log event 09-25017 when all the data necessary for resynchronization has been retrieved. This log event can be used as a clearance event (Recommendations for Resynchronization). You can also set an alarm Clearance Timeout which will clear the alarm condition after the specified time (in hours) has expired.
How to Resynchronize Configuration Data
By default, Interaction Concentrator resynchronizes with Configuration Server every time it starts. However, you may need to manually resynchronize ICON and Configuration Server, as discussed in the following section.
If you must resynchronize your configuration data in IDB, do the following while ICON is running:
- Verify that the ICON application with the role configuration option set to cfg, is started.
- In Genesys Administrator Extension, open the ICON Application and set the start-cfg-sync option to 0 on the Options tab.
- Save your update.
- Now change the option value set for the start-cfg-sync option to 1 on the Options tab.
- Apply this new setting.
This action prompts Interaction Concentrator to start the resynchronization process. Once started, the resynchronization process continues until completion regardless of any subsequent changes to the option value. ICON logs a message when synchronization begins and when it completes.
Recommendations for Resynchronization
Consider changing the Configuration Server operation mode to Read-only for the time period during which data resynchronization is performed.
After ICON has retrieved all the data necessary for resynchronization from Configuration Server, ICON generates the following Standard-level log event:
- 09-25017 Configuration objects are reloaded in IDB
At this point, you can change the Configuration Server operation mode back to normal. Consider using this log event as a clearance event when configuring the alarm condition for resynchronization (see Setting an Alarm Condition).
If you are using downstream reporting applications that rely on Interaction Concentrator as their data source, do the following to verify that the data in IDB is ready before you start your ETL engine for the first time after the resynchronization process:
- Check ICON logs for log event: 09-25017, Configuration objects are reloaded in IDB.
- Execute the following SQL statement against IDB:
- select eventid from G_SYNC_CONTROL where providertag = 5
- If the SQL statement returns no records or eventID = 0, the resynchronization is still in progress.
- If the above statement returns a non-zero value for eventID, the resynchronization is completed, and it is safe to run your ETL engine.
If you are restoring data from a backup Configuration Database (after your primary Configuration Database is corrupted, for example), perform the following steps:
- Restore the Configuration Database from a backup copy (see Restoring the Configuration Database from Backup).
- Restart Interaction Concentrator.
- Perform manual resynchronization of configuration data in IDB as described in How to Resynchronize Configuration Data.
Restoring the Configuration Database from Backup
To restore your Configuration Database from backup, do the following:
- Stop Configuration Server.
- Stop the Interaction Concentrator instance that is tracking configuration data changes (role = cfg).
- Restore the Configuration database from backup.
- Make modifications in the Configuration Database to prevent Configuration Server from reusing the same DBID previously reported to ICON (see Modifying the Configuration Database, below).
- Start Configuration Server.
Modifying the Configuration Database
To prevent Configuration Server from reusing the same (already reported) DBIDs, make the following modifications to the Configuration Database.
- Check the last object DBID reported to ICON by Configuration Server by executing the following SQL statement against the IDB (and saving the result):
- select max(id) from IDB_TABLE_NAME
- Replace IDB_TABLE_NAME in the SQL statement with the correct table name (see the Configuration Server Object Types and IDB table).
- If the result of the statement is not Null—that is to say, some records exist in the IDB table—go to Step 3. If the result is Null, repeat Step 1 for the next type of configuration object in the Configuration Server Object Types and IDB table.
- Check the maximum value of the last object DBID by executing the following SQL statement against the Configuration Database:
- select MAX_DBID from CFG_MAX_DBID where object_type = cfg_object_type
- Replace cfg_object_type in the SQL statement with the integer code of the Configuration Server object type (see the Configuration Server Object Types and IDB table).
- If the result of the statement executed in Step 3 is any value—that is to say, not Null—go to Step 6. If the result is Null, go to Step 5.
- Insert a record in the CFG_MAX_DBID Configuration Database table by executing the following SQL statement against the Configuration Database:
- insert into CFG_MAX_DBID (object_type,max_dbid) values (cfg_object_type, max_id + 1)
- Replace cfg_object_type in the SQL statement with the integer code of the Configuration Server object type (see the Configuration Server Object Types and IDB table).
- Replace max_id in the SQL statement with the value of max(id) from Step 1.
- Update the record in the CFG_MAX_DBID Configuration Database table by executing the following SQL statement against the Configuration Database:
- update CFG_MAX_DBID set max_dbid = max_id + 1 where object_type = cfg_object_type
- Replace cfg_object_type in the SQL statement with the integer code of the Configuration Server object type (see the Configuration Server Object Types and IDB table).
- Replace max_id in the SQL statement with the value of max(id) from Step 1.
- Repeat Steps 1 through 6 for each configuration object type stored by ICON.
Configuration Server Object Types and IDB Tables
Object Type | IDB Table Name: IDB_TABLE_NAME | Config Server Object Type: cfg_object_type |
---|---|---|
Switch | GC_SWITCH | 1 |
Endpoint (DN) | GC_ENDPOINT | 2 |
Person (Agent) | GC_AGENT | 3 |
Place | GC_PLACE | 4 |
Groups | GC_GROUP | 5 |
Tenant | GC_TENANT | 7 |
Application | GC_APPLICATION | 9 |
Scripts | GC_SCRIPT | 12 |
Skills | GC_SKILL | 13 |
Action Codes | GC_ACTION_CODE | 14 |
Agent Login | GC_LOGIN | 15 |
Folder | GC_FOLDER | 22 |
Table Field | GC_FIELD | 23 |
Table Formats | GC_FORMAT | 24 |
Table Access | GC_TABLE_ACCESS | 25 |
Calling List | GC_CALLING_LIST | 26 |
Campaigns | GC_CAMPAIGN | 27 |
Treatments | GC_TREATMENT | 28 |
Filters | GC_FILTER | 29 |
Time Zones | GC_TIME_ZONE | 30 |
Voice Prompts | GC_VOICE_PROMPT | 31 |
IVR Ports | GC_IVRPORT | 32 |
IVRs | GC_IVR | 33 |
Business Attributes | GC_BUS_ATTRIBUTE | 35 |
Attribute Values | GC_ATTR_VALUE | 36 |
Objective Table | GC_OBJ_TABLE | 37 |