Michael.Shrall | 2020-03-05 15:07:05 UTC | #1
We have setup a data action which calls a platform API call to check if any agents are available in a queue with a specific skill requirement. We use this data action in a Dialer Pre-Call Rule to determine if there are any agents available with the required skill before dialing that call. If it returns 0, it skips the record and goes to the next one.
It is all working great but given the speed of dialer progressing through the list, the API limits are being hit.
Any suggestions on a way to work within the confines of the API limit but still be able to check for agent + Skill + queue availability before making the call?
tim.smith | 2020-03-06 14:03:19 UTC | #2
This is a good use case for creating a persistent service to track this information. The service can use v2.users.{id}.activity to determine agent status (presence, routing status, queues) and a conversation topic on the user or queue to track the conversations. Because the service will receive information in notifications, it won't hit rate limits and can keep up with a much greater amount of traffic. The data action would then make a request to your service to look up the information from its cache instead of hitting the Genesys Cloud API.
Jason_Mathison | 2020-03-06 15:56:45 UTC | #3
Probably need to take this to support to figure out which rate limit you are exceeding. Tim's idea would work if the limit is with Data Actions hitting public API. However, if this is a Dialer rate limit it wouldn't help at all.
Michael.Shrall | 2020-03-06 17:27:17 UTC | #4
That is a really good point Jason. We actually ran the data action manually through the UI when the campaign was running to see what was happening and found the error. It is pasted below. Does this point to which limit is being hit?
tim.smith | 2020-03-06 17:41:48 UTC | #5
I assume that's in response to an analytics query. That is a rate limiter that's being applied directly by the analytics service, not the main API limiter. As the error notes, analytics has a limit on how many contains queries you can do. You may be able to alleviate your problems by using a different query that doesn't use contains. Using matches or [not] exists should be less expensive and should avoid the analytics service rate limit.
agilio | 2020-03-06 18:08:14 UTC | #6
Tim this is the request URL we are using
/api/v2/routing/queues/${input.QueueId}/users?pageSize=15&skills=${input.countrySkill}%2C${input.languageSkill}&routingStatus=IDLE
tim.smith | 2020-03-06 18:20:27 UTC | #7
That's likely using analtyics behind the scenes to fetch some of the data. I don't know if the query that's being used could avoid using contains, but that's a discussion that would need to go through Care on the grounds of reporting a potentially inefficient API operation.
This would also be a good use case to share on https://purecloud.ideas.aha.io/ideas that can help drive new API and Outbound features.
anon28066628 | 2020-03-09 14:08:19 UTC | #8
That resource was the subject of this deprecation:
https://developer.mypurecloud.com/forum/t/removing-totals-counts-from-the-queue-users-get-query/6106
I believe the deprecation is on hold at the moment, but I wouldn't expect this endpoint to be a long-term solution.
system | 2020-04-09 14:08:23 UTC | #9
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 7272