8 Replies Latest reply on Jun 13, 2013 3:09 PM by mhamel

    Update PI Graphic Using XSLT

    chumenik

      I am not sure if this is the correct place for this question, but here it is...

       

      I am trying to update a PI Graphic using an XSLT transform file that will use an Active Directory user group to determine where the button redirects the user in the PI Graphic. I would also like to be able to set the visibility of some objects within the PI Graphic using the same user group information. Has anyone done something like this or have any suggestions on how this can be done.

       

      Thank you in advance.

        • Re: Update PI Graphic Using XSLT
          mhamel

          @Christopher: Resolving Active Directory questions require to be "server-side" or to make use of an ActiveX on the client which has to be enabled. On SharePoint, there are some ways to extract SharePoint group membership if you need but I don`t know if that would work within a PI Graphics.

           

          One way I can think you can succeed with this would be to write a custom AF Data Reference that would perform this job (finding the group membership) for you and return it via an AF Attribute. Thereafter, you would need to hide an XML element within your .svg file for later manipulation. Using conditional XSL transform instructions, you could handle the right redirection for your buttons.

           

          I haven`t tested this myself before but this is something that could work.

           

          I am curious to better understand your use case. Can you describe it better?

            • Re: Update PI Graphic Using XSLT
              gsorin

              Some background on this post:

               

              The PI WebParts site has displays for many plants. The highest level display is map with geographic regions. The user is currently able to navigate through a geographic hierarchy of displays to the Overview display level for each plant. Each plant has an Overview display and buttons to navigate to 4-6 other plant-specific displays.

               

              The new requirement is to control access to the displays for three basic AD groups as follows:

               

              •         Group A – allowed to see the data on all displays for all plants

               

              •         Group B – allowed to see the data on all displays for only some of the plants (in reality there will be many ‘Group B’s’)

               

              •         Group C – allowed to see the data on only one display (not the overview display) for each of the plants

               

              Tech support suggested using XSLT to modify the contents of the SVG file. (Call # 472014)

               

              What is the best way to meet the requirements stated above? Is XSLT the only option here?

                • Re: Update PI Graphic Using XSLT
                  kpierce

                  This is my understanding of the scenario, please correct, update if incorrect...

                   

                  1. A user connects into a home page.

                   

                  2. The user can navigate from the home page, by clicking within a PI graphic SVG file.  The link will take them to a plant overview. Each user should be able to see the home page and the plant page.

                   

                  3. Only some users should be able to click the links in the plant level display that will take them to other, more detailed displays (SVG files).  We want to limit some user groups to not be able to see the detailed pages (Sharepoint page and detailed SVG display).  The limitation would be by Sharepoint user group or role.

                   

                  I’m not sure that I have the correct info on the current setup, i.e. I’m not sure if they are changing the content of the PI Graphic web part (based on clicking items within the graphic) or that they are navigating to different Sharepoint pages using the links within the graphic.  I'm not aware of a way to navigate Sharepoint pages using PI Graphic (SVG) links or change the PI Graphic content using the same sort of links.

                   

                  Here are some potential options or things for consideration:

                   

                  1.     Let Sharepoint show the error page when the page being accessed is not allowed by this user group. (Sharepoint security would be used to control access to pages with additional detail that some users should not have access to).

                   

                  2.     Disable the links (e.g. hide them) within the PI Graphic using XSLT for the display that will render it differently for different Sharepoint groups (although I'm not sure how one would know the Sharepoint group of the logged on user within XSLT)

                   

                  3.     Setup separate navigation paths, allowing users to go to role-based page paths (requires additional Sharepoint page setup and additional SVG files)

                   

                  4.     Setup different SVG files at the plant level, one with the detailed links and one without. Show the correct display based on the Sharepoint user group (not sure this can be done with OOTB web parts; might require a hidden web part (custom) that sends the right graphic to the PI Graphic web part based on the logged on users group membership).

                   

                  5.     Allow navigation to deeper levels of detail using links in other web parts (e.g. AF treeview, Sharepoint list links, PI Table part, etc.) and limit the visibility of links based on Sharepoint and possibly PI security principals and authorization definitions (maens that the links come out of the graphics).

                   

                  It's an interesting issue.  Food for thought...

                    • Re: Update PI Graphic Using XSLT
                      Asle Frantzen

                      Couple of comments:

                       

                      1. This is a PI Graphic webpart and it's probably just that one webpart being used. He only says 'displays', not 'pages' - and from that I take it that the SVG path is being sent from the PI Treeview to the PI Graphic webpart, and all the different displays are shown in that single PI Graphic instance. If you're going to have different Sharepoint security for the different SVG files you probably need to create different document libraries and set the security on each of those.

                       

                      3. This is a little bit what I said in pt 1. I would like to mention I've been using the Audience feature of Sharepoint a couple of times and that also works great with AD groups. The idea there is mostly to hide/show webparts based on the audience settings. So if you set up multiple PI Treeview webparts, each pointing to different hierarchies in AF, you can just show the webpart corresponding with the AD group the current user belongs to. (I don't think there are limitations on how many PI Treeview webparts can send client-side parameters to the PI Graphic webpart)

                      • Re: Update PI Graphic Using XSLT
                        chumenik

                        Current Setup: Once a user has selected the region on the US map, the web page updates with that Region PI Graphic. Then the user must select a site, then only the PI Graphic updates to the sites Overview page. The Overview page displays information and button links to more detailed information, when select only updates the PI Graphic, not the web page.

                         

                        #1: We would like to not show an error page.

                         

                        #2: This is our current thought process and what makes the most sense to me for maintainability.

                         

                        #3 & #4 : We do not want to duplicate files.

                         

                        #5: Would involve having to convert all of the screens data points into and build the AF database and then tie the template screens to that database and then build out the differences, which we are not ready to invest the time and effort for this option.

                         

                        At this point I would like any more information regarding #2. Thank you for your reply.