Share all details about your problem, including any error messages you may have received.
we have configured azure connector (we are aggregating managed identities and application type service principals)and we have just enabled partitioning in aggregation task without adding the userPartition key in application xml.I can see that by default two partition are getting created like
1Managed Identity partition
servicePrincipal Application partition.
yes, that is expected behavior but it is almost certainly not giving you the performance benefit you enabled partitioning for.
Two constraints that are worth knowing about before you make any further tunes
Partitioning only applies to accounts on this connector, group aggregation will not partition, hence if your service principals are modelled as groups instead of accounts, then partitioning will not apply to them at all. Worth double checking which of the two schemas you are on.
If you have PIM enabled then partitioning is not supported with the Azure connector, in addition to the limitations of delta + partitioning that are mentioned here. If you intend to change to using partitioned delta aggregation then well worth checking these as people hit this error “Delta aggregation is not supported for partitioned task” because of this.
you are right. We are considering service principals are account , not group. We have not enabled PIM in connector. I think , the partitioned aggregation worth doing in our environment right?
one strange thing i have observed that , during portioned aggregation , if we just create a customization rule (no content , just a sysout of object.toXml() statement only), the managedIdentity partition , throwing this error " he LazyInitializationException for sailpoint.object.Rule.referencedRules").if i remove that customization rule , all partition are working well.Have you seen this.
Yes, it is a known problem in the IIQ and your observation is actually the cleanest reproduction of it I have seen posted.
Practical approach to go from here: there is no simple and lasting configuration solution in any of the threads that I have seen.
Reboot of Tomcat works, but only temporarily. Not a solution.
Check for context.decache() in any of the rules in the chain of aggregation. Does not apply to your situation (no context in an empty rule), but this is a known issue and should be eliminated to make sure that it is not the root cause for the Support team.
Submit a Support case. If It is a bug in IIQ rule caching/session handling and only SailPoint can address it.
Hello Suneeth. I would treat the partitioning behavior and the LazyInitializationException separately. For partitioning, userPartitions is the documented way to split the Entra user population using search filters. If performance is the goal, configure non-overlapping userPartitions and compare the aggregation runtime with your current setup.
For the exception, first reduce the Customization Rule to only: return object; Also check the Rule XML for any <ReferencedRules> entries.
Then run the same aggregation once with partitioning enabled and once with Enable Partitioning disabled. If the error occurs only with partitioning enabled, that would strongly point to an issue with the partitioned execution path rather than the code inside your rule.
In that case, collect the full stack trace and raise a SailPoint Support case. Since you are on 8.4p1, if you have a later supported 8.4 patch available in non-production, I would also try reproducing it there.
i have just a created simple customization rule with just import statements only. Then ran account aggregation without partitioning , it is running fine. After i have just enabled the partition and aggregation is getting failed with that error. This could be SailPoint issue i believe.