9 Replies Latest reply on Aug 27, 2018 3:46 PM by AbelHeinsbroek

    Streamset AdHoc error handling

    AbelHeinsbroek

      Hi All,

       

      I'm building an optimized PI Web API wrapper that collects value, recorded, etc, requests and groups them into a single Streamset Ad Hoc request.

      I'm running into the following problem however: as soon as a single WebID cannot be found, the whole requests fails with a single error.

       

      For example:

       

      https://devdata.osisoft.com/piwebapi/streamsets/value?webid=P1AbEUElTUlYxXE5VR1JFRU5cTlVHUkVFTlxMSVRUTEUgUk9DS1xESVNUSUxMSU5HIFBST0NFU1NcRVFVSVBNRU5UXEYtMjcyfEFTU0VUIE5BTUU&webid=P1AbEUElTUlYxXE5VR1JFRU5cTlVHUkVFTlxMSVRUTEUgUk9DS1xESVNUSUxMSU5HIFBST0NFU1NcRVFVSVBNRU5UXEYtMjcyfEJMQURFUw&webid=P1AbEUElTUlYxXE5VR1JFRU5cTlVHUkVFTlxMSVRUTEUgUk9DS1xESVNUSUxMSU5HIFBST0NFU1NcRVFVSVBNRU5UXEYtMjcyfE5PTiBFWElTVEFOVA&webIDType=PathOnly

       

      Contains two correct WebIDs and one nonexisting, causing the complete request to fail with a single error. Ideally the PI Web Api would include the errors per WebID inside the returned Items array.

       

      Does anyone know a good solution for this problem? Checking each attribute existence prior to the batched streamset request would defeat the purpose of batching the requests. Using templates alleviates the problem somewhat, but we still run into issues when elements contain custom attributes.

       

      Regards,

       

      Abel Heinsbroek

      Vitens

        • Re: Streamset AdHoc error handling
          gregor

          Hi Abel,

           

          I kind of understand your ask to return results for those data items (AF Attributes or PI Points) with GetValuesAdHoc that can be resolved and to return an error for those which cannot be resolved.

           

          PI Web API depends on AF SDK and what is often is a single call against PI Web API must be broken into multiple AF SDK calls. One of the first things PI Web API needs to do is resolving the data items referred to by WebId(s). It appears the implementation of GetValuesAdHoc is processing the WebId's in the order they are passed with the query URL and as soon as a WebId cannot be resolved into a data item, the call breaks and returns the error referring the 'bad' WebId. If there are multiple 'bad' WebId's, only the first 'bad' one is returned. The good thing with this implementation is that the query will return much faster in case of a 'bad' WebId.

           

          My idea about error handling would be to remove the 'bad' WebId from the query URL and to re-execute the query. A blacklisting approach can be used to avoid asking the same 'bad' data items over and over again.

           

          Can you tell where the bad WebId comes from? It doesn't look to me as if this is a WebId 2.0 which was generated client side based on path information but this may also be due to the example against our public PI Web API you picked.

           

          When working asset centric using GetValues may be a good alternative because it allows refer data items by the WebId of a parent Element. By verifying if the parent Element exist one could also maintain a whitelist.  

            • Re: Streamset AdHoc error handling
              AbelHeinsbroek

              Hi Gregor,

               

              We are building a custom framework (PIVue (Work in Progress!)) for building highly interactive web-applications for use-cases where PI Vision is not sufficient. This frameworks allows for building element relative displays, based on an element context and element relative paths. This works perfectly for our newer databases that are template based, but can fail for some of our older databases, where sometimes a random attribute has been deleted or renamed by hand. Because of the request buffering and batching no element is supplied with data because of a single faulty path.

               

              Your suggestion for error handling is ok for now, but will, in the case of multiple bad WebIDs, result in multiple round-trips to the WebAPI server. Another possibility is to forego webid2.0 generation and instead request the webids from the PI server, which does handle exceptions as expected and puts the exceptions inside the Items array.

              https://devdata.osisoft.com/piwebapi/attributes/multiple?path=%5C%5CPISRV1%5CNuGreen%5CNuGreen%5CLittle%20Rock%5CDistill…

               

              For us the perfect solution would be to have the StreamSet/AdHoc methods function the same way as the Attributes/Multiple method does, with exceptions inside the response Items array.

                • Re: Streamset AdHoc error handling
                  gregor

                  Hello Abel,

                   

                  I am still interested to understand where those 'bad' WebId's come from.

                  The GetMultiple method from the Attributes controller is a good choice to verify if Attributes exist.

                  With regards to the behavior of GetAdHoc methods of the Streamset controller, please feel encouraged to create an enhancement request at Uservoice.

                    • Re: Streamset AdHoc error handling
                      AbelHeinsbroek

                      We generate them ourselves based on an element context and context relative path. Because some of our older databases are not template based, the probability of a missing or renamed attribute is high.

                       

                      The problem I have is very similar to that of Aaron Rosenthal. For now introducing a 2-call system would work, first to convert the paths to valid WebIDs, and filtering out the invalid paths, then a second to get all the values.

                    • Re: Streamset AdHoc error handling
                      arosenthal

                      I have this exact issue on UserVoice here: https://feedback.osisoft.com/forums/555145-pi-developer-technologies/suggestions/19591780-adhoc-streamset-actions-fail-if-there-is-at-least

                       

                      Incidentally, I have also been implementing a custom framework with VueJS and I use the same approach to first validate WebIDs with Attributes/Multiple. I had the exact problem you had because I use template inheritance quite a bit, but I request my list of elements based on CategoryName. Since there is no guarantee the elements will all be of the same template, they will not have the same attributes. However, asking for a list of all attributes for each element is an expensive query, so I just generate WebIDs myself on the client.

                       

                      I agree it would be even faster if StreamSet/AdHoc could handle invalid WebIDs better. I believe AF SDK does this natively, so I'm not sure what is causing the whole request to fail on the Web API side.

                      1 of 1 people found this helpful
                  • Re: Streamset AdHoc error handling
                    vkaufmann

                    Hi Abel,

                     

                    What is the scenario in which you are supplying an invalid WebId to the AdHoc call? Where did this WebId come from?

                     

                    --Vince

                    • Re: Streamset AdHoc error handling
                      Roger Palmen

                      You could try and refactor into a batch call, but i admit this is not a great approach. I agree with Vincent Kaufmann here, if you have failing WebID's you should prevent those...