7 Replies Latest reply on Aug 19, 2016 12:44 PM by JimGavigan

    Managing AF Hierarchies across Devlopment,Test, and Production Environments

    JimGavigan

      We have several instances where a customer wants us to do initial work in a development environment, then move it to a test environment, and finally to a production environment. We are struggling with certain things that I am not finding any resources on. The XML import and PI builder tools don't really address them.

       

      For instance, in the development environment, if I do the following:

       

      • I take set of elements and put them under a new primary parent element and delete the references under the old primary parent element. i.e. I move the Pump 101 element out from under the Line 1 element and move it to a new element called Pumps. I then delete the Pump 101 reference under line 1. If I have done this many times across the hierarchy, how to I migrate this change? An xml import of the full database gives me both elements as it has no way of knowing that I physically moved the element. If in the below picture, I move the element FVLSI2 to be under the Pensacola element. When I do a full xml import, I have an FVLSI2 under both Cellar 1 and Pensacola
      • If I want to move just a certain set of elements in a hierarchy in to a specific place in the hierarchy. For instance, in the below hierarchy, I want a Cellar 2 element under LSI brewing. If I export Cellar 2 and its associated elements only, then import it, it imports under the root of the hierarchy and I have to specifically move it under LSI Brewing.

      It seems like if things are added at the template level, new analyses are done at the template level, and many other things that may change, those seem to be easy to manage across the three environments. However, hierarchical relationships aren't easily managed. It seems that there should be a tool that allows one to do an import comparison and either accept or not accept a change between two databases. We can do this in the PLC world, so it seems like we should be able to do it with PI.

       

      Does anyone have an answer to these issues?

       

      Stephen Kwan?

        • Re: Managing AF Hierarchies across Devlopment,Test, and Production Environments
          Jerome Lefebvre

          Hello Jim,

           

          I could not reproduce this issue. Once the element has been deleted and that change has been checkedin, I don't see how it could remain in the database afterwards. Is it possible to do an export of the database in which you are seeing this issue crop up? For example, if I move the child attribute from underneath Element2 to Element1, then delete it from underneath Element2, it is gone from underneath Element2 when I look at the XML export.

           

            <AFDatabase>

              <Name>Database109</Name>

              <AFElement>

                <Name>Element1</Name>

                <AFElement ReferenceType="Parent-Child">

                  <Name>Child</Name>

                </AFElement>

              </AFElement>

              <AFElement>

                <Name>Element2</Name>

              </AFElement>

            </AFDatabase>

            • Re: Managing AF Hierarchies across Devlopment,Test, and Production Environments
              JimGavigan

              Jerome - make two databases that are identical (simulating Dev and Prod). Then move a bunch of things around - completely rearrange the dev database. Move elements around, delete them, add them, etc.

               

              Do an xml export and import it into the prod database. It will not look like dev.

               

              Here is the Nugreen database (both dev and prod start out looking like this, like in an original deployment):

               

              Now, let's rearrange it - I added South and West elements and moved a bunch of equipment out of Houston somewhere else:

              Now, I will export the new database with South, West and rearranged elements and import it into the prod database and here is what it looks like:

               

              Note the duplicate Houston elements that look different. Tucson is now under both the Nugreen and West elements. Oh by the way, both Houston and Tuscon elements have duplicate primary parents (South and West elements and Nugreen) also, which is not what is desired, because what if there are a years' worth of event frames and analyses associated with the Nugreen\Houston\Cracking Process\Equipment\B-210 element? Now I have a whole different element somewhere else (recall, I moved B-210 under another plant's process) creating the same event frames and analyses also. I have to delete one and better not delete the one that has the years' worth of data attached to it. I did this in the testing database for my customer and there were no event frames from the date I made the import backward (because I deleted the elements that had generated a years' worth of event frames), despite the fact that those elements had been there a year. Because I deleted the primary parent element, the event frames no longer knew where to be attached. So, they are sitting in the SQL database orphaned I suppose.

               

              So, this is a mess....

               

              I don't think there is a trivial answer and will take some serious thought to figure out how to solve, but is definitely something that needs to be dealt with on a true enterprise level. I have a customer that I just did this with and it was painful migrating everything.

            • Re: Managing AF Hierarchies across Devlopment,Test, and Production Environments
              arosenthal

              Hi Jim,

               

              I too have been working on this problem and have developed some in-house solutions over the past year or so. It is indeed a complex problem, especially when you factor in library changes (element templates, analyses, etc.).

               

              I will be giving a first presentation on this very topic at the upcoming 2016 PI System T&D Users Group Meeting in Scottsdale (Sep 14-Sep 16). Stay tuned for that as the presentation will of course be made available to the public.

              3 of 3 people found this helpful