Revision as of 23:38, June 19, 2018 by Tanyai (talk | contribs) (Removed ICON HA heading as a duplicate)
Jump to: navigation, search

geo-location

Section: gim-etl
Default Value: “”
Valid Values: Any string
Changes Take Effect: For an extraction DAP, at the next run of the extraction job for the particular data domain; for the Info Mart DAP, on restart of the Genesys Info Mart Server.
Introduced: 8.1.2

On the extraction DAP, specifies the location of the IDB. On the Info Mart DAP, specifies the location of the Info Mart database. Genesys Info Mart compares the string value of the option on the Info Mart DAP against the value of the geo-location option in redundant extraction DAPs. If the values are the same, the IDB for which the extraction DAP provides the connection information is considered to be local; if the values are not the same, the IDB is considered to be remote.

In an HA environment, Genesys Info Mart uses geolocation as a tie-breaker to determine the best IDB from which to extract data: If data-quality criteria do not identify one IDB as the best, Genesys Info Mart gives preference to the local IDB.

Historical Reporting Operational Considerations

[READY FOR REVIEW]

Operational Considerations for ICON in a Cluster Environment

Filtering Event Subscription

To ensure that network traffic is as efficient as possible, ICON in a Cluster environment requests that only a subset of the possible TEvents be sent by SIP Server.

User Data Subscriptions

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. To lighten network load, by default ICON collects only a certain set of user data types.

To add other types, configure the ccon_adata_spec.xml file, as described in Enabling Storage of User Data. For a detailed discussion of attached data, see Processing Attached Data in the Interaction Concentrator User’s Guide.

Operational Optimization

To optimize operations and prevent data loss, additional functionality is implemented in Interaction Concentrator. Improvements in the following areas ensure that ICON observes stricter startup conditions and sustains short network disconnects:

PQ File

To prevent data loss at the pq file level, ICON does not start and does not attempt to connect to SIP Server if the pq file is not created or opened correctly on startup. In case of a problem, a Standard-level log event (ID# 09-25024) notes the error.

Event Backlog

To prevent data loss during a temporary disconnection from a client such as ICON, SIP Server stores all events in its cache and automatically sends them to the client when the connection is restored.

Disaster Recovery

In a Cluster environment, Interaction Concentrator is set up locally with each SIP Server in a cluster node. In a disaster recovery scenario, calls move to SIP Servers in the Cluster nodes within the still-active data centers and the ICON instances located in those nodes store data in the associated IDBs as usual. You can replicate IDBs for additional data redundancy, if required.

High Availability

As in a non-Cluster environment, Interaction Concentrator supports high availability (HA) deployments of SIP Server. HA for the SIP Server that operates in Cluster mode functions in the same way as for the non-Cluster SIP Server. A number of HA options are available for SIP Server, as documented in the SIP Server High-Availability Deployment Guide.

Redundant Deployment of Interaction Concentrator

Interaction Concentrator has no specific features for HA deployment in a Cluster environment. As in a non-Cluster environment, a redundant pair of ICONs receives interaction-related events from the same SIP Server. Both ICONs in the HA pair operate in parallel as stand-alone servers; they process incoming data independently and store data in two independent IDBs. The downstream reporting applications are responsible for managing extraction of reliable data.

As a general recommendation, deploy one HA pair of Interaction Concentrator instances per SIP Server (or HA pair of SIP Servers). As shown in the diagram, each Interaction Database instance should be located at the same site as the ICON Server writing to it.

ICON sip cluster HA.png

For a complete description of Interaction Concentrator HA functionality, see The Interaction Concentrator HA Model in the Interaction Concentrator User’s Guide.

Operational Considerations for Genesys Info Mart in a Cluster Environment

The differences in data processing for Genesys Info Mart operating in a SIP Cluster environment arise from the need to:

  • Report on resources that are not configured in the Configuration Layer ("DBID-less" resources).
  • Match up agent and interaction information from separate ICON providers for I-Proxy and T-Controller data, respectively.

DBID-less Resources

Writer's Note: Is this section still applicable? If so, please suggest revisions as necessary.

In the absence of a DBID that Configuration Server assigns in a non-Cluster environment to uniquely identify resources, population of the RESOURCE_ table is the key difference. Starting with release 8.1.2, Genesys Info Mart creates RESOURCE_ records on demand when the transformation job encounters DBID-less resources during voice or agent-state transformation.

For more information about the resulting data in the RESOURCE_ table, see Resources and Resource Groups.

Matching Agents with Interaction Information

In all deployments, agent information and interaction information for Genesys Info Mart come from different ICON providers (gls and gcc). In a non-Cluster deployment, the gcc provider reports the AGENTID in the party record. In the SIP Cluster solution, there is no AGENTID in the party record. Additional logic enables the transformation job to use endpoint and timestamp information to identify the AGENTID from the G_LOGIN_SESSION table.

Writer's Note: Explain here why the timestamp is important? From TOI: "By the time the interaction reaches the endpoint, the session has lasted longer than [gim-etl]:max-session-duration-in-hours. In that case GIM will not find the session, and IRF.RESOURCE_KEY will point to the endpoint (IRF.MEDIA_RESOURCE_KEY) rather than the agent."

Note: When it is deployed in a mixed environment, Genesys Info Mart extracts both Cluster-related and non-Cluster-related data from different IDBs and uses the appropriate logic for processing available data.

High Availability

There are no special requirements for Genesys Info Mart to support HA of Interaction Concentrator and upstream data sources in SIP Cluster deployments. Similarly, there are no special features of Genesys Info Mart HA support that apply for SIP Cluster.

As for any deployment with distributed data centers, you can configure the geo-location option in the gim-etl section on the extraction and Info Mart Database Access Points (DAPs) to enable the Genesys Info Mart extraction job to give preference to the IDBs that are local to the Info Mart database. This only applies to the deployments where two Interaction Concentrator instances that operate as an HA pair are located at different sites; this might be the case with Interaction Concentrator instances that collect data regarding virtual queue (VQ) DN activity when the VQ SIP Servers from an HA pair are located at different sites.

Standby Server and Disaster Recovery

Genesys Info Mart does not provide HA of Genesys Info Mart itself. However, as described in Standby Genesys Info Mart Server Instance in the Genesys Info Mart Deployment Guide, you can deploy a second instance of the Genesys Info Mart Server, along with a second instance of the Info Mart database, to act as a standby.

Starting with release 8.1.2, Genesys Info Mart supports the use of Oracle GoldenGate to replicate data to a standby Info Mart database, to enable timely disaster recovery with minimal data loss. For more information about disaster recovery with Oracle GoldenGate, see Historical Reporting and SIP Business Continuity.

Comments or questions about this documentation? Contact us for support!