1 Reply Latest reply on May 15, 2013 7:11 PM by Bill Robinson

    ImportExport related issues and known bugs

    Clément BARRET



      I'm working on an "Export/Import" tool and I'm facing many issues that I can't deal with... because some of them are due to some not working blcli ImportExport namespace methods...


      I'll list those issues and "broken" methods here and try to reach BMC customer support at the same time (I've already opened two tickets related to those issues).


      That might help some of you who would like to export/import objects from one BladeLogic infrastructure to another one.


      Feel free to post any ImportExport related issue and any workaround you have about this "Export/Import" topic in there.



      • ImportExport importObject_api (version 7.6) :
        I got three issues there.

        The first one is really a BUG that's just has no workaround possible (or may be one but REALLY hard to do).
        • using importObject_api import objects but let them in a "importAndUpdate" group at the root of the tree (Jobs) which is automatically created during the blcli_execute and which should automatically be deleted afterwise. No error is raised by the blcli called.

          => For "unlinked" exported objects, I could just make a check after import like this :

          1) is my object there ? yes => OK
          2) is my object in /importAndUpdate ? yes => move it to the right place (which I know because it's an unlinked object, standalone if you prefer)
          3) repeat steps 1/2 for all objects imported
          4) delete the /importAndUpdate

          => The problem is for "linked objects" for which I just have the path of the source object (often a BatcJob) and for which I just don't have any information about their "child objects" destinations...


          In this screenshot, the "/importAndUpdate/SOFT-TOOLS_1.0_Windows_BL-2.0" should have ended up in the selected "/Software/SOFT-TOOLS/1.0/Windows" group...

        • I got an error message for which I can't find a workaround after the importObject_api call on one of my exported object :

          blcli_execute  'ImportExport' 'importObject_api' '/tmp/bl_expimp_24300/SASP_2.6.0_Linux_BL-1.0/Depot/Software/SASP/2.6.0/Linux/SASP_2.6.0_Linux_BL-1.0' '/tmp/bl_expimp_24300/SASP_2.6.0_Linux_BL-1.0/Depot/Software/SASP/2.6.0/Linux/SASP_2.6.0_Linux_BL-1.0/mapping.xml' 'true'
          Command execution failed. com.bladelogic.mfw.util.BlException: com.bladelogic.mfw.util.NotFoundException: no child of name 2 found

          => When I use the "Configuration Manager" GUI to import the object "manually", I have a "property mapping error" and a popup asking me to map the "missing property" (which already exists in the "Property dictionnary").


          The GUI automatically chooses the right property and I just have to click "OK" (screenshot included) then the import of the object works flawlessly...


          I need to be able -- using the blcli -- to "tell" BladeLogic the same "answer" as the one giveng using the GUI. That might be by adding some lines in the "mapping.xml" file of the exported object.

        • When I try to import an object for which some properties (added to the Built-in properties of "Depot Object") are of type "String enumeration" and for which the visible enumeration values are the same on both BladeLogic infrastructure (source and target one) but for which "historical values" are not the same (for example, on the "source" you had some values in the enumeration which have been deleted -- thus only having been flagged "deprecated" by BladeLogic -- the import of this object will fail -- except if it uses the default value of the enumeration for theses properties, which must match the one of the same enumeration property in the target dictionnary.


          As you can see here, all values (including the historical values) are listed (greyed values) in the enumeration but only those in the main window are actually usable and "choosable".

          => So either you apply on all your source object the default value on the enumeration (which in this case make you lose information, you obviously can store this value in some file before... anyway that's not convenient) OR you add the historical entries in the enumerations and delete them afterwards on the target dictionnary. Thus you'll be able to import those objects...

          I think the behaviour of the importObject_api method should just match labels of the enumeration and don't use "indices" of those labels since they don't have to match the target enumeration as long as all "undeprecated" values are in it...

      • ImportExport exportObject_api (version 8.2)

        There is a regression in this method... We used to be able to give "relative" path for the export method (output directory).
        Now, for some objects, if you use "relative path" you'll encounter the following error :

        blcli_execute 'ImportExport' 'exportObject_api' '28' 'DBKey:SDepotObjectModelKeyImpl:2016320-1-2005615' '__EXP_20130320/ORANGE-APACHE_2.2.8-EQ1.03_Linux_RedHatES5.3_x86_64_BL-1/Depot/Software/ORANGE-APACHE/2.2.8-EQ1.03/Linux/RedHatES5.3/x86_64/ORANGE-APACHE_2.2.8-EQ1.03_Linux_RedHatES5.3_x86_64_BL-1.0' 'false' 'false' 'false' 'false' 'false' 'false' 'true' 'false' 'false' 'false'
        Command execution failed. com.bladelogic.om.infra.mfw.util.BlException: Unable to create output directory: /__EXP_20130320/ORANGE-APACHE_2.2.8-EQ1.03_Linux_RedHatES5.3_x86_64_BL-1/Depot/Software/ORANGE-APACHE/2.2.8-EQ1.03/Linux/RedHatES5.3/x86_64/ORANGE-APACHE_2.2.8-EQ1.03_Linux_RedHatES5.3_x86_64_BL-1.0/files/installables/2000901

        => The workaround is "simple" as you can use an absolute path instead of a relative one but since this error doesn't occur on every exported object (I assume the guys who are working on the API are split by namespaces or object types and are not working together, neither sharing code...)

        So... even if that's not a "blocking" issue, I think this bug should be addressed in the next release... For the matter, this bug never happened in our 7.6 environment...


      Ok guys, that's it for now, I'll update this message when I got more information/any solutions available.



        • 1. Re: ImportExport related issues and known bugs
          Bill Robinson

          you've listed a few different issues here so i'll try to hit on each one - i will mention that 7.6 is EOL so it's unlikely that you will get any fixes for this version.


          - importAndUpdate group left behind - this group should be cleaned up after the import is successful - is that the case ?


          - when you import an object that references an enumerated string, the values in the export need to match the values in the import - i believe that is the root cause of both of your errors there.  i believe if you run the import using the blcli and do not specify a mapping, the values in the export will be ignored and the import should just work - though this might be new behaviour in 8.x.  also 8.x in the gui will allow you to create a new property and map to that - i'm not sure what you could do in 7.6.


          for the 8.2 issue - that seems like a simple fix, though i tend to always use full paths.