Jump to: navigation, search

Attached Data Specification File

This section presents the XML schema definition for processing key-value pairs (KVPs) from the attached data that T-Server or Interaction Server, if applicable, provides with TEvents. If you require ICON to store attached data in IDB, create an attached data specification for ICON to use, based on the information in this section.

About the Attached Data Specification File

The attached data specification file (named ccon_adata_spec.xml by default) maps the key-value pairs (KVPs) in reporting event attributes to IDB tables and fields.

Important
For more information about attached data in Interaction Concentrator, see Processing Attached Data in the Interaction Concentrator User's Guide.

Uniqueness Requirements

When creating the attached data specification file, keep in mind the following requirement for unique key names.

In Vertical Tables

With respect to the vertical tables (that is, the public and secure G_USERDATA_HISTORY and G_SECURE_USERDATA_HISTORY tables), key name uniqueness is determined by a combination of three parameters:

  • <key_name>
  • <source_id> (userdata, reasons, extensions)
  • <storage_id> (public, secure)

So a duplicate is a key name that is the same in all three parts. When it finds a duplicate key name, ICON only uses the first occurrence of the key name definition and rejects the duplicates.

Vertical Tables Example 1:
<public>
<key name = "key1" source="userdata" history ="first"></key>
<key name = "key1" source="reasons" history ="first"></key>
</public>

These records are not duplicates because they have different <source_id> parameters.

Vertical Tables Example 2:
<public>
<key name = "key1" source="userdata" history ="first"></key>
</public>
<secure>
<key name = "key1" source="userdata" history ="first"></key>
</secure>

These records are not duplicates because they have different <storage_id> parameters.

In Horizontal Tables

The horizontal tables may include the following sections:

<call>, <call_cust>, <call_cust1>, <call_cust2>, <mcr-f>, <mcr-l>, <cust-disp-group-n>

For these sections key uniqueness depends on the following parameters:

  • <storage_id> (<call>, <call_cust>, <call_cust1>, <call_cust2>, <mcr-f>, <mcr-l>, <cust-disp-group-n>)
  • <field>

ICON only uses the first occurrence of the key definition and rejects duplicates. The key name parameter is not included when checking for uniqueness in horizontal tables because the same key name can be used multiple times if it is associated with different field or storage_id parameters.

Horizontal Tables Example 1:
<call_cust>
<key name = "key1" source="userdata" history ="first" field="cust-data-1"></key>
<key name = "key1" source="userdata" history ="first" field="cust-data-2"></key>
</call_cust>

These records are not duplicates because they have different <field> parameters.

Horizontal Tables Example 2:
<call_cust1>
<key name = "key1" source="userdata" history ="first" field="cust-data-1"></key>
</call_cust1>
<call_cust2>
<key name = "key1" source="userdata" history ="first" field="cust-data-1"></key>
</call_cust2>

These records are not duplicates because they have different <storage_id> parameters.

Schema Definition

The following is the XML schema definition for your attached data specification.

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema targetNamespace="http://www.genesyslab.com/standards/icon/ed1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:icon="http://www.genesyslab.com/standards/icon/ed1" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:annotation>
 
<xsd:documentation>Attached data configuration specification</xsd:documentation>
</xsd:annotation>

<xsd:simpleType name="AdataHistoryType">
<xsd:restriction base="xsd:string">
               
<xsd:enumeration value="none" />
<xsd:enumeration value="first" />
<xsd:enumeration value="last" />
<xsd:enumeration value="all" />
 
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="AdataCallHistoryType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="first" />
<xsd:enumeration value="last" />
       
</xsd:restriction>
 
</xsd:simpleType>

<xsd:simpleType name="AdataCallFieldType">
<xsd:restriction base="xsd:string">
               
<xsd:enumeration value="customer-segment" />
<xsd:enumeration value="service-type" />
               
<xsd:enumeration value="service-subtype" />
               
<xsd:enumeration value="busines-result" />
               
<xsd:enumeration value="customer-id" />
               
<xsd:enumeration value="transaction-id" />
               
<xsd:enumeration value="cause-id" />
               
<xsd:enumeration value="account-id" />
               
<xsd:enumeration value="destination-id" />
               
<xsd:enumeration value="target-id" />
 
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="AdataCallCustFieldType">
<xsd:restriction base="xsd:string">
               
<xsd:enumeration value="cust-data-1" />
               
<xsd:enumeration value="cust-data-2" />
               
<xsd:enumeration value="cust-data-3" />
               
<xsd:enumeration value="cust-data-4" />
               
<xsd:enumeration value="cust-data-5" />
               
<xsd:enumeration value="cust-data-6" />
               
<xsd:enumeration value="cust-data-7" />
               
<xsd:enumeration value="cust-data-8" />
               
<xsd:enumeration value="cust-data-8" />
               
<xsd:enumeration value="cust-data-10" />
               
<xsd:enumeration value="cust-data-11" />
               
<xsd:enumeration value="cust-data-12" />
               
<xsd:enumeration value="cust-data-13" />
               
<xsd:enumeration value="cust-data-14" />
               
<xsd:enumeration value="cust-data-15" />
               
<xsd:enumeration value="cust-data-16" />
               
<xsd:enumeration value="cust-data-17" />
               
<xsd:enumeration value="cust-data-18" />
               
<xsd:enumeration value="cust-data-19" />
 
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="AdataHistoryRecord">
       
<xsd:attribute name="name" type="xsd:string" />
       
<xsd:attribute name="source" type="icon:AdataSource" />
       
<xsd:attribute name="history" type="icon:AdataHistoryType" />
</xsd:complexType>
<xsd:complexType name="AdataCallRecord">
       
<xsd:attribute name="name" type="xsd:string" />
<xsd:attribute name="source" type="icon:AdataSource" />
       
<xsd:attribute name="history" type="icon:AdataCallHistoryType" />
       
<xsd:attribute name="field" type="icon:AdataCallFieldType" />
</xsd:complexType>
<xsd:complexType name="AdataCallCustRecord">
       
<xsd:attribute name="name" type="xsd:string" />
       
<xsd:attribute name="source" type="icon:AdataSource" />
       
<xsd:attribute name="history" type="icon:AdataCallHistoryType" />
       
<xsd:attribute name="field" type="icon:AdataCallCustFieldType" />
</xsd:complexType>
<xsd:element name="adata_spec">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="public" type="icon:AdataHistoryRecord" />
               
<xsd:element name="secure" type="icon:AdataHistoryRecord" />
               
<xsd:element name="call" type="icon:AdataCallRecord" />
               
<xsd:element name="call-cust" type="icon:AdataCallCustRecord" />
               
<xsd:element name="call-cust1" type="icon:AdataCallCustRecord" />
               
<xsd:element name="call-cust2" type="icon:AdataCallCustRecord" />
 
</xsd:sequence>
 
</xsd:complexType>
 
</xsd:element>
 
</xsd:schema>

Basic Sample

The following is an example of a basic adata_spec.xml file for voice and multimedia interactions. A similar sample file, ccon_adata_spec_example.xml, is available in your ICON installation folder after you install the application.

Attached data that you specify in the <public> and <secure> storage type sections of the specification file applies to all interactions. Attached data that you specify in the <call> and <call-cust> sections applies to voice calls only.

This sample includes examples of keys in a nested key-value list (in this case, attached data from Universal Routing Server [URS]). For more information about specifying URS attached data, see Universal Routing Server Attached Data.

<?xml version="1.0" encoding="utf-8" ?>
<adata_spec>
<public>       
       
<key name = "u_key1" source="userdata"    history ="first"/>
       
<key name="u_key2" source="userdata" history="all" />
       
<key name="RTargetAgentSelected" source="userdata" history="first" />
       
<key name="RTargetUsed/RTargetName" source="userdata" history="first" />
       
<key name="RTargetUsed/RTargetType" source="userdata" history="first" />
</public>

<secure>       
       
<key name="RTenant" source="userdata" history="first" />
</secure>

<call> 
       
<key name = "customer-segment" source="userdata" history ="first" field="customer-segment"/>
       
<key name = "svc_class_cd" source="userdata" history ="first" field="service-type"/>
       
<key name = "CCTP_CALLTYPE" source="userdata" history ="first" field="service-subtype"/>
       
<key name = "cid" source="userdata" history ="first" field="customer-id"/>
       
<key name = "transact_tn_final" source="userdata" history ="first" field="transaction-id"/>
</call>

<call-cust>    
       
<key name = "STATE" source="userdata"  history ="last" field="cust-data-1"/>
</call-cust>

<call-cust1>   
       
<key name = "PegTD" source="userdata"  history ="last" field="cust-data-2"/>
</call-cust1>

<call-cust2>   
       
<key name = "vrapp_ctl_lang" source="userdata"  history ="last" field="cust-data-3"/>
</call-cust2>

</adata_spec>

Multimedia Sample

The following is an example of an adata_spec.xml file that has been modified to capture multimedia-specific attached data. A similar sample file, ccon_adata_spec_mcr_example.xml, is available in your ICON installation folder after you install the application.

With this attached data specification, values for the following predefined and customer-defined keys and attributes are stored in IDB in the GM_F_USERDATA or the GM_L_USERDATA table.

The GM_F_USERDATA table

The following user data key names and event attributes are always stored, whether or not they are defined explicitly in the XML file.

<mcr-f>
<key name = "FromPersonal" source="userdata"  history ="first" field="mcr-from-name"/>
<key name = "FromAddress" source="userdata"  history ="first" field="mcr-from-address"/>
<key name = "Subject" source="userdata"  history ="first" field="mcr-subject"/>
<key name = "Origination_Source" source="userdata"  history ="first" field="mcr-origin-source"/>
<key name = "attr_itx_subtype" source="userdata" history="first"  field="mcr-sub-type”/>
<key name = "
attr_itx_received_at" source="userdata" history="first"  field="mcr-received-at”/>
</ mcr-f>

You can use the XML to define four additional keys that will be stored in the GM_F_USERDATA table. For example, you might define keys similar to the following ones:

<key name = "Custom Key Name - 1" source="userdata"  history ="first" field="mcr-reserved-1"/>
<key name = "Custom Key Name - 4" source="userdata"  history ="first" field="mcr-reserved-4"/>

The GM_L_USERDATA table

The following user data key names are always stored, whether or not they are defined explicitly in the XML file.

<key name = "SuggestedResponseID"       source="userdata"  history ="last" field="mcr-suggested-response"/>
<key name = "AutoResponseID"            source="userdata"  history ="last" field="mcr-auto-response"/>
<key name = "AutoACKID"                 source="userdata"  history ="last" field="mcr-auto-ack"/>
<key name = "Stop_Reason"               source="userdata"  history ="last" field="mcr-stop-reason"/>
<key name = "ContactId"                 source="userdata"  history ="last" field="mcr-ucs-contact-id"/>

Predefined event attribute: attr_reason_system_name

Customer-defined keys: SuggestedResponseID, AutoResponseID, AutoACKID

For information about the IDB fields in which the values will be stored, see IDB Fields.

Sample adata_spec.xml File

In the GM_F_USERDATA section of the sample adata_spec.xml file that follows, the FromPersonal, Subject, and Origination_Source key names are defined, though they would appear in the table in any case. The CalledBack key name is user-defined and would not appear without the explicit definition. The event attributes are also pre-defined. In the GM_L_USERDATA table section, all of the key names are ones that are also predefined.

<?xml version="1.0" encoding="utf-8" ?>
<adata_spec>   

<mcr-f>
       
     
<key name = "FromPersonal" source="userdata"  history ="first" field="mcr-from-name"/>
     
<key name = "FromAddress" source="userdata"  history ="first" field="mcr-from-address"/>
     
<key name = "Subject" source="userdata"  history ="first" field="mcr-subject"/>
     
<key name = "Origination_Source" source="userdata"  history ="first" field="mcr-origin-source"/>
     
<key name = "attr_itx_subtype" source="userdata" history="first"  field="mcr-sub-type”/>
    <key name = "
attr_itx_received_at" source="userdata" history="first"  field="mcr-received-at”/>

</ mcr-f>

<mcr-l>
       
     
<key name = "SuggestedResponseID" source="userdata" history ="last" field=" mcr-suggested-response "/>
     
<key name = "AutoResponseID" source="userdata" history ="last" field=" mcr-auto-response "/>
     
<key name = "AutoAckID" source="userdata" history ="last" field=" mcr-auto-ack "/>
     
<key name = " Stop_Reason " source="userdata" history ="last" field=" mcr-stop-reason "/>
     
<key name = "ContactID" source="userdata" history ="last" field=" mcr-ucs-contact-id "/>

</ mcr-l>

</adata_spec>

Custom Data Sample

The following is an example of an adata_spec.xml file that has been modified for customized attached data processing.

You must create a custom dispatcher stored procedure to process the custom attached data. For an example of the script to create a custom dispatcher stored procedure, see Sample Script for Custom Attached Data.

<?xml version="1.0" encoding="utf-8" ?>

<adata_spec>           

     
<cust-disp-group-1>       
       
<key name = "name1_1" source="userdata" history ="first" field="cust-int-1"></key>
       
<key name = "name2_1" source="userdata" history ="last" field="cust-int-2"></key>
        ...
       
<key name = "name17_1" source="userdata" history ="last" field="cust-int-17"></key>
       
<key name = "name18_1" source="userdata" history ="last" field="cust-str-1"></key>
       
<key name = "name19-1" source="userdata" history ="last" field="cust-str-2"></key>
        ...
       
<key name = "name34_1" source="userdata" history ="last" field="cust-str-17"></key>
     
</cust-disp-group-1>

     
<cust-disp-group-2>       
       
<key name = "name1_2" source="userdata" history ="first" field="cust-int-1"></key>
       
<key name = "name2_2" source="userdata" history ="last" field="cust-int-2"></key>
        ...
       
<key name = "name17_2" source="userdata" history ="last" field="cust-int-17"></key>
       
<key name = "name18_2" source="userdata" history ="last" field="cust-str-1"></key>
       
<key name = "name19_2" source="userdata" history ="last" field="cust-str-2"></key>
        ...
       
<key name = "name34_2" source="userdata" history ="last" field="cust-str-17"></key>
     
</cust-disp-group-2>

...

     
<cust-disp-group-16>      
       
<key name = "name1_3" source="userdata" history ="first" field="cust-int-1"></key>
       
<key name = "name2_3" source="userdata" history ="last" field="cust-int-2"></key>
        ...
       
<key name = "name17_3" source="userdata" history ="last" field="cust-int-17"></key>
       
<key name = "name18_3" source="userdata" history ="last" field="cust-str-1"></key>
       
<key name = "name19_3" source="userdata" history ="last" field="cust-str-2"></key>
        ...
       
<key name = "name34_3" source="userdata" history ="last" field="cust-str-17"></key>
     
</cust-disp-group-16>

</adata_spec>

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 31 May 2018, at 08:01.