5 Replies Latest reply on May 21, 2015 4:05 PM by JFors

    Element Path Alias via PB ERD display

    JFors

      Our project is using fully redundant PI Servers(HA) and interfaces.  The Health Monitoring of the PI system utilizing Performance Monitor tags is requiring that we be able to build PB displays in a multicolumn format.  In right column will be the graphical display of PerfMon values for the Primary Object( interface, PiServer, AFElement/Template driven), in the left column will be the same attributes for the Backup/secondary object.  Now make the display Element Relative where you select the primary object as the current context and both columns update with the associated data where the backup column resolves what is the backup object for the selected primary object.

       

      I'm using PB 2014 version 3.4.0.251.  I'm looking for a reliable generalized answer for this display format and any suggestions would be appreciated.

       

      Solution Experiment 1:

      The concept is of an alias element path.  Where an object (AFelement) can be reference by its role similar to an attribute being an alias for a tag. 

      I've seen(via PI system Explorer) that AFAttributes can have a datatype= AFElement.  If I have an attribute named Backup, datatype AFElement with a DataReference that returns an element, would ProcessBook handle a ER path with syntax looking like:    E.Backup|AttributeofInterest

      The custom data reference could resolve the AFElement representing the Backup roled object.

       

      The concept of Element Path Aliasing (role based element resolution)  would be a feature that I believe would be of great value but would like to hear if anybody has tried this or other methods to have a Process Book Element Relative Display with attributes of both Primary/Backup displayed.

        • Re: Element Path Alias via PB ERD display
          bshang

          Hi John,

           

          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:

          Creating multiple views of assets

           

          and in particular, the element reference type strengths.

          Reference types

           

          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.

          • Re: Element Path Alias via PB ERD display
            JFors

            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.

              • Re: Element Path Alias via PB ERD display
                JFors

                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?

                  • Re: Element Path Alias via PB ERD display
                    zge

                    Hi Jhon,

                     

                    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.

                • Re: Element Path Alias via PB ERD display
                  JFors

                  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

                  MyNetwork

                        |====>Server(s)

                                       '

                                       |====>Interface(s)

                   

                  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.