01/27/2023 05:39 AM
How do you deal with the scenario when running an actionable analytic on a schedule (say to disable accounts) that ends in a task error, but you correct the underlying cause and then you need to reprocess the task? The ideal scenario would be to do this automatically and the analytic would pull it in again. I'm finding with a scheduled analytic, the task is generated but if it errors out, subsequent runs of the analytic still call back to the failed task and do not generate a new one. What is the best way to get around this?
Solved! Go to Solution.
01/27/2023 05:56 AM
Usually error out tasks set status as 8 . For same you need to change status to 1 and provisioning retries to 0
01/27/2023 06:00 AM
You mean by a custom query job?
01/27/2023 06:13 AM
01/27/2023 06:29 AM
The downside to this approach using customquery is that we'd have to write a targeted SQL query for each failure that maxes out it's retry attempts so only those tasks get adjusted. This isn't scalable unfortunately.
01/27/2023 06:34 AM
01/27/2023 05:58 AM
Have you tried setting the base count and no. of history to keep to 1?
01/27/2023 06:22 AM
I had not tried that but just did and the result is the same. Here is a screenshot from the run. You can see it did not create a new disable account task for the first row. That task had errored out due to an underlying issue that is now resolved. The second row is new record matching the result set.
I know I likely could work through these with manual ARS requests, but that is not a scalable approach. It would be best if somehow these could re-generate on their own after retry count is exhausted and the data is still showing up in subsequent analytic executions.
02/03/2023 07:00 AM
I have opened a ticket on this issue as there doesn't seem to be an obvious solution that is scalable and automated.
05/01/2023 07:12 AM
Support indicated this is not currently supported. Idea created. Please upvote if you share this issue: https://ideas.saviynt.com/ideas/EIC-I-4566