Finesse Desktop High Availability Failover

[mark.rennie1]

Hi,

We are now looking at ensuring our 3rd party Finesse application handles HA fail-over scenarios correctly.  As I understand Finesse works similarly to CTIOS where there is a primary server and a secondary server.  The secondary server is there to kick in should the primary fail.

On login currently we perform a SystemInfo call to ensure the primary server is IN_SERVICE and we then attempt to make the XMPP connection (using Smack API) to the primary server.

Question - at the initial login stage should we also be logging the agent into the secondary server as well as the primary so they are already connected to both servers so that if one goes down we can seamlessly just switch to the other?

I notice in the Cisco Finesse Web Developer guide there are a number of potential failover scenarios and notifications you may receive:

Scenario	Notification
Cisco Finesse Notification Service goes down	Client loses BOSH connection
Cisco Finesse Tomcat goes down	Finesse user presence is 'unavailable'
Finesse loses connection to the CTI server	Finesse sends SystemInfo notification of OUT_OF_SERVICE

E.g. We are currently connected to primary finesse server...

If our XMPP connection loses connection e.g. (Finesse Notification Service goes down) is the onus on our application at that stage to then switch the Rest API connection & notification service connection over to use the secondary server instead of the primary?

If our we receive a presence unavailable for the Finesse user on the XMPP notification service connection e.g. (Finesse Tomcat goes down) is the onus on our application at that stage to then switch the Rest API connection & notification service connection over to use the secondary server instead of the primary?

If Finesse loses connection to the CTI server and we get an OUT_OF_SERVICE event do we try to connect to the secondary at that stage? Or do we wait for some time and retry? Presumably there will be failover of the CTI server component behind the scenes.

I might have more questions once I get into the deeper detail  but I'm just at the early stages of trying to work out what we need to implement in our code to allow our desktop to handle HA failover scenarios.

Thanks,

Mark

[dekwan · Accepted solution]

Hi Mark,

You are correct that there is a primary and secondary Finesse server. For a UCCE deployment, Finesse follows an active/active model where both servers are connected to the CTI server and will both get all of the CTI messages from UCCE.

Mark Rennie wrote:

Question - at the initial login stage should we also be logging the agent into the secondary server as well as the primary so they are already connected to both servers so that if one goes down we can seamlessly just switch to the other?

The Finesse out of the box desktop only logs in the xmpp connection to the primary server. We have never attempted to log into both, but I would think that getting the notifications twice would be a performance drain.

Mark Rennie wrote:

If our XMPP connection loses connection e.g. (Finesse Notification Service goes down) is the onus on our application at that stage to then switch the Rest API connection & notification service connection over to use the secondary server instead of the primary?

If our we receive a presence unavailable for the Finesse user on the XMPP notification service connection e.g. (Finesse Tomcat goes down) is the onus on our application at that stage to then switch the Rest API connection & notification service connection over to use the secondary server instead of the primary?

If Finesse loses connection to the CTI server and we get an OUT_OF_SERVICE event do we try to connect to the secondary at that stage? Or do we wait for some time and retry? Presumably there will be failover of the CTI server component behind the scenes.

If I am not mistaken, in all three of these situations, the Finesse out of the box desktop switches over to to the secondary server (as long as it is IN_SERVICE). There is indeed a failover of the CTI server component behind the scenes, but it is typically faster for the client to just switch to the secondary. For UCCE, since Finesse is an active/active model, the Finesse data is the same.

Thanx,

Denise

[mark.rennie1]

Thanks for that info.  We'll probably look to detect those scenarios via the notification methods and upon these we can attempt to switch all our rest calls over to the secondary server (if IN_SERVICE) and create a new XMPP connection to the secondary server.

Is there not a risk of a race condition with this approach as in the time the client takes to re-connect the notification service to the secondary server we may have missed events that would have came through in that time period? (E.g. Customer drops the call to the agent and the notification dialog does not arrive while the connection to the notification service is in flux).

Thanks,
Mark

[dekwan]

Hi Mark,

Is there not a risk of a race condition with this approach as in the time the client takes to re-connect the notification service to the secondary server we may have missed events that would have came through in that time period? (E.g. Customer drops the call to the agent and the notification dialog does not arrive while the connection to the notification service is in flux).

You will indeed miss events that come through during the time period that you are connecting. But if you follow your same login process as a normal login, you should be doing a GET on the User, which will get you the latest agent state. Then you should be doing a GET on the User's Dialogs (and a GET on the dialog), which should get your the latest dialog state. When you do that, you should be updating the desktop to reflect the latest state from the GET. Since Finesse on a UCCE deployment is active/active, the secondary Finesse will be at the most updated state and doing a GET will reflect correctly.

Thanx,

Denise

[mark.rennie1]

Thanks Denise. 

I think we've now managed to cover the various scenarios and see the corresponding notifications coming through.

[dekwan]

You're welcome.