IIQ Version: 8.3P1
We have an Identity Refresh task running daily once through a sequential task. Recently, we added the same task to a different Sequential task, and the new identity refresh is behaving differently than the previous task.
We are using the same task in both sequences, but the new schedule is behaving differently, causing long execution times (approximately 6 hours) and generating many provisioning transactions.
CSTicket.docx (382.1 KB)h
I am attaching a word document which has the issue in a detailed summary.
Hi @sunilasm,
the difference oin time execution depends by the number of identity examinated, on the first 5k and in the second less tha 1k.
This is normal, but it is necessary to understand why this difference exists.
It could depends what and how are you aggregating and how many rules\process have been launched during the refresh.
Also, I think you some problem on the configuration because 1 hour for 1k identies or 6 hours for 5k identies its too much.
How did you setup aggregation and refresh?
The one which has 1K identities is part of sequential task which has the HR application aggregation task followed by the refresh task.
The new task we added is into the sequential where it has all our delimited file apps aggregation followed by refresh task.
Both the refresh task’s are exact same configurations.
Things to check:
nº1 are you using any foreground processing, all workflow should be Backgroung.
n2° do your LCM events schedule the execution or are synced executions?
n°3 how is the partition configured?
Best!
ok, this is a normal behavior because if an aggregation updates 1k identities the refresh will be works on 1k identities, the same for 2k,5k or 10k identies.
The strange behavior is on the time, because 45 min for 1k identies is very very much, in the same time on my project I refresh 40k with a lot of subprocess.
To resolve this issue, you need to unmark the Disable optimization on aggregation(if its marked), use delta aggregation where you can and configure threads\partitioning.
Are these 2 sequential tasks getting executed on same time ? Or, is second sequential task getting executed before 1st sequential task execution over ?
There could be a situation where 1st refresh task locks the identity while it executes, and if 2nd task tries to refresh same identity then it will wait until lock gets released by 1st refresh task. This would also cause the delay in execution.