Replaced by
This API behaves differently then the older one.
If we call /cc/api/role/refresh, it gives an error if there are pending tasks. If /cc/api/org/getPendingIdentityTasks returns an empty array, we know that we can call the ''Apply changes" button through the API /cc/api/role/refresh. If it is not empty, we know we would have to wait.
Right now /cc/api/org/getPendingIdentityTasks returns an empty array in our environments, while beta/task-status/pending-tasks does not.
How can we now ensure ourselves that we can call the “Apply Changes” button?
Kind regards,
Angelo
Rather than polling for an empty task status list, could you instead implement retry logic for role refresh? For example, call role refresh once. If it fails, wait 5 minutes and then try again. Repeat until it doesn’t fail.
Yes, that would work as well! Good idea. I usually prefer checking the status rather than doing try catch retry logic, but I understand that this is quite a low priority as part of migrating all the APIs. I will update the code and consider this solved then.
1 Like
Hi @colin_mckibben,
I tried what you suggested, but apparently /cc/api/role/refresh is behaving differently than what I thought it did a while ago (either the API or my memory has altered). This API to apply roles is accepting the request even though there are pending tasks. the UI is preventing this API from getting called by checking /tpe/taskResult/taskResults/pendingIdentityTasks.
So either the /cc/api/role/refresh accepts it and does nothing, giving a false sense of progress, or it accepts and performs it while there are pending tasks, which might corrupt the data?
This discussion goes hand-in-hand with /cc/api/role/refresh, which we are discussing with product management now. I’ll bring these concerns to them so they are aware of the gaps.
Here is the deprecation notice for /api/role/refresh. Please comment on the linked post with any concerns you might have.
should I assume then that there won’t be a replacement for this endpoint before the deadline?
if yes, then it does mean this endpoint will continue to work, right?
Thanks,
Gustavo
The replacement is provided in the first post of this topic. If there are any gaps in the functionality, please let us know.
it not look like is the right replacement, as in right now our sandbox environment the endpoint /cc/api/org/getPendingIdentityTasks does not return any results while for /beta/task-status/pending-tasks there are 250.
I have exactly the same behavior in production.
Now, I see that (in sandbox at least) the UI is calling the endpoint /tpe/taskResult/taskResults/pendingIdentityTasks that does return a similar payload as the old /cc endpoint …
But I do not see that /tpe endpoint documented, could you point us to the doc page for it?
Hey Gustavo,
The tpe endpoint is an internal endpoint, which is being used by the UI and does not have documentation associated with it. GET /beta/task-status will return the information you are looking for, but it also returns a lot more information beyond what the getPendingIdentityTasks endpoint did previously. The task-status endpoint returns all aggregations (accounts, entitlements, or manual correlation processing) + role refresh tasks, whether completed or not.
To gather pending tasks that are not yet completed, you can filter on completionStatus like this:
GET /beta/task-status?filters=completionStatus eq “null”
There are additional filters that you can use as well, they are documented here: get-task-status-list | SailPoint Developer Community
Filtering is supported for the following fields and operators:
id: eq, in
sourceId: eq, in
completionStatus: eq, in
type: eq, in
Example: completionStatus eq "Success"
The reason you are hitting 250 is because of pagination, beta/task-status is only setup to retrieve the first 250 results. You can add count=true to see how many results are included, but keep in mind this endpoint returns everything including completed/non-completed tasks.
Hope this helps!
Thank you,
Tyler
Hi Tyler,
First thing … the beginning of this post indicates to use /beta/task-status/pending-tasks and you indicate /beta/task-status which one is the correct?
If I assume the one you gave is the correct, then is not the same information as the /cc one or the /tpe one.
the need is to know if a “REFRESH_IDENTITIES” process is running, in the /cc one (or the /tpe) one the fact that there is something on the response means the process is running, while in the /beta/task-status the entry appears immediately as “completionStatus”: “SUCCESS” and the “completed” has a timestamp milliseconds after the created.
and this is because /beta/task-status reports that the “Cloud Refresh Role” was triggered, not its progress.
So to be clear, what we need is to be able to replicate the behavior of the “Apply Changes” in the UI, and for this we can only do it if we can validate that there is no “REFRESH_IDENTITIES” running.
So how do we accomplish this?
Thanks,
Gustavo