cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
885
Views
0
Helpful
2
Replies

Finesse web API - Limit ?

Hello,

I actually coded a basic Windows Application to display agent status in the System tray (icon Green/Red/Black depending on the status). My client wanted to see the status without going back on Finesse web page...

This status is read through Finesse API web service (HTTPS GET with read only user : http://finesse-server1/finesse/api/User/My_user ) and makes a refreshing request every 3 seconds.

Today our deployment model is a Cisco Finesse cluster for 2000 thousands agents.

I was wondering if there was an official limit for the web service or if these requests could affect the Finesse agent Service ? I cannot find this information in Cisco documentation.

Thank you in advance.

Best regards,

JP

1 Accepted Solution

Accepted Solutions

dekwan
Cisco Employee
Cisco Employee

Hi,

Looks like this question was posted twice, so I will delete the other one to avoid confusion.

I was wondering if there was an official limit for the web service or if these requests could affect the Finesse agent Service?

There isn't any limit with the number of REST APIs that are sent to the web services. GET requests are pretty lightweight and typically won't affect the webservices. The best thing is always to performance test it and see. If you start to see issues, then you may need to scale back.

Today our deployment model is a Cisco Finesse cluster for 2000 thousands agents.

I just want to make sure, but you mean 2000 agents right? not 2000 thousands?

Also, I am assuming that these agents are using the Finesse out of the box desktop. Have you thought of piggybacking on the Finesse notifications that are received when the agent state changes by creating a custom gadget? There have been a couple of developers who have something similar. What they would do is in the custom gadget, which can listen to the agent state events, the code will call a HTTP GET on a url such as http://localhost:<unique port> depending on which state it changes to. The windows application would listen to these ports to know which agent state the agent is in and act upon that. By doing so, you won't have to poll the GET User API and the desktop already receives these agent state events, so it doesn't add anything additional. This is just a suggestion.

Thanx,

Denise

View solution in original post

2 Replies 2

dekwan
Cisco Employee
Cisco Employee

Hi,

Looks like this question was posted twice, so I will delete the other one to avoid confusion.

I was wondering if there was an official limit for the web service or if these requests could affect the Finesse agent Service?

There isn't any limit with the number of REST APIs that are sent to the web services. GET requests are pretty lightweight and typically won't affect the webservices. The best thing is always to performance test it and see. If you start to see issues, then you may need to scale back.

Today our deployment model is a Cisco Finesse cluster for 2000 thousands agents.

I just want to make sure, but you mean 2000 agents right? not 2000 thousands?

Also, I am assuming that these agents are using the Finesse out of the box desktop. Have you thought of piggybacking on the Finesse notifications that are received when the agent state changes by creating a custom gadget? There have been a couple of developers who have something similar. What they would do is in the custom gadget, which can listen to the agent state events, the code will call a HTTP GET on a url such as http://localhost:<unique port> depending on which state it changes to. The windows application would listen to these ports to know which agent state the agent is in and act upon that. By doing so, you won't have to poll the GET User API and the desktop already receives these agent state events, so it doesn't add anything additional. This is just a suggestion.

Thanx,

Denise

Hi Denise !

Thank you for your detailled answer ! 

You're right, we have a 2000 agents deployment !

Your last idea is very interesting. I probably will explore this way...

Thank you again !

Kind regards,

JP