Getting started with Content Server Developer Tools (CSDT)

Hey, Curtis here. I’m hectic busy at the moment which makes Manifesto’s accountants happy but leaves me feeling neglectful of the Fatwire and WebCenter Sites Blog audience. So I’ve drafted in the help of Hamish Buchanan, who, as well as being a thoroughly good bloke, is also a WebCenter Architect at Hewlett-Packard. He’s going to introduce us to Content Server Developer Tools which is bundled with WebCenter Sites and is really rather useful for reasons that I’ll let Hamish explain…

CSDT (Content Server Developer Tools) is provided with WebCenter Sites to allow you to migrate content between environments. One of the main uses of CSDT is to synchronise a Developer’s Eclipse workspace with a Sites environment. However it can also be used to migrate code deployment too. This post explains how to use the command-line interface with CSDT to deploy code to WebCenter Sites.

While there’s nothing stopping you using CSDT to migrate Content it’s better suited to moving code (and I’m using Code here as a term which includes Asset definitions, Attributes, Templates and even things like Start Menus.)

Like Publishing in Sites, CSDT will ensure that dependencies are automatically included when moving assets.

The CSDT libraries are located in the Sites folder at: /Sites/11.1.1.8.0/csdt and to use them you will need to include all the jar files in the lib folder.

A quick introduction to CSDT

The basic structure of a CSDT command is:

java com.fatwire.csdt.client.main.CSDT <content server url> username=<user> password=<password> cmd=<command> [options]

There are four available commands with CSDT and these are:

• export, exports assets from Sites to the file system
• import, import assets to Sites from the file system
• listcs, display a list of content in Sites
• listds, display a list of content in a workspace on the file system

listcs and listds are slightly confusingly named. It might help to think of them as list-Content-Server, i.e. list what’s in Sites repository, and list-Data-Store, i.e. what’s on the file system.

Importing and exporting with CSDT

There are a number of options available with CSDT, namely;

• resources, this lets you select a group of assets, more on this later
• fromSites, specify that assets should only come from a particular site
• toSites, specify that assets should only be imported to a particular site
• modifiedSince, lets you filter assets by date
• datastore, allows you to specify the workspace or folder where content will be placed or read from

The resources option is probably the most important as this is where you can specify exactly which assets you want to import or export.

You can query for assets using wildcards or the asset id. You can even combine several resource commands together. The resources options take the format;

@<content type>:<filter>

Where;

Content Type is the type of asset or resource you wish to process. Examples of these are;

• SITE
• TREETAB
• STARTMENU
• or the actual name of an Asset type e.g. CONTENT_C, PRODUCT_P

There are two special Resource options which are ALL_ASSETS and ALL_NONASSETS. As you would expect these options will process all matching items t finds.

– Filter lets you select which items to include. You can either specify the id of the item or use a wildcard.

Some examples of resource commands

• resources=@SITE:avisports
  • Extracts the avisports Site definition by its self

• resources=@CONTENT_C:*;@PRODUCT_A:*
  • will process all CONTENT_C and PRODUCT_A assets as well as an dependent assets such as the Parent

• resources=@ALL_ASSETS:*;@ALL_NONASSETS:*
  • will match all items in the repository or datastore

When exporting objects using CSDT you can just specify the lowest level item, for example the asset itself, knowing that CSDT will also extract the dependencies.

Importing using CSDT is slightly harder.

When you’re doing an import you can again use the resource command to select which items you want to process, however it’s important that you get them in the right order.

The CSDT will process items in the order it finds them. This means that it could try to import an asset before its dependency even though the dependency exists later in the batch.

The way to avoid these issues is to make sure that you import assets in order. The order is the same as you would use if you were creating a site e.g. @SITE, @ATTRIBUTE, @PARENTDEF etc.

A word about CSDT ids

Sites uses two types of id, a local one, which is used within a Sites server and a global one which is shared across all environments. When you’re querying for assets in the Content Server you need to specify the local id but if you’re querying the Workspace assets you need to use the global id.

The CSDT is a powerful tool but it does have some limitations

The main ones seem to be:

• Stop on error. If the CSDT encounters an error it will halt and won’t continue until the error is resolved. This is good for keeping your repository in sync but sometimes you know what you’re doing and you want to force an import.

• Limited filtering of assets. CSDT lets you do some limited filtering of assets for example on the modified date but it doesn’t let you filter by other metadata or to write your own queries.

• Dependencies. The CSDT tool will always include the dependencies when you export items. For the majority of the time this is fine however there are occasions when it would be useful not to take the dependencies. For example if you are moving some content from Production back to a test environment bringing the dependencies could overwrite the new code you are trying to test.

At the moment CSDT is a powerful tool and one which is really useful for moving Code from a Development environment to a Test server. However, the potential is there to create a mechanism which is a useful alternative to Publishing.