The OPC landscape is shifting away from DA/HDA and towards UA servers. A significant number of OPC client tools are being created that connect to OPC UA servers, and none of these are compatible with PI without the use of a third party UA wrapper since we only provide DA and HDA servers.

Add auditing or a view of statistics for the calls or requests done by each individual application. Allow a PI Admin to see which user or application is making a specific call and see how long it takes to complete to monitor performance and potentially resource intensive Web API calls.

As a PI Web API user I want to know exactly what kind of Body Parameters (their defaults and description) are supported by PI Web API methods. The current sample requests are not sufficient because they do not describe the values for body parameter, though many parameters have unique restrictions.

Here is an example of desired content:
https://developers.jivesoftware.com/api/v3/cloud/rest/StreamEntity.html

When the crawler fails on an incremental crawl, the index search must perform a complete rebuild of the index. It would be beneficial for there to be a way to revert to a previous built index just prior to the failed incremental crawl so that the index file is available. This is particularly useful for large data sources that take hours or days to crawl before they're usable again.

Add methods to retrieve messages from the local and remote PI Message Logs where remote can refer a PI Data Archive node or any remote PINS.

Because the EventLog Class in .NET Framework provides access to local and remote Event Logs, offering the AF (Server) Event Log through PI AF SDK is not necesarry.

As of now, we can get PINetMgr statistics via PowerShell command Get-PIConnectionStatistics. # of users familiar with AF SDK are more than with PowerShell.
It will be nice feature addition in AF SDK, and usability will also increased.

I would like the RTQP Engine to be able to read annotations.
My use case is the following :
I have user that enter manual values into PI along with these values the operator will specify the reason for this manual input.

The comment is stored in an annotations, there is currently no way to retrieve this information.

Retrieving a string would be sufficient for my needs.

When any time related functions need to be performed against timestamp columns in PI SQL Commander, one needs to utilize a significant amount of conversions to make this work. For example, if one needs to round timestamps to the nearest minute or the nearest hour, a CASE statement with multiple CASTs needs to be done to get this to work.

If T-SQL DATEADD and DATEDIFF commands were implemented, this would simplify the query by a significant amount. Similarly, in PL/SQL, the ROUND function is able to round the datetime value directly, which would fit perfectly to this scenario.

The ability to backfill an analysis using an end time in the future. This would read data from future inputs and write the results as future values.

I would like the ability to access event frame annotations using PI SQL Client, in the same way as in PI OLEDB Enterprise.

As a PI SQL Client OLEDB user, I would like to have the TIME(), DATE(), LOCALDATE() and TOLOCALDATE() functions available in order to construct datetimes for my queries.

These functions were available in PI OLEDB Enterprise, but are not available in PI SQL Client OLEDB.

The OPC DA Server service uses %PIPC%\PI_OPCDA2\Data\SavedNamespace.xml to load the tags and does not update the  cache until  the service is stopped and started again. If any new tag is added to the PI Server, it is not picked by the OPC DA Server. The service should periodically update its cache from the PI Server after the initial start.

I would like the ability to pass response values from one request into the body of a dependent request using the batch controller to avoid making 2 calls to the PI Web API.

Currently,  I can only use Parameters in subsequent URLs, but not bodies.

As a PI Web API user, I would like a simple method to perform bulk deletes of a particular attribute or PI tag. Currently, a bulk delete requires 2 calls. One to retrieve the event I wish to delete and another to delete it.

As an end-user, I want to be able to see to which PI Collective member I am connecting to. I also want to be able to toggle programmatically from one PI Collective member to the other so I can make sure the informaiton I am seeing is aligned and in synch accross all PI Collective members without going into thick PI clients or through log files.

With Microsoft supporting .NET Core on Linux operating systems such as RHEL, SLES Ubuntu, CentOS, and Debian.
https://docs.microsoft.com/en-us/dotnet/core/about
https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x

They are even supporting SQL Server on Linux OS'es.

I don't know the dependencies of the AF SDK nor the Web API, but if they can use .NET Core; it would be nice to have the AF SDK and Web API available for Linux based OS'es.

As a developer of custom applications that use the PI  AF SDK, I'd like to be able to easily determine if an attribute based of an attribute template is configured for tag creation. Currently the AF Attribute Template class does not have this property. The current work around is to look at the configuration string which is less efficient.

As someone tasked with upgrading PI environments, it would be nice if there was a tool such as a PI PowerShell cmdlet that would retrieve all of the version information for all installed PI software on a given machine, as well as which install kit was run to install it. This would help save time during the audit process, before upgrading many servers with the latest version of that install kit.

The ProgID of the 2015 PI OPC DA Server is OSISoft.OPCDA2.DA.1, while the ProgID of the 2010 PI OPC DA Server is OPC.DA.1.

Existing client tools that pointed to the 2010 PI OPC DA server will need to be reconfigured to point to the new ProgID after the PI OPC DA server is upgraded to 2015.

While this is done because of an architecture change between the 2010 and 2015 servers, potentially necessitating changes to be made to the client application, it is still desirable in some cases to point it to the new server without changing the ProgID.

Expose interfaces for asynchronous data method calls (ex. InterpolatedValues, PlotValues, RecordedValues, Summaries) that:
    1. Take an asynchronous enumerable of AFAttributes as input
    2. Output an asynchronous enumerable of results
    3. Throttle the calls made to PI Data Archive so that it does not overwhelm it

The use case is to be able to make end-to-end asynchronous data method calls on a set of AFAttributes.