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
Hey Gustavo,
You are correct - the filtering does not work on null and makes this a rough replacement. I’ve filed an internal engineering case and an idea for product management to make this API better, or expose the tpe API as a beta API.
https://ideas.sailpoint.com/ideas/GOV-I-3550
I will let you know when I have additional information.
Thank you,
Tyler
Hey,
** you have deprecated the old getPending tasks without a suitable replacement!**
** what are we supposed to do?**
Gustavo
@tyler_stevens, please tell us what is the solution for this, based on experience it takes about 1.5 years for Sailpoint to read the submitted ideas, and way longer to act on them.
How we can get the roles updated everyday without having to have a person to click on a button?
Thanks,
Gustavo
@tyler_stevens and @colin_mckibben when I call “beta/task-status/pending-tasks?count=true” the X-Total_Count comes back with a total over 50k. When I look at the Created time stamps for the first 250 they are dated back to 2018 and have Null Completion statuses.
The CC endoint would typically come back with only a handful of Tasks. Any advice? I’m trying to Delete a Source bet it keeps erroring out because it is in use by [pendingCisTasks]."
I have the same issue, endpoint is gone, no suitable replacement.
/task-status/pending-tasks does not return the equivalent of /cc/api/org/getPendingIdentityTasks
We have a utility that would find pending tasks and allow us to optionally cancel them to free up the system, particularly useful in a sandbox tenant.
/task-status/pending-tasks is returning a huge list of tasks we don’t care about, not the list of tasks that are blocking activity. Please advise.
1 Like
Encountering the same as Jason. Trying to do some work and can no longer use the CC to get the batch jobs that are running to cancel them. The new API doesn’t appear to provide the same high level and shows individual attribute syncs and other activity.
1 Like
Hey Gustavo,
I completely understand the frustration and I am advocating internally - this is a pain point for several internal teams as well. I hope to have some positive movement soon and we will keep you in the loop.
Thank you,
Tyler
4 Likes
Hey Tyler,
Since this is a headache for “several internal teams” are we not going to be able to get support to kill stuck tasks? If so, that should definitely escalate this further as it will block us from doing some of our day to day work.
Thanks,
Chris