Document toolboxDocument toolbox

(13.2) Solution Architecture

Owned by Ammara Ammara Bokhari
Last updated: Jan 11, 2024

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.