In order to store voice interaction, agent state, and login session data in IDB, certain configuration settings are required in the Genesys Configuration Layer. This section describes the configuration settings that are required on the ICON Application object.
Connections:
To enable ICON to receive voice data and store it in IDB, you must configure ICON connections to appropriate T-Server instances.
Configuring for Voice Data
Any ICON Application object that has a configured connection to T-Server processes voice interaction data, regardless of the role that has been configured for the ICON application. However, to enable ICON to store interaction-related and party-related data for voice calls in IDB, you must configure the gcc role for the ICON application and associated Database Access Point (DAP).
To capture other types of data for voice objects and interactions, you must configure the appropriate values for the role configuration option.
To enable ICON to identify the party that initiated release of a call, in deployments that support this functionality, set the value of the store-releasing-party option to 1.
Filtering Data
To improve Interaction Concentrator performance, consider excluding certain types of data from IDB storage. Review the filtering options in the filter-data Section, and set appropriate values for your deployment.
If your deployment utilizes the feature to identify which party initiated release of a call, be aware that certain ICON filtering options can effectively disable this functionality.
For call-based reporting, the call-metrics option, in the filter-data configuration section, must be set to 0 (the default). Otherwise, ICON does not write any data to the G_CALL_STAT table.
The following options in the filter-data configuration section affect storage of information in the G_PARTY_STAT table:
*acd-party-history
- acd-party-metrics
- external-party
- observer-party
If you want to implement DN-based reporting on the parties that initiated release of calls, Genesys recommends that you retain the default values for these options, so that you do not filter party information.
For more information about using this feature, see the section about populating voice data in the Interaction Concentrator 8.1 User’s Guide.
In order to store multimedia interaction, agent state, and login session data in IDB, certain configuration settings are required in the Genesys Configuration Layer. This section describes the configuration settings that are required on the ICON Application object.
For more information about multimedia data in Interaction Concentrator, see the chapter about integrating with Genesys eServices/Multimedia and 3rd Party Media in the Interaction Concentrator 8.1 User’s Guide.
[+] ICON Application
To enable ICON to receive eServices and 3rd Party Media data and store it in IDB, you must configure ICON connections to appropriate Interaction Server instances.
Connections
ICON cannot connect directly to an Application object of type Interaction Server. Instead, an Application object of type T-Server must represent Interaction Server.
You must perform the Interaction Server configuration differently depending on your environment, as follows:
- In a single-tenant environment or an environment with a single Interaction Server for each tenant, create a single application of type T-Server for each Interaction Server.
- In an environment with an Interaction Server that serves multiple tenants, you must create for each Interaction Server:
- One application of the Interaction Server type (which can accommodate multiple Tenants).
- As many applications of the T-Server type as there are tenants served by this Interaction Server, one for each tenant. Configure these applications using the actual Interaction Server host and port settings, following the instructions below.
To have ICON recognize connect to Interaction Server, execute the following steps:
- Create an application with application type T-Server in Configuration Server. This might be either in addition to or instead of an Interaction Server-type application, depending on your environment (see the explanation in the bullet-points above).
- On the Server Info tab of this application, specify the host and port parameters for your Interaction Server. If you are using both an Interaction Server-type application and a T-Server-type application, the host and port parameters must be identical.
- Designate the multimedia switch that Interaction Server uses as a switch for the T-Server-type application.
- Add the T-Server-type application to the Connections tab of the ICON application (instead of the Interaction Server application).
- If ICON is already running, restart it.
Important
Starting in release 8.1.2, if host or port information changes for any T-Server listed on the Connections tab, Interaction Concentrator dynamically reconnects using the new connection parameters.
While ICON disconnects from the prior host/port and connects to the new one, there might be a brief gap in data received from the T-Server.
In releases 8.1.0 and 8.1.1, you must restart ICON for updates to listed T-Servers to take effect.
[+] Other Configuration for Multimedia
There are no special requirements for other ICON Application object configuration options. The type of data that ICON captures for multimedia objects and interactions depends on the role configuration option that you configure for the ICON instance.
[+] Configuring for 3rd Party Media
To enable ICON to store information about 3rd Party Media interactions in IDB, you must configure the mcr-om-processing configuration option in the callconcentrator section of the ICON Application object.
Attached data refers to the interaction-related business data that is sent by T–Server or Interaction Server as key–value pairs (KVPs) in the UserData, Extensions, or Reasons attributes in TEvents.
Configuring Interaction Concentrator to store attached data in IDB is a two–part process:
- Specify the attached data key configuration file, which maps the key–value pairs (KVPs) in reporting event attributes to IDB tables and fields. For more information, see “Attached Data Specification File”.
- Specify the attached data configuration settings in the Genesys Configuration Layer. For more information, see “ICON Application”.
- For more information about attached data in Interaction Concentrator, see the chapter about processing attached data in the Interaction Concentrator 8.1 User’s Guide.
- For information about configuring Interaction Concentrator to store user data from EventUserEvents that are distributed by T–Server or Interaction Server from other client applications (for example, from an agent desktop application), see “Storing Agent State and Login Session Data”.
[+] ICON Application
This section describes the configuration settings that are available on the ICON Application object.
ICON Role Configuration Option
For every ICON instance that must store attached data, make sure that the role option on the Options tab of the ICON Application object includes gud in the list of values. If you deploy a single ICON instance for the entire contact center, you can keep the default value (all). For more information, see the description of the role configuration option.
Attached Data Specification File
The adata–spec–name ICON configuration option enables you to point ICON to a different attached data specification file:
Attached Data Configuration Options
The following ICON configuration options enable you to specify what attached data ICON should store, and in what manner:
- adata–default–storage
- adata–extensions–history
- adata–reasons–history
- adata–userdata–history
Review the descriptions and values for the attached data configuration options. Select the appropriate values for your environment, and make related configuration changes on the Options tab of the ICON Application object.
Custom Dispatcher Configuration Options
The following ICON configuration options enable you to specify how the custom dispatcher will process attached data:
- gud–cust–disp
- gud–cust–disp–groups
Review the descriptions and values for the custom dispatcher configuration options. Select the appropriate values for your environment, and make related configuration changes on the Options tab of the ICON Application object.
[+] Overview: Attached Data Specification File
If you require ICON to store attached data in IDB, create an attached data specification for ICON to use. The attached data specification is an XML file stored in the installation directory that you specify when you install the Interaction Concentrator application (see “Deploying Interaction Concentrator”).
- For the XML schema definition for your attached data specification, see “Schema Definition” on page 185.
Important
If you change the XML file, you must restart ICON in order for the changes to take effect.
For sample attached data specifications, see:
- Sample Basic Attached Data Specification
- Sample Specification for Multimedia Attached Data
- Sample Specification for Customized Attached Data
In this section, unlike in the rest of this document, angle brackets indicate required syntax elements and do not indicate placeholders. Italics indicate placeholder text.
This section provides information about the following topics:
[+] Parser Limitations
The ICON XML parser imposes the following limitations:
- ICON ignores unknown attributes if they are present in the specification. When parsing the XML specification, ICON checks only for missing attributes.
- The ICON XML parser does not support namespaces.
- ICON ignores duplicate keys. Only the first occurrence of a key name is used to update the specified field in the database table.
[+] Attribute Values
This section describes the attributes that are used in the XML schema definition.
History Types
The following values can be used as history types:
| none
|
No value for a given key is recorded in IDB.
|
| first
|
Only the first value for a given key is recorded in IDB.
|
| last
|
Only the last value for a given key is recorded in IDB.
|
| all
|
Every change in value for a given key is recorded in IDB. This value applies only to keys that are configured to be stored in the history tables.
|
Storage Types
The table below shows the IDB table in which each attribute is stored.
| Attribute Name
|
IDB Table Name
|
| public
|
G_USERDATA_HISTORY
|
| secure
|
G_SECURE_USERDATA_HISTORY
|
| call
|
G_CALL_USERDATA
|
| call-cust
|
G_CALL_USERDATA_CUST
|
| call-cust1
|
G_CALL_USERDATA_CUST1
|
| call-cust2
|
G_CALL_USERDATA_CUST2
|
| mcr-f
|
GM_F_USERDATA
|
| mcr-l
|
GM_L_USERDATA
|
| user_supplied_name, such as cust-disp-group-n
|
Customer-defined name, as specified in the custom dispatcher.
|
Data Source Types
The following table shows the TEvent attribute from which each attribute is derived.
| Attribute Name
|
TEvent Attribute Name
|
| reasons
|
AttributeReasons
|
| extensions
|
AttributeExtensions
|
| userdata
|
AttributeUserData
|
[+] IDB Fields
The mapping between the field attribute (the logical key name) in the attached data specification and fields in the IDB tables is predefined. This section describes the predefined IDB fields for:
- Voice attached data
- Multimedia-specific attached data
- Custom attached data
Predefined IDB Columns—Voice
For voice calls, the table below shows the predefined IDB field in which each attribute is stored in the G_CALL_USERDATA table.
| Attribute Name
|
G_CALL_USERDATA Field
|
| customer-segment
|
G_CUSTOMER_SEGMENT
|
| service-type
|
G_SERVICE_TYPE
|
| service-subtype
|
G_SERVICE_SUBTYPE
|
| business-result
|
G_BUSINESS_RESULT
|
| customer-id
|
CUSTOMER_ID
|
| transaction-id
|
TRANSACTION_ID
|
| cause-id
|
CAUSE_ID
|
| account-id
|
ACCOUNT_ID
|
| destination-id
|
DESTINATION_ID
|
| target-id
|
TARGET_ID
|
Predefined IDB Columns—Multimedia
For eServices and 3rd Party Media interactions, the following table shows the predefined IDB fields in the GM_F_USERDATA and GM_L_USERDATA tables in which multimedia-specific attributes are stored. All the IDB fields listed in this table can be used for customer-defined keys.
Important
- In this table, the Key Name and Field columns refer to Attached Data Specification attributes.
- For any field attributes marked with an asterisk (*), if it is not mapped to a customer-defined key in the attached data specification file, the IDB field will be populated with the value of the predefined key.
| Predefined Key Name
|
Key Name
|
Field
|
IDB Field
|
| GM_F_USERDATA Table
|
|
|
|
| FromPersonal
|
MyKeyName (customer-defined)
|
mcr-from-name
|
G_FROM_NAME
|
|
|
MyKeyName (customer-defined)
|
mcr-called-back
|
G_CALLED_BACK
|
| Subject
|
MyKeyName (customer-defined)
|
*mcr-subject
|
G_SUBJECT
|
| Origination_Source
|
MyKeyName (customer-defined)
|
*mcr-origin-source
|
G_ORIGIN_SOURCE
|
| FromAddress
|
MyKeyName (customer-defined)
|
*mcr-from-address
|
G_FROM_ADDRESS
|
|
|
MyKeyName (customer-defined)
|
mcr-reserved-1 through mcr-reserved-4
|
G_RESERVED1 through G_RESERVED4
|
| GM_L_USERDATA Table
|
|
|
|
|
|
MyKeyName (customer-defined)
|
mcr-suggested-response
|
G_S_RESPONSE
|
|
|
MyKeyName (customer-defined)
|
mcr-auto-response
|
G_A_RESPONSE
|
|
|
MyKeyName (customer-defined)
|
mcr-auto-ack
|
G_A_ACK
|
| ContactId
|
MyKeyName (customer-defined)
|
mcr-ucs-contact-id
|
G_UCS_CONTACT_ID
|
Predefined IDB Columns—Custom Fields
ICON creates the IDB G_CALL_USERDATA_CUST* fields in the G_CALL_USERDATA_CUST* tables for the custom attributes that you might use in your attached data specification. You can use these fields for both voice and multimedia interactions.
- The G_CALL_USERDATA_CUST* fields are named CUST_DATA_1, CUST_DATA_2, CUST_DATA_3, and so on to CUST_DATA_19.
- As needed, you can use the following attribute names, which correspond to the similarly-numbered G_CALL_USERDATA_CUST* fields: cust-data-1, cust-data-2, cust-data-3, and so on to cust-data-19.
[+] Universal Routing Server Attached Data
Universal Routing Server (URS) distributes a standard set of attached data that usually exceeds reporting requirements for actual deployments.
To improve performance and conserve database resources, ICON does not store values for these keys in the IDB history tables by default, regardless of the value that you specify for the adata-userdata-history option. If you require some or all of the following keys to be stored, explicitly define the respective keys in your attached data specification.
Depending on whether you specify the URS keys in the <public> or <secure> sections of the attached data specification, the KVP data will be stored in the KeyName, Value, and, if you also specify the id attribute, KEYID fields in the G_USERDATA_HISTORY or the G_SECURE_USERDATA_HISTORY table.
For an example of an attached data specification that includes URS attached data keys, see “Sample Basic Attached Data Specification”.
Important
As a result of separate ICON processing, the value of any key that is marked with an asterisk (*) in the tables below is stored in the
G_ROUTE_RESULT table by default. You must nevertheless include this key in the attached data specification file if you want the key value to be stored in the user data history tables.
| source=“userdata”
|
|
|
| CBR-Interaction_cost
|
RTargetAgentGroup
|
RTargetUsed/RTargetType
|
| CBR-IT-path_DBIDs
|
RTargetRuleSelected
|
RTargetAgSelDBID
|
| CBR-actual_volume
|
*RTargetObjectSelected
|
CustomerSegment
|
| CBR-contract_DBIDs
|
*RTargetTypeSelected
|
RTargetPlSelDBID
|
| RStrategyDBID
|
*RTargetAgentSelected
|
RRequestedSkills
|
| ServiceType
|
*RTargetPlaceSelected
|
RTargetPlaceGroup
|
| ServiceObjective
|
*RStrategyName
|
RTargetCampaignGroup
|
| RVQID
|
*RRequestedSkillCombination
|
RouterData70
|
| RTargetObjSelDBID
|
*RTenant
|
|
| RTargetRequested
|
RTargetUsed/RTargetName
|
|
| source=“reasons”
|
|
|
| RTR
|
RTargetObjSelDBID
|
RTargetUsed/RTargetName
|
| CBR-Interaction_cost
|
*RTargetRuleSelected
|
RTargetUsed/RTargetType
|
| CBR-IT-path_DBIDs
|
*RTargetObjectSelected
|
RTargetAgSelDBID
|
| CBR-actual_volume
|
*RTargetTypeSelected
|
CustomerSegment
|
| CBR-contract_DBIDs
|
*RTargetAgentSelected
|
RTargetPlSelDBID
|
| RStrategyDBID
|
*RTargetPlaceSelected
|
RRequestedSkills
|
| ServiceType
|
*RStrategyName
|
RTargetPlaceGroup
|
| ServiceObjective
|
*RRequestedSkillCombination
|
RTargetCampaignGroup
|
| RVQID
|
*RTenant
|
RouterData70
|
| source=“extensions”
|
|
|
| Reasons/RTR
|
*Reasons/RRequestedSkillCombination
|
RTargetUsed/RTargetName
|
| Reasons/ServiceType
|
*Reasons/RTenant
|
RTargetUsed/RTargetType
|
| Reasons/ServiceObjective
|
Reasons/RTargetAgSelDBID
|
Reasons/RTargetUsed
|
| Reasons/RVQID
|
Reasons/CustomerSegment
|
Reasons/RTargetUsed/RTargetName
|
| Reasons/RTargetObjSelDBID
|
Reasons/RTargetPlSelDBID
|
Reasons/RTargetUsed/RTargetType
|
| Reasons/RStrategyDBID
|
Reasons/RRequestedSkills
|
Reasons/CBR-IT-path_DBIDs
|
| *Reasons/RTargetRuleSelected
|
Reasons/RTargetPlaceGroup
|
Reasons/CBR-Interaction_cost
|
| *Reasons/RTargetObjectSelected
|
Reasons/RTargetCampaignGroup
|
Reasons/CBR-actual_volume
|
| *Reasons/RTargetTypeSelected
|
Reasons/RouterData70
|
Reasons/CBR-contract_DBIDs
|
| *Reasons/RTargetAgentSelected
|
ReportingEventSequenceNumber
|
Reasons/RTR
|
| *Reasons/RTargetPlaceSelected
|
Reasons
|
Reasons/RTargetAgentGroup
|
| *Reasons/RStrategyName
|
RTargetUsed
|
Reasons/RTargetRequested
|
This section provides information about the configuration settings in the Genesys Configuration Layer that are related to virtual queue functionality. The default configuration settings enable the storage of virtual queue data, provided that your releases of both Interaction Concentrator and URS support virtual queue functionality.
Configuration settings on the ICON Application object, the virtual queue DN object, and the Switch object enable you to manipulate virtual queue monitoring in the following ways:
- Change the storage mode of Interaction Concentrator.
- Disable monitoring and data storage for a particular virtual queue.
- Disable monitoring and data storage at the switch level—that is, for all virtual queues that belong to a particular switch.
For more information about virtual queue data in Interaction Concentrator, see the chapter about monitoring virtual queues and routing points in the Interaction Concentrator 8.1 User’s Guide.
Universal Routing Server
Although a URS release that supports virtual queue functionality is necessary in order to enable virtual queue monitoring in Interaction Concentrator, no special configuration is required on the URS side.
Beginning in release 7.6, URS provides additional information to ICON regarding the reason for routing an interaction using the AttributeReason of routing events. URS can also attach information to interactions about the targets for which it is waiting. (For more information, see the section about monitoring route results on routing points in the Interaction Concentrator 8.1 User’s Guide.) To make this information available to Interaction Concentrator for downstream reporting purposes, set the following configuration options to true on the URS Application object:
report_reasons
report_targets
For more information about these URS configuration options, see the Universal Routing Reference Manual.
ICON Application
The default settings enable ICON to receive virtual queue data and store it in IDB.
Connections
Although a URS release that supports virtual queue functionality is necessary in order to enable virtual queue monitoring in Interaction Concentrator, ICON receives the data from T-Server or Interaction Server. Therefore, no connection to URS is required.
vq-write-mode
The vq-write-mode configuration option enables you to switch the storage mode for virtual queue data, if necessary. For descriptions of the storage modes, see the chapter about monitoring virtual queues and routing points in the Interaction Concentrator 8.1 User’s Guide. You configure the vq-write-mode option in the callconcentrator section on the Options tab of the ICON Application object.
extended-route-
result
The extended-route-result configuration option specifies whether ICON stores extended routing results (from URS) in IDB. You configure extended-route-result in the callconcentrator section on the Options tab of the ICON Application object.
To store extended route results in IDB, ICON requires URS release 7.6 and Interaction Server release 7.6.000.18 (or higher).
Interaction Concentrator functionality related to storing Virtual Queues history in the G_ROUTE_RES_VQ_HIST table requires URS release 8.1 or higher.
For more information about these options, see page 134.
Virtual Queue DN
Unless you need to disable monitoring and data storage for a particular virtual queue, no configuration is necessary for the DN object that represents this virtual queue in the Configuration Layer.
monitor
The monitor configuration option enables you to turn off ICON monitoring and data storage for a particular virtual queue, if necessary. If the option is set to 0, ICON does not register with T-Server to receive events that pertain to this virtual queue. You configure the monitor option in the gts section on the Annex tab of the DN object that is configured for this virtual queue. For more information about this option, see page 170.
Switch
Unless you need to disable virtual queue monitoring and data storage for a particular switch, no configuration is necessary for the corresponding Switch object in the Configuration Layer.
support-dn-type-5
The support-dn-type-5 configuration option enables you to turn off ICON monitoring and data storage for all virtual queues that belong to a particular switch, if necessary. If the option is set to 0, ICON does not register with T-Server to receive events that pertain to virtual queue DNs that belong to this switch. In this case, ICON does not process or store virtual queue–related TEvents, even if the monitor option is set to 1 for any of the virtual queues that belong to the switch. You configure the support-dn-type-5 option in the gts section on the Annex tab of the Switch object that is configured for this switch. For more information about this option, see page 167.
