Jump to: navigation, search

Historical Reporting Operational Considerations

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.

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.

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.

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 match up agent and interaction information from separate ICON providers for I-Proxy and T-Controller data, respectively.

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 because ICON receives call data separately from agent activity data. Additional logic enables the transformation job to use endpoint and timestamp information to identify the AGENTID from the G_LOGIN_SESSION table.

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.

Disaster Recovery

Genesys Info Mart does not provide HA of Genesys Info Mart itself. However, you can deploy a second instance of the Genesys Info Mart Server, along with a second instance of the Info Mart database, for Disaster Recovery purposes. See Historical Reporting and SIP Business Continuity.

This page was last edited on June 29, 2018, at 18:59.
Comments or questions about this documentation? Contact us for support!