Hi,
We started recently a project to allow launching workflows through SCIM from an internal process in identityIQ. POST: /identityiq/scim/v2/LaunchedWorkflows. The workflow will at the end create an identity cube
Is there a way to limit the number of calls an application can make to IIQ, to avoid for example calling 1000 time the workflow? without trusting the application and let it control the threshold.
If anyone has any idea, it would be a great help
Thank you
Hi @bensals - Welcome to the forum!
I believe the best place for this type of logic is client side in the application you are building - it is where you will have the most control. The application (in this case IdentityIQ) itself can implement things like 429 rate limiting - but at the end of the day the calling app could get around this by spacing out the number of requests and still achieve pushing 1000’s of requests.
Thanks for the response. Yes on client side we can put this control, but was not sure if using SCIM there is a way to configure this control out of the box in IIQ. Let’s say if the the calls (from client side) exceed 500 (hence 500 TaskResults created) the next call will return an error response.
I think we can check the number of created TaskResults when starting the workflow and throw an exception is the threshold is reached, but wanted to ask if someone faced the same challenge in IIQ.
Thank you Adam
Right - you could probably have a step in your workflow to check the total number of open workflowcase objects, or pending task results etc… and fail the flow - but building this safeguard into your app calling the API’s it will probably be less overall work to implement than modifying the workflow to behave accordingly.