14 Replies Latest reply on Aug 29, 2018 3:35 PM by kduffy

    AFSDK: Access, analyze and modify Process Book Displays

    martin.mertens

      Hi,

       

      is there any way to open and read/modify the structure of PB Display files with an AFSDK based application? Which piece of code could do that?

       

      Especially, I would like to avoid that a PB application object will start reading all the data that is linked in the displays, which would create unneeded load as well as delays.

       

      Thanks

      Martin

        • Re: AFSDK: Access, analyze and modify Process Book Displays
          vkaufmann

          Hi Martin,

           

          There is nothing in the AFSDK that interacts with ProcessBook displays. Can you elaborate more on what you are trying to accomplish?

           

          --Vince

            • Re: AFSDK: Access, analyze and modify Process Book Displays
              martin.mertens

              Hi Vince,

               

              I would like to access and modify PB elements (including datasets) that read linked data like Points and AF Attributes. At the same time, I would like to have access to this linked data, for example to see whether a Point exists and how it is configured. In some cases, I would like to change these references, for example by replacing a tag reference by an attribute reference in a trend.

               

              I will have a look at the PB support tool.

               

              Thanks

              Martin

            • Re: AFSDK: Access, analyze and modify Process Book Displays
              Rick Davin

              Hello Martin,

               

              I am answering this with some reluctance, and it's not because what you want to do has nothing to do with AFSDK but rather because what you ask requires a solid intermediate level knowledge of programming, which is not apparent from your question.  But the mere fact that you asked the question the way you did leads me to believe that you may not understand the basic things involved with what you want to do.  Hence, my reluctance.

               

              First of all, AFSDK has absolutely nothing to do with what you want.  But let me extend the original question: Can you use .NET (C# or VB.NET) to programmatically modify a ProcessBook display?  The answer to that is yes.  But the key to that is not really .NET but by virtue of ProcessBook being a Component Object Model (COM) Automation object.  An automation object could be opened and manipulated with VBA as well as .NET.  The fact that your automation object of interest just happens to be ProcessBook is nothing special since it adheres to Microsoft's COM rules, just like Excel or Word.

               

              There is an amazing amount of automation help on the Internet, not to mention within TechSupport and/or PI Square.  This could be easily searched, and the fact that you did not try such as search also leads to my reluctance to share examples.  However, you may try an Internet search on: vba automation object.  If you want to know more about using COM Automation with .NET, you could search on .net com automation object.

               

              For specific help on ProcessBook, I suggest you download and carefully read:  PI ProcessBook Programmer's Reference.  Granted that is in VBA, but it does give examples of manipulating the automation objects, and if you are an experienced enough developer, you should be able to translate that into your .NET language of choice. 

               

              Good luck,

              Rick

              3 of 3 people found this helpful
                • Re: AFSDK: Access, analyze and modify Process Book Displays
                  martin.mertens

                  Hello Rick,

                   

                  thank you. I intentionally put my question this way, because I was hoping to avoid the whole "COM thing".

                   

                  Since PDIs are just files, there is no reason to me why a native .NET library like AFSDK should not offer a way to parse these files.Of source, this neither is the main intention of this SDK, nor it's the same generation of products. So, for you it may look like I do not understand the basic things involved with what I want to do, while for me, it more looks that I am trying to find a simple way that seems not to be existing.

                   

                  Thanks

                  Martin

                • Re: AFSDK: Access, analyze and modify Process Book Displays
                  jyi

                  Perhaps what you are looking for is something close to this? PI ProcessBook Support Tool

                  With this tool, you can:

                  • Silently open and replace pi servername/tagname, AF servername/path
                  • Extract displays from .piw
                  • change language codes
                  • convert displays' format
                  5 of 5 people found this helpful
                    • Re: AFSDK: Access, analyze and modify Process Book Displays
                      martin.mertens

                      Thank you! I will have a look at this tool.

                        • Re: AFSDK: Access, analyze and modify Process Book Displays
                          martin.mertens

                          I tested the PB Support Tool. It creates a full PB application object, which loads all referenced data and executes all macros. Unfortunately, this means a lot of time, load and also errors and crashes while batch processing lot's of display files.

                           

                          I will try again, but I suspect that it will not do the trick.

                           

                          Thanks

                          Martin

                            • Re: AFSDK: Access, analyze and modify Process Book Displays
                              gregor

                              Hi Martin,

                               

                              What is the exact issue you like to address?

                                • Re: AFSDK: Access, analyze and modify Process Book Displays
                                  martin.mertens

                                  Hi Gregor,

                                   

                                  I would like to access and modify PB elements (including datasets) that read linked data like Points and AF Attributes. At the same time, I would like to have access to this linked data, for example to see whether a Point exists and how it is configured. In some cases, I would like to change these references, for example by replacing a tag reference by an attribute reference in a trend. It may also be necessary to create attributes and analytics.

                                   

                                  Thanks

                                  Martin

                                    • Re: AFSDK: Access, analyze and modify Process Book Displays
                                      gregor

                                      Hi Martin,

                                       

                                      The usual way to do this is modifying the display with PI ProcessBook in Edit mode but I assume you wouldn't ask if you wouldn't experience any issues with that. I read you try to avoid creating load and delays. Is it that you are on a slow network causing data retrieval to be very slow? Is it that some data items referred to in displays are unavailable for some reason? Is it that displays open with huge time periods selected so calls for data time out?

                                      1 of 1 people found this helpful
                                        • Re: AFSDK: Access, analyze and modify Process Book Displays
                                          martin.mertens

                                          Hi Gregor,

                                           

                                          sorry, I forgot to mention that I am talking about 9000 display files. They have been created by different persons with different aims and lot's of custom content. I don't see any way to do anything manually, especially assuming that this way has to be probably repeatable.

                                           

                                          Fully loading these files is no option (in my opinion): startup macros are sometimes defect and cause error messages, the data loading time is consiable in many cases (some minutes). It would take at leat days to do this.

                                        • Re: AFSDK: Access, analyze and modify Process Book Displays
                                          kduffy

                                          Hi Martin,

                                           

                                          Unfortunately, the way the support tool is doing it is the best way. You don't have to use the support tool itself, but the support tool uses the PB Interop libraries, which is your best bet in this case (either to write a .NET application yourself that uses them, or to just use the PB support tool). The interop libraries expose a Processbook object model and convert the .NET calls made in the application (either yours or the support tool) into COM calls that ProcessBook understands, however, as far as I know, they rely on a display being open within ProcessBook so that it can handle any calls to the file itself (to get things like the point being referenced by the value symbol). Therefore, you'd need the display to have been loaded, triggering the initialization sequence, but you don't need to mess with any of the COM stuff yourself.

                                           

                                          If you'd like to go this route, the object model from the interops is very similar to that of the VBA object model (documentation here). You just need to add the two interop libraries to your project (%pihome%\ProcBook\PublicAssemblies\ then OSIsoft.PBObjLib.dll and OSIsoft.PBSymLib.dll).

                                           

                                          If the macros themselves are a majority of the problem, then you can get around this by turning off the loading of macros from the procbook.ini file using the MacroProtectionLevel=6. This should allow your application to open the display without triggering the Display_Open code, and hopefully get around these errors at startup.

                                           

                                          As for any other real option, there's not much that can be done because PDI files are stored in binary and we don't have a binary reader aside from ProcessBook itself that you can use to read in the file, and we don't provide support for manually reading in the byte array from file. I understand your logic in that the AFSDK could have been written to expose the displays since it's our libraries and our client tools, however our libraries (AFSDK, PISDK, PI API, PI Web API, etc) have never exposed anything about the client tools themselves, just the PI System (PI Data Archive and AF Server). Since ProcessBook files are stored on disc, as opposed to somehow being stored in an AF element or a PI module, then the libraries we release don't expose them.

                                           

                                          Kelsey

                                          4 of 4 people found this helpful
                                            • Re: AFSDK: Access, analyze and modify Process Book Displays
                                              martin.mertens

                                              Hi Kelsey,

                                               

                                              thank you for your detailed and very helpful reply.

                                               

                                              I would like to address the design aspect of the libraries first: I understand your logic that the purpose of AFSDK is the access to the main PI server infrastructure. However, from a user's view, there's a catch: there is logic and data in PB displays that is intented (by OSIsoft, not by me) to migrate to AF in future. Currently, we are asked by OSIsoft to try to use AF Analytics instead of datasets, because datasets in large scale seem to cause some severe problems in the Archive Subsystem. This might seem an individual problem, but I think that the migration aspect is something that others will also have. Of course, it can be another native .NET library and does not need to be AFSDK (as I formulated in my first post and which was apparently interpreted as ignorance). But the COM approach seems at least problematic.

                                               

                                              I will have a look at the interop libraries. Turning off macro loading is definately helpful. Is there also any way to prevent PB from access all the archive/AF data?

                                               

                                              Thanks

                                              Martin

                                              1 of 1 people found this helpful
                                                • Re: AFSDK: Access, analyze and modify Process Book Displays
                                                  kduffy

                                                  Hi Martin,

                                                   

                                                  Unfortunately, the answer to both is no, it's not possible.

                                                   

                                                  First, there is no way to turn off connectivity to the PI server when loading the display like there is with macros. If the machine loading ProcessBook can't physically reach the PI server (disconnected from the network, etc) then it will wait for the timeout period before moving on; this may be faster or slower than loading the data depending on how much data you're loading. The problem with this technique is that when using the ProcessBook object model to replace data items, certain changes may not take if there is no response from the server. If a datatype is needed to be known, for example, then setting the data item can fail if the server doesn't respond with the type. You may be able to get away with this approach, but across so many displays and data item changes, I would expect you to run into this issue a number of times.

                                                   

                                                  Second, there is no migration tool of sorts that migrates a dataset to an AF Analysis. The reason for this is because a dataset uses PI tags and literals (ints, strings, etc), whatever the archive subsystem can understand. AF Analyses can use these as well, but it's not our recommended method of analysis creation to use PI tags directly. Therefore, we haven't created anything that migrates the formula of a dataset to a formula of an analysis. Instead, we recommend building the element and attribute hierarchy of the AF database, then referencing these attributes in the analysis. There is no possible way to know how to map a dataset's tags to this new AF structure. Since this is our best practice, it leads to a situation where we don't have anything for you.

                                                   

                                                  Finally, you're definitely not the only person that's running into this, nor is this the only problem with migrating from ProcessBook to something else. ProcessBook has been enhanced pretty extensively over the last couple decades, but it's been done in a fairly silo'd manner. This has yielded a lot of issues for customers and ourselves as we try to pull everything together, and has resulted in a lot of lessons learned for future products. I've discussed this thread with one of our product managers to make sure the right people are aware of this situation, but to set expectations correctly, that conversation will have more long term results as opposed to anything that would assist you with this in the short term.

                                                   

                                                  Given that this is not an ideal situation for you, I can walk you through what I would attempt to do if I were in charge this task:

                                                  1. Get a list of all the calculation dataset formulas across the displays. This thread can get you started on how to iterate through all of them; it uses VBA but the .NET object model is similar enough, and your application could potentially loop through all displays at once (not quickly, obviously, but shouldn't need to be attended to).

                                                  2. Build out an AF element structure if necessary. I'm not sure if you already have the analyses built out, or were thinking of doing that. This step can be pretty involved and we have a lot of resources (documentation, videos, classes, etc).

                                                  3. Build out a csv file or a dictionary mapping the existing dataset names to the new af analysis attribute names

                                                  4. Use the processbook object model to loop through each display, each data item, and when it finds the dataset, switch it to the analysis.

                                                   

                                                  Hopefully this sheds some light on why your perfectly valid request really doesn't have a good answer on our end. And if you have any further questions, I'd be happy to facilitate a conversation with the product managers.

                                                   

                                                  Kelsey

                                                  2 of 2 people found this helpful