Using XMPP to monitor other agents

[joe.outzen]

I've got a client that is looking to run a thick client CRM app side-by-side with Finesse; the CRM app must respond to call events that occur in Finesse.  I know it's not supported to log into XMPP with the same agent as is logged into Finesse (and it clearly doesn't work; Finesse starts experiencing all sorts of problems when you do this).  But what if we log into XMPP with a "fake" agent, and then subscribe to the "real" agent's event streams?

I've tested this in a lab environment, and it seems to work - all instances of the fake agent receive all the events for every real agent it is subscribed to, and the real agents seem to be able to work through Finesse just fine.  So the plan is to have a small pool of fake agents; each CRM app instance logs into XMPP using one of the fake agents and subscribes to the real agent that's running Finesse side-by-side with the CRM app instance.  The CRM app instance would need to filter out the events for all the other agents it's getting (since multiple instances would be using the same fake agent login), but, at least so far, I don't see any other significant challenges with this approach.

Any thoughts as to whether this arrangement would be supported?  Or what sort of impact this might have on the Finesse server (we're talking 500+ simultaneous agents)?

[dekwan]

Hi,

There shouldn't be a problem as long as the total number of agents ("real" and "fake") does not exceed the max number of agents supported on the system. How many agents does each "fake" agent monitor? I think you may need to do some performance tuning to get the right "fake" agent to "real" agent ratio so that there is no impact to the Finesse server. What type of deployment do you have? UCCE? UCCX?

Thanx,

Denise

[joe.outzen]

This is UCCE.  We were thinking each fake agent would be responsible for up to 80 real agents.  So if we have 500 real agents, there would be about 7 fake agents.

[dekwan]

80 real agents per fake agent might be a little bit high if all 80 are continuously on active calls simultaneously. I think it will just come down to performance tuning to find the right fake to real agent ratio.

[joe.outzen]

Do you have an instinct for what a better number might be - at least as a starting point?

[dekwan]

For Finesse with UCCE, it supports supervisor teams to have a maximum of 50 agents. These supervisors would subscribe to the agent's user node to get the agent state events. These events is less frequent and smaller than dialog events (which your application is subscribing to). So I would suggest to start at 50 agents. I am not saying that 80 agents won't work, it would just need to be performance tested.

[joe.outzen]

Completely understood; we'll start at 50 and see what happens.

Thanks!