Real Time Snapshot Support

A must have if replicating to an enterprise server that is then used as the primary source of data for end users.

This idea is very important, Tood. Thanks for sharing.   I would like to mention is a typical use:   - Daily KPIs are calculated at the source system, and they should be available immediately on the destination server as soon as they get calculated in the source.   Unfortunately, with the current implementation of PI System connector, we see a lag of 1 day between the last daily result available in the destination PI System and the one available in the source PI System. One of my customers is having this issue right now.

Another example: One of my customers has a situation where manually entered data or KPIs are calculated on a daily basis, or even hourly. The snapshot value won’t get to our central server till the next hour/day/etc. I don’t think there is a way to force the value to automatically go from snapshot to archive. PI always needs the current value and the previous value to decide if it needs to archive. Therefore, they need the snapshot value to be included in the PI System Connector.

Another vote for this functionality. We replicate data from remote site PI servers to a central enterprise server - having snapshot data available here to trigger real-time alarms is critical. Without this functionality, we are unable to implement PI System Connector at this time.

I heard that this feature is in the works. Is there a tentative timeline for this? Like everyone else here, I agree that this is a very necessary feature.

We need this as well. We have a project on hold until this is done.

In response to Matthew Bailey, "We need this as well. We have a project ..." I should add that we have been waiting for the connector to meet these requirements for 4 years! Essentially we want two collectives ( a source and destination) to be the same.   Requirements - Send PI data even if it's not in AF. - Send real-time snapshot data. It seems really useless for us to be able to only send archive data. Users using the destination system don't get the real-time or accurate values?  A breaker is closed, but the users see's it open? Not making sense. - If a tag name is changed on the source collective, it should update on the destination side. - Should be much faster then PI to PI and APS (multi threaded), should work better across two locations where latency comes to play. - Should be easier to configure then PItoPI and APS

In response to Matthew Bailey, "We need this as well. We have a project ..." I wouldn't get your hopes up. I received an update on this on January 4, 2019 from a connectors product specialist at OSI. He reached out to the product manager for System Connector and they have decided not to support snapshot data collection with PI System Connector. On hearing this news my org has decided to remove System Connector and go with PItoPI/APS instead. The PI System Connector seems like a half-baked solution right now. I've heard from OSI that it should not be seen as a PItoPI replacement (see here) but instead should be seen as a solution for migrating AF DB structure from one AF environment to another. However, as of now, System Connector doesn't support migrating Analyses or Notifications. I have to say that System Connector seemed to handle PI tag creation/updates a lot more seamlessly than APS but also there was much less control and customization. With time I'm sure System Connector will become a solid product but seems lacking as of now.

With 47 votes you would think the folks would listen to what we need. I have not been impressed with how slow this connector has been moving. APS and PItoPI are not working for us. Syncing a collective across a few states, causes latency issues and the sync process takes 24 hours currently.

PI to PI and APS is still not meeting our requirements. While OSIsoft says this is the solution, its not a good one. PI APS processes tags one at a time. Startup time for PItoPI is also slow. APS and PItoPI is not multithreaded. The APS syncing for a large amount of tags is not meeting our need. Because the Connector still does not meet our requirements, we've had to add many (currently 14) interfaces which is very difficult to manage across multiple servers at multiple locations. Anytime we have PI to PI or APS talking to systems at other locations (for disaster recovery) latency causes the startup time and sync times to take hours. Not an acceptable high availability solution.

PI to PI in parallel is not a solution. i expect to have one tool to communicate from a local system to a global system. there should be a straight forward way to connect one PI System to another and not different combinations of tools. another reason, the communication from local to global should be secured (it's with the connector, but not with PI to PI). so the connector should be able to: -communicate historical data based on archive -communicate snapshots in real-time mode -full AF/EF support

In response to Joshua Duncan, "I wouldn't get your hopes up. I received..." I had heard the same thing, but I've also recently heard they've re considered.

In response to Franz Krauter, "PI to PI in parallel is not a solution. ..." Couldn't agree more!

In response to Matthew Bailey, "I had heard the same thing, but I've als..." Hey Matthew, really? So the System Connector team now plans on supporting snapshots? If they do that, give it a more full featured history recovery GUI, and allow for choosing archive modes then maybe it could replace PItoPI. I was disappointed with several aspects of System Connector but I did see some benefits: One-way firewall rules, seamless PI tag attribute sync, and more resilient to network issues (since using SDK vs API tech). I'm happy they're considering supporting snapshots though, that's vital.

It is misleading to brand this product a "PI System Connector" without support for snapshot since it is one of the most fundamental subsystems.

This topic is already under Research/Evaluating. Is there a new status? It's really important to get this support. Use of additional tools like PI Cloud connect, PItoPI interface,... is not straightforward and not in scope of best practice for an state of the art IT Architecture.

Using a historian and it's related tools, it is obvious to get the data real-time. I had no idea System Connector does not support this and it's always a value behind. We are having so much issues especially with Digital, manual entry PI points where OSIsoft recommended to use both Connector and PI to PI. I VOTE!

Without snapshot support, none of my customers will consider using the tool. Snapshots are required for all Analysis and decision making

Now we need to support multiple tools to sync systems: PI2PI and System connector. Moving to a single tool will reduce overall ownership cost.

We need the support as well for a lot of analysis and decision making projects. We have already got a lot of requests from our customer.