Managing Aggregation Schedules

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi All,

Is there any quick way to remove aggregation schedules before change and reinstate them after change ? This needs to be done for over 50 apps and after the deprecation of scheduled aggregation API this activity looks be pretty cumbersome to do manually.

Thanks.

2

Hi @aditya_pathak,

Correct, doesn’t seem to be any available at this current time. I would recommend doing it manually because of this…

But, if you are certain you need it, you can get a bit creative (at your own risk) and use the following ones which are not public -

Get Account Aggregation Schedule
Method: GET
URL: https://{{tenant}}.api.identitynow.com/diana/sources/sources/{{sourceId}}/accountAggregationSchedules

Update Account Aggregation Schedules
Method: POST
URL: https://{{tenant}}.api.identitynow.com/diana/sources/sources/{{sourceId}}/accountAggregationSchedules
Body: { “enable”: true, “cronExp”: “0 0 6 * * ?” }

Remove Account Aggregation Schedule
Method: POST
URL: https://{{tenant}}.api.identitynow.com/diana/sources/sources/{{sourceId}}/accountAggregationSchedules
Body: { “enable”: false, “cronExp”: “0 0 6 * * ?” }

You’ll have to build some sort of a script to loop through the Account Aggregation Schedules, save the CronExpressions and then Add/Remove the schedule as required.

Hope this helps.

2 Likes
3

Hi @aditya_pathak,

Please go through this community developed solution. It is achieving the same use-case which you are trying to address. Link is given below.

Let me know in case of concern.

Thanks

4

@ashutosh08 I do not believe the link that you shared does do what the original topic creator is looking to do. In his original post, he is looking for a way to programmatically disable/suspend/remove the aggregation schedules during a configuration change. He is then looking for a way to reenable them programmatically after the configuration changes are done. The link you posted is a method to add additional aggregations that follow non-standard schedules that are triggered from a workflow, but it does not accomplish what the person is looking to do with the Built-in aggregation scheduling.

However, if the user is willing to change their process so that they have a workflow (as defined in the link you posted) per aggregation, they could get similar functionality by using the Update Workflow to set it to Disabled during their Change Window, and then re-enable them after using the same endpoint.

While this would accomplish the end result, I would not recommend it unless absolutely necessary for the following reasons:

  • The user stated they have over 50 apps, which would mean 50+ new workflows added to maintain. This is the Primary reason I would not recommend this.
  • The workflow engine and aggregation scheduler may run differently
  • The current workflow aggregations will need to have their schedules disabled
  • This is non-standard, so there is a risk someone turns on the built-in aggregation that could cause conflicts.
4 Likes
5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.