3 Replies Latest reply on Jul 28, 2014 6:00 PM by I.Berry

    Web API bulk query and Performance Equation paths

    I.Berry
    I.Berry Jul 24, 2014 8:05 PM

      Hi,

       

      I am currently trying to determine if we will be able to port some of the calls we are doing in PI Webservices to PI Web API when it is released.

       

      There are two things that I am not sure if we will be able to do with Web API that I hope someone can help with.

       

      1) Will it be possible to specify multiple PI Points or attributes when doing a query? 

       

      With PI web-services it was possible to build requests asking for huge numbers of snapshots, in some examples we have requests with over 2000 snapshot values being returned in a single request. How would this be accomplished with the Web API? Would we need to do 2000 GET requests? 

       

      2) Is it possible to use performance equation paths?

       

      The GET streams requires a webID parameter. Can I specify a PE path using GET points and then use that webID calling GET streams? I couldn't get this to work, but it was not clear to me that this is how it might be used.

       

      Many thanks for any help.

       

       

       

      Regards,

       

      Ivan

        • Re: Web API bulk query and Performance Equation paths
          I.Berry
          I.Berry Jul 25, 2014 6:34 PM (in response to I.Berry)

          The more I think about question 1, perhaps it is a stupid question that doesn't fit into the REST approach/paradigm. I suppose it would need to be a post to support such a large number of paths/webIDs.

           

          Perhaps a better way to accomplish this would be by configuring the 2000 tags that we needed snapshot values for to be element attributes, then requesting attributes values for that element.

           

          Still would like to know how to do (2), the ability to do adhoc PEs via the PI web services was very useful functionality.

            • Re: Web API bulk query and Performance Equation paths
              Bhess
              Bhess Employee Jul 25, 2014 7:24 PM (in response to I.Berry)

              Ivan,

               

              Not a stupid question at all.  You've identified the conundrum-- that doing simultaneous requests across multiple resources isn't as straightforward in the REST world as it is in the SOAP world.  In SOAP, you define your request/response to do whatever you'd like.  In REST, a GET implies that you're accessing a single resource.  It's possible of course to define a resource that is a collection of resources.  We're struggling with the best way to model these interactions in PI Web API.  We'd like to build patterns that are repeatable and easy to anticipate across the surface area.  Hence why you won't see it in the first release.  Rest assured (and pardon the pun)-- we're actively working on this internally.

               

              As to your second question-- we unfortunately will not support Performance Equations in our first release.  A good potential workaround is to define an AF attribute that performs the calculation.  This way, common calculations can be written, debugged, and maintained in one place for reuse across the PI System (in DataLink, ProcessBook, PI Web API, and more!)

               

              Best,

               

              Brad

                • Re: Web API bulk query and Performance Equation paths
                  I.Berry
                  I.Berry Jul 28, 2014 6:00 PM (in response to Bhess)

                  Thanks Brad! I would be very interested to see how you handle this. I think one possibility would be something similar to the Batch request  as defined in oData?(www.odata.org/.../batch-processing)

                   

                  The problem with the AF Formula workaround is that it is really powerful to not have to define calculations in advance. DataLink 2014 handles PEs really nicely, you can do them on PI tags or AF PI Points, as long as they are all from the same server. I would hope to see this in WebAPI at some point:)