I recently had to perform a large migration and I choose to use to use CSDT. Well, this may be contradictory with some post I did in the past, where I stated I was don't like CSDT. Actually, what I dislike is the CSDT eclipse plugin. While it has some usefulness, it is not that great andI currently just use Eclipse in a local jumpstart using this trick for editing.
But CSDT command line is pretty useful when used as an export/import tool. It could be better however. Using it, I learned a few lessons and I wrote a couple of scripts to make it easier to use. I stored them in my FatGoodies repository, here. You can downloading the scripts with git or just display them raw and save them locally (there are just 3 files).
CSDT jars are not included though. Being proprietary software, I cannot distribute it. You have to take the relevant jars from your Fatwire/WCS installation and copy them in the lib subdirectory where you placed the scripts. Read the README for the list of the required jars.
There are 2 scripts: a launcher, and an exporter. Scripts are written for the BASH shell and works out of the box in common Unixes (Linux / Mac OSX). For Windows you need to install CygWin or another unix like environment with Bash like the one that comes with Git for Windows. I actually use this last one, not Cygwin, but I do not expect problems with Cygwin
The first script is the launcher. It actually comes in 2 flavors: csdt-unix.sh for Unix and and csdt-win.sh for windows. The script does the dirty work of building the classpath you need to lanunch csdt and provide all the numerous parameter that are making a pain to use it.
However the intended use of the launcher is from a wrapper script. You should copy the wrapper.sh in your own file, and edit it filling in the parameter: location of your content server, username, password and site. Defaults are good for a local jumpstart kit.
Your wrapper will the invoke the launcher, and then working with CSDT becomes easy. The launcher is separated from the wrapper because you can have multiple wrappers. I actually make copies of the wrapper script for each server I want to use: for example staging.sh, delivery.sh and so on.
The wrapper script synopsis is then just: ./wrapper.sh [<selection>] [<command>]
If you run it without argument, you will get the list of all assets in the configured server.
The first argument is the <selection> of the assets and it defaults to @ALL_ASSETS. Its syntax is documented in the Content Server developer tools manual. Basically, AssetType:AssetId select a single asset, AssetType select all the assets of a given type, @ALL_ASSETS select all the assets and @ALL_NONASSETS select the configurations. It
The second argument is the csdt command to perform, one of listcs, listds, export, import. You can now do easily stuff like:
The previous script is good enough to launch csdt. However, when performing a full export of a site, there is a problem. CSDT is somewhat fragile: if there is an inconsistency in the content model , the export fails.
There are many possible incosistencies: for example, an asset using a deleted attribute, or a locked asset or something shared with another site. Many inconsistencies that are not a big issue and survive to publishing and don't impact site rendering are fatal for CSDT.
The problem is particularly evident when you try to export all with @ALL_ASSETS, you may to wait a lot of time for answer, then finally the export stops with an exception. You have to fix the issue and then run again the script. When you have thousand of assets, the loop "export - fix - try again" can be unacceptably slow.
The solution is, sadly, exporting all the but one by one, collect the errors and then fix all of them at the end. This is what the second script does.
The synopsis is: ./export.sh <wrapper> [<selection>]
The script requires as the first argument a wrapper script, one of those created in the first part of the post, providing the parameters to connect to a specific CSDT instance. As said in the previous section, you create one copying the wrapper.sh into another file and then editing it providing the appropriate parameters.
The <selection> is by default @ALL_ASSETS but you can use also something like "Template" or "CSElement" to select only one specific asset type or even "CSElement:123456789" to select a single asset.
The export script will export each asset in the selection separately.
The output will be logged in a file called out/<wrapper>/<asset-type>/<asset-id>
The script has 2 advantages: it won't stop if there is an error, and it is incremental .
While csdt alone will bomb if there is any error and stop processing, the export script will simply log the error and continue. However you can stop the processing at any time, and then resume: existing logs will be used as markers, and already extracted asset will not be extracted again.
Once you have all the logs, you can search for errors. The simple command
grep -r out/staging Exception
will return a list of assets that logged an exception, something like this
out/staging/CSElement/1327351719222:Exception out/staging/CSElement/1327351719637:Exception out/staging/CSElement/1327351720069:Exception
You can then inspect the export that failed the export, fix it and then export them again. Since by default already exported assets are skipped you have to add "-f" to the script to force a re-export. So for export again the first asset of the previous list you may use
./export.sh staging.sh CSElement:1327351719222 -f
