Easily deploying and maintaining AF objects in multiple remote AF databases
Originally posted on PI Square at https://pisquare.osisoft.com/ideas/5538-easily-deploying-and-maintaining-af-objects-in-multiple-remote-af-databases
Today, one of the method that can be used to selectively reconcile object changes (including templates, analyses, UOM, etc.) between source and destination servers is using Excel (in order to keep track of object changes and/or object deletions). However, it is very time-consuming and prone to errors.
Inspired in the current project I am working on (containing a central AF server and remote AF servers), it would be great to have a tool that allowed us to deploy and maintain all types of AF objects in a selective way in multiple remote AF servers.
Here is a use case:
The user selects the desired source objects (templates, elements, analyses, enumerations, UOMs, etc.) and export (or "publish") them to several destinations, at once, after of the press of a button (instead of “live” sync). The user selects what to be exported or synchronized to each destination, and not necessarily the same group of objects would be exported/sync to all destinations: each destination may contain different set of elements and templates.The synchronization would support name changes, object additions and deletions (similar to what is available in PI System Connector today)The user should be warned if he tries to export an element that depends on an enumeration or UOM (*) that is not included in the object set being exported.The user should be optionally warned about the attributes, analyses, etc. that will be deleted from the destination databases, if the corresponding ones have been deleted from the source templates or elements.The user should be able reconcile tag name changes: if the tag name convention is changed in the source attribute set with auto-tag creation, the tags created at the destination should be renamed as per new substitution parameters string.User should be able to save/load different export scenarios.
(*) You may ask: why not export the entire UOM? The answer is because the source server may be a development server and may contain UOMs that were added for other type of industries, which would be irrelevant in some production environments.
Scott Robertson commented
In response to Fabiano Batista, "Interesting use case. It looks like yo..."
I'm thinking that a scheduled update would be best. For the continuous use case, as in ML, I would say "Daily at 3 AM". For the Template updates, I would set a day and time when the update would occur, which could be days or weeks in advance. The ideal model, from a security standpoint, is an outbound connection from the remote sites, that checks periodically for updates, downloads the updates, and schedules locally for execution.
Fabiano Batista commented
In response to Scott Robertson, "I have a very similar use case. Potent..."
Interesting use case.
It looks like your use case requires a continuous AF synchronization (instead of "on-demand" one, like the one I suggested). PI System Connector would be the best product for this, but unfortunately the current version of PI System Connector cannot push analysis objects to the destination servers (i.e., your remote servers).
Scott Robertson commented
I have a very similar use case. Potentially 1,000s of remote PI Servers will need to be kept in sync. A typical deployment pattern is to use Machine Learning to update analytics for real-time alerting. ML would update the central AF server, and the remote AF servers would check in periodically for their updates.