4 Replies Latest reply on Feb 9, 2011 9:59 PM by spilon

    Multiple PI Collective.

    farooquf

       

       

       

       

      Hi Guys,

       

      Couples of week back we had long discussion on multiple PICollective and path construction. Those questions still are open. In this thread I'm discibing the flow of message and involvement of systems. Considering Middleware and multiple collective what can be the stretagic solution to handle PICollective in Path?

       

      1882.timeseries-data.JPG

       

      SAP IS-U is calling SAP PI Webservice and sending require parameters such as UII, Channel, CIM , Start date, end date and number values in request. SAP PI is taking all request parameters, constructing path (pi://server/UII.Channel.CIM.Value), setting Arch Mannar and finally calling GetPIArchieveData. This solution works fine if we have only one PICollective and know the server name in advance. But in case of multiple PICollective, both SAP IS-U and SAP PI have no information on PICollective and location of the tag.  So I can’t pass server name either from IS-U or SAP PI. If consumer doesn’t know the server name how can he approach and get the time-series data using PITimeSeries service? How can I archive this scenario in our requirements where multiple PICollective are involved? Is there any plan/roadmap of implementing this functionality?  I’m looking for a solution that can call the PITimeSeries service, hit the right PICollective server and get the time-series data.

       

      Note: Similar constraints for GetPISummaryData and GetPISnapshotData. We have a requirement to use this operation also.

       

      Can these be possible solutions??

       

      -          Implement the logic of identifying PI collective in PITimeSeries service itself. Consumer (SAP IS-U/SAP PI) pass complete tag name except server name. Service should identify the server name and handle the request.

       

      -          Make PITimeSeries as a composite service so that it can take tag parameters, call the AF server, get the tag location, if possible, read the data, and finally return the time-series data to consumer.

       

      -          A look up service that can tell the server name where particular tag sits. Once we have a server name we can pass it in the path (in SAP PI or IS-U).

       

       

        • Re: Multiple PI Collective.
          Ahmad Fattahi

          Farooq,

           

          Currently I can think of two plausible ways to approach this problem. One would be to somehow name your tags in a way that it can uniquely identify the parent PI Collective. This way, by looking at the tag name, your application should be able to decipher the name of the corresponding PI Collective. If this is doable and you can set your naming convention for quite some time, this would be a easy-to-implement and scalable solution. Obviously thinking the naming convention through in advance is key.

           

          Another possibility is to devise a local database (at SAP IS-U or SAP PI) and use it as a look up table. This solution would be pretty general and wouldn't bound you to any naming conventions. However, you would need to take care of synchronization between the PI Collectives and the database.

            • Re: Multiple PI Collective.
              farooquf

              Thanks Ahmad.

               

              If I understand second approach correctly, you suggest that a table should contains tag-server pair values.I believe it will be a big impact on performance. If I have 30-40 millions tags (in future), a look-up take ample time. We also want to call this service on a web page to display latest reads.  So performance and response time are also a key factors.

               

              Why can't the PITimeSeries service can accommodate this?  PITimeSeries is developed to fetch time-series data from PI System. And if this is general solution to fetch time-series data then it should support multiple pi collective(that we configure with web-server) also. It can be an enhancement in the service.

               

              Thanks

               

              Farooq

               

               

                • Re: Multiple PI Collective.
                  Ahmad Fattahi

                  Thanks Farooq. If we give it just a tag name without any path, how are you suggesting PITimeSeries should find out the corresponding PI Server/Collective? Do you mean PITimeSeries to keep a database of tags and their corresponding PI Servers/Collectives?

                    • Re: Multiple PI Collective.

                      Farooq, as discussed in the last discussion thread you initiated on the topic, the problem isn't with PI Web Services reading from multiple PI Server Collectives (which it can)... the problem has to do with the notion of "auto-discovering tags" across these multiple collectives. Conceptually, what you are trying to do here is a Collective of PI Server Collectives, which our current offering does not support. In other words, any given PI Server Collective has a unique collection of PI Points and these PI Server Collectives have no knowledge of each other (meaning these collections of PI Points are disconnected). Given the growing scale of PI Systems, rest assured some people at OSIsoft are looking into how to address this the best way possible.

                       

                      In the meantime, a few people suggested ways around this in this thread and the last one, which I'll reiterate here:

                      1. Use some PI Point naming convention from which the PI Server Collective name can be obtained
                        • Fair amount of up front work, but no performance impact and easy maintenance
                      2. Logically group your PI Points across the PI Server Collectives (by location?), so that you implicitly know which PI Server Collective to query for any given PI Point (i.e. not relying on PI Point naming, but rather some other means of grouping)
                        • Significant work to move existing PI Points around and their history, but easy maintenance going forward, and no performance impact and easy maintenance
                      3. Create and maintain some sort of lookup table where you can obtain which PI Server Collective to query for any given PI Point
                        • Fair amount of work to create and maintain, will have some impact on performance

                      One other option I would like to bring to the table here, is the organization of your entire collection of PI Points in an AF hierarchy. The PI Asset Framework (AF) is the recommended approach to navigate your entire set of data, and can point to multiple PI Server Collectives no problem. Then, using PI Web Services' PITimeSeries methods, you simply query these AF Attributes instead of the PI Point directly (af: path instead of pi: path).

                       

                      In order to make sure this is a viable option, I would like to recommend you get in touch with our Technical Support team or your Enterprise Project Manager (EPM) and look into the ideal AF hierarchy, based on your organization and the collection of PI Points you wish to organize that way.

                       

                      Hope this helps!