3 Replies Latest reply on Jan 8, 2016 7:26 PM by bshang

    Retrieving a subset of attribute values using the PI Web API

    Lonnie Bowling

      Hi Everyone,

       

      I'm trying to determine the most efficient way to get a subset of attribute values if I have the WebId of an element. StreamSet is working find to make bulk calls such as:

       

      /piwebapi/streamsets/{webId}/end

       

      That returns all the values, but I can't see a way to get just a subset of several attributes. The nameFilter looks like it could do the job, but only seems to allow for exact matches or wildcard searches. The exact match works for a single attribute, but I don't see a way to do multiple attribute names like:

       

      /piwebapi/streamsets/{webId}/value?nameFilter=att1name+or+att2name

       

      I know I could use GetValuesAdHoc, but that requires me to collect all the attribute WebIds, which is an extra call using the element information and more overhead.

       

      Any ideas?

       

      Thanks,

       

      Lonnie

        • Re: Retrieving a subset of attribute values using the PI Web API
          bshang

          Hi Lonnie,

           

          There doesn't appear to be a way to do this in the current PI Web API. Your point about abstracting away the attribute webId and removing roundtrips is a good one. I'll bring this up to the dev team and see what can be done.

            • Re: Retrieving a subset of attribute values using the PI Web API
              Lonnie Bowling

              Thanks Barry, that is what I figured.

               

              This is a very typical call that we use all the time, so it would be nice to see the capabilities expanded in a future release. While we are on the subject, it would be really nice to expand that to elements. So if I have a set of elements (maybe built from templates) I could make a single call that would return all the elements with attribute values, including the ability to define a subset. This could potential take 100's of calls down to a single call. MaxCount and index would probably be a good idea to have implemented. The basic work flow we do all the time is find the elements, loop through each one and get the attribute links, then use the links (or WebIds for bulk calls) to get the attribute values, usually the current value.

               

              Lonnie

                • Re: Retrieving a subset of attribute values using the PI Web API
                  bshang

                  Lonnie, I'm wondering if you've looked into using the Batch CTP feature in Web API 2015 R3. It might potentially suit this use case. The single batch request represents a graph of dependent requests. The first set of requests can be Attribute>GetByPath requests. Then, the webIds returned from this request are passed into GetValuesAdHoc. Examples 4-6 in the POST batch/execute documentation show this pattern.

                   

                  The drawbacks to Batch though is that the posted JSON can be large and tedious to construct if there are many attributes. It also requires the client to construct/maintain a set of target attribute paths, so the ability to dynamically query for target attributes are lost (e.g. for a different set of attributes, a different JSON batch document must be defined). So Batch is useful if you know the exact list of attributes to get values for at "compile" time, but doesn't allow for getting attribute values if the attribute list is dynamically constructed (via a query filter) at "runtime". Do you find having the former or latter (or both) more useful in this case?

                   

                  Let us know if you think the Batch controller could be used here or how it could be improved.

                   

                  We also plan to expose AF SDK's FindElementAttributes in the next release so target attribute webIds can be found more directly, instead of looping through each element. It won't decrease the number of calls down to one but should decrease it significantly for some use cases.