Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
We have inhouse Auth source integrated with webservice connector. We need to configure delta aggregation for which we need to pass startDate and endDate in request body. Aggregation API expects key/value pair as below in request parameters
startDate:20240601
endDate:20240602
I understand we can use “lastAggregationDate_account” in application context as endDate which supports delta aggregation. I already went through the documentation
I have some queries understanding this–
Will the Auth source needs to update API to consume $application.lastAggregationDate_account$ if added to request param or as URL filter?
Also how it is different from aggregation scheduled which is optimized anyway.
Is there any way to add current date or now as the startDate to get the delta accounts aggregated from auth source.
i am not sure what you want, but for me is better using the webservice filter.
You can configure a normal aggregation filtered with today date.
Also, you can use the delta of IDNOW without problem.
If you use the lastAggregationDate_account, the API must support this parameter to be passed in. Depending on the API you are using this may not be supported right out of the box without adjusting the pattern of the parameter. You can adjust the pattern using the connector_dateTimePattern & connector_serverTimeZone.
By using the lastAggregationDate_account, this puts the delta in control of the API and expects that the API will send a smaller payload with only the changes to the accounts - unchanged accounts are not expected to be sent to IdentityNow (although it doesn’t cause issues if unchanged accounts are sent). The normal optimization will have a full payload from the API and complete the processing within the IdentityNow tenant.
Per my knowledge, I am not aware of a way to capture current date during an aggregation with the configuration alone. You can implement a Web Services Before Operation rule which alters/appends the current date to the request endpoint before it is sent by IdentityNow.
Here is an example of how you could do todays date as start date and tomorrows as end date in a Before Provisioning rule (this is untested and just a quick example):