Batch Customers Are Asking: Can I run PI Batch and PI Event Frames in Parallel?

Background:

First, for a recent summary of the status of PI Event Frames for batch customers, refer to the following post:

http://community.osisoft.com/index.php?/topic/1899-batch-customer-roadmap/

We've been receiving more and more questions of late from batch customers asking if it's possible to run PI Batch Interfaces in parallel with PI Event Frame [Batch] Interfaces so that data is stored in both the PI Batch Database and PI Event Frames database redundantly. 

The thought with this approach is that it would potentially enable batch customers to continue to use batch clients they need (like PI BatchView overlay trend and RtReports) but still enable them to take advantage PI Event Frames advantages such as flexibility, scalability, and new client support in PI Coresight and PI DataLink.

In terms of historical batch data, customers have asked if they can just run the EF Interface instances in history recovery mode to backfill that data into PI Event Frames and then they wouldn't need to run the PI Server 2014 migration functionality when released. 

As a product manager, when I hear these customer questions, I see them as clear evidence that batch customers are very excited about moving to PI Event Frames as soon as possible and are even willing to consider redundantly storing data in two places to get there sooner (typically these approaches are greatly frowned upon from an IT and Quality perspective).  At the same time, it also points out the frustration that some of our batch customers feel with the progress we've made on the PI Event Frames roadmap that they are considering unproven sub-par architectures that result in redundant data and redundant implementation work and could potentially result in problems down the line just to get to use PI Event Frames sooner.  This tells me that we need to continue to work to deliver EF support for an Overlay Trend and RtReports as soon as possible (along with all the other work we already have in progress). 

So, does OSIsoft recommend running PI Batch and PI Event Frames interfaces in parallel?

The bottom line is that OSIsoft does not recommend running PI Batch interfaces and PI Event Frames interfaces in parallel in production (this includes the suggested approach where customers don’t plan on using PI Server 2014 migration functionality).  Why?

There are several reasons why:

1. It is generally not a best practice to store the same data into two identical databases within the same system.  These architectures also typically require pre-approval from quality departments. 
2. Our PI Server 2014 migration strategy will not take into account customers running interfaces in parallel.  The result could be duplicate EF records which would require extensive manual work to clean up. 
3. Since these batch execution system interfaces write to PI tags, it's very likely that a customer may configure both instances to write to the same PI tag and cause duplicate values. 
4. This architecture of PI Batch and PI Event Frames running in parallel potentially keeps batch customers running PI Batch indefinitely whereas we believe it's in batch customers best interest to have a strategy to move them fully forward to PI Event Frames at a time in the future. 
5. OSIsoft has not designed nor tested our batch and EF interfaces to run in parallel so the behaviors in various situations are unknown.  So using the interfaces in this configuration is outside of the intended design. 
6. In regards to our migration strategy from PI Batch to PI Event Frames, this architecture and design is outside of the design assumptions we're making in our migration strategy and as such is a higher likelihood to fail and cause problems for customers in the future.

For these reasons, OSIsoft does not recommend that batch customers run PI Batch and PI EF Interfaces in parallel for the same batch data.  At this time, our standard recommendation is that that most batch customers should continue to use PI Batch over PI Event Frames because it still provides the most complete functionality for this use case at this time. 

The biggest remaining gaps we have to enable most customers to move to PI Event Frames are the Overlay Trend functionality (PI BatchView replacement) and support for AF/EF in RtReports.  For RtReports, this work will begin following the upcoming printing release (RtReports 3.4).  For the overlay trend, we are planning this functionality for a future version of PI Coresight (details TBD) and working it into a plan with some of the other technology changes that need to happen with PI Coresight at the same time (such as Silverlight to HTML5 transition). 

While existing batch customers will likely be disappointed by this news, we believe it is in our batch customer's best interest not to take this unproven approach.

Sincerely,

Todd Brown

Product Manager, PI Batch, PI Event Frames, & RtReports