While the Value Type for an Attribute can be set to objects like AF Element, that feature was more for backward compatibility with older clients and may not be supported in the future.
AF Elements were more designed to represent physical or logical assets, while AF Attributes are the metadata or streaming data associated with the asset. Attributes therefore are mostly configured to be numeric or string types, rather than object reference types.
What may be of interest is creating element references. See the section below:
and in particular, the element reference type strengths.
Essentially, you can create multiple hierarchies in AF without duplicating the AF element. Not sure if this is what you are looking for or similar.
For Processbook ERDs, the constraint is that the element path to the attribute must be consistent. So GrandParent1\Parent1|Attribute1 and GrandParent2\Parent2|Attribute1 cannot share the same ERD if the element context is at the GrandParent level. But it is possible to create a separate AF hierarchy using element references which can assist in building the view model you'd like to see in a client application such as Processbook.
If you can share parts of the existing AF hierarchy and maybe a mockup of the type of PB display you'd like the create, we can look into other ideas as well.
OK so I wrote a quick DataReference where the configstring was a element path. Used the AFSDK Element..FindElementsByPath to return a reference to an AFElement.
Not that easy for Process Book to resolve the dynamically created AFElement reference. The value/symbol objects using the syntax "E.Backup|DisplayName" to reference an attribute on the backup object, just responded with a dialog "Unable to locate datapoint:." My guess is that PB was trying to resolve the path as if it were statically created where the syntax would be the same as a child attribute of the Backup attribute.
So I'm back to the design board.
Thank You Barry for the response.
I think I understand use of creating multiple references to create multiple paths to the same element. But I think the problem is not resolved by multiple paths to an object. The constraint in PB's resolution of the path is dependent on the string identifiers i.e. the tokens of the path, derived from the names, being static. Since the name of the context element will be different between instances of the Primary object there is no way to make the secondary/backup reference static.
The concept of an "Element Path Alias" would be more similar to the path getting its tokens from the name of the reference. None of the reference types provided are for a "named" reference. The reference types provided only serve to change the behavior of reference counts to an element for extinction.
Another idea that I think has been attempted is to create an alternate Context Handler within the PB Display so that the ERD reference "E.Value" on the primary context would be equivalent to "B.Value" on the backup context. Then VBA would just have to catch a context change event on the E context handler and update the relevant context on the B context handler. So far my VBA code has not been able to insert a new ContextHandler into the Application.ContextHandlers collection.
Anyone else solved this problem?
If the right and left column of the display are exacly the same and you won't need to switch them back and forth (switch from primary on the right to secondary on the right). Then this might help you:
Creat an Element for each pair of the object (Interface/PI Data Archive), and two child elements named "Primary" and "Secondary". Then in ERD, select the parent element as element of interest, and trace down to the child elements to get the attributes for primary and secondary.
The other workaround is to add child attribute to each every attribute of the primary and reference the corresponding attribute of the secondary, and vice versa. In this case if the child attributes' names are the same between primary and secondary element, the context of the left and the right of the display can be switched.
Both the above methods needs modification to the AF asset structure, which can be made in bulk or through template. If such modification is not acceptable, then they are out of the scope.
Hi Zhengqi, Thanks for the response
The problem with your approach is that the context of the Primary and Backup objects is where they live in the hierarchy. Where they live feeds the roll-up statistics that live above them and to have an intermediary element between them that would confuse the roll-up. My current hierarchy appears like this
So my Server object can see how many interfaces are running on each and the rolled-up state of the interface. I.E how many are "primary" or "Faulted" , even how many Events/Sec the server is handling through the interfaces.
Expanded Solution experiment 1:
I've already written the DataReference that returns the AFElement reference which is the backup object. The configuration string provides the path to the backup element. Now I'm trying to create a second data reference that will find the appropriate AFattribute on the AFElement returned and impersonate that attribute in the current element. I.E. when the getvalue method is called the results returned will be that returned from the ImpersonatedAttribute.getvalue. All of the limited number of attributes needed for the displays will all have to be "Mapped" with this "AttInherit" datareference. I know I can get this to work for simple getvalue but I'm not sure if I know all about AFDataReference class to implement the ability to drop the attribute into a PB-Trend object and have the features associated with a PIPoint attribute.