14 Replies Latest reply on Jun 24, 2016 9:00 PM by Roger Palmen

    Issues with Ordering and Positioning of AF Element Attributes

    acarlini548b

      One of the main concern I've got during the implementation of PI AF is the representation / visualization of AF Element Attributes in the Clients and in the responses from the various Interfaces ( ODBC/JDBC, Restful web services .. etc ).

       

      In many other applications we use , for example to manage product specifications, recipes, etc, the grouping and positioning of attributes/variables within an entity must respect certain rules, and the application provides a sort of "ordering field", that is automatically updated according the position of the attribute or attribute group / category when you physically create that attribute/variable within an element ( or element template ).

       

      Now, in my specific use case, my element is an instrument ( or device as well ) that has attributes with three different categories that must be represented always in a specific order :

      1. Design parameters
      2. Engineering parameters
      3. Operating conditions / variables

      Within this categories the attributes and sub-attributes must always be represented in the same order, ( as you enter it in the template ), and not by name.

      In other applications I own and manage this kind of discussion started more than two decades ago, then it was implemented so far, and today it has been promoted as a best practice for the most common scientific and business application in the market.

       

      I would like to know how some of you solved this issue without doing a very old and bad practice : putting numbers or alphanumeric characters in front of an element name, category name or attribute name.

       

      Why we can simply have an ordering number field/property at least for category and attributes, that can be used for automatic sorting ( i.e. in sortField for PI webapi or PI SDK ? )

       

      Thanks in advance for your comments and contribution for this topic.

      Andy

        • Re: Issues with Ordering and Positioning of AF Element Attributes
          gregor

          Hello Andrea,

           

          Have you considered using Attribute Categories to identify if an Attribute belongs to Design, Engineering or Operating category?

           

          Within PI System Explorer the Attributes View can be customized by defining what columns should be visible. By clicking on the header of a column you can change the sorting. There's also an option to Group attributes by Category.

          Some of the AF SDK calls allow to define a sorting that should be applied. A predefined AFSortField Enumeration has the available sort fields. Unfortunately AFCategory or Category is not included with that enumeration but AFCategory can be used as a filter for the Attribute retrieval. With AF SDK it's recommended to perform bulk calls which instead of single items return a collection of items. Those item collections can easily be sorted client side.

          Because PI Web API depends on AF SDK, I assume that the before mentioned as well applies here.

          Just to avoid confusion, PI SDK doesn't provide access to the Asset Framework. In addition we recommend against using it with recent development projects because PI SDK is announced to become deprecated

           

          Because you expressed to be interested in how others have addressed the issue you described, I join you in hoping to see some answers from other users.

          1 of 1 people found this helpful
            • Re: Issues with Ordering and Positioning of AF Element Attributes
              acarlini548b

              Hello Gregor,

               

              We have considered all options, but probably the main requirements has not been well understood.

               

              In Practice, we need to have a predefined position of categories and attributes in the asset element display , from any client or interface request result, getting this order automatically and not setting it outside the source ( i.e. in the client or interface )

               

              The importance of category and attribute positioning is well known in the scientific environment, where they order / sequence you display and report the information must follow some specific rules, and most of them solve this using ordering/positioning fields on attributes/variables.

              Not only a category/group of attributes before others, but even within the same category a specific attribute/variable must be placed before another one, and so on.

              This because each attribute/variable/parameter has its own weight of importance and the way you report it has a strong impact on human readability and easy of use.

               

              Well, I know the importance of this can vary a lot from business to business, but maintain this ordering logic from the client side costs a lot of efforts we do not have to pay in other applications.

               

              Thanks in advance for your feedbacks, highly appreciated.

               

              Here a use case.

               

              An element template must be represented in that way:

               

              CategoryAttributeName
              YellowVolume
              YellowPressure
              YellowMin
              YellowMax
              YellowTemperature
              YellowMin
              YellowMax
              RedVolume
              RedPressure
              RedMin
              RedMax
              RedTemperature
              RedMin
              RedMax

               

              As soon as you checkin the element will be visualized in the following "wrong" ( it does not respect the needed layout ) way:

              CategoryAttributeName
              RedPressure
              RedMax
              RedMin
              RedTemperature
              RedMax
              RedMin
              RedVolume
              YellowPressure
              YellowMax
              YellowMin
              YellowTemperature
              YellowMax
              YellowMin
              Yellow

              Volume

                • Re: Issues with Ordering and Positioning of AF Element Attributes
                  gregor

                  Hi Andrea,

                   

                  Is the behavior you are expecting described somewhere as a kind of industry standard or similar? Is there any resource that you can refer to?

                  Besides that I wouldn't know the behavior you expect is built in with the Asset Framework but Stephen Kwan can likely better answer this question.

                  If this is a common problem, there should be somebody who has been facing this already. I am still hoping for a comment from within the community of users.

                    • Re: Issues with Ordering and Positioning of AF Element Attributes
                      skwan

                      Hi Andrea:

                      AF sorts by name because the sorting is done by SQL Server.  I understand your needs and I can recall maybe a couple of customers requesting this feature.  In their case, they want the asset hierarchy to resemble the physical arrangement of their assets - i.e. Asset_B is positioned before Asset_A in their plant so they want to see that same physical ordering in client tools such as PI System Explorer.  We have not implemented this due to several concerns that we have.  Let me elaborate on a couple of things that immediately come to mind.

                      • By adding a sort field, we would increase the size of the AF object.  This may be small but having it on every attribute and in some of the industries that we serve, such as AMI, an AF database can have 1 billion attributes.  Any increase in size would negatively affect performance in very large systems.
                      • When there are large number of objects to retrieve from SQL Server, we implement paging.  If we had another sort field, we would need to first sort it before we can start doing paging, otherwise you would get very weird results from clients as the 10th page may have data that really belongs on the 1st page.  This sorting + paging is very resource intensive and again negatively affect performance especially for large systems.
                      • Any implementation of a sort field would require all our clients to adopt it, e.g. Coresight, ProcessBook, etc.

                      Unfortunately the number of customers requiring a custom sort field is quite small and it's simply not very high on our priority list - both servers and clients.

                      --

                      Steve Kwan

                      7 of 7 people found this helpful
                        • Re: Issues with Ordering and Positioning of AF Element Attributes
                          Guilherme Ferreira

                          Hi Steve!

                           

                          As system integrator, I have been questioned by customers a couple of times about this ordering also. I have wanted this feature myself as well, but never brought this up to discussion and appreciate your explanation on the matter now.

                          However, not beeing an expert in SQL server or relational database performance in general, I have a doubt:

                          why is it ok for SQL Server ordering by name while expensive ordering by any other field? Isn't object's name one column the same way any other field is?

                           

                          Regards

                            • Re: Issues with Ordering and Positioning of AF Element Attributes
                              skwan

                              Hi Guilherme,

                              I did not imply that it cannot be done .  What I wanted to say was that this would increase complexity and negatively impact scalability.  It also requires all our clients to support this so it's impactful to the entire PI System.  Due to the relatively small number of requests that I have received, it has never been high priority to support this both on the server side and client side.

                              --

                              Steve Kwan

                              1 of 1 people found this helpful
                                • Re: Issues with Ordering and Positioning of AF Element Attributes
                                  acarlini548b

                                  Thanks Steve for the clarification.

                                  While I completely understand your concern , I'm with those that are looking forward to complete AF with this kind of basic functionalities we consider fundamental in such kind of applications.

                                   

                                  To reply to Gregor,  we are talking about standards in defining measures for analytical tests, or characteristics for Product Specifications and Recipes ( in AF we should have Instrument and Equipment Design Specification ).

                                  All of them refers to an order/positioning field in the structure that is normally a simple integer, maintained by the app when you edit your set of records ( attributes/parameters/measures ) . It is not commonly set in all the results/element attributes , but only at the "attribute template" level, and a view links that order field to the other information so you don't have to create that field in the big data table. If you need it, you search through the view ( using JDBC/ODBC interfaces ).

                                  From the client/reporting side this has a terrific positive effect.

                                   

                                  As mentioned before, in the past ( starting more than 20 years ago ) we faced this issue in user groups meeting of many different application types ( LIMS, MES, PLMs, ERP ... ) and it was hard as today to explain why this is was very important feature until everybody were able to test the resulting benefits. It is the same logic of "what you type is what you get"

                                   

                                  Again, as this ordering field is added only at attribute template level , it would have no impact in the huge collections, and for those using JDBC/ODBC a definition of a custom view would be enough to do the magic

                                   

                                  Thanks a lot for your feedback.

                                  Andrea.

                                    • Re: Issues with Ordering and Positioning of AF Element Attributes
                                      skwan

                                      Hi Andrea:

                                      What would you use as a client tool to visualize your data if such ordering is possible?

                                      --

                                      Steve Kwan

                                        • Re: Issues with Ordering and Positioning of AF Element Attributes
                                          acarlini548b

                                          Well, first of all, PI System Explorer.

                                           

                                          Then, for the advanced reporting it depends if the ordering is kept at template level or down to the snapshot, as we have a Web App to navigate through Instrument and Equipment Design Specification, down to real time data.

                                           

                                          In the first case ( template level ) we are forced to use JDBC/ODBC with the view I mentioned before and , a simplify our Web application that communicates with PI with two interfaces

                                          1)  PI Web API , for simple queries and data maintenance operations

                                          2) Our own SOAP that get the data in JSON or XML format via JDBC performed at the server side ( that's a very simple service )

                                           

                                          In the second case, where the ordering will be implemented down to the element attribute details and in PI Web API, then we would use only the native PI Web API to communicate with PI.

                                          Eventually also PI CoreSight would be a bit more readable for the users if the attributes are automatically sorted in the correct order, and even with PI DataLink you can build a single simple spreadsheet to visualize any kind of element data in the correct sequence disregarding from the template type.

                                           

                                          Andrea

                                      • Re: Issues with Ordering and Positioning of AF Element Attributes
                                        jagdish.konathala

                                        Hi Steve! We approached this order problem on the client side in a previous project without a lot of work since it could be easily done by the developers. Having said that, if we receive the request in a predefined order, then that is one less thing we have to worry about. Order is AF related and best implemented at template level is what I feel. Andrea's requirement is a definite feature request and I am hoping your team can perform some testing to see if it negatively impacts with scale.