Solution Architecture
Integration with UCCX
On the backend, the application synchronizes all the changes with UCCX directly over the CCX REST APIs.
The following diagram shows the links of communication between the application and the CCX server.
Integration with UCCX
The direct integration approach saves all changes made through the application configuration interface to the CCX server directly. However, it doesn’t store the changes in the following scenarios:
When UCCX is unreachable
In a UCCX cluster, when any of the UCCX is down and CCX is in a read-only mode
Both of the UCCX cluster nodes are down
On the script level, the UCCX IVR script integrates with Supervisor Tools over the REST APIs to load:
Announcement information
Business calendars on/off settings
Caller profile
The script handles client-side failover of Supervisor Tools and automatically requests to the secondary application server when the primary instance in inaccessible.
Note
In a future release, all the changes made to UCCX through the Supervisor Tools interface will first be stored in the local database and asynchronously be written to CCX if/when CCX is available.
This will help to handle the scenarios where CCX server is down and it becomes impossible to make any modification through the Supervisor Tools unless the primary CCX is up again.
UCCX Failover Cluster Support
The Web App connects to Cisco UCCX API Server for reading and writing data to UCCX.
To detect failover, it continuously monitors the API Server state. In the event of connection failure to the primary UCCX API server, it connects to the secondary API Server to read data from UCCX.
Note
UCCX subscriber becomes read-only and kept locked for any changes during failover by Cisco. So any changes made to UCCX data via the application would not be written to CCX during connection failure and might lead to data inconsistency issues.
Also, note that the application could not handle the failover of CCX to Secondary when the CCX primary node is completely shut down and needs a restart.