Jump to: navigation, search

cfg-dbname

Section: callconcentrator
Default Value: cfg-sync.db
Valid Values: Any valid file path, absolute or relative, to the ICON start directory, and any valid file name.
Changes Take Effect: After restart


Controls the name and location of the persistent cache file where Configuration Server data used by ICON is stored locally. You can use this in order to run multiple ICON Applications from the same directory using the same executable. Each ICON Application must have a different value for the three following options: cfg-dbname, pq-dbname, and agent-pstorage-name. If the ICON Applications are configured to write log data to a file or files, these filenames should also be different.

Notes:

  • This file is created only when ICON has cfg role set. For more on this role, see the description of the role option.
  • This file should be on a local hard drive. Avoid placing it on a network or removable drive.

 

agent-pstorage-name

Section: callconcentrator
Default Value: apstorage.db
Valid Values: Any valid file name
Changes Take Effect: After restart


Specifies the name of the persistent cache file that ICON creates and uses to store information about agent login sessions before writing the information to IDB.

pq-dbname

Section: callconcentrator
Default Value: icon_<dbid>.pq
Valid Values: Any valid file name, :memory:
Changes Take Effect: After restart


Specifies the name of the persistent queue file that ICON creates and uses to store information before writing the information to IDB. With the default setting, the file name consists of the prefix icon_, followed by the identifier that Configuration Server assigns to this particular ICON application (the DBID) - for example, icon_161.pq.

The special value :memory: instructs the Persistent Queue Manager to use memory as storage instead of a physical file. Using memory for persistent queue storage may improve ICON performance with regard to database writes. However, this setting increases memory consumption, and you run the increased risk of losing data in the event ICON terminates abnormally.  

Deploying IDB

To create a new Interaction Database (IDB), ask your Database Administrator to create a new database for each IDB instance that you intend to deploy for ICON data storage. You can use any of the supported RDBMSs to host your IDB. Then, initialize each IDB instance, using the appropriate scripts for your environment and following the initialization procedures provided in this topic.

Important
  • If you plan to use Genesys Info Mart for your downstream reporting, ensure that the connection-related settings for the RDBMS server(s) hosting IDB are suitable for Genesys Info Mart. If your IDBs and Info Mart database are not hosted by the same RDBMS instance, ensure that you set connection-related parameters for your IDB RDBMS server(s) as described on Database Tuning in the Genesys Info Mart Deployment Guide.
  • The user account that is created for IDB must have permissions to create database objects such as tables, stored procedures, and sequences.
  • If you are running an Oracle database and are planning to use the native purge locking mechanism, do not initialize IDB until after you install the Oracle DBMS_LOCK package.
  • If you need to reconfigure Interaction Concentrator to work with a different IDB instance, or you re-initialize your IDB, see Changing IDB Instances or Re-Initializing Your Current IDB for instructions.

Internationalization Settings

  • If you require UTF-8 support, you must use Configuration Layer components of release 8.1.3 or higher.
  • If you require Unicode support on a Microsoft SQL database, you must use DB Server 8.1.301.11 or higher. To use Unicode on a Microsoft SQL database, run the CoreSchema_multilang_mssql.sql database initialization script rather than the CoreSchema_mssql.sql initialization script. For additional details on how to configure Interaction Concentrator to store Unicode data, see Configuring for Unicode Support in an Environment with a Microsoft SQL IDB.
  • If you are using a Unicode PostgreSQL IDB, be sure to have client encoding set to UTF-8 as well. If you encounter an error message indicating: invalid byte sequence for encoding, you can enforce client encoding to UTF-8 by setting the PGCLIENTENCODING environment variable to UTF8 for the DB Server environment.
  • If you are running an Oracle database, make sure the NLS_LANG environment variable on the host where DB Server is installed is set to match the character encoding of data in the Oracle database; for example, NLS_LANG=.UTF8. This is especially important when using UTF-8 language encoding, and in all Chinese, Japanese, and Korean language environments. For additional information on specific configuration information for Oracle databases, see the Framework Database Connectivity Reference Guide.
  • In environments with PostgreSQL RBDMS, the IDB processing configuration details (having the role option set to cfg) should be created to use encoding identical to that used by Configuration Server. For example, you may set PostgreSQL database encoding to WIN1252 to use extended ASCII from European languages, or use SQL_ASCII.
  • In environments with PostgreSQL RBDMS, if you require ICON to process user data using any symbols other than ASCII, you must create your PostgreSQL IDB with encoding that supports these symbols. If this encoding is different from the Configuration Server encoding, you must have a separate IDB for configuration details.

For additional details, see Configuring Interaction Concentrator for Multi-Language Support.

Sample Script

Genesys provides the SampleProc_db_type.sql script to help you understand how you can modify the stored procedures for customized attached data processing. Do not execute the sample script during installation. For more information about configuring your ICON application to support customized attached data processing, see Configuring for Attached Data. For an example of a script to create a custom dispatcher stored procedure and custom storage table, see Sample Script for Custom Attached Data.

Initialization Scripts

After you install the ICON application, the scripts subfolder in the directory to which you installed ICON contains a set of initialization, migration, and sample scripts for each RDBMS type. See the Table of Initialization Scripts (below) for a list of these scripts and the purpose of each. In the script names, db_type is a placeholder for the specific RDBMS type (db2, mssql, postgre, or ora [for Oracle]).

Warning
If you are migrating from an existing IDB, do not simply apply all the scripts listed under Initialization Scripts below. To avoid damaging or erasing existing data, follow the migration procedures that are described in Appendix: Migration Procedures.


If you are running Genesys Info Mart 8.1.1 or 8.1.0, see Scripts Required for Environments Running Genesys Info Mart 8.1.1 or 8.1.0 below.

Table of Initialization Scripts

Script Name Description
CoreSchema_db_type.sql (For initial installation only) Creates the core IDB tables and indexes.

To use Unicode on a Microsoft SQL database, run the CoreSchema_multilang_mssql.sql database initialization script rather than the CoreSchema_mssql.sql initialization script.

Upgrade_target_database_version_db_type.sql (For migration only) Upgrades the IDB schema.

The scripts you must execute depend on the releases from which and to which you are upgrading. For more information, see the instructions in Appendix: Migration Procedures.

CoreProcedures_db_type.sql Creates the database schema–specific set of stored procedures that implement core ICON functionality, including the merge procedures and the separate procedures to purge different types of data.
Tip
The script creates default (empty) custom dispatchers named gudCustDISP1 and gudCustDISP2 without first dropping any existing stored procedures. This is to decrease the risk of overwriting customer-created stored procedures. However, if the gudCustDISP1 and gudCustDISP2 custom dispatcher stored procedures already exist in IDB, the script returns an error, which you can safely ignore.
Purge2_db_type.sql or (in special scenarios) Purge2_PartitionType0_ora.sql Creates the gsysPurge80 or gsysPurge81 stored procedure. The version created corresponds to the release of Interaction Concentrator you are installing.


For a non-partitioned Oracle IDB with the partition-type configuration option set to 0, your best performance will be achieved with the Purge2_PartitionType0_ora.sql script (available in release 8.1.505.05 and higher). All other non-partitioned environments should use Purge2_db_type.sql.

CoreSchemaPart_ora.sql (Optional, for Oracle RDBMSs only) Creates tables, sequences, and indexes for use in a partitioned schema.
PurgePart_ora.sql (Optional, for Oracle RDBMSs only) Creates the purgePartitions811 stored procedure required to purge a partitioned Oracle IDB.
Wrapper_for_schema version_db_type.sql Links generically named merge and purge procedures to the equivalent, schema-specific stored procedures in the new set.
drop_schema version_db_type.sql (Optional, for migration only) Removes the set of stored procedures for the specified Interaction Concentrator schema version.
SampleProc_db_type.sql Serves as a sample script, illustrating how to create a custom attached data storage table and modify the custom dispatcher stored procedures.

Scripts Required for Environments Running Genesys Info Mart 8.1.1 or 8.1.0

For environments that include Genesys Info Mart 8.1.1 or an earlier 8.1.x release, run the appropriate script as described in this section every time you migrate to a new release of Interaction Concentrator. (Starting with release 8.1.4, Genesys Info Mart automatically runs the scripts when required.)

Tip
For the location of the scripts and detailed instructions, see the Genesys Info Mart 8.1 Deployment Procedure or the Genesys Info Mart 8.1 Deployment Guide.
  • For a Voice details IDB, use update_idb_for_gim.sql.
  • For a Multimedia details IDB, use update_idb_for_gim_mm.sql.
  • For a Configuration details or an Outbound Contact details IDB, use either update_idb_for_gim.sql or update_idb_for_gim_mm.sql.

Initializing IDB

For a first-time initialization of IDB, follow the RDBMS-specific instructions in the following procedures:

Initializing IDB on DB2

To initialize IDB by running the initialization scripts provided for a DB2 database:

  1. Go to the directory into which you installed ICON.
  2. Go to the scripts\db2 subdirectory.
  3. Execute the following scripts in the order shown:
    1. CoreSchema_db2.sql
    2. CoreProcedures_db2.sql
    3. Purge2_db2.sql—This script is optional. Execute this script if you want to use the gsysPurge80/gsysPurge81 stored procedure in your deployment.
    4. Wrapper_for_schema version_db2.sql—Execute this script if your deployment will use the gsysIRMerge or gsysIRMerge2 merge procedure, or if your deployment will use the gsysPurgeIR, gsysPurgeUDH, gsysPurgeLS, or gsysPurgeOS purge procedures.
  4. To execute the scripts:
    • Insert the following command line at the beginning of each script, providing appropriate values for the placeholders:
    db2 connect to dbname user user using password
    • Use the following command line to load each initialization script:
    db2 -w -td@ -fscript_name

Initializing IDB on Microsoft SQL

To initialize IDB by running the initialization scripts provided for a Microsoft SQL database:

  1. Go to the directory into which you installed ICON.
  2. Go to the scripts\mssql subdirectory.
  3. Execute the following scripts in the order shown:
    1. CoreSchema_mssql.sql or, for environments requiring Unicode support, CoreSchema_multilang_mssql.sql
    2. CoreProcedures_mssql.sql
    3. Purge2_mssql.sql—This script is optional. Execute this script if you want to use the gsysPurge80/gsysPurge81 stored procedure in your deployment.
    4. Wrapper_for_schema version_mssql.sql—Execute this script if your deployment will use the gsysIRMerge or gsysIRMerge2 merge procedure, or if your deployment will use the gsysPurgeIR, gsysPurgeUDH, gsysPurgeLS, or gsysPurgeOS purge procedures.
  4. To execute the scripts, use the following command line to load each initialization script, providing appropriate values for the placeholders:
    sqlcmd -S dbms_server -d dbname -U user -P password -i script_name

where sqlcmd is isql.exe or osql.exe

Initializing IDB on Oracle

To initialize IDB by running the initialization scripts provided for an Oracle database:

  1. Go to the directory into which you installed ICON.
  2. Go to the scripts\oracle subdirectory.
  3. Execute the following scripts in the order shown, unless you are creating a partitioned Oracle database, in which case use the list of scripts that follows the standard set.
    • To execute the scripts, log in to the sqlplus command processor, and type the following at the command prompt:
    @ script_name
    • For a standard Oracle IDB, run the following scripts:
    1. CoreSchema_ora.sql
    2. CoreProcedures_ora.sql
    3. Purge2_ora.sql or Purge2_PartitionType0_ora.sql—These scripts are optional. Execute one of these scripts if you want to use the gsysPurge80/gsysPurge81 stored procedure in your deployment. Purge2_PartitionType0_ora.sql (available in release 8.1.505.05 and higher) is specifically optimized for a non-partitioned Oracle IDB with the partition-type configuration option set to 0. Other environments should use Purge2_ora.sql.
    4. Wrapper_for_schema version_ora.sql—Execute this script if your deployment will use the gsysIRMerge or gsysIRMerge2 merge procedure, or if your deployment will use the gsysPurgeIR, gsysPurgeUDH, gsysPurgeLS, or gsysPurgeOS purge procedures.
    • If you are using partitioning on Oracle, run the following scripts instead:
    1. CoreSchemaPart_ora.sql (instead of CoreSchema_ora.sql)
    2. CoreProcedures_ora.sql
    3. PurgePart_ora.sql (instead of Purge2_ora.sql).Execute this script if you want to purge a partitioned IDB by truncating partitions. This purge method can speed up the purge process in large deployments.

Initializing IDB on PostgreSQL

To initialize IDB by running the initialization scripts provided for a PostgreSQL database:

  1. Go to the directory into which you installed ICON.
  2. Go to the scripts\postgre subdirectory.
  3. Execute the following scripts in the order shown:
    1. CoreSchema_postgre.sql
    2. CoreProcedures_postgre.sql
    3. Purge2_postgre.sql—This script is optional. Execute this script if you want to use the gsysPurge81 stored procedure in your deployment.
    4. Wrapper_for_schema version_postgre.sql—Execute this script if your deployment will use the gsysIRMerge or gsysIRMerge2 merge procedure, or if your deployment will use the gsysPurgeIR, gsysPurgeUDH, gsysPurgeLS, or gsysPurgeOS purge procedures.
  4. To execute the scripts, use the following command line to load each initialization script, providing appropriate values for the placeholders:

psql -h dbms_server -U user --dbname=dbname --file=script_name

Important
PostgreSQL is supported for use with Genesys Info Mart 8.x, which does not use the Interaction Concentrator merge stored procedures.

Changing IDB Instances or Re-Initializing Your Current IDB

If you reconfigure Interaction Concentrator to work with a different IDB instance, or you re-initialize your IDB, Genesys recommends that you delete the following ICON operational files before staring (or restarting) ICON:

  • The Persistent Queue file. The filename is controlled by the pq-dbname option.
  • The agent storage file. The filename is controlled by the agent-pstorage-name option.
  • The configuration storage file. The filename is controlled by the cfg-dbname option.
This page was last edited on February 5, 2020, at 15:37.
Comments or questions about this documentation? Contact us for support!