Welcome to my 1st blog post since vCampus became part of PI Square. It has been far too long since I last wrote a blog.
I wanted to start off this blog post by first briefly mentioning my long history working with PI ProcessBook over the years, particularly in the automation of PI ProcessBook displays to achieve specific user experience challenges. It is fair to say I have written thousands upon thousands of lines of VBA to achieve different tasks for different clients. So I am no stranger to automation and in some ways it has always been easier to quickly automate something whilst we wait for ProcessBook to natively provide functionality...although those waiting days may be numbered.
Also, I've been involved with OSIsoft products for far too long (around 15 years), raised my children on Chocolate Milk from the OSIsoft AF Chocolate Milk Factory, taught them to draw squiggly lines just like Sinusoid, and educated them on the reason for Compressing their allowance so it takes up less room in their pockets.
Back on track about PI Coresight...
You can imagine my first thoughts when we all first heard about PI Coresight, "that's awesome" but it was swiftly followed by "hang on what about all my VBA code", which was quickly followed by "what about my PI ProcessBook displays without VBA, what am I going to do with them". I'm not the world's biggest fan of SharePoint so I wasn't looking at PI Web Parts to be my saviour.
Anyway, fast forward some time and we land at the dawn of having hosted PI ProcessBook displays in PI Coresight. Brilliant. Straight away I was working with a client and came up with some scripts to make 1000s of PI ProcessBook displays "ready" for PI Coresight and then identify those displays that need some special attention because of the use of lots of VBA. I managed to work my way through to undo the VBA used over the years to achieve the same thing that can now be done by PI ProcessBook natively, and this made sure the displays would play nicely in PI Coresight. Obviously you can only take that so far before you hit those limitations on having an even better user experience in PI Coresight hosted ProcessBook displays. It is probably no surprise that I came up against that limitation pretty quickly, but being the OSIsoft advocate that I am I wasn't ready to give in just yet...
In this post on PI Square I highlighted an issue that I could solve with VBA in ProcessBook but there didn't seem to be a way to solve it when the PI ProcessBook display was hosted in PI Coresight.
Here is a brief explanation of the problem:
I have an Overview screen - Overview.pdi - that visually represents a large number of assets, and the display was built using VBA automation in PI ProcessBook. Each asset has a "hidden" ProcessBook button overlaid that points at another ProcessBook display - AssetDetail.pdi. AssetDetail.pdi is an Element Relative Display based on the AF Template of the assets represented in Overview.pdi. Hidden buttons work just fine in PI Coresight.
The 1st challenge was to know how to point each of the buttons at the ERD in Coresight and pass the correct "Current Element" so that PI Coresight sets the correct context. Well this step was pretty straightforward. First the AssetDetail.pdi display is loaded into PI Coresight, it is converted & then hosted in PI Coresight. I now have the URL for that display, which I know to set context I append the QueryString with "?CurrentElement=" followed by the path to the AF Element. Some nice VBA later and I extract the root Element path from the Symbols that visually make up the asset and then automatically change the ProcessBook button to link to the PI coresight hosted version with the "?CurrentElement=" part already filled in. Now whenever anybody goes to Overview.pdi in PI Coresight they'll be able to click on any asset and go straight to the detail for that asset because the URL was already set in ProcessBook. Perfect, and it works beautifully. I also had some VBA to disable the button if the user was using ProcessBook so that they didn't keep linking off to Coresight, instead some other VBA kicks in and opens the ERD display in ProcessBook and sets the context.
The next challenge was painful and meant I lacked some sleep for a couple of nights. You can only fit so much information onto a display before the display starts to lose its effectiveness by overburdening the user with too much information. This meant that I actually need to have a number of AssetDetails.pdi type displays that all share the same context but show different information based on the display. For example, AssetDetails-Overview.pdi, AssetDetails-Component1.pdi, AssetDetails-Component2.pdi ...
I kept thinking "how on earth will I do this in PI Coresight hosted displays", and tried to think of all kind of ways to trick ProcessBook or Coresight into setting the context. Basicially instead of drilling down from an "Overview" to a "Detail" display, I want to side-step from one "Detail" display to another "Detail" display.
My focus at this point was well and truly set on manipulating what PI coresight is rendering because I can't do anything with VBA at run-time in ProcessBook that would influence what PI Coresight renders.
The start of the solution:
One evening after I managed to get all my kids to sleep, an achievement in itself, I opened my laptop, fired up Visual Studio and made a nice strong cup of coffee. I was playing with a few ideas that seemed promising but wasn't really getting to where I wanted to be. Earlier in the day I had a message from Patrice Thivierge who had suggested a possible approach which was along the same lines as to what I was already exploring but upon re-reading his message he made "the penny drop" for me, so I am thankful to Patrice for the added inspiration!
What I soon discovered was a huge floodgate of ideas that I could now achieve, something that is probably going to open up a whole new world of PI Coresight automation!
What now happens on my PI Coresight displays is that when I view an Element Relative Display hosted in Coresight is that any of "my links" to another ERD display in Coresight have the CurrentElement automatically set based on the current context of the PI Coresight hosted display being viewed. And it works perfectly so far in both IE and Chrome. I've not gone near the mobile aspects yet, I may decide to test that at a later date but I think it will work fine too.
How did I do it:
Now if you are still reading this blog post then I must have captured your attention & interest. I am also going to tease you for now as for this 1st blog post I wanted to introduce the problem and share my delight at finding a solution. The details of the solution will follow in my next blog post - you won't have too long to wait for that. If there is sufficient demand for the blog post earlier then I may accelerate the writing of that post.
Just to open your mind a little bit as to what I can now achieve (some items not fully tested) in PI Coresight:
- Manipulation of ProcessBook Symbols.
- Timer based events, e.g. re-introducing the "Display_DataUpdate" event.
- Play Sounds.
- Custom text in Tool tips on Symbols.
Note: At the moment I built a "hack" in order to solve a real issue that I had with PI Coresight hosted ProcessBook displays. It works for my particular problem and may not work for your problems nor is it a solution to have all your VBA working when hosted in PI Coresight. Instead what I have is a lightweight ability to provide similar, certainly only a sub-set of, functionality to that which we've all achieved over the years in ProcessBook.
Project "Coresight Candy".
What I am interested in hearing from everyone is if there is appetite in the community to have a community led project based on this that provides a light-weight framework for display automation in PI Coresight?
It would be seen as a stop gap until we have the next generation web display builder from OSIsoft. It may end up being a stop gap for a year or so.
Part 2 coming soon.