Fabiano Batista
My feedback
-
270 votes
At this time, this item is not currently scheduled for a release of PI Vision. If this changes, this item will be updated to reflect the current status.
Fabiano Batista
supported this idea
·
-
20 votesFabiano Batista
supported this idea
·
-
59 votesFabiano Batista
supported this idea
·
-
5 votes
Hi,
So what would be the expected behavior if elements have already been created from the template? It would then be possible to have deletion of data upon an import of a template. What if there are overridden template attributes? What would be the expected behavior if the imported template affects these overridden template attributes?An error occurred while saving the comment Fabiano Batista
shared this idea
·
-
3 votes
An error occurred while saving the comment Fabiano Batista
commented
This is very important when we are working with different AF Servers (ex: one development and the other one is production). Sometimes the development database is located at the system integrator office, and not necessarily the conversion factors would be the same across the 2 databases. With the option you suggested, we avoid "polluting" the production database, making sure it remains intact. If a specific UOM is needed, the user would simply import it in a separate xml file before importing the full xml file with the option "Exclude UOM" set.
Today, I manually have to delete the UOM section of the XML file to avoid contamination of the production database during a deployment activity.
Fabiano Batista
supported this idea
·
-
99 votesFabiano Batista
supported this idea
·
An error occurred while saving the comment Fabiano Batista
commented
Here is another user case:
A customer has a federated PI System with several remote AF units, and one central AF showing the same content from each of those units. Each unit has the same set of templates and tables. The remote AF structures are supposed to be copied to the central unit via PI System Connector, each one appearing in the right branch of the central AF hierarchy. The central AF server has also the same set of templates and table names. Today, PI System connector cannot merge table data, but instead it replaces the existing central table by the content from the last unit which table was synchronized by PI System Connector.
As a solution, the tables at each unit could be renamed by appending a unique identifier (such as unit code). Then, the element template could be configured with a TABLE LOOKUP containing a substitution parameter in the FROM clause to allow pulling data from different tables (i.e., unit specific tables).
Some benefits of this solution:
- Less element templates needed (easier to maintain in a federated PI system environment)
- Better lookup performance (each branch on the central unit will be pointing to smaller tables, instead of pointing to a single big table) -
14 votesFabiano Batista
supported this idea
·
-
3 votesFabiano Batista
supported this idea
·
Fabiano Batista
shared this idea
·
-
17 votesFabiano Batista
supported this idea
·
-
33 votesFabiano Batista
supported this idea
·
-
48 votesFabiano Batista
supported this idea
·
-
2 votesFabiano Batista
supported this idea
·
Fabiano Batista
shared this idea
·
-
3 votesFabiano Batista
supported this idea
·
-
5 votesFabiano Batista
supported this idea
·
-
59 votesFabiano Batista
supported this idea
·
-
128 votesRESEARCHING / EVALUATING · 1 comment · PI Server » Analytics & Calculations · Flag idea as inappropriate… · Admin →Fabiano Batista
supported this idea
·
-
270 votes
Reopening this suggestion to collect additional feedback.
Fabiano Batista
supported this idea
·
-
Allow users to "Add Columns" while "Modifying View" even if there is no time series values selected.
11 votes2 comments · PI Integrators » PI Integrator for Business Analytics · Flag idea as inappropriate… · Admin →An error occurred while saving the comment Fabiano Batista
commented
Also, this will allow us to provide table normalization, allowing us to put the metadata in a separate table. This way we will be improving the performance on the front end (i.e., the BI tool), since all metadata (which is static data) will not need to be repeated on the table that will contain the time series data.
Fabiano Batista
supported this idea
·
-
28 votes
An error occurred while saving the comment Fabiano Batista
commented
In response to Scott Robertson, "I have a very similar use case. Potent..."
Interesting use case.
It looks like your use case requires a continuous AF synchronization (instead of "on-demand" one, like the one I suggested). PI System Connector would be the best product for this, but unfortunately the current version of PI System Connector cannot push analysis objects to the destination servers (i.e., your remote servers).Fabiano Batista
shared this idea
·
-
213 votesFabiano Batista
supported this idea
·
The expected behavior is to have the elements containing the same attributes as their templates, so if attributes are deleted from the template, they will be removed from the elements. This is what we expect when deploying templates from a dev database into a production database.
Regarding the question about overridden attributes, this is more related to the design of the AF templates in the first place. During a deployment task, we need to make sure the templates in the production database contain the same attributes as int the development database. So, after verifying the changes performed on dev database templates are good, by deploying those modified templates on production database should work correctly (considering the reconciliation step is applied to delete attributes and analyses that are no longer required).
I usually perform reconciliation of AF templates manually during a typical AF deployment task (using Excel formulas and PI Builder), but is very time consuming operation. If we had this option implemented in PSE, it would take me seconds.
Of course there are other things that need reconciliation (element hierarchy, UOM, etc.), but addressing the templates first one would be a good start and reduce a lot the complexity of a typical AF deployment activity.