Although steeply-priced at $2495, the annual EMC Documentum Developer Conference offered in-depth looks into the forthcoming 5.3 sp1 release (due out tomorrow) and access to Documentum product managers and engineers. I'd estimate about 300 developers from around the world attended the four day conference in Berkeley.

Release 5.3 sp1 promises to be pretty major, as far as service packs go. Many of the features that didn't make it in to 5.3 due to time constraints are included in the service pack. That's contrary to the normal EMC Documentum practice of limiting service packs to bug fixes with only minor changes or additions to functionality.

From my perspective, one of the most anticipated features is the next generation of the Business Objects Framework, BOF 2.0. The ability to hot-deploy and sandbox BOF Type Based Objects (TBO's) and Service Based Objects (SBO's) is high on my list. There's also a new package of Search interfaces that look interesting.

This release will be the first in which Linux is supported across the stack. Release 5.3 installed without issue on my Red Hat Linux Enterprise 3 VMWare image. Customers already familiar with content server installations on other flavors of Unix should not have a problem.

6:13:10 PM    

When you create custom Java methods for Documentum's Java Method Server you can add the class or JAR files to $DOCUMENTUM/dba/java_methods and they'll get added to the Java Method Server's classpath automatically. However, if those methods leverage BOF classes, you may need to do some tweaks so that the Java Method Server can load those classes.

Currently, our preferred approach for telling the content server where our custom classes live is to create a directory off of $DM_HOME, let's call it nav/lib for this discussion, in which our JARs live. We then create a JAR that only contains a manifest, we'll name it nav.jar, in $DM_HOME. The manifest points to the JARs in nav/lib. This enables us to have a single file in the classpath, nav.jar, with as many additional JARs in nav/lib as we need and we only have to update the manifest file in nav.jar when we make changes rather than changing the classpath.

Documentum does this as well. That's what dctm.jar is all about. It contains no classes. Only a manifest. Here's what's in the dctm.jar's manifest.mf:

Manifest-Version: 1.0
Created-By: Documentum Installer Component Library
Class-Path: Shared/dfcbase.jar Shared/dfc.jar Shared/bsf.jar Shared/lo
 g4j.jar Shared/xalan.jar Shared/xercesImpl.jar Shared/xmlParserAPIs.j
 ar Shared/xml-apis.jar Shared/All-MB.jar Shared/ldapjdk.jar Shared/ld
 apfilt.jar Shared/jss311.jar Shared/certj.jar Shared/sslj.jar Shared/
 jsafe.jar Shared/jnet.jar Shared/ldap.jar Shared/ldapbp.jar Shared/jn
 di.jar Shared/bpmutil.jar Shared/ci.jar Shared/subscription.jar Share
 d/workflow.jar Shared/xforms.jar Shared/dam_services.jar Shared/tar.j
 ar Shared/wcm.jar Shared/WcmMethods.jar

An easy way to create a JAR with only a manifest is to use the Ant jar and netsted manifest tasks, like this:

On UNIX servers, the Java Method Server is started manually using Tomcat's startup.sh script. There are many ways to tell Tomcat about classes you want to share across webapps. The way Documentum does it (and therefore, the technique we've copied) is to update setenv.sh to include dctm.jar (or in our case, nav.jar) in Tomcat's classpath.

When your content server runs on a Windows host, however, the Java Method Server is started as a service which calls tomcat.exe. If you want to use a similar approach as described above, you can use regedit to update the registry so that the right arguments are set when tomcat.exe is run. In this case, the classpath needs to be updated to include nav.jar.

The key you need to update is HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDmJavaMethodServerParameters. On my content server the classpath argument was in the string named JVM Option Number 0. I updated mine to include nav.jar, like this:

-Djava.class.path=C:Program FilesDocumentumtomcat4.1.27binbootstrap.jar;C:Program FilesDocumentumjdk131_04libtools.jar;C:Program FilesDocumentumdctm.jar;C:DocumentumConfig;c:program filesDocumentumnav.jar

After you make the change, restart the Documentum Java Method Server service and your methods will be able to find your BOF classes without a problem.

12:56:49 PM    

From time-to-time, you may find that dm_jobs fail to run according to their schedule. Sometimes they can be "encouraged" to run by logging in to Documentum Administrator, opening the properties for the job, changing the next invocation date to a time shortly after the present, and saving the changes by clicking OK. Or you can simply open the object, select "Run After Update" and click OK.

When those attempts fail, and assuming you've already checked $DM_HOME/tomcat/logs/catalina.out and $DOCUMENTUM/dba/log/<docbase_name>.log for obvious error messages, your agent_exec process might be hung. If none of the jobs are running when they are supposed to this is another indicator of a hung agent_exec process.

One way to clear this problem is to simply kill the agent_exec process. On UNIX you would grep for the process (ps -ef|grep agent_exec ought to do the trick) and then kill it (kill <process id>). The content server will notice that the agent exec process is dead and will start a new one. This should free up those stuck jobs.

6:03:02 PM