9 Replies Latest reply on Jul 2, 2015 1:32 PM by TimCarmichael

    PI-SDK Deprecation and PI-ACE

    TimCarmichael

      Since the PI-SDK is moving towards a deprecated state, it would seem there are implications for development of PI-ACE modules.

      PI-ACE uses the module database to load PI points, properties, etc which we currently access via the PI-SDK.

      So, if we move to using the AF-SDK instead of the PI-SDK, is there a method to access the module database from AF or should we rethink how we access data?

      I have an application that I am actively developing that loads the bulk of the data from an AF table, however, configuration data (AF server name, AF database, AF table name, AF query qualifier) are loaded from the module database.

      This could just as easily be put into an application .config file, but I'd like to use the 'preferred method' as defined by OSISoft.

       

      So... how should we proceed?

        • Re: PI-SDK Deprecation and PI-ACE
          bshang

          Hi Tim,

           

          there is not a method to access the Module Database from AF SDK. In addition to placing the config information in app.config, another option is to place it in a separate config AF database. For example, a few PI products place this information in the Configuration AF database. When using AF SDK in ACE, you may want to target the .NET 4.x framework to take advantage of the Rich Data Access features (ACE by default targets 2.x): KB00645 - Specifying the version of .NET framework for PI ACE calculations 

          1 of 1 people found this helpful
          • Re: PI-SDK Deprecation and PI-ACE
            gachen

            Hi Tim,

             

            When you say you are reading configuration data from the MDB, is this from under the %OSI root module?

             

            In general, you should still have access [indirectly] to what's in MDB (except for everything under %OSI) from AFSDK by taking advantage of MDB-AF synchronization. Provided that everything is in-sync, and that you don't hit any of the limitations of the sync (some listed here), you can use AFSDK to just read/write to the synced database in largely the same way you would have manipulated the MDB with PISDK.

            1 of 1 people found this helpful
              • Re: PI-SDK Deprecation and PI-ACE
                TimCarmichael

                The configuration data I am loading is: AF server name, AF database name, AF Table Name, query qualifier and logging level.

                All other data is loaded from an table at run time, including tag names. The PIPoint items are created dynamically as needed.

                Since the AF SDK provides a method to write data to PI, the only reason to use the PI-SDK is to access the configuration data in the module database.

                Long term, there may be a desire to implement MDB to AF synchronization, but, for now, there is no such need.

                My application is just poking its figurative toe in the water to where which way the current is moving.

                  • Re: PI-SDK Deprecation and PI-ACE
                    gregor

                    Hi Tim,

                     

                    Have you thought about storing the information your ACE application needs in PI AF instead of in the Module Database?

                    Each node with PI AF Client installed should have a definition of a default AF Server. You could create an AF Database in the default AF Server that serves as a store for your configuration data.

                      • Re: PI-SDK Deprecation and PI-ACE
                        TimCarmichael

                        Gregor, yes... and most of the data is there.

                        The only data that is not in the AF database is the configuration database.

                        The items are: AF node, AF database, AF table and query qualifier.

                        The AF Node has multiple AF databases, some of which were inherited from third party work; I can change the default AF node and database, but, if someone else changes it, my application will then break.

                        So... to truly control it, the 4 listed items are stored (currently) in the module database; long term.. they will be moved out.