Please consider creating a web application like PI Vision Admin, PI Web API Search, PI Manual Logger for Web, and the various integrators, but for PI System Explorer (PSE, PI AF). I would prefer this to the client-server design now. It would make version management, software dependency management, upgrading, firewall/network-services management, etc. easier. This would obviate the need to re-package the OSIsoft installers in whatever software package management software an organization uses. Another solution would be to use the Windows 10 application store. However, that wouldn't mesh well with using Cloud IaaS services. OSIsoft could even offer this new PSE Web as a PaaS: gear, Juju charm, Docker container, Amazon image, whatever.

It's great that we have one more option as recalculation other than backfilling in Analyses plugin.

The backfilling / recalculation of analyses is manual process we do, because of delayed data or change of logic of analysis. In this case, sometime it happens that user has defined wrong period or selected wrong analysis while clicking on backfill / recalculate option, and if # of analysis selected are large, then it is quite frustrating to let wrong backfilling/recalculation be completed.

To stop current backfilling / recalculation operation, non-recommended approach is update the RecalculationProcessor.RequestedRecalculations.xml file. Problem with this approach is that end user generally has very limited / no access on AF Server, and capability of end user to perform this operation also varies.

It will be great if abort like button provided once backfilling / recalculation starts. Clicking on which will give pop-up to confirm the abort action.

I know it's not an easy task, because it has to deal with consistency of data as well. This is common problem we faced, so just putting forward the same,

Thanks,
Paurav Joshi

Read access to the PIPOINT table is required for most identities. Pointsecurity and Datasecurity currently use the settings on the PIPOINT table as the default. New points will generally give read access to most identities because of these defaults. This makes it difficult to configure an identity with read access to some points, but not all points (common when giving external contractors limited access).

Additionally, for best practice security, buffer identities need read access to Pointsecurity, but read/write access to Datasecurity. There is currently no way to configure this combination as a default.

Adding two new tables (ex. PTSECDEFAULT and DATASECDEFAULT) that are used for these defaults, instead of pulling directly from PIPOINT, will fix all of these issues.

The feature added in 2017 R2 was for authentication of the SOAP payload, not for managing headers within the payload.  PI remains unusable as a secure source of data for Maximo without it because you can't configure a MAXAUTH header.

There's no way to configure headers for Notification Rules associated with a PI AF Services v2017 SP1 Elements with a SOAP or REST Web Service Endpoint.  Authenticated web services, such as our company's Maximo's meter data inbound service requires a MAXAUTH header with a base64-encrypted username:password string.  As a result, you can't use PI as a source of data for Maximo's condition-based maintenance triggers and automated asset meter reading updates, if Maximo uses authentication on its web services.  That's a fairly common scenario with a high rate of return on the PI-Maximo integration efforts for a lot of customers.

As a PI user, I want to be able to visualize and analyze the SQC violations that are generated by the SQC rules. 

The ability to save SQC outputs such as  Mean, median, mode, stdev, Cpk, max, min, 1-5 sigma zones, ucl, lcl in the following ways

1) the EF associated with the SQC rule - essentially the alarm event
2) an EF associated with a process event.  I want SQC summaries added as EF attributes bound by process event frames
3) AF clients.  I want to be able to add Cpk, sigma etc for any applicable AF attribute to a PI vision screen and have the results reflect the timerange on the screen.

If an Analysis is triggered on "Any Input", and the inputs have the same timestamp but come in after each other, the Analysis is only triggered at the first input.

For example: We have a simple Analysis which summarizes 2 tag.
The first tag comes in a 14:00, with timestamp 14:00. This triggers the calculation. The second tag comes in at 14:02 also with timestamp 14:00. Now the calculation in not triggered anymore.

We've also discussed this with Techsupport, and they came with the following statement: "With Event Triggered, the first value to come into the PI DA is used by the Analysis Service. Other events with the same timestamp are ignored."
We would expect that the Analysis would be triggered again if the timestamp is greater or equal to the last incoming event.