Integration Architecture Overview (PureConnect)
- Ronald Tsang
- Arielle Kaye Odeste
Overview
Integration Points
There are two key integration points with this architecture design:
The PureConnect ICWS Service for RealTime metrics
The PureConnect CIC database
The ICWS integration (PureConnect Adapter)
Data Available from the ICWS is loosely based on the Statistics Catalog provided by the Genesys, for the latest revision of the Statistics Catalog. See this link: Statistics Catalog. eMite categorizes the available statistics based on the modules it uses.
Module Name | Module Description |
|---|---|
Interactions | Subscribes to the interaction data looks at key information such as AcdSkillSet, CallState, ConnectionTime, WorkGroup Assigned, Agent Assigned, Acd Wait Reason, Termination Time (to clear the message) |
QueueStatMetrics | Subscribes to the Queue Stat Metrics available within the Statistics Catalog. |
UserStatMetrics | Subscribes to the User Stat Metrics within the Statistics Catalog |
UserStatus | Subscribes to the User Statuses, looks at key information such as Agent Name, Agent Status |
WorkGroupStatMetrics | Subscribes to the WorkGroup Stat metrics available within the Statistics catalog. |
PureConnect Adapter Behavior
The PureConnect Adapter utilizes the ICWS pub-sub model of retrieving real time data. Its adapter acts like a subscriber and listens to the any new messages or changed states associated to the subscriptions.
Its first step is to attempt to log in using the credentials provided. Once authenticated, it will subscribe to the relevant APIs (based on the Module name). It will keep a running thread associated to the specific API to provide real time notifications.
Multiple ICWS Services - It's common that there are multiple hosts associated to ICWS, usually when the ICWS hosts switch - it provides an error message to notify the subscriber that an alternate host is being used.
In the scenario when it switches it, there will be a period of time where the subscriptions will need to be re-subscribed. This might affect dashboards for a minute.
The PureConnect CIC Database integration
Data Available
Fact Queries | Description |
|---|---|
AgentActivityLog | Provides data around the agent states; usually stored within the Agent Activity tables within the CIC Database |
AgentHistorySummary | Based on the Interval Queue data using the Agent Summary Views |
AgentHistoryDetail | Based on the Interval Queue data using the Agent Detail Views |
QueueHistorySummary | Based on the Interval Queue data using the WorkGroup Summary Views |
QueueHistoryDetail | Based on the Interval Queue data using the WorkGroup Detail Views; "CHKey4" being the key shown (in some contact centers this is used as a Skill field) |
InteractionDetailSegments | Based on the Interaction Detail Data, key components of interaction data is broken down into 'Segments' to provide detailed analysis on transitions of segments within an interaction. |
InteractionDetailSummary | Based on the Interaction Detail Data, key aggregated statistics associated to the interaction for faster statistical analysis over standard metrics. |
Availability - Note that this data's availability can be delayed up to 30 minutes. There is a key dependency on the PureConnect PMQ (Persistent Messaging Queue) on pushing this data into the CIC Database. eMite will poll the latest data that is available at 5 minute intervals. However, it is still dependent on the availability within the database.
Granularity - Pertains to the Interval Queue data dependent indexes. The granularity is specified by PureConnect's settings. If the intervals are setup to be a minimum of 30 minutes, all our data Interval Queue data related indexes will be aggregated at 30 minute intervals.
Application Scaling (Multi-Tier Infrastructure)
The recommended method of scaling the solution once the single tier infrastructure has been maxed out is to naturally introduce multiple servers. To aid this process, it's easiest to understand how to set up each server and their server specifications based upon the core functions of each eMite component and understand which resource it is dependent upon.
Component | Resource Bottleneck | Comments |
|---|---|---|
PureConnect Adapter | CPU | Each module uses a single thread based upon a listening subscription. |
PureConnect CIC Database Integration | RAM | Each fact query will poll data from the database, stores the data in memory and pushes it into the persistent ES store |
RTBI Framework + Index Server | CPU | Handles requests from the dashboard and translates requests to Elasticsearch, dependent upon IIS. |
Elasticsearch | RAM + Disk | Persistent data store; operates better with Linux based servers |
Dashboard | CPU | Direct interface and handles requests from Users/Wallboards, dependent upon IIS. |
eMite Scheduler | CPU | Fires/Schedules jobs based on configurations, runs Adapters. Low resource profile, takes from half to 1 CPU thread. |
eMite Configuration DB | CPU | SQL Server Express capability. Low resource profile, takes up 1 CPU thread. |
Examples
Example Configuration 1: Historical Analysis Orientated Configuration based on 2 servers
Server 1 - eMite Dashboard + Data Onboarding Server
Key Components:
Dashboard
eMite Scheduler
eMite Configuration DB
PureConnect Adapter
RTBI Framework + Index Server
Server 2 - Dedicated Elasticsearch host
Elasticsearch
Example Configuration 2: Real-Time Dashboard Orientated Configuration based on 2 servers
Server 1 - eMite Dashboard
Key Components:
Dashboard
eMite Configuration DB
Server 2 - eMite Onboarding Server
eMite Scheduler
RTBI Framework + Index Server
Elasticsearch
PureConnect Adapter
CIC Database Integration