Hello my friend!
I have used this script in the past, and done the equivalent import/export myself. There is no easy way to do this (as far as I know) using export/import. What I have done in the past is to have the secondary import create a duplicate depot object (so that it will import), then manually repoint the Job to the correct, original, shared depot object. You may also run into this problem if there is a shared property in the job, and it is the same resolution. Hopefully there are relatively few jobs that are sharing the same depot objects, so the impact is relatively light for you. If this is not the case, and there are many instances of this issue for you, please reply and we can chase the issue further.
Is there any reason that you don't just copy the DB any use that in the new environment
we can't copy the DB to our new environment because the DB size is so big that the cleanup process can't do it job.
So we need to do assessements and export the real good object to the new environment.
(have you tried the new turbo db cleanups?)
nice to see you in the communities.
well, in fact, we've got many BLPACKAGEs (over 200 BLPs) linked to 2 to 4 Jobs each..
So we should import 200Jobs attached to 200 blps but we got almost 600jobs to recreate manually.
It's not very possible, in the automation team, to understand why we need to do massive operation by the hands.
we try to search how modify the 'magic' script but we're not superstar on jython....
if you or someone can help us, it will be very great.
hope to see you next time in France
There are some very recently developed, very fast cleanups for very large databases (so-called "turbo" cleanups): let's talk about them offline.
Yes, unfortunately, some times when working -on- automation, there is only so much automation available. We might consider retaining the original author of this script to further update it, alternately I will look for someone internal to work on it. When do you need it working (besides immediately)?
well... even if we need this very soon because our migration is very close, this script would be very useful when it will be available.
is there a way in the unrealesed BLCli commands to help us in the resolution of our problem ?
what tables are large in the database ?
for oracle can you run these:
sqlserver run this:
and attach the results.
in the jython script, who can help me to modify the call of the blcli ImportExport command to execute with other arguments : we need to use the ImportExport Export with all the exclude options.
The line to correct seems to be this one (I don't know jython):
I thank the guru who will help me !
Hi Olivier, From the BLCLI command help: ImportExport : exportObject This command exports an object into an XML file. It also exports any other additional files that the object requires. This version of exportObject also lets you specify: • Whether or not you want to include Component Discovery Jobs. • Whether or not you want to include Compliance Jobs. • Whether or not you want to include Software Deploy Jobs. • Whether or not you want to include depot software objects. • Whether or not you want to include BLPackages. • Whether you want to keep BLPackage soft links, or convert them to hard links. • Whether or not you want to include referenced grammar files. Talk to you soon !
we're still blocked with this tricky problem and we need to export and import many elements from old bladelogic plateform to new one.
if Adam Bowen should take a few minutes to give us some clue, it will be great.
Have a happy new year 2K14
I'm not Adam, but might be able to give some pointers here
Olivier has picked up the right command for the export here. The run_blcli_cmd takes 3 (variable) arguments. The first one is the blcli Namespace (e.g. ImportExport), the second one is the blcli command (e.g. exportObject) and any subsequent arguments are treated as strings to be appended to the command (and so should pass the needed parameters for the command).
't' is the Object type (e.g. Job) to be exported
'k' is the Object DB Key retrieved previously
'oDir+"/"+exportName' is the output file for the export.
There is another importExport command (released) that takes the args Olivier mentioned to exclude various items.
Variable Name Variable Type Description objectType Integer Type of the object you want to export. objectDBKey DBKey Handle to the object you want to export. outputPath String Name of the directory in which you want to put the exported object. If this directory exists and has files in it, this command overwrites the files. If this directory does not exist, this command creates it. excludeDiscoveryJobs Boolean True to exclude Component Discovery Jobs from the exported object, false to include them. excludeComplianceJobs Boolean True to exclude Compliance Jobs from the exported object, false to include them. excludeSoftwareDeployJobs Boolean True to exclude Software Deploy Jobs from the exported object, false to include them. excludeDepotSoftware Boolean True to exclude depot software objects from the exported object, false to include them. excludeBlPackages Boolean True to exclude BLPackages from the exported object, false to include them. convertSoftlinks Boolean True to convert BLPackage soft links to hard links, false to preserve the soft links. includeGrammars Boolean True to include referenced grammar files, false to exclude them. Note that setting this argument to false requires grammar file mapping on the importing system. excludeTemplates Boolean True to exclude component templates, false to include them. excludeNSHScripts Boolean True to exclude NSH scripts, false to include them. excludeDepotFiles Boolean True to exclude depot files, false to include them.
So we can make use of this, for example:
should export jobs, but not any associated packages, depot objects or templates.
The only thing that I am not quite sure about is whether you need to pass the args as strings (i.e. "false"). Python uses True / False, but you might need to experiment a little here ...