Currently we can "filter" what is replicated by including a specific branch. But if using a composite model, say a site with all it's composite assets, and only want to replicate the "foo" assets from all sites, this option does not work.

It is possible to build a weak referenced homogeneous asset model elsewhere under a separate branch and include only this branch. But this can be tremendous amounts of work / automation with all the burden on the client.

An improved mechanism might be like the ESRI integrator -- selection by template type(s). And even more flexible, allow filtering based on any boolean attribute type. Allowing an option to create using existing paths or new path (by filter type) would provide flexibility where there is little now.

Supporting better selection and translation supports cases where specific user groups can replicate their specific types to their individual systems. This is not an edge case -- it reflects clients organizations -- for example T&D FERC rules between traders, transmission and even generation. In this case, certain classes of users may have permission to portions of the database, but not all.

Despite having released hundreds of PI Interfaces and dozens of PI Connectors, OSIsoft struggles to keep up with the ever-increasing number of data sources. Meanwhile, there's Power BI Desktop, a free program by Microsoft that allows users to combine and reshape data from different sources by using a simple query language (Power Query) or the even simpler GUI. It is a perfect match!

The PI Connector For Power BI Desktop would instantly give PI support for many more data sources, and users can always write custom data connectors for data sources that are not natively supported and possibly share them on GitHub. This effectively outsources and deduplicates a lot of the work related to connecting to different data sources. Maybe OSIsoft might even decide to create and share a custom data connector, which benefits both OSIsoft customers and Microsoft customers.

The PI Connector For Power BI Desktop would let users easily combine data from different sources and then save only the required values into PI, which saves tags, disk space, and processing power compared to saving the raw data into PI first and using the PI Analysis Service to derive new values.

The PI Connector For Power BI Desktop would replace some existing PI Connectors and satisfy some of the suggestions for new PI Connectors, giving users a much more unified and simplified experience. For example, since Power BI Desktop can handle both text sources and relational database sources, the PI Connector For Power BI Desktop would supersede most of the PI Connector For UFL and all of the idea of a PI Connector For RDBMS. The user can also skip learning SQL and the INI file language and focus on just Power Query, which is not only 1 language instead of 2, but also much easier to learn, read, and write and much more useful to the user outside of PI work. In addition, Power BI Desktop has a GUI that allows users to build queries without writing code and to preview and undo any step.

The only downsides that come to mind are that there may be licensing fees from Microsoft and that the PI Connector For Power BI Desktop would likely be too slow to collect data from sources that send data more often than every few seconds, so OSIsoft would still need to make PI Connectors for such sources. Despite this, a PI Connector for a program as solid as Power BI Desktop would undoubtedly benefit PI users in their data retrieval journey.

Summary:

Pros:
• Combine and reshape data like never before in a PI system
• Instant spike in the number of supported data sources
• Outsources and crowdsources the work for developing new connectors; a symbiotic relationship with Microsoft and its customers
• Can reduce the strain on the PI system
• Reduces the number of PI Connectors needed
• Reduces the number and difficulty of query languages to use; GUI can dodge coding entirely
• Knowledge of Power Query and Power BI Desktop is useful outside of PI work

Cons:
• Likely too slow for real-time data
• May have a licensing fee

The PI Connector for e-terraHabitat HabConnect SAMPLER pulls tag descriptions from the PNTNAM and ALGNAM records. For Oil & Gas e-terraPipeline (a.k.a. ETPL or "LMS") customers, the DESCRIP field on those records are usually left blank, or they have a very generic value. The description for new Pi Tags created by this connector should come from the individual POINT or ANALOG records instead. This information was confirmed by a GE employee as being applicable to all current ETPL/LMS customers.

For my company, here are a couple of examples:

DESCRIPALGNAM = "# - Interface Level - #"
DESCRIPANALOG = "Cavern 1 - Interface Level - Water (Trend)"

DESCRIPPNTNAM = "# Valve #"
DESCRIPPOINT = "Manifold Valve T2"
DESCRIP_POINT = "DRA Discharge Valve DD1"

Please either: make it possible to configurably request DESCRIP off of ALGNAM vs ANALOG and PNTNAM vs POINT, or preferably, just assume that if we've configured for "DESCRIP" (which only applies to an LMS system) that we want the DESCRIP value from the ANALOG or POINT record.

Note - this likely means you don't even need to register for any ALGNAM or PNTNAM data, if DESCRIP is the only thing you're getting from those record types.