3 Replies Latest reply on Aug 21, 2016 3:11 PM by David Haberkorn

    Ways of automating/scripting ArcFM configuration?

    David Haberkorn

      We are currently implementing schema changes on our database which includes adding new feature- and objects classes but also adding new subtypes to existing ones. Going through the ArcFM configuration manually is a very tedious and error prone process, especially when having lots of changes/fields/etc. We have tried exporting the configuration as XML and editing these XML files (e.g. copy one subtype setting and change for a new subtype). However, the XML files do not seem to be built in the expected structure and hence we cannot use them for easier configuration. Also, there is no way of using Python or any other scripting as far as we are aware. We are currently on 10.1.1.588.

       

      Does anyone know of a smarter/more efficient way of doing the configuration (field config, modelnames, auto updaters,..)?

        • Re: Ways of automating/scripting ArcFM configuration?
          Terri Harris

          David,

           

          Unfortunately I don't know of a good way to accomplish this. I would suggest viewing and possibly voting on the following Idea:

           

          https://infrastructurecommunity.schneider-electric.com/ideas/1165   Creating of ArcFM tracing geoprocessing tools.

           

          It currently has 27 votes.

          • Re: Ways of automating/scripting ArcFM configuration?
            Samuel Valdez

            David,

             

            We are on ArcFM 10.2.  I ran into the same thing a while back so I ended up trying to manage this with Python.  In the end, this is still a proof-of-concept which I have not had the need to re-visit, though that could change.  In other words, I wrote some software to do what I wanted (my problem was the same as your problem) but I never went back to use the code or idea in a production setting.  Without going back and looking at the code, I seem to remember the following:

             

            • New/changed domains, and other changes, were captured in internal (to Python) data structures.  I might move these to external text files but in any case, the program would use/read these to "know what to change".
            • The current "state" (things that I wanted to change) was also captured before I changed it but I do not remember where I saved this information.  Because this state was saved, I could revert to it programmatically, which decreased the risk of making changes.
            • The programming was fairly low-level but not ridiculous.
            • My extensions were fairly simple but as you pointed out, quite tedious to apply manually, and error-prone.  I think that my program could be modified to accommodate more extensive changes; I do not remember any technical issue to prevent this.  It seemed to be more a question of how much I wanted to invest in developing the program.
            • I am not sure to what extent the program could be generalized but it seemed to be a viable path for at least my limited set of extensions.

             

            BOTTOM LINE: If you are a strong programmer, and have the time, then writing a fair bit of Python to do the work could be a viable option for you.

             

            FOR SCHNEIDER ELECTRIC: For those customers that need to implement extensions, more product support in this area would be very helpful, particularly with scripting/programmatic support.  Using the GUI to apply extensive changes is not optimal, and the XML approach seems appropriate for more wholesale changes and less so for targeting to specific areas.  More guidance in the documentation on different "extension scenarios" (type and number) and how best to pursue them would also be welcomed by customers.

            • Re: Ways of automating/scripting ArcFM configuration?
              David Haberkorn

              Yes, looks like there is nothing out there out of the box really to do mass configuration in ArcFM. I found this on the web and will give this a go. Also, our third party developer reckons that it should be fairly possible to put some code together that would do the job. Not really user friendly to be honest, considering that e.g. adding a new subtype to a feature class recently took between 600-700 manual mouse clicks..