Webservice Pagniation / API Rate limit configuration

[Learner (R D)]

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

Hi All , I used OOTB webservice connector and all Operations are working as expected . Now I have to add pagination / API rate limit for Create , Update , Account aggregation operations.

Can someone help me on how to proceed further and also I noticed Paging option is avaialbe only for Account Aggregation operation. Below is the paging condition.

ALT Response for rate limit. Current limit is 200 requests per 1 hr
• Status Code: 429
• Body:
{
“message”: “Rate limit exceeded”
}

[MuhammadMustafa]

Hi @Learner I’m just curious :), why do you need pagination in create or update?

[Learner (R D)]

Hi @MuhammadMustafa - Application team have limit on users creation or update which is set to 100 requests for hour.

[MuhammadMustafa]

Okaaaaay, got it now…
If I’m understanding correctly you meant by developing WebService Connector that you are using the OOTB SailPoint WebService Connector, I’m I correct?

[Learner (R D)]

Yes , that’s correct.

[MuhammadMustafa]

I faced almost the same situation with one of our clients 2.5 years back, I’m not sure if there is a solution now for such situation but it ended up for me by developing a custom connector and leveraging the capability of creating a custom table to save the requests and their status and buliding a retry mechanism.

Let’s see if anyine else having another suggestion or maybe an easier idea for you and if not I can help you in drafting the architecture for your custom connector (if needed).

Have a nice and great one!

[ipobeidi (Ivan Obeidi)]

Hey!
Just create a after rule to sleep the aggregation thread.

Best!

[Learner (R D)]

Hi @ipobeidi . Thanks for your reply . Can you please share any sample code or reference on how to write the logic in after rule.

[ipobeidi (Ivan Obeidi)]

Sure :
Simple as that, you will need to break the aggregation in at least two operations and have this one on the second call.
Kind like you grab 100 users, call the second one grab these 100 any attribute and sleep.
is not IDEAL , but it works.

import java.util.concurrent.TimeUnit;
TimeUnit.MILLISECONDS.sleep(2000);

[Remold (Remold Krol)]

The sleep option will not help if there are 100s of update actions. It will just wait for each independently. (Also the issue is not only for the aggregation, but also all (de-)provisioning actions.)

The best wait overcome the rate limit is a throttling mechanism, to delay all the requests when a specific limit is surpassed. Throttling is not available for the OOTB WebService connector

An other option is to retry and retry and retry. You can enable Retry and set the retry options in the workflow ‘Provision with Retries’. For this it is best to have the provisioning run in the background (foregroundProvisioning set to false), as access request and/or approvals will delay the response to the end-users with foreGround provisioning.

And another option is already provided by @MuhammadMustafa, save the request in a custom table and run a (throttled) provisioning from that table using a custom task/rule which is scheduled in a regular interval. (Maybe use an integration Config to re-route the requests to that custom table.)

So there are options to make it work

– Remold