AnsweredAssumed Answered

Is there a way to ignore redundant AFChangeInfo objects that result from updating a Template?

Question asked by Noga on Apr 29, 2019
Latest reply on Apr 29, 2019 by Noga

I am using AF-SDK 2018 to sync source and destination PI-AF servers.

I use the PISystem.FindChangedItems method to retrieve any changes made to the source server, export these changed objects to xml files and import them to the destination server.

 

When adding a template to the source server (such as: NotificationRuleTemplate, ElementTemplate etc..), the PISystem.FindChangedItems call does not only return AFChangeInfo list with the added/edited template, but also all other objects that rely on that template.

So for instance:

Adding a NotificationRule to an Element on the source server, converting that NotificationRule to a template, and do CheckIn to the server, results in AFChangeInfo list containing the added NotificationRuleTemplate, but also hundreds and even thousands of AFChangeInfo objects (NotificationRules and Elements) that I will need to export to xml files and import to the destination server.

 

Since I do not wish to process these amount of files, and also since importing the Template xml alone is sufficient to update all the related objects that use that template:

I wish to know what is the best way to filter out from the AFChangeInfo list these objects that were returned because of the template added/updated, and not because they were updated themselves regardless of the template update.

If I could know that I could filter the templates and import them only.

 

Currently my problem to filter and import the templates alone, is that I may loose (filter-out) a ChangeInfo data for an object (such as an Element) that was edited in that same CheckIn operation of the Template update.

Also, in case the PISystem.FindChangedItems call occurs after the application was not running for a while, the AFChangeInfo list will contain several CheckIn operations, so filtering only templates will probably lead to loosing changes to non-template objects that should be imported to the destination server.

 

Another related question I have is: Is there a way to distinguish in a returned AFChangeInfo list between different CheckIn operations?

 

I will be glad to know if there is a way to handle this issue.

 

Thanks.

Outcomes