Documentum has been OEM’ing Captiva’s scanning software for quite a while. Looks like they’re going the next logical step…

EMC to Acquire Captiva Software

EMC to Resell WoodWing’s Smart Connection Enterprise. WoodWing Software announced that EMC Corporation will resell its Smart Connection Enterprise software as part of the EMC Documentum Enterprise Publishing Solution (EPS), a new content management solution that provides editorial design and layout capabilities. WoodWing’s Smart Connection Enterprise is an Adobe InDesign and InCopy integration tool that enables workflow flexibility through management, organization and document security standards for editorial production. The integration of WoodWing Smart Connection in EMC Documentum EPS allows publishers to manage their editorial production workflows, using the same print content and related ancillary content for publishing to the Web or other emerging channels such as wireless devices. Documentum EPS is built on the unified EMC Documentum enterprise content management (ECM) architecture, enabling users to utilize the full ECM capabilities such as digital asset management, web publishing, XML support, workflows, security, content rendering and localization. Smart Connection Enterprise serves complex workflows and environments, where searching files and/or the content of a story or specific keywords or metadata is required, and comes with support for MySQL, Oracle, Microsoft SQL Server, and Sybase. The server runs on Windows, Mac OS X, Linux and Solaris. http://www.woodwing.com [Gilbane Report News]

There seemed to be a lot of interest in load-testing WDK applications with something other than Mercury LoadRunner. Here is an article I wrote that gives an introduction on using Apache JMeter to perform load-tests against Documentum WDK applications.

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.

I’m in Berkeley for the Documentum Developer Conference. Spent a wonderful evening over at my aunt and uncle’s house in El Cerrito. Great dinner and lots of fun catching up. The Claremont Hotel & Resort, the venue for the conference, is pretty sweet.

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:

<target name=”classpath_jar”>
    <jar destfile=”${dir.dist}/nav.jar” excludes=”*.jar” >
        <manifest>
            <attribute name=”Class-Path” value=”nav/lib/nav_server.jar nav/lib/someother.jar nav/lib/andanother.jar”/>
        </manifest>
</jar>
</target>

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_MACHINE\SYSTEM\CurrentControlSet\Services\DmJavaMethodServer\Parameters. 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 Files\Documentum\tomcat\4.1.27\bin\bootstrap.jar;C:\Program Files\Documentum\jdk\131_04\lib\tools.jar;C:\Program Files\Documentum\dctm.jar;C:\Documentum\Config;c:\program files\Documentum\nav.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.

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.

EMC Posts Higher Net; Stock Up 10 Pct.. EMC Corp. reported its profit nearly doubled, as it shook off a weak global economy and reaffirmed its outlook for the year, sending its shares up 10 percent. [eWEEK Technology News]