Jython on Documentum part 3

March 12, 2009 at 5:44 pm | Posted in Continous Integration, Jython | Leave a comment
Tags: , ,

It’s been a while since I’ve blogged and even longer since I blogged about Jython on Documentum. Sadly excessive work schedules have prevented me from blogging as much as I would like and it’s unlikely to change for the forseeable future. Anyway I’m waiting for a build to run so I’ve got 5 minutes for a coffee and a swift blog.

Since my last Jython on Documentum post I’ve been using jython in a real-live project as part of a build system. The next couple of posts will record some things that I found out.

First up is organising script files. In my previous posts I had just been using jython by changing to the installation directory, saving a .py file and running it from the installation directory. This is not really a great way to organise your script files. I’ve found the following organisation to work well though no doubt there are other ways to do the same thing.

First I have my jython installation in say c:\jython2.2.1. So anytime I want to kick off a jython script I do the following:

  • Start a cmd prompt
  • set path=%path%;c:\jython2.2.1
  • jython

Next I organise my jython scripts in the source code repository in their own folder structure. Something like /scripts/jython/dctm or something similar. The scripts can then be included in builds or deployments as necessary.

A useful object to know about is the sys.path object. This is represents the classpath that jython uses to pickup python libraries, this includes libraries you write yourself (just standard jython code files). You can easily import an external library using the following code snippet (which I have seared into my brain!):


import sys
sys.path.append('scripts/jython/dctm')
import dctm

sys is a standard python library that contains a lot of useful system functions/features. One of them is the aforementioned sys.path. The append method allows you to add extra paths that jython can use to look for libraries. In this case the relative path script/jython/dctm is where I keep my standard dctm.py library. After these lines I can use the dctm object to access any of the methods in dctm.py.

So my standard dctm.py is stored scripts/jython/dctm, my project specific jython file (e.g. myfile.py) is also stored in this folder structure. By navigating to the top-level folder (the one containing the scripts folder) I can run jython like this:

jython myfile.py

WebPublisher Apply Presentation from the command line

February 3, 2009 at 9:25 am | Posted in Continous Integration | 3 Comments
Tags: , ,

Update 5 July 2010: corrected an error in the method calling string
Ever thought it would be useful to be able to utilise the WebPublisher Apply Presentation functionality from the command line but didn’t want to have a whole application server install to make it work? Perhaps you need to put together installation scripts or an automated testing environment. Here is the ‘under-the-covers’ method that is behind the Apply Presentation logic in WebPublisher.

Much of the back-end logic that is exposed by the WebPublisher front end goes through a java server method called wcm_utils. Suppose you have:

  • a docbase DB1
  • install owner of dmadmin
  • xsl template with object id 090ff0ff80003852
  • xml object to be transformed 090ff0ff8000f921

then you need to call the wcm_utils method with the following arguments:

-docbase_name DB1 -user dmadmin -action 12 
    -object_id 090ff0ff80003852 -object_ids 090ff0ff8000f921

for example in IAPI this would be:

apply,c,NULL,DO_METHOD,METHOD,S,wcm_utils,
     ARGUMENTS,S,-docbase_name DB1 -user dmadmin -action 12 
     -object_id 090ff0ff80003852 -object_ids 090ff0ff8000f921

You can also use this interface to transform more than 1 xml object, just separate the -object_ids parameter with colons:

apply,c,NULL,DO_METHOD,METHOD,S,wcm_utils,
     ARGUMENTS,S,-docbase_name DB1 -user dmadmin -action 12 
     -object_id 090ff0ff80003852 -object_ids 
    090ff0ff8000f921:090ff0ff8000f922:090ff0ff8000f924

Why DocApps are bad

January 27, 2009 at 5:23 pm | Posted in Continous Integration, Development | 4 Comments
Tags: , ,

A recent comment on one of my posts pointed out that you could script DocApp installs using an unsupported ant task. This is certainly a useful facility however it doesn’t overcome the basic problem with Documentum Application Builder and DocApps – they don’t integrate well with source code control systems that are used to maintain all the other code and artefacts needed to develop a working system.

Think how you probably develop code for your system. You probably store your source code in a repository (Visual SourceSafe, Subversion, CVS, etc.). You probably have integrations in your IDE to allow you to automatically checkout and checkin code. You probably build your code automatically from the source code system. This is is all fairly standard development practice (hopefully!).

If you are a little more advanced then maybe you also package and deploy your application automatically and you store automated tests in your source code control system. The tests would be automatically executed whenever you build and deploy from your souce code control system.

Basically the source code control system is the lynchpin of your whole development effort. Using version control and labelling you can see how different releases have progressed and maybe track where and when bugs were introduced.

DocApps sit completely outside of this setup, you are effectively using a development docbase as an alternative source code control system – without all the benefits of a properly featured SCC! In an ideal world all your Documentum configuration assets would live in the source code control system – that includes things like type definitions. Now all the source artefacts for your development live in one place. Hopefully this is exactly what Composer will allow you to do.

Create a free website or blog at WordPress.com.
Entries and comments feeds.