The newest release of DeltaV has the capabilities of enabling an OPC UA server that could be used to transmit realtime date from DeltaV to the PI database. Right now, the interface between the two systems uses OPC DA. With DeltaV's plan to migrate to only using OPC UA, Is there a roadmap to update the smart connector such that it uses OPC UA for realtime data transmission? This could allow the OPC UA connector to be placed on the PI data server directly since it is much easier to setup OPC UA connections across physically separate machines (as opposed to OPC DA).

Wonderware Connector has limited historical data recovery capabilities. It can cover a few days back in time but has not been designed to perform both realtime values and configurable history recovery period as both processes are synchronous.
An old date is configurable but it would delay real time values capture which is counterproductive with the nature of the connector.
It is not a reproach; that's just what it is.
That's we figured out when implementig and assessing connector with an excellent support from OSISOFT engineers.

Our connector implementation project came with the need of nearly a year of historical data for 27000 tags, so millions and millions of values to read and write.
We considered the method recommended in PI Square with RDBMS, we considered using a Matrikon product that allows the creation of an OPC HDA server, etc.
In the end, all techniques will hit the Wonderware Historian SQL Database.
The connector natively uses the Historian SDK which provides a direct access to Historian block files, which provides better performances.

After a discussion with OSI teams they provided us, with no support, a utility they developped for their own use and that allows to recover historical data from Wonderware Historian.
It is absolutely what we where looking for. Thumbs up !
It is easily configurable, based upon config and text files, run through, can be copied multiple times in different folders and be executed multiple times in parallel (in our case I run 5 distinct instances).

I am convinced that such utility, even if not graphically integrated in the Wonderware Connector graphical interface would be the ideal tool for so many customers. It's easy to use and really does what's expected : recover historical data.

In my humble view, with a few more testings and stress, I could be made officially available as a separate utility.

We are just starting the first tests with PI OPC UA Interface. We notice that the classic method of tag configuration, known from the interface, is no longer possible. This is probably due to the connector concept.
Unfortunately, this does not fit with our central approach of tag configuration. We urgently need a way to control the transfer of the data into the archive, as usual from the interfaces, via the point attributes.

Since there is a tags-only mode - is there any hope that there will be an OPC connector mode so that the connector behaves more like an interface?

To cut a long story short: How about a PI OPC UA interface where structural information is not needed/desired?

Deploying a UFL Connector solution requires a LOT of edits of the INI file as part of the development/testing/debugging process. After each INI file change and file save, the required procedure is as follows:
1. Click on the Data Source List link.
2. Click on ‘See Configuration’.
3. Click on the ‘Change’ button.
4. Click on the ‘Browse…’ button.
5. Double-click on the INI file.
6. Scroll the page down until the ‘Save’ button is visible (I’m using a 1920 x 1080 monitor).
7. Press the ‘Save’ button.
8. Click on the ‘Overview’ link.
9. Press the ‘Start connector’ button.

A ’Reload .ini file and restart Connector’ button would make this process much more efficient. A second ‘Run once and exit’ button would also make the development/testing/debugging process much easier.

Use case: The UFL Connector needs to read a huge data set from a REST Server which is updated once a day. The only way to control when the data fetch occurs is by starting the connector at the desired time. The Connector however currently waits for the configured scan frequency time to pass before doing its first scan after starting. Furthermore, the Connector/hosting server may be restarted throughout the day for various reasons (e.g. application of Windows patches) throwing the timing off and further adding another 24 hour delay.

Scanning, processing and sending to PI the same data more than once per day is not a practical workaround either due to the handling cost of the large data sets involved.