How does the Web Services Connector manage a timestamp to enable delta aggregations?
There is a value on the source that can be utilized in the Delta Aggregation Operation through $application.lastAggregationDate_account$. However, this is not sufficient since this value changes every time the aggregation activity starts, even in case of failure or termination. Moreover, it’s based on IdentityNow’s time, which may not always align with the source’s time due to time drift.
Thank you for bringing this to our attention Kurt. The connector team has opened a bug report and they are looking into this. Here is the current and expected behavior of delta aggregation, as per the bug report.
Current behaviour: To support Web Services delta aggregation, Connector saves lastAggregationDate_account for each account aggregation.
Expected behaviour: It should store lastAggregationDate_account only in case of successful aggregation.
I will keep you posted once this is fixed.
Follow-up question: there is an option for “Account Delete Status Attribute”. Despite multiple variations, I am unable to get it to register and result in accounts being ‘dropped’.
With the field set with a value of: deleted=true
The account schema has an attribute of deleted and type string.
The HTTP operations response mapping will return either true or false for deleted
Even with change the values or switching to type Boolean, same results. The expected value shows up on the account, but it is not deleted/dropped during the aggregation
@Kurt_Ramsey This should now be fixed. Please let us know if you have any further issues with delta aggregations.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.