7 Replies Latest reply on Jun 9, 2011 2:55 PM by Asle Frantzen

    SharePoint Web Parts in a PI Environment

    paulverey

      Can you imagine a client that has a big investment in PI Enterprise Servers running as a PI Collective serving up 0.5M points of extremely valuable process data into a dashboard/portal environment for presentation, analysis and decision making. So far so good, but then this client tells you he is not keen on PI WebParts!

       

      Question is, how do we persuade him that PI WebParts really are the best components to use in this scenario given their superb integration with the PI Server, their Web Part communication capability, real-time refresh and so on? Despite this the client insists on the use of other Web Part catalogues.

       

      Another question, how good can the Dundas Charts product be, or Chart FX, both companies offer SharePoint Web Parts, can they be effective in a PI environment. Are there any other Web Part catalogues that should be consisdered before we really do persuade the client of the error of his ways? Has anyone got views/experience of 3rd party Web Parts directly accessing PI?

        • Re: SharePoint Web Parts in a PI Environment
          merighm

          Many people have that initial attitude because they see more Gauge templates in third-paty packages than in RtWebparts!  But the moment you ignore RtGauge and examine the other webparts, you find a very rich set of features.

           

          1. A customer such as you describe is likely to have a large number of ProcessBook documents.  RtGraphic is the only webpart that can be used to publish those graphics through SharePoint with practically no additional effort.  RtGraphic not only refreshes data periodically, but double-clicking on a tag value in RtGraphic displays its trend (you can also select a group of tags and display their trend).  There are quite a few features like this that no other "general purpose" webpart can mimic.

           

          2. RtTrend is also a high performance component.  I know of no other charing component that comes close to RtTrend when dealing with large amounts of PI data.

           

          3. A license for RtWebparts comes with PI DataLink for Excel Services.  This is a easy and powerfull way to publish DataLink reports and/or create nicely formatted table-like webparts.

           

          4. Third-party packages such as Dundas Charts looks flashy (at least on glossy magazines and demo screens), but they require PI-DA.  This is not an issue for customers who have PI-DA, but it is important for those who do not.

           

          5. RtTreeView leverages your PI-MDB (and PI-AF) configuration.

           

          Moh&

            • Re: SharePoint Web Parts in a PI Environment
              Sam Pride

              Good points Moh,

               

               

               

              Whilst there are a lot of very valid reasons for using PI-WebParts over a brew-your-own, I will outline a few that spring to mind.

              • The classic Off The Shelf, vs Custom coding argument. OSIsoft employs a large team of Developers, QA, testers, techsupport and us vCampus guys that handle the all the design, maintenance and support of the suite. People often underestimate the real costs of developing software. Looking at the licensing fees for dundas chart (for sharepoint), I can see a custom solution will start costing some real money to implement.
              • The PI components are optimised for Live, real-time data. Smooth, seemless updating of the trends and graphical elements opposed to constantly refreshing a generated image has performance and usability bonuses. Furthermore, trends and other graph's have much more functionality straight out of the box. Zooming, trend cursors ad-hoc trending and the consistent functionality/mechanisms across all WebParts is a big bonus.
              • PI Baseline Services is pretty smart. It does a lot of work to pump data into the WebParts smoothly and efficiently. Baseline offers cachnign of data, something that will be hard to implement in a brew-your-own solution.
              • As Moh has metnioned, DLES is a no-brainer.
              • Again, Moh mentioned Context-sensitive pages, using the RtTreeView and connections. This is such a time saver, I think I need to reiterate.

              Whilst I do agree, you get some very pretty looking graphs with Dundas etc, after a while, its the content that counts. RtTrend provides a much quicker, more accurate version of the data. DOn't forget, you are not limited to PI data as well.

               

              If you want more help, why not enlist your friendly Account Manager? They come across these questions frequently and can most likely provide materials for you to help persuade the customer (or they could do it for you

                • Re: SharePoint Web Parts in a PI Environment
                  formerpigeek

                  Moh and Sam have made some good points.

                   

                  It seems like you’ve already identified some key selling points, namely superb integration with the PI Server, Web Part communication capability, and real-time refresh. I would emphasize that our web part communications occur client-side, and when coupled with real-time refresh this means the user has an interactive web application that doesn’t require the user to refresh the page, nor does the page refresh when the user takes action. But to me, the key differentiator is a combination of your first & third points: PI Server integration, and real-time refresh. Most generic web part packages that you’ll find will certainly require some work to get them to display PI Server data, but once you’ve tackled that challenge, the web parts themselves simply aren’t oriented around time. None of them will understand what “*-1h” means, and it will be difficult or impossible to have a user-modifiable time context on the web part page that could be passed effectively to a generic part. In short, generic web parts are constructed for looking at last quarter’s financial data, and not to watch time-series data in real-time.

                   

                  Can you share any more information regarding why your client is not keen on PI WebParts?  Is there a particular visualization that they are interested in that we currently do not provide?  I am in the product management group at OSIsoft and am interested in hearing the feedback your clients have about PI WebParts.

                • Re: SharePoint Web Parts in a PI Environment
                  shifflet

                  I have the same issue going on.   PI Web Parts needs some fancy gauge templates.   They want the eye candy so they are looking at another product.  

                    • Re: SharePoint Web Parts in a PI Environment
                      Asle Frantzen

                      Have you considered using just a couple of hours with the tools already available? The image I've attached here is of PI Webparts with different designs.

                       

                      I understand what you mean by nice looking gauge templates though. We've actually tried using Dundas Charts and Gauges in some cases, but unfortunately those products aren't available any longer (as Dundas sold the code base to Microsoft). Microsoft haven't come up with the same kind of products yet, but the chart component which used to be Dundas Charts is now .NET Chart component.

                       

                      But as long as you use a third party visual component which can read data from SQL (via a Linked Server to PI) or directly via PI OLEDB Provider, you should have no problem presenting PI data in a more sexy way

                       

                       

                       

                      4454.webparts_5F00_example.jpg