robm | 2020-09-07 14:13:08 UTC | #1
Hello,
We are a Data Action to check the amount of agents with the correct skill available in a queue for a preview outbound campagne (In a pre-call rule). The mechanism works perfectly, I only wonder if there is a limit on the amount of requests we can use per minute/second.
We haven't reached any limit yet, and it might be that we cannot reach this while testing. But we do not want surprises when going live. We run a COVID-19 tracing contact center and when we need to scale up we would like to know the platform can handle this.
The inin-ratelimit-allowed is set to 300, but I read in the docs. that these headers are deprecated and not used anymore. And developers should use the retry-after. Does this also apply for Data Actions directly on the platform?
The API request I use is /api/v2/routing/queues/${input.queue_id}/users?skills=${input.skill}&routingStatus=${input.status}
Thanks. Best regards Rob
anon11147534 | 2020-09-07 17:03:20 UTC | #2
Hi Rob,
The rate limit isn't given per API because the formula to calculate the limit can be complex and some micro-services have varying rates that change based on server load.
This formula also applies to Data Actions. The best practice to follow is handling a 429 error and employing an exponential back-off strategy using the retry-after header if you become rate-limited. See the Rate Limits Guide for more info on rate limiting.
Richard.Schott | 2020-09-08 14:04:58 UTC | #3
Rob,
yes, rate limits still apply to the Genesys Cloud Data Action integration, as that integration is still making public API calls back into Genesys Cloud Public API. In addition to the Public API rate limits, there are limits placed on Data Action executions regarding the number of concurrent Data Actions that can be in flight, as well as the number of Data Actions that can be executed on a per minute basis (the concurrency limit is generally only ever hit if you are connecting to a poorly performing api resource that takes quite a while to respond).
There is some work in flight that will make the rate limits available on specific API resources more transparent, but it will not be generally available until later this year.
A best practice to keep in mind is that call flows should have a fallback plan in case a data action fails to return the expected result (a default routing, null check within the call flow, etc.). This will allow the routing flow to continue to operate in the event of an outage of the external resource, unavailable data from the API, or running into various rate limits; this is really an extension of the API best practices for making a resilient client consuming API resources.
robm | 2020-09-08 14:39:27 UTC | #4
Hi,
Thanks for the answer, now my question is how can I embed a backup plan in the Data Action. I use it in a Pre-Call Rule for an Preview Outbound campaign, so there is no Architect involved.
I just check the value total: from the /api/v2/routing/queues/ which gives back the number of agents available with the correct skill. When the API hits the limit the value total: will not be there I guess.
Is there a value I can check in both cases (API limit OK and hit the limit (429))? Like success = true or false? Then when the Data Action fails and gives back a false I can let the Pre Call Rule do something else.
Second question, when thinking about using this mechanism, can we use the value of 300 calls per minute for this one to work with? Or can we aim higher. This to have the discussion with the customer how to continue with this project.
Best regards, Rob
Richard.Schott | 2020-09-11 12:42:33 UTC | #5
For a successful response that doesn't contain the value you're looking for, you can use the translation map defaults to return a specified value and perform a check later in your flow: https://help.mypurecloud.com/articles/response-configuration-data-actions/
In the case of an error response, the data action will take the failure path; you set your variable to a specified value inside the failure path of the data action, and use the same check from above later in your flow.
I can't speak to the specific throughput limits for data actions, but what I can say is that your flow can be structured to be fault tolerant using the tools provided in architect. When performing a data lookup in any system, Genesys Cloud included, it is a best practice to plan for the failure of that lookup within the flow because "things happen".
system | 2020-10-12 12:42:35 UTC | #6
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: 8761