Manual AF Replication

Discussion created by mjarvis Employee on Mar 27, 2015
Latest reply on Aug 7, 2017 by Shafqat_Iqbal

Hello there PI Square Users,


This is a post about manual AF Replication, which some users may call AF2AF or AF to AF. I'm not advising the community on development or architecture best practices, but I would like to share some thoughts on how a customer could achieve this type of functionality today. Also listed are some of the caveats. For example, you might have a corporate level asset model, and want to push pieces of the tree to various sites. The asset model gets pushed down, and the data gets sent back up. This is a model I have heard from several end customers.


If you want to replicate your AF Hierarchy from one AF Server to another, or even between databases, here are some ideas:


1. AF has an import/export functionality from PI System Explorer, as well as from the command line. This will export to XML, and this file could be modified using standard methods. If you were going to import this file to another AF Server or database, the import functionality will only append or create. You will not be able to edit/delete/rename using AF Import. The problems you could run into here are the AF Server that you are importing information into could simply grow with lots of obsolete information.

     a. I have heard of some customers deleting the entire AF Hierarchy, and rebuilding it. That would result in the most current structures, however, all of your GUIDs will change. Several applications use the AF GUIDs, such as PI ProcessBook for Element Relative Displays. If you are only using PI DataLink, you should be fine.

     b. Everyone knows that AF Export/Import will not support any kind of AF Versioning, right?


2. You could get fancy with the PI Builder, which has the ability to rename/edit/delete. This would need to be run with a mostly manual process. It can be difficult to consistently open/close excel sheets programmatically.


3. The AFSDK has a FindChangedItems(..) Function, which will find changes for a given database over a given time period. This could be used to detect only the changes from an AF Hierarchy, and will result in lots of AF objects in the AFChangeInfo, which you will need to sort out. You will also need to figure out where they go on the other AF Server or AF Database. This is not a trivial problem to solve.


PI Cloud Connect will handle these AF Changes and modifications very easily, and I would hope that anyone that is considering doing the above would examine the feature set that is currently available in PI Cloud Connect.



Mike Jarvis - OSIsoft Product Manager