Version 8.4
Hi Sailors,
We have an issue with Delta aggregation for an application and we would like to apply a fix for the same.
Is there a way to identify if the aggregation is triggered by Delta aggregation in the customization rule so that we can make sure the customization is only applied for Delta aggregation task.
thanks
Pradeep
there should be taskresult object in the namespace to help you find that, have you tried dumping the namespace in your customization rule?
Already tried that @sunnyajmera
nothing available there
Lemme know if you are pointing to any specific object.
If you trace out the aggregator class in the log4j2.properties
2024-03-11T04:32:01,876 TRACE QuartzScheduler_Worker-3 sailpoint.api.Aggregator:120 - Entering <init>(con = sailpoint.server.InternalContext@4b10a3a3, args = {refreshScorecard=false,
enableManagedAttributeRenameDetection=false, enablePartitioning=false, haltOnMaxError=false, sequential=false, timezone=America/Los_Angeles,
TaskDefinition.runs=25, correlateOnly=true, locale=en_US, checkHistory=false, TaskDefinition.runLengthTotal=113, TaskSchedule.host=null,
noManagerCorrelation=true, promoteManagedAttributes=true, deltaAggregation=true, correlateEntitlements=false, taskCompletionEmailTemplate=null, noNeedsRefresh=false, correlateScope=false,
noAutoCreateScopes=false, TaskDefinition.runLengthAverage=4, taskCompletionEmailRecipients=null, noAutoCreateApplications=false,
noOptimizeReaggregation=false, taskCompletionEmailNotify=Disabled,
checkDeleted=false, checkPolicies=false, applications=AD, launcher=spadmin})
Tracing anything is not recommended in production environments, not sure if this could help, but throwing it out there anyway.
I don’t think you will have a direct way to get it, can you explain your issue in detailed and application, may be some other work around approach can be suggested instead of this way.
this will only print it in logs won’t have anything in the customization rule
You’ll not be able to identify if aggregation is delta or not in the customization rule. Basically, the rule doesn’t differentiate between a delta aggregation and a run-of-the-mill aggregation.
We were having an issue with Workday connector for pre-hires it is not aggregating some specific attributes.
If we do full aggregation/targeted aggregation then it does bring up the values.
We already have opened a case with SailPoint but were also thinking if we could put a fix in there by doing single account aggregation in customization rule and fix the issue.
but looks like that is causing even more before trouble.
Calling get object on connector keeps on calling the customization rule and ends up being a infinite recursive loop.
Are you saying for same pre-hires you are getting the values in Full aggregation but those specific attributes are only missing during delta aggregation?
Did you try to print the object xml in both the cases, are the attributes missing from object itself or some issue with Customization rule. If the object itself is missing the attributes during delta aggregation rule , my next question after your full aggregation runs and if delta runs agian, are these attributes nullifying again?
Yes that is what I mean
organization ref chain id and some other related attributes are not read by the delta aggregation.
Full aggregation/targeted aggregation does bring in those values though.
FYI: delta aggregation only runs once for an even in workday not twice. Which is causing issues for us as we do an LCE to create accounts 14 days prior to joining and that is resulting in some accounts not being created by birthright because those attributes are missng.
Same issue happens without customization rule. We have an open case with SailPoint for this but we are also trying to think of having a workaround in place. Same used to work in previous 8.1p4 version but it does not work with 8.4 version