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

As a PI Administrator, I need assistance configuring and testing Kerberos delegation, so that I can access the full functionality of the products without exposing my system to potential threats.

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.

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.

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.

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.

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 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.

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.

Be able to get and set data archive annotations with PI Web api. Ie access to PIPoint.SetAnnotation Method and PIPoint.GetAnnotation Method in the AF SDK.

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.

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 `AFAttribute`s 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.

Currently calling any of the AdHoc StreamSet actions causes the entire call to fail if the request includes at least one bad WebId. It would be better if the response came back successful and only the sub-items with bad WebIds included an error message.

Currently the PIPointQuery cannot contain a filter condition with same filter name twice per AND condition of the query string.

PointId:>5 AND PointId:<10.

This would cause an error.

Therefore filtering for a certain range is annoying as both result lists then have to be compared for common elements, workaround for the AND in above condition.

Enhancement:

Introduce a "BETWEEN" operator for the filter condition.

Allow multiple use of filter names in the same AND condition.

https://pisquare.osisoft.com/message/116957-pi-sql-commander-and-ssrs-how-to-retrieve-multiple-values-with-the-same-timstamp

In the current implementation of the transpose archive in OLEDBEnt, a user is unable to retrieve data that may exist at the same timestamp as  another piece of data. This is because the time column is treated as the primary key of the transpose table. I would like to be able to retrieve all data using the archive transpose function regardless if timestamps are duplicated.