FINESSE IN UCCX FAILOVER SCENARIOS
Finesse is the next generation agent desktop available in Contact Center. Rich by its own features, it provides an extensive solution for web based agent desktop.
This short document explains the failover scenarios in Finesse and the expected behavior.
Following are the Service dependencies for Cisco Finesse.
Cisco Unified CCX Cluster View Daemon - Popularly known as the CVD Service, the Finesse Tomcat Service is controlled by the CVD Service.
Condtion: CVD - STOPPED
Impacts:
Finesse Tomcat - STOPPED
Finesse Status Info via the API (http://<ipaddress>:8082/finesse/api/SystemInfo) - NA as there is no finesse tomcat to serve the API calls.
Finesse Administration page (http://<ipaddress>/cfadmin) - NOT ACCESSIBLE as the Finesse Tomcat is down.
Cisco Unified CCX Engine - This is the primary Service for UCCX to cater to calls and agent related activities. This is the core service of CCX.
Condition: Engine - STOPPED
Finesse Tomcat - STARTED
Finesse Status Info via the API (http://<ipaddress>:8082/finesse/api/SystemInfo) - OUT_OF_SERVICE on this node. In case of HA, failover is triggered and the other node will be master and the API will be IN_SERVICE
Finesse Administration page (http://<ipaddress>/cfadmin) - ACCESSIBLE - The cfadmin has Read/Write privileges only from the PUB and Read Only from the SUB as per design.
Cisco Unified CCX Notification Service - Popularly known as the Openfire Service which is responsible for catering the XMPP requests from Finesse, CUIC.
Condition: Openfire - STOPPED
Finesse Tomcat - STARTED
Finesse Status Info via the API (http://<ipaddress>:8082/finesse/api/SystemInfo) - OUT_OF_SERVICE on this node. No failover is triggered.
Finesse Administration page (http://<ipaddress>/cfadmin) - ACCESSIBLE - The cfadmin has Read/Write privileges only from the PUB and Read Only from the SUB as per design.
Based on the above dependencies for Finesse, we can conclude the following expected behavior in failover scenarios:
Let us assume a deployment with the following:
Site A = UCCX PUB with co-res Finesse + CUCM PUB + optional CUCM SUBS
Site B = UCCX SUB with co-res Finesse + CUCM SUBS
WAN between Site A and Site B
Finesse Clients are logged into Site A which is the current Master
Failure Scenario 1 - CCX Engine Failover
Site B becomes the master.
Finesse on Site A becomes OUT_OF_SERVICE.
Finesse on Site B becomes IN_SERVICE within few minutes (no specific time duration)
After Site B comes IN SERVICE, the clients are redirected automatically to this node
Recovery - After Site A comes back up and if Site B goes down, Finesse on Site A comes IN SERVICE and the clients are redirected.
Failure Scenario 2 - Finesse Tomcat Crash
Site A remains Master.
Finesse on Site A becomes OUT_OF_SERVICE.
Finesse on Site B remains OUT_OF_SERVICE (by default when Site A is master)
Sessions will be stuck, no operations can be performed.
Recovery - After Finesse Tomcat comes back up, stuck sessions resume automatically.
Failure Scenario 3 - Finesse Tomcat is IN SERVICE but Finesse Status is OUT_OF_SERVICE.
Site A remains Master.
Finesse on Site A becomes OUT_OF_SERVICE.
Finesse on Site B remains OUT_OF_SERVICE (by default when Site A is master)
Sessions will be stuck, no operations can be performed.
Recovery - After Finesse status comes back up, stuck sessions resume automatically.
Failure Scenario 4 - WAN link between Site and Site B is broken (Island Mode/Split Brain Mode)
Both Site A and Site B become Master
Finesse on Site A is IN_SERVICE
Finesse on Site B is also IN_SERVICE
Clients can connect and operate on both the sites.
Recovery - Once WAN link is up, CCX Converges on primary node and becomes the master. Clients connected to Site B are auto redirected to the primary node.
Failure Scenario 5 - CCX Openfire Service crashes
Site A remains the Master.
Finesse on Site A is OUT_OF_SERVICE
Finesse on Site B remains OUT_OF_SERVICE (by default when Site A is master)
Sessions will be CLOSED.
Recovery - After Openfire comes back up, all clients will need to re-login.
