Home / OIM / Bulk Open Task Cleanup
df470cdb1d0a0bbb2f21920726ff9829.jpeg

Bulk Open Task Cleanup

I worked with a client that had too many open process tasks in OIM. This had occurred as the result of a combination of network issues and the surprise retirement of an application. This resulted in thousands of process tasks stuck in a rejected status. Since the application had been retired, many of the tasks could not simply be retried. The rest were not being retried as there was just too many that had been missed.

The Requirement
The requirement was to remove the tasks that belonged to the system that had been retired, and retry the tasks that were legitimate and needed to be completed.

The Solution
Using a combination of one-off processes and Custom Scheduled tasks that could be run at regular intervals, it was possible to clean out these tasks. A scheduled task was created and set to run regularly. This task would retry all open tasks. 

Any task that failed due to a network outage, or other unforeseen issue, would be retried until it was able to complete.  After a certain number of days, these tasks would drop off and no longer be retried. This was accomplished with the tcProvisioningOperationsIntf class, which is part of the OIM API. Using the method findAllOpenProvisioningTasks, a list of all tasks could be generated. The method returns a result set that contains the task key. Once you have that you can use the retryTask method along with the task key to retry your task.

The other issue was that many of these tasks couldn’t be retried. Since the system they were attempting to provision was no longer in service, they would hang until a timeout and then fail. 

For those, we needed to use the API to set the tasks as manually completed. For that, we used the setTasksCompletedManually method from the tcProvisioningOperationsIntf class.  As before, we could search for open tasks, this time with filters to get only tasks that belonged to the resource that we were interested in, then we could set the tasks to completed.  This was run as a one-off for the specific system that had been decommissioned. When running this we found that we were able to clear out 5000 open tasks within 30 minutes. Your mileage will vary, as it depends greatly on network conditions and hardware.

Conclusion
Between these two API calls we were able to remove/retry all of the process tasks that had been rejected.  After the cleanup effort we used the scheduled job regularly to ensure that other missed tasks would have a chance to be retried to help avoid these kinds of issues. We were also able to verify that the user data between OIM and its targets were still in sync, saving us from having to do a data cleanup effort on over 20,000 accounts.

Check Also

Logging into & setting up iManager

Logging into iManager is a little deceptive if trying to do it for the first …

Taking Control of Your Oracle Identity Manager Scheduler

According to Oracle’s sizing guide for Oracle Identity Manager (OIM) 10g in a large deployment …