A recent question on vCampus from a Batch Pharma Customer:
"As long as not all client tools do support event frames (RtReports) I'm struggling with the question what's the best way to move forward with new implementations. We do need the batch events because of rtReports for our deviation reporting purposes, but besides that we also want to start using the CoreSight & Mirabo Livepoint product and I prefer to go for the new Event Frame features. it would be nice if there was a kind of BE to EF sync interface (or vice versa). Maybe there's already an easy solution out there, but at this moment I'm not aware of it ... What do other customers do? How do they solve this?"
=====
Here is my response ... I wanted to make sure batch customers see where we are on this topic.
First, I know from talking to our batch customers that just having EFGen or our Batch Interfaces or the upcoming PI Server Batch DB to EF migration is not enough to enable you to move to PI Event Frames. It needs to be the ‘whole package’, whatever this is for your specific situation. For the majority of existing pharmaceutical PI Batch customers, the ‘whole package of EF support’ is Interfaces + Server Database Migration + PI DataLink + Overlay Trend (BatchView replacement) + RtReports. This formula is essentially is ‘functional equivalence’ for what most have ‘out of the box’ with PI Batch today. I can tell you that we’ve made significant progress on the PI Event Frames roadmap but we have not yet crossed the threshold where I believe the majority of batch customers can move to PI Event Frames. As such, our standard recommendation for batch customers is to go with PI Batch today. For non-batch customers (like other industries or other non-batch event use cases in Chem/Pharma) the recommendation is to start with PI Event Frames. The recommendation is different because different companies are coming from different starting points. So for batch customers, the gaps we have today are mainly the Overlay Trend and RtReports.
Overlay Trend (PI BatchView replacement) – First, we do not plan on adding an overlay trend into PI ProcessBook. There are several reasons for this but the main one is that we don’t believe this would be the fastest route to delivering this functionality to our customers do to the aging code base of PI ProcessBook. We also want to invest our engineering resources into our visualization innovation platform which is PI Coresight and put our customers on a path to the future. So our plan is to add overlay trend functionality into PI Coresight. Your next question is ‘when?’ For this question, I don’t have a definitive answer today but we are working on this plan and this is the next highest priority for visualization of EF. In terms of delivering this functionality, there is a lot of other related work to making this happen in terms of setting our customers up for the future (such as transitioning PI Coresight to HTML5 from Silverlight). So while I don’t have a date to give right now, it’s likely to not be in 2014. In the meantime, Axel is right that functionality like the Overlay Trend and other types of EF visualization can be supplemented by 3rd Party partner products such as Mirabo Livepoint.
RtReports – Our RtReports development team is working on revamping our printing mechanisms to not rely on Word which should resolve many of the issues our customers have with printing. This release is expected as early as the end of March or as late as sometime in May. We are in testing now. After this release, we will turn our attention to adding AF and EF support in RtReports as we know this is a pre-requisite for existing RtReports customers to be able to move to PI Event Frames. Again, there is no date we can put on the roadmap at this time (but this will happen in the months after the upcoming release, RtReports 3.4). While I don’t have a date to give right now, it’s likely to not be in 2014. Alternatives to RtReports on PI Event Frames would be to use our PI System Access products (PI OLEDB Enterprise) to write SQL queries against EF leveraging a reporting solution such as SSRS or Crystal Reports. But this approach is obviously not the same as configuring a report in product like RtReports, but I did want to mention it as an option, for completeness.
Batch & EF Sync – Regarding Axel’s suggested Batch to EF sync interface that would essentially enable running PI Batch and EF in parallel … this is not an approach we are taking with our PI Server 2014 Migration functionality which will be a 1-time migration of the old Batch Data to EF and then PI Batch will be marked to read-only. There are many reasons why we are not doing a live synchronization approach but the main one is that it significantly increases the technical complexity of the implementation and would delay our release to a time period that isn’t desirable for customers either. So it’s a lot more work and it doesn’t get our existing batch customers to PI Event Frames any sooner than our current plan. We also don’t recommend that customers run dual instances of the Batch/EF Interfaces in parallel in production (one writing to PI Batch and another writing to PI Event Frames) because this approach will likely increase the migration complexity significantly when it becomes available in PI Server 2014. Our design will not account for this.
Summary – In summary, based on where we are currently with our released and upcoming products supporting PI Event Frames, our recommendation is that PI Batch customers continue to use PI Batch today. We do not have a complete end-to-end solution for batch customers at this time. This is the focus of Wave 3 of our PI Event Frames roadmap (we are currently finishing Wave 2). We don’t have official dates for the overlay trend or RtReports today, but it is not likely to be delivered in 2014. When we have dates available, I will put them on our official Product Roadmap.
Also, below is a checklist I keep on this subject. It is also important to note that customers that have a lot of custom PI Batch applications (or third party product integration) is really the focus of Wave 3.
I understand that this is not the best news to hear but I do want to be honest and upfront with our batch customers and let you know everything that I know as of today. We’ve built a lot of great EF functionality up in the PI System over the past several years and we are getting closer but we still have some final steps to take so that a majority of our batch customers can move to PI Event Frames. I’ll continue to update everyone as more information becomes available. In the meantime, most existing batch customers should continue to use PI Batch which end-to-end still provides more value than PI Event Frames for batch customers at this time.
Thanks,
Todd Brown
Product Manager, PI Batch, PI Event Frames, RtReports