Solution Reference
Introduction
ExpertFlow Dashboards & Wallboards application allows the contact center administrators, supervisors and agents to customize new dashboards as per the needs of the business. Each user can create its own dashboard or admins create a contact center Wallboard to be displayed on a large screen in a room.The application comes with predefined gadgets (display types ) to be added on a dashboard container. The user can then customize the gadget to see the attributes important to the business while hiding the rest of the other attributes.
There are six different templates. So user can create dashboard in six different ways. User can also add gadgets to the dashboard. The gadgets are
|
|
Different dashboards can be added in a Dashboard Group. The link can be generated for the dashboard and dashboard group. The dashboard can also be copied. User can also add Data Services URL in it. Settings are used to update the logo
Business Features
Gadget-Oriented Dashboards
ExpertFlow Dashboards & Wallboards application allows the contact center administrators, supervisors and agents to customize new dashboards as per the needs of the business. Each user can create its own dashboard or admins create a contact center Wallboard to be displayed on a large screen in a room.
The application comes with predefined gadgets (display types and data stats) to be added on a dashboard container. The user can then customize the gadget to see the attributes important to the business while hiding the rest of the other attributes.
Predefined Layouts/ Dashboard Templates
The application also provides some predefined templates to be used while designing the dashboards. Each time the user has to create a dashboard, it chooses a template from the list of predefined templates to define the dashboard layout. Gadgets are then added to the dashboard following the selected template.
Display Types
The display type defines how the data will be displayed in a gadget. A user-defined gadget carries a specific display type and data logic as defined by the user while adding the gadget into a dashboard.
Following are the visuals and display types as available today:
- Pie Chart: Draws the data in the form of a pie chart. Used to display real-time data across particular answer categories. For a call center dashboard, this display type is particularly useful and recommended for viewing the current states of agents in a team using Agent Service.
- Doughnut Chart: Draws the data in the form of a doughnut. Used to display real-time data across particular answer categories. While showing call center stats, this display type is particularly useful and recommended for viewing the current states of agents in a team using Agent Service.
- Scorecards: Each data attribute is represented by a square box called a "scorecard". While viewing call center stats, this display type is particularly useful for viewing real-time queue stats and reporting interval stats (for CCE only), using Queue data service. To view agents states summary, use the Agent Service with the display type Pie/ Doughnut chart.
- Line Chart: Draws a line chart of the selected data statistics based on the specified resolution (daily, hourly). While viewing call center stats, this display type is only relevant while showing historical data of calls based on the Queue data service for calls answered, abandoned, and received.
- Bar Chart: Draws a bar chart of the selected data statistics based on the specified resolution. While viewing call center stats, this display type is only relevant while showing historical data of calls based on the Queue data service for calls answered, abandoned, and received.
- Text Message: To display a static text message on the dashboard.
- Greeting Message: To display a static text message with a greeting such as "Good Morning Team!" on the Wallboard
- Data Table: To display data in a tabular format. While viewing call center statistics, you may see the agent teams summary across all teams in a table, using Agent Data Service.
See the screenshot below.
Data Services
Dashboards or Wallboards refer to a data service (or data source) to report on the statistical data in a gadget. A Data Service is a REST+GraphQL-based microservice that returns real-time and historical data attributes to be displayed on Dashboards and Wallboards.
The application comes with two prebuilt data services that report on queues and agent statistics.
- Queue Service: This reports all the statistics related to the contact center queues/ skill groups such as calls received, answered, abandoned, SLA based on queues or skill groups.
- Agent Service: This reports all the statistics related to the team agents such as Current state, Time in the state, ASA, AHT of agents.
- The Queue Data Service only caters inbound call queues to show the inbound call statistics. Outbound campaign call stats cannot be shown on the Wallboard.
- Any 3rd-party application can also write its own data services to return any real-time and historical data to be displayed on dashboards and wallboards. For instance, a data service connected to the reporting DB of a CRM to report on statistics from the CRM.
Consolidate Call Center Stats
See the consolidated statistics of the call center by selecting all (or not selecting any) skill groups while drawing a gadget on the dashboard. Choose the data aggregation type as one of the following:
- Sum: Choosing this option sums up data of all selected attributes across all skill groups or teams.
- Average: Choosing this option takes an average of all selected attributes across all skill groups or teams. This is also the default aggregation type for the Speedometer display type.
- Count: This counts the occurrences for a particular value in the database and shows the total count. This is the default aggregation type for Pie and Doughnut charts and is currently only applicable to Pie and Doughnut display types.
- While viewing consolidated statistics of the contact center, use the Queue Data Service to view calls summary (such as calls answered/received/abandoned, SLA) and Agent Data Service to view agents statistics (such as logged in, ready, not ready)
- Choose the Scorecard view to show the call stats summary and Pie/Doughnut to show the agent stats summary.
Dashboard Groups
A dashboard group is a group of multiple dashboards that allows the user to set scrolling intervals to display each dashboard in the group one by one.
Generate a URL of the group to see all dashboards in the group in the browser window.
No user authentication is required for now to access the final link of a dashboard group.
Auto scrolling and ordering among dashboards in a group
The auto-scrolling feature allows scrolling dashboards in a group in the sequence and interval as defined by the user in the Dashboard Group definition.
Link sharing of dashboards and dashboard groups
Get the URLs to the dashboards and dashboard groups to see your final dashboard(s) as Wallboards on a big screen in a browser tab.
By default, anyone with the link can access the dashboards. No user authentication is required for now to access the final dashboards.
Light and Dark Color Backgrounds
Choose a dark color theme to display your wallboard with a darker background or a light theme to display it on a lighter background.
APIs for 3rd-parties to report external system statistics
ExpertFlow exposes Data Services model (REST/ GraphQL APIs) to urge external systems to report on their data in the ExpertFlow Dashboard application. The 3rd-party data service should then get itself registered with the ExpertFlow application. The application then calls APIs of the external service to display the statistics from the 3rd-party system.
Note:
- Multi-tenancy on Dashboards is not supported as of today; i.e. a user, for instance, who has the access to the application can view all dashboards irrespective of the tenant or team to which he belongs.
Solution Components and Architecture
Deployment Models
Deployment Architecture
Each solution component is deployed as a stateless microservice in its own Docker container. Expertflow opted for a service-per-container paradigm in which each backend microservice is executed in its separate container with a separate DB layer and interfacing layer.
Each Docker container is deployed with the “Restart Always” policy which causes it to restart automatically on the same VM. Notice that there might be a downtime of a few seconds while restarting the container. This implies that any requests received during the downtime will be rejected.
Services will be available via a virtual IP. If one of the VMs goes down, the virtual IP will route the traffic to the other VM.
draw.io
/pages/viewpage.action?pageId=25172327
Out of Scope
- Component-Level Failover: Failover of individual components is not supported.
- Network-level failover support: The internal network/link between the VMs (or the Docker network) is assumed to be working all the time.
Assumptions
- Both VMs must be on the same subnet. Otherwise, the failover won't work.
- Setting up the DB cluster for MS SQL Server lies under the Customer responsibility.
- Manual intervention will be required when both VMs are down.
Failover scenarios
The following table lists the various failover scenarios and the behavior of the different solution components in each scenario:
| Failover Scenarios | Behavior |
|---|---|
| Synchronizer failover | Synchronizer component runs in an active-active state on both the VMs, using a heartbeat mechanism. The active synchronizer updates its state in the DB after every 2 minutes. |
| Synchronizer restores after failover | If and when the previous, non-active synchronizer comes up again after the failover is successfully completed, the stats appearing on the gadgets become zero for a second once again. It continues to work afterward. |
| VM failover | The application runs on both VMs. When one VM goes down or failover happens, the user can still continue to perform all the CRUD operations on the application front-end. However, since the insertion of the active synchronizer state is updated in the DB after every 2 minutes, the synchronizer stops syncing the stats with Cisco DB for 2 minutes. Once the newly-active synchronizer instance takes full control, all stats become zero for a second and then get refreshed afterward. |
Out of Scope
- Component-Level Failover: Failover of individual components is not supported.
- Network-level failover support: The internal network/link between the VMs (or the Docker network) is assumed to be working all the time.
Assumptions
- Both VMs must be on the same subnet. Otherwise, the failover won't work.
- Setting up the DB cluster for MS SQL Server lies under the Customer responsibility.
- Manual intervention will be required when both VMs are down.
Solution Security
Permissions-based User Access
Note:
- User-based access to selective dashboards is currently not available. That is, dashboards cannot be created or assigned to selective teams.
Please note that each user upon a valid login has access to view all dashboards in the admin application. However, any user can only make changes to dashboards if given the respective permission to do that.
HTTP/S Support
The application supports HTTP and HTTPS. However, to run the application over HTTPS requires to get a domain-signed certificate from a valid CA.
Cisco Contact Center Fail over
When the CCX Master node fails over to the subscriber node, the subscriber node becomes the new Master. Due to this change, calls start landing on the new Master node, hence, all the real-time stats in CCX are refreshed and the count starts from zero as if the deployment is refreshed. This also affects the real-time stats shown on the EF application.
All the real-time data displayed in the following display types may affect with the CCX failover:
- Speedometer
- PIE Chart
- Doughnut Chart
- Scorecards (all variations)
- Data Table
However, all the historical stats in the Wallboard application remain unchanged. This means that the historical views, the Bar Chart and Line Chart, will not be affected by the CCX failover and will continue to show/update the historical data.
CCE Failover handling is not supported for now.
System Limitations
Summary | Description |
| CCX 11.0 is not offering Blind/Direct transfer, so the test cases related to Blind/Direct transfer were discarded in this release. | CCX 11.0 is not offering Blind/Direct transfer, so the test cases related to Blind/Direct transfer were discarded in this release. |
During the load test, we have observed a stats mismatch between Real-time and historical stats in ccx 11.0 | During the load test, we have observed a stats mismatch between Real-time and historical stats in ccx 11.0 |
| SLA for multiple or all queues | If a single queue is selected on the gadget, the SLA is calculated by using one of the configured formulas. See Integration Specifications with CCX to see how SLA is calculated for an individual queue.
|
| Maximum Talk Time across multiple queues | When more than one queue is added to the gadget, the gadget shows the maximum talk time of a call (across all queues). |
| Maximum Wait Time across multiple queues | When more than one queue is added to the gadget, the gadget shows the maximum time a call waited in the queue (out of all queues). |
| Select the Just Scan option using the TV | Just scan is a 1:1 pixel mapping picture size, which eliminates overscan. This is useful when using the TV as a PC monitor because PCs do not have overscan, so some of the PC images would be cut off. By using Just Scan, the picture fills the screen just as it should. |
| Tested on a 32-inches screen | Wallboard displays are tested on a 32-inches screen |
| Font size enhancements are implemented only for the Scorecard gadget | Font size enhancements are implemented only for the Scorecard gadget. See the following limitations in terms of the font size of the data values in the cards:
|
| SSO enabled UCCX/UCCE | User tries to login SSO enabled agent with SSO disabled settings from the environment variables than for UCCX agent will not log in to the wallboard and for UCCE agent is able to login into the wallboard application |
| Timezone implementation is for the historical data | The timezone variable in the Environment Variables applies only to the historical data. The gadgets used for historical data are Line and Bar charts. |
| Use Agent Data Service to view agent stats summary | To view the real-time summary of call center agent states (Ready, Not Ready, Talking), it is suggested to use the Agent Data Service with Pie/Doughnut display type. This is because an agent can have multiple skills and hence, could be a part of multiple queues, viewing agent states summary queue-wise might not depict the true picture of the call center. Use Data table (for individual agent stats) display type to view the individual agent stats team-wise. |
| Date and Time on the dashboard/wallboard on the final link | Date and Time of the Dashboards&Wallboards are based on the machine/browser settings where it is opened. |
| In CCE, an agent in the "Talking" state is also reflected in the "Ready" state | In CCE, an agent in the "Talking" state is also reflected in the "Ready" state. |
| For CCE, a call that gets abandoned after getting routed to an agent by skill group is not available for reporting | A call that gets abandoned by the customer after being routed to an agent is not available for reporting purposes and thus, is not shown in the EF dashboards. However, this may affect the SLA of the skill group. |
| For CCE, the application currently only displays stats based on skill groups and not on precision queues/ call types | For CCE, the application currently only displays stats based on skill groups and not on precision queues or call types. |
| Only the call center calls are available for reporting on EF dashboards & wallboards | Only the inbound voice calls routed by the call center are reported on the dashboards. This means that any internal, ACD, outbound calls or other non-inbound customer calls are NOT available for reporting on wallboards for now. |
The range of speedometer display type provides two options:
| The range of speedometer display type provides two options:
|
| Any changes made to the dashboard configurations are not automatically reflected on the dashboard link | Refresh the browser tab to reflect any changes that are made to the dashboard configuration (such as changes to the name, background color, company logo, dashboard gadgets (added, removed, updated)) |
| Any changes made to the dashboard group configurations are reflected only on the browser refresh | Any changes made to the dashboard group configurations (such as Auto-scroll flag, auto-scroll time changes) are reflected only on the browser refresh |
| Gadgets are not resizeable | Gadgets added in the dashboard are of the fixed sizes. |
| Templates are not resizeable | Templates are not resizeable. The user has to follow one of the fixed templates while creating a dashboard. |
| Free Dashboard Design grid not available to create custom dashboard templates | Dashboards can only be created following one of the predefined dashboard templates. Users cannot create customized dashboard templates for now. |
| Large gadgets in small boxes might disturb the UI | Avoid plotting the gadgets with large visualizations especially the Bar/Line charts and data tables on the dashboard templates having small boxes. |
| Refresh the dashboard final link manually in case of a network glitch, | In case of a network glitch, manual intervention is required to refresh the dashboard view |
| Refresh the dashboard link to see updated or removed gadgets from the dashboard | If the user changes or removes and adds another gadget in a dashboard while the final dashboard link is already opened in a separate window, the user would need to refresh the page to see the updated gadgets. However, the real-time stats are updated automatically without requiring to refresh the page. |
| Refresh the final link to see the updated logo on the Dashboard fullscreen | Refresh the final link of the dashboard to see the modified or updated logo on the Dashboard fullscreen. |
| Dashboard Template once selected cannot be updated later | Once the dashboard template is selected, the dashboard is created with a default name. The user cannot later change the template. To change the template, delete the dashboard and create a new dashboard with the desired template. |
| Default data refresh rate is 5 seconds | The default data refresh rate of the synchronizer is about 5 seconds. However, on the frontend, it takes around 7-10 seconds to refresh each dashboard gadget. |
| Font colors and sizes of gadget titles cannot be changed | You cannot change the font size and color of the gadget titles. The size of the title is adjusted automatically based on the screen resolution. Only the font color of the message text can be changed in the Text Message gadgets. |
If the data is null, gadgets are added without drawing the display types | If the data is null, gadgets are added without drawing the display types (since there’s null data in the gadget) |
| Statistics get refreshed when the Master node is shifted from one node to the subscriber node | All the real-time stats are refreshed and the count starts from zero whenever the master node is shifted to a new Master. |
| Data Service attribute tooltips are not translated | The tooltips displayed for each data service attribute are not translated automatically. This is shown in the same language in which it was mentioned within the data service. |
| The translation is only for the left to right languages | The application supports language translation for all languages mentioned on the Languages Support page. You can place the translation file in the /root/wallboard/docker/translation folder with the name translation_code.json. The frontend should be restarted after placing the translation file in the translation folder. |
| UCCX failover for version 12.5 is not tested | UCCX failover for version 12.5 is not tested |
Solution Prerequisites
Hardware Sizing
The following lists the machine specifications with no other EF components installed on the VM.
vCPU | vRAM | vDisk | Notes |
2 cores (2.60GHz, 2 processors) | 4 GB | 1x100 GB mounted on / | In case MSSQL server is installed on a separate machine |
| 4 cores (2.60 GHz, 4 processors | 8 GB | 1x100 GB mounted on / | If MSSQL server is installed on the same machine as the wallboard stack |
For HA, the same specifications would be doubled for two machines.
To get machine specifications for a larger agent volume and/or with other ExpertFlow products in a co-resident deployment, please get a quote from ExpertFlow or contact your ExpertFlow Account Manager.
Software Requirements
OS Compatibility
The following OS software is required on the server:
Item | Version | Notes |
CentOS | 7.x updated to the latest packages (use Yum update) | The application can deploy in any folder |
Database Requirements
Item | Notes |
| MS SQL Database Server 2019 Express/Standard/Enterprise | For clustered SQL Server installation, the customer will be responsible to provide the cluster. For stand-alone DB deployment, DB (2017 express) will be included within docker containers. |
| Microsoft SQL Server 2017 | Microsoft SQL Server 2017, Microsoft Corporation Express Edition (64-bit) on Linux (Ubuntu 16.04.5 LTS). Only valid in case of a non-HA deployment. |
Docker Engine Requirements
| Item | Notes |
Docker CE 18.06.0+ |
Browser Compatibility
Item | Version | Notes |
Firefox | 108.0.2 (64-bit) | |
Chrome | Not tested | Some UI elements might not render properly. A full-blown testing cycle can be carried out on demand. |
| IE | Not tested | Not supported |
Cisco Unified CCE Compatibility
Tested with the CCE 11.6
Wallboard Reporting/ Display Device
The provisioning of reporting devices is partner/customer's responsibility. For reporting device, one of the following hardware solutions must be provided to display wallboard views in the production environment.
- An existing PC with a pre-installed OS, Monitor or LCD for wallboard display OR
- A Smart LCD with an embedded browser to open the wallboard view OR
- A raspberry pi device with OS installed with an LCD to display.
For raspberry pi device's details, see https://www.raspberrypi.org/products/raspberry-pi-3-model-b/
Port Utilization
The following ports should remain open on the Firewall. The local security policy and any antivirus should also allow open communication on the following ports.
Type | Source Host | Source Port | Destination Host | Destination Port |
HTTP | Enterprise web user | any | Dashboard & Wallboards | 80 |
HTTPS | Dashboards & Wallboards server | any | Dashboard & Wallboards | 443 |
| UDP/TCP | Dashboards & Wallboards server | any | MS SQL Server (CCE DB) | 1433 |
System Access Requirements
Deployment Privileges
Administrative privileges (root) on the machine are required to follow the deployment steps. The Internet should be available on the machine where the application is being installed and connections on port 9242 should be allowed in the network firewall to carry out the installation steps.
Provision Database and a user on SQL Server Cluster
The following database and the privileged SQL user is required to connect to the application database. The application will create its tables and other schema objects itself after connection.
- Create a wallboard application database with the name EFWallboard.
- Create an SQL Server User EFUser with a database role db_owner on the EFWallboard database.
Integration with UCCX
To read CSQs and agents list from CCX, we need admin user credentials to access UCCX Configuration APIs to fetch the list of CSQs, agents, and teams.
To access the Cisco CCX database remotely via the wallboard application, CCX reporting user (uccxhruser) password is required.
Integration with UCCE
Since we need access on the Cisco AW database remotely, create an SQL server user, EFUser, with db_datareader role on the Cisco AW database.
Time Synchronization Requirements
If the system dates and times are not synchronized, the system can produce unpredictable results. Therefore, the EF applications and Cisco Contact Center should have their time zone and date/time properly configured, according to the geographic region and must be synchronized.
To configure the time zone, please see the instructions from the hardware or software manufacturer of the NTP server. The application servers should be synchronized. This synchronization should be maintained continuously and validated on a regular basis. For security reasons, the Network Time Protocol (NTP) V 4.1+ is recommended.
Anchor to this text::