09-24-2021 02:33 PM
Hey everyone,
I am working on a CVP 11.6 Call Studio application that will accomplish route a call to an agent based on their Ready time. For a multitude of reasons I am unable to have the system calculate it for me. First the app will perform a SQL query to get a list of applicable agents and will then utilize the Finesse API to get both their agent state along with their <stateChangeTime> element. I am able getting the results from the SQL query and see my xml_result, however am unsure how to parse that information and send to the Finesse API. I could set a counter to send individual API calls to the
https://<finesse_server>/finesse/api/User/<id>
URL, but is there a way to compare multiple <stateChangeTime> elements once I have have all of those values? Open to any insight or efficiencies.
Chad Meyer
09-26-2021 06:48 PM
I don’t even know if this is possible and I don’t think anyone in the world (including Cisco) will be able to tell you if it actually will work. Sorry to be a negative nelly, but here are some of the challenges I see:
- Querying the UCCE DB directly can lead to performance issues.
- You have to think about handling failure of one AW to the secondary AW.
- Let’s assume these agents aren’t getting calls from anywhere else. By the time you get their latest status and send the call to them, they might be in an routable state (picked up the phone, logged out, etc.)
- You have to handle failure on the Finesse side too.
- At any scale you’re going to see issue with the Finesse throttling you.
I would look at any way possible to have ICM do the agent selection since that’s the whole point of the software. However, if I was doing this… I would create a gadget which updates a 3rd party DB with extension and ready time. I would then build an API which the IVR reads.
david
09-27-2021 04:31 AM
Thanks @david.macias. This would be a third party database so no querying on the prod DB would occur. From a call routing perspective I would have ICM logic in place to account for someone changing states to requery the call to another agent as well. Error handling for Finesse is accounted for as well, however you bring up an interesting point on Finesse throttling. Is there any documentation on the API limit of when Finesse would begin throttling connections? I don't see anything in the documentation. I did see a response in the forums located here.
Regarding the gadget, you mean creating a Finesse gadget that would write to a DB? My java is practically non-existent so not really an option unfortunately. I feel like there may be a way with the Math operator to compare all returned values but coming up short so far. I will keep trying and but if I can't get it I will investigate sending agent states and time in state to a DB to be read.
Appreciate the explanation as always!
Chad Meyer
09-27-2021 05:18 AM
09-27-2021 06:20 AM
Thanks @ptindall. I am fairly new to CVP development and have not begun to learn the Java development. Can you advise how I can load this into Call Studio? This example will be beneficial to learning how components are added from a Call Studio perspective, so thank you again.
09-27-2021 07:02 AM
Chad,
Docs below.
But going back to your initial requirement?
Why use a CVP app to route a call to the agent who is Ready the longest?
Is this the ask? This is what a standard ICM Skillgroup Longest Available agent routing will do by default?
Regards,
Gerry
References for Call Studio:
09-27-2021 07:45 AM
Thanks @Gerry O'Rourke. I will give these another pass but were pretty foreign to me on my first pass. The reason for qualifying an agent and doing everything outside of ICM is due to the complex requirements for agent matching. They need to be matched on a multiple criteria which I cannot evaluate through typical means (attributes, consider if...) as there are too many. Their current system allows for an unlimited amount of queue assignments which we obviously cannot accommodate in UCCE so doing some outside the box thinking to come up with a solution.
09-27-2021 09:02 AM
Over Complexity / high levels of flexibility is not necessary a good idea.
I wonder if they REALLY need this or not - but I think this way lies madness.
Good luck!
Gerry
09-27-2021 09:51 AM
If the customer is migrating away from UCCE and wants to make UCCE what they migrated away from, then why migrate in the first place. You or your company need to have a conversation about what UCCE is best at and how to "modernize" what they are doing today. Going down this path is going to yield unhappy customers. I've had customers who have hundreds of agents with thousands of skills. This is unmanageable in the long run and you end up with skill groups of one agent. This is not a call center.
david
09-27-2021 02:09 PM
Chad,
For the sake of your customer and yourself - listen to the good advice from David above!
Lean from years of experience and pain!
Gerry
09-27-2021 08:17 AM
With regard to building custom elements, everyone has their own preferences. A custom element is just standard Java that has to be compiled and the resultant class or JAR file located in the right places (2 of them) in CVP. Personally, I always build custom classes into a JAR file and deploy for common use across all Studio applications --
To build the Java, use an IDE of choice or raw Java commands.
The alternative approach is to deploy the Java classes with the Studio application itself rather than into common locations. That should be covered in the docs if you want to go that way.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide