6 Replies Latest reply on Sep 18, 2012 9:22 AM by RJKSolutions

    AF Data References (again!)


      Sorry to hit you with this perenial bugbear again, but I am trying to create a simple text attribute that takes its value from the same attribute in the parent element. So I can have a root element called [PIServer] which is the PI server containing the data for that part of the tree, and the child elements below it can all have the same attribute, pointing to their parent. So the attributes in the child have been set up as Formula data references with the settings:




      If the attribute in the root element is "snafu", then the attribute in the immediate child gets the value:


      Data was not available for attribute 'PIServer': snafu


      and the next level down gets:


      Data was not available for attribute 'PIServer': Data was not available for attribute 'PIServer': snafu


      so it has clearly got the value of the parent attribute (snafu), but it looks like it is trying to evaluate that instead of just presenting it.




      What am I doing wrong?


      --- Alistair.

        • Re: AF Data References (again!)



          Formula data reference doesn't support strings.  You may want to take a look the String Concat data reference in the AF white paper on creating data references.  This white paper is available in the Library.

            • Re: AF Data References (again!)
              Asle Frantzen

              I would advice you do a couple of technology tests with the StringConcat DR before relying on it 100%. I have some bad experience using this.


              You can read about it here, but basically I created tag names dynamically using the StringConcat DR and then tried having a PI Point DR attribute read that tag name. It worked in PI System Explorer but didn't work as expected in PI Webparts, because by using the StringConcat DR like this - AF considers it a "complex data reference" which behaves a bit differently than "simple" DR's






              Steve - I've asked about this before but I'd like to remind you: We need better string handling in AF/PI System Explorer. The formula DR can have data type 'string' today but that's mostly just a source to confusion. Make that work and throw in a few string operators, like concatenate, substring, left, right, length, trim, etc.

                • Re: AF Data References (again!)

                  Thanks for that, we will abandon this idea then. I second the call for string support in the Formula data reference!


                  The other solution we thought of was to have the 3 PI servers in an AF table and put a table DR in every element, pointing to the appropriate row. Then we can change the PI Server for one of the areas by changing one row in the table.




                  --- Alistair.

                    • Re: AF Data References (again!)

                      Alistair...in this particular example why do you need to display the PI Server name?  You can use (I am sure you are) the PI Server name directly in the PI Point DR by way of substitution parameters.


                      If you have a client then they can always refer to the parent that has the text with the PI Server name.


                      Others have used the Table Lookup DR for displaying PI Server names.  There is one or two posts on here about it.

                        • Re: AF Data References (again!)

                          The substitution parameters have %server%, which I believe is supposed to translate to the default PI Server for the AF server but we have found this to be unreliable. We currently use it in the template for all the PI Point DR attributes and yet some of the elements point to Lime01 and others point to Limes, which is a version of the PI server that we have not used for months and longer exists!


                          Also, there will be three sub-trees in this AF hierarchy, each sub-tree collecting its data from a different server. We need to be able to change the names of these servers easily in AF so that elements at any level in the sub-tree below its root will pick up the change. Can we do this…


                          The tree goes like this:


                                         Organisation > Network > Station > [Asset | substation > Asset]


                          So a station has assets and substations, which also have assets. Each network gets its data from a different PI server so the Network needs to have a simple PIServer string attribute.


                          1. We could have all the PIPoint DR attributes below having a substitution string going up the appropriate number of steps to get the parent Networks PI Server.


                          2. We could have a [Network] simple string attribute at every level, with the name of the ancestor network and then have an identical substitution string for each PIPoint DR attribute, starting at the top and using the Network attribute to decide which network to use.


                          Option 1 means being careful to have the right number of parents in the PIPoint data reference. Option 2 means we have to duplicate the [Network] attribute at every level. So neither is perfect. But if we were to use the Table root, that has the same disadvantage as option 2. However, they both have the benefit that we can change the PI Server name in one place and have it apply throughout the network.


                          --- Alistair.

                            • Re: AF Data References (again!)

                              Using %Server% will use the default PI Server from the client's connections and won't be consistent amongst a large user base, or a company with a lot of PI Servers.


                              I have done both 1 & 2 from your options, but I have a preference of 1.  If you have a strong asset hierarchy structure then your templates can reflect where to pick up the PI Server name easily.  Of course you can also have an absolute substitution path for where to pick up the PI Server names from.  Also, I know you can define a template that doesn't exactly have a fixed place in the hierarchy...these are the tricky ones unless you use absolute paths to the attribute with the PI Server name.


                              It is common to see varying lengths depths of substitutions in my templates, e.g.


                              %@..\..\|Server Name%........


                              %@..\..\..\|Server Name%........


                              Normally easier to plan out when viewing templates by template references.