cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1839
Views
15
Helpful
10
Replies

Evaluate multiple API results

chad_meyer
Level 1
Level 1

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

10 Replies 10

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

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

ptindall
Cisco Employee
Cisco Employee

Here's a simple Studio custom element that can help you iterate through and access fields in the multi-row DB results object.

  

chad_meyer
Level 1
Level 1

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.

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.

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

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

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

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 --

 

  • Cisco/CVP/VXMLServer/common/lib for the runtime
  • Cisco/CallStudio/eclipse/plugins/com.audiumcorp.studio.library.common/lib for Call Studio to get it into the palette

 

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.