Jump to: navigation, search

g:tenant-prefix

Section: elasticsearch-<data-source-id>
Default Value: No default value
Valid Values: A string identifying the tenant on a shared Elasticsearch cluster
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.011.15

In Cloud deployments, the option defines a Cloud tenant prefix for Elasticsearch indexes on an Elasticsearch cluster shared across multiple Cloud tenants. The tenant prefix enables Genesys Info Mart to identify Elasticsearch indexes related to the particular Cloud tenant.

If specified, the option value overrides the index-pattern and index-regexp values from the XML source metadata, and the tenant prefix is included in index pattern and regexp strings.

Example

The following table illustrates the effect of specifying a tenant prefix, where the source type is sdr and the source ID is sdr0.

[elasticsearch-sdr0].g:tenant-prefix index-pattern index-regexp
Not defined ‘sdr’-yyyy.MM.dd sdr-*
-my-tenant ’sdr-my-tenant’-yyyy.MM.dd sdr-my-tenant-*

client

Section: elasticsearch-<data-source-id>
Default Value: off
Valid Values: off or any valid location of the cluster node(s) of the Elasticsearch cluster, properly formatted
Changes Take Effect: On the next ETL cycle
Dependencies: None
Introduced: 8.5.009.20

This option specifies one or more nodes in the Elasticsearch cluster that Genesys Info Mart uses to retrieve data from an Elasticsearch database version 5.0 or higher. Genesys Info Mart uses the REST API client to communicate with the Elasticsearch cluster. You must specify the REST API URL address(es) for the REST client in the following format:

  • rest(http://<es-node>:<port>[,http://<es-node>:<port>]*)

Extract, Transform, And Load

Also known as ETL. The ETL processes extract data from various data sources; transform the data into a format and structure that is suitable for subsequent business purposes; and load the data into a target data store (other database, data mart, or data warehouse).



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Integrating CX Contact with Genesys Historical Reporting

This page describes the component and configuration requirements to enable historical reporting on unattempted records.

Overview: Historical Reporting on Unattempted Records

While OCS reports on the outcome of all attempted records and records that failed pre-dial validation checks, it does not report on records belonging to a contact suppression list for the campaign group. This comes from CX Contact. The process is as follows:

  1. When the campaign group is activated, CX Contact writes all information related to unattempted records to an Elasticsearch index (it writes one Elasticsearch document for each suppressed record).
  2. As part of the regular ETL cycle, Genesys Info Mart extracts the data from Elasticsearch and transforms it into Genesys Info Mart LDR_* tables, which you can join with OCS-sourced data on that campaign group's attempted records.

For more information about the Genesys Info Mart database tables, see the Genesys Info Mart Physical Data Model for your RDBMS. For more information about managing the Genesys Info Mart ETL jobs, see the Genesys Info Mart Operations Guide.

Defining Unattempted Records

In this context, an unattempted record refers to a record belonging to a contact suppression list. Records excluded from a campaign because of defined filtering criteria or compliance rules are not considered unattempted records in this context.

The following table summarizes the ways in which records are reported on:

Record Type Reporting Source
Dialed/attempted records OCS > ICON > Genesys Info Mart
Records belonging to a contact suppression list (unattempted records) CX Contact > Elasticsearch > Genesys Info Mart
Records that failed pre-dial validation checks (unattempted records) OCS > ICON > Genesys Info Mart

Enabling Historical Reporting on Unattempted Records

Prerequisites

The following table summarizes the minimum release requirements for the Genesys and third-party components that enable CX Contact historical reporting.

Component Minimum release
CX Contact 9.0.000.09
Elasticsearch 6.3.1
Genesys Info Mart 8.5.012.15
ICON 8.1.514.11 (Recommended minimum for Genesys Info Mart; Required for OCS historical reporting)

Setting up Historical Reporting

To set up historical reporting of unattempted records, you first need to deploy Elasticsearch version 6.3.1. Once this is successfully deployed, CX Contact can write all required indexes to Elasticsearch. No explicit CX Contact configuration is required.

Important
There are index properties that contain personally identifiable information (PII) and therefore need to be considered for the EU General Data Protection Regulation (GDPR). Ensure you configure the Elasticsearch data-retention settings so that indexes are purged before 30 days.

Then, you need to configure Genesys Info Mart to extract the CX Contact reporting data from Elasticsearch, as follows:

  1. On the Options tab of the Genesys Info Mart application object, create a new configuration section, called elasticsearch-ldr0.
  2. Add the client option. For example: elasticsearch-ldr0/client=rest(http://ccs-es.usw1.genhtcc.com:9700)
  3. Add the g:tenant-prefix option. For example: elasticsearch-ldr0/g:tenant-prefix=-2115
Important
Genesys expects that CX Contact reporting on unattempted records will be used to supplement existing Outbound Contact reporting sourced from OCS. Ensure that your deployment has been configured as required for Genesys Info Mart to support Outbound Contact reporting. For more information, see Enabling Reporting on Outbound Contact Activity in the Genesys Info Mart Deployment Guide.


Elasticsearch Index Properties

The following table describes the Elasticsearch index properties, in which CX Contact stores the data about unattempted records. Note the following:

  • The Index property column represents the XPath term Genesys Info Mart uses to extract and map the data.
  • The Info Mart Database Target column indicates the Info Mart database table and column to which the property is mapped.


Index property Description Info Mart Database Target
Index property Description Info Mart Database Target
campaignGroupId
The DBID of the campaign group as assigned by Configuration Server. LDR_CAMPAIGN.CAMPAIGN_GROUP_ID (referenced through LDR_FACT.LDR_CAMPAIGN_KEY)
campaignGroupName
The name of the campaign group. LDR_CAMPAIGN.CAMPAIGN_GROUP_NAME (referenced through LDR_FACT.LDR_CAMPAIGN_KEY)
campaignTemplateName
The name of the campaign template on which the campaign group is based. LDR_CAMPAIGN.CAMPAIGN_TEMPLATE_NAME (referenced through LDR_FACT.LDR_CAMPAIGN_KEY)
chainId
The chain identifier of the record from the contact list. LDR_FACT.CHAIN_ID
chainN
The order of the contact list record within the chain. LDR_FACT.CHAIN_NUMBER
clientId
The unique client identifier of the contact from the contact list. LDR_FACT.CLIENT_ID
contact_info
The contact information (device) for the contact from the contact list. LDR_FACT.CONTACT_INFO
contact_info_type
The type of the contact device. This field is set to one of the following values:
Valid values:
  • No Contact Type
  • Home Phone
  • Direct Business Phone
  • Business With Extension
  • Mobile
  • Vacation Phone
  • Pager
  • Modem
  • Voice Mail
  • Pin Pager
  • E-Mail Address
  • Instant Messaging
LDR_RECORD.CONTACT_INFO_TYPE (referenced through LDR_FACT.LDR_RECORD_KEY)
deviceAreaCode
The area code of the record from the contact list. LDR_DEVICE.DEVICE_AREA_CODE (referenced through LDR_FACT.LDR_DEVICE_KEY)
deviceCountryCode
The country code of the record from the contact list. LDR_DEVICE.DEVICE_COUNTRY_CODE (referenced through LDR_FACT.LDR_DEVICE_KEY)
deviceMask
The bit mask of the record from the contact list. LDR_FACT.DEVICE_MASK
deviceStateCode
The state code (or country code) of the record from the contact list. LDR_DEVICE.DEVICE_STATE_CODE (referenced through LDR_FACT.LDR_DEVICE_KEY)
deviceTimezone
The time zone indicated in the record from the contact list. LDR_DEVICE.DEVICE_TIMEZONE (referenced through LDR_FACT.LDR_DEVICE_KEY)
disposition
The reason for filtering out the record from the campaign during the pre-loading phase, as reported by CX Contact. LDR_RECORD.DISPOSITION (referenced through LDR_FACT.LDR_RECORD_KEY)
groupName
The name of the agent group or place group. LDR_GROUP.GROUP_NAME (referenced through LDR_FACT.LDR_GROUP_KEY)
id
An identifier Genesys Info Mart generates based on the long UUID timestamp reported by CX Contact. LDR_FACT.ID
listId
DBID of the contact list as assigned by Configuration Server. LDR_LIST.LIST_ID (referenced through LDR_FACT.LDR_LIST_KEY)
listName
The name of the contact list. LDR_LIST.LIST_NAME (referenced through LDR_FACT.LDR_LIST_KEY)
postalCode
The postal code of the record from the contact list. LDR_POSTAL_CODE.POSTAL_CODE (referenced through LDR_FACT.LDR_POSTAL_CODE_KEY)
recordId
The identifier of the record from the contact list. LDR_FACT.RECORD_ID
recordStatus
The status of the record from the contact list. This field is set to one of the following values:
Valid values:
  • No Record Status
  • Ready
  • Retrieved
  • Updated
  • Stale
  • Cancelled
  • Agent Error
  • Chain Updated
  • Missed Callback
  • Chain Ready
LDR_RECORD.RECORD_STATUS (referenced through LDR_FACT.LDR_RECORD_KEY)
recordType
The type of the record from the contact list. This field is set to one of the following values:
Valid values:
  • No Record Status
  • Ready
  • Retrieved
  • Updated
  • Stale
  • Cancelled
  • Agent Error
  • Chain Updated
  • Missed Callback
  • Chain Ready
LDR_RECORD.RECORD_TYPE (referenced through LDR_FACT.LDR_RECORD_KEY)
timestamp_iso8601
The timestamp when the event regarding the suppressed contact list records was generated by CX Contact. LDR_FACT.START_DATE_TIME_KEY
This page was last modified on March 5, 2019, at 07:28.

Feedback

Comment on this article:

blog comments powered by Disqus