12 Replies Latest reply on Apr 23, 2009 4:14 AM by pcombellick

    PI V3.5.390 Makes all MDB applications AF aware

    paulverey

      Can anyone tell me in practical terms what this statement of intent means please?

       

      I would like to assume that migration of MDB modules to AF coupled with developments in the PI SDK to enable legacy calls to the MDF to be routed to the AF might mean NO changes to applications and thus transparent migration to AF? Can anyone confirm this or tell me the extent to which backward compatibility will be supported. I really look forward to the new found performance this will give us in July...

        • Re: PI V3.5.390 Makes all MDB applications AF aware

          Would be interested in OSI's answer to this too.  I note from the Engineering plan in 2010 all client applications will have MDB dependancy removed (PI-ML v3, ProcessBook v4...).  I assume that PI >= v3.5.390 comes bundled with an AF Database?

           

          I doubt that PISDK will reroute calls to AF as it is seperate library calls (AFSDK)...plus AF v2 onwards does not have a COM interface.  Maybe the PI server will treat its AF database as both an AF DB and Module DB??

            • Re: PI V3.5.390 Makes all MDB applications AF aware
              kilgored

              Excited by the prospect of what that could mean, I did some investigation at the UC and some subsequent follow up with OSI.

               

              The v3.5 feature involves a synchronization engine that takes the entire MDB structure and replicates it to a single user-selectable branch within AF. From that point forward AF is the master record for hierarchical / MDB information - however, there is no redirection involved. The MDB will still exist and all MDB aware applications will still get thier information from MDB, however, all create/edit/delete operations become transactional with AF to ensuring that the 'master' is in sync.

               

              Over the next 12 months or so, the client applications themselves will become directly AF aware, eventually deprecating the need for an MDB altogether.

                • Re: PI V3.5.390 Makes all MDB applications AF aware

                  Good feedback Dennis.
                  So longer term that still means developers will need to rewrite code once MDB gets the chop.  Not a big task (PIModule = AFElement, PIProperty = AFAttribute, PIAlias = AFAttributeDR = PI Point DR) but a cost for developers anyway.

                   

                   

                    • Re: PI V3.5.390 Makes all MDB applications AF aware
                      pcombellick

                      I am not aware of any plans to make MDB disappear.  We (OSIsoft) expend a lot of engineering effort to not abandon our customer's investments.  Perhaps you should target your new development to use AF, instead of MDB.  My personal hope is that you will use your every waking moment to move your applications to AF.

                      • Re: PI V3.5.390 Makes all MDB applications AF aware
                        mheere

                        I don't think it's accurate to say developers will "need to rewrite code once MDB gets the chop".  MDB isn't going anywhere.  Just because the new platform architecture will allow all of the tools to function in an AF only setup doesn't mean that MDB is going away.  If you have an MDB based application the release of 3.5.390 will not force you to move away from that architecture.  This is one of the rationale for going with a replication based design rather than a redirector based approach.

                         

                        Even with the replication engine in place, there is nothing forcing you to move your code to native AF.  Replication is planned to be bidirectional, essentially making both AF and MDB writeable.  A hybrid setup where legacy apps use MDB and newer ones use AF is completely feasible.

                         

                        Of course, AF does bring advantages to the table.  The expectation is that eventually there will be a business case to enhance or replace old applications, and this will be the time to mograte them natively to AF.  The fact that this is business case driven is key though.  You're not going to be migrating just for the sake of migration.

                          • Re: PI V3.5.390 Makes all MDB applications AF aware
                            formerpigeek

                            I have to agree with both Dennis and Matt here (Heere too!). MDB is not going away until you, as a customers or a partners, want it to go away. And with regards to porting existing MDB based applications to AF 2.x, we won't completely put that burden on the customers. We will have migration tools for moving displays, reports and potentially ACE code. And that's an area where we need feedback because balancing development effort between upgrading/migrating 'legacy' applications and building new ones is a difficult exercice when ressources are not unlimited. So is it better to make sure that we can upgrade everything customers have built with previous versions of software/technology? Or should we focus on building new, faster, easier tools to supersede our previous offering? Probably something in between but how would you split that effort?

                              • Re: PI V3.5.390 Makes all MDB applications AF aware

                                Migration tools for MDB to AF are great but I doubt they will cover most custom applications and how they have been written, for starters you no longer ship a COM interface for AFSDK v2.x.  Seen as though VBA is going to be around in ProcessBook and Office for many more years, users are being forced to .Net Addins and can't make use of the ease of using VBA. 

                                 

                                An example, some ProcessBook displays make use of MDB for configuration and some other neat stuff in the VBA environment.  We can't replicate the functionality in AF2.x (reason above) so apart from going down the route of a .Net addin you loose that freedom of just typing a few lines inside a VBA event and manipulating the display accordingly.  Same goes for any OBA's where VBA is utilised to give that extra functionality that is not there as standard.
                                Was touched on in this thread: http://vcampus.osisoft.com/forums/t/199.aspx

                                 

                                Do OSI really envisage they will be continuing to support MDB 5 years down the line?  Will the PISystem and AF Server not become one product in the future??

                                 

                                How will the MDB/AF replication work when custom DR's are used?  Is the value from the DR sent across to MDB?

                                 

                                New, faster, easier tools to supersede previous offerings gets my vote

                                 

                                 

                                  • Re: PI V3.5.390 Makes all MDB applications AF aware
                                    mheere

                                    Couple of things:

                                     

                                    - Yes, OSIsoft envisions suppoting MDB so long as there is a customer using it.  We still support customers running the PI2 server on a VAX!

                                     

                                    - No, the PI server and the AF server are not going to become one product.  Actually, the future holds more servers for the back end, not fewer.

                                     

                                    - The replication strategy does not mean that we are attempting to bring full AF functionality down to MDB.  MDB supports aliases for PI points and static properties, so only the corresponding AF element attributes will be replicated.  No table, formula or custom DRs.  Perhaps you could start another thread to discuss what you are doing with a custom DR, and why you went that route?

                                     

                                    - Likewise it's not expected that a structure, once migrated to AF from MDB, will grow more significantly than it would have if left in MDB.  Scalability of the two databases is different, and replication isn't meant to address this.

                                     

                                    So what this means is that replication is not meant to bring full AF functionality to MDB or to older MDB driven apps (ours or yours).  The "new, faster, easier tools" are comming and they will all be natively AF connected.  The replication strategy is intended to prevent the user from having to maintain two seperate asset structures while achieving some level of interoperability between the old and new tools.

                                     

                                    The migration tools to be provided will handle migration of any out of the box functionality.  For example, if you have a module relative display in PB now, once all the migration is done you'll have an element relative display that works just like the old one.  What it isn't practical to handle is any custom code that has been written.  The AF aware version of PB should give you the hooks needed to tap into AF from code, so the scenario mentioned above where COM accessiblility is a limitation could be resolved.  However, the actual code migration will need to be done by hand.

                        • Re: PI V3.5.390 Makes all MDB applications AF aware
                          pcombellick

                          >> I really look forward to the new found performance this will give us in July...

                           

                          I am curious about this statement.  Can you explain what your performance expectations are ?