Category: Documentum

EMC Documentum tips and tricks.

Handy use for VMWare #2: Instant training setup

My practice has put together a “Documentum Boot Camp” which is an intensive course aimed at taking folks with Java development experience and turning them into Documentum developers in much less time than if you were to take formal training on each topic. We cover everything from Administration, Security, and Workflow to writing custom Documentum WDK-based applications.

Keeping a pristine training environment set up, or better yet, providing each student with their own training environment wouldn’t be practical if it weren’t for VMWare. With VMWare we’re able to create a standard “client” and “server” image, each pre-configured with everything the student will need to get through the Boot Camp exercises. So, when it is time for someone to go through the Boot Camp, we give them a CD with the courseware, lab book, and instructions, and two DVDs with the VMWare images. They use the VMWare Player to run their images. If they trash their environment it’s no problem–they simply re-copy the image from the DVD.

I’ve seen training providers handle this with ghost images in the past. The nice thing about the VMWare approach is that the images run on the student’s machine on top of the OS they already have installed. This is the first time I’ve seen a training class where you can actually take the training “machine” with you when the class is over. The next time you pay for training, instead of asking, “Is this course material going to be available for download?” you should ask, “Is my training machine available over BitTorrent?”

Documentum: Open up the WDK!

The Documentum Web Development Kit (WDK) is a rich component library developers can use to build Documentum-centric web applications. All of Documentum’s web clients–Documentum Administrator, Documentum Webtop, Documentum Web Publisher, Documentum Digital Asset Manager, etc.–are all built on the WDK.

The WDK is similar to JavaServer Faces(JSF) but it is not JSF. Although EMC Documentum was a contributor to the JSR-127 JavaServer Faces specification which went to “Final Release” on March 11, 2004, the WDK continues to be a proprietary framework.

Why do I care? In my personal opinion, there are two main reasons why Documentum should open up the WDK. First, although the WDK makes it easy to make simple changes (often requiring nothing more than editing an XML file), more complex extensions are often hampered because, ironically, some pieces of the library just weren’t built to be extended. If you are an engineer at EMC, this isn’t a hurdle for you–you have the source code. But for third-party developers, determining exactly what’s going on behind-the-scenes can be a time-consuming and frustrating task.

Second, experienced WDK developers are hard to find. This resource scarcity results in increased development and maintenance costs. (A related problem is that companies invest time and money in developing WDK talent and end up with resources that are not perfectly transferrable across other, non-WDK projects).

My first choice to solve this problem would be to migrate the WDK to JavaServer Faces. EMC Documentum would then supply any Documentum-specific JSF components that are needed, along with the source. This would address both of my issues. Everyone would have access to all of the source. And it opens up the resource pool to the larger population of developers familiar with open, standards-based component frameworks.

Here’s an idea. If Documentum doesn’t do it, maybe the open source community could be rallied to do so. I know companies are already building Documentum web applications using JSF–why not build those apps on some open building blocks the entire community can leverage?

In the short-term, I would settle for some tweaks to the existing WDK and the distribution of the source code for every single WDK class. Progress has been made in this area with the release of 5.3 sp1. Some of the previously private and protected methods have been made public. I haven’t compared the 5.3 release to 5.2.5 to see if any additional source code has been provided.

At the Documentum Developer Conference this past Fall I spoke to Howard Shao, Documentum’s CTO, about opening the source. He responded positively, saying that he wished it had been done already. So, I’m hopeful. But, I’m also realistic. I realize a tremendous investment has been made in the WDK and I know it would take a lot of work on behalf of EMC and their customers to move to an open framework. Compounding the problem is that the business users may not see the bigger picture benefits of an open framework. As EMC and its customers continue to invest in the WDK, the cost of switching only goes up. Why not move now?

Documentum Web Publisher Portlet Builder

EMC Documentum announced today the release of their new product, Web Publisher Portlet Builder. The goal of the product is to allow non-technical users to define and deploy new portlets to a portal by filling out forms in a wizard-style interface.

In the product announcement, EMC called portal “the new web master bottleneck”. I think this can certainly be true. When a company makes an investment in web content management, the management of the content itself is streamlined, obviously, but when that content is being served up through the portal, you end up with a new layer of process, administration, and management inefficiencies.

For example, suppose we have a portal in which each portlet is serving up a specific static URL. A press release portlet might contain a list of press releases, and the list of press releases would change over time, but that portlet would always contain press releases. The WCM system makes sure that non-technical owners of press releases can contribute the content, route it for approval, transform it into the desired formats, etc. But what if the portlet needs to start serving up press releases from a company subsidiary or maybe an entirely new type of content altogether? Often, the portal administrators have to be involved at that point.

As another example, suppose an entirely new portlet is being added. In some implementations, adding a new portlet can require a fairly involved build process. The portlet might be built in a development environment, get migrated to the test environment, and then finally rolled out to production as part of a scheduled maintenance release. This process certainly results in a quality end-product, but is not very responsive to change.

Because portlet configuration is usually XML-based, it lends itself to a more automated, forms-based approach, like the product Documentum has announced. In fact, I know of others who have done this on their own using home-grown approaches or by leveraging XML-based templating engines built-in to their web content management system.

I haven’t played with Documentum’s new offering yet so I cannot say how robust it is. I do wish it supported more than just BEA WebLogic Portal. I imagine they’ll offer more support for other vendors (probably IBM WebSphere Portal and Oracle) over time.

The bigger issue is that portal vendors need to do more to beef up and simplify portlet deployment. And content management vendors need to do more to allow their repository to be integrated with the portal more seamlessly so that dynamic content can be delivered to the portal without requiring costly integration, duplication of back-end stores, or performance hits.

Downgrading from Documentum 5.3

I recently found myself billing at two different clients, each of whom use different versions of Documentum. I used VMWare to create a development environment for one client and used my laptop as the dev environment for the other.

When I created the VMWare image, rather than starting with a fresh, clean Windows image, I started with my “Documentum 5.3 Clients” image. I uninstalled everything, cleaned out the registry, deleted all directories, and re-booted.

All of the 5.2.5 software installed cleanly except for Documentum Application Builder. It was still seeing traces of the 5.3 components. I double-checked the registry and the file system and re-booted again but it still had the problem. Puzzling.

Luckily, support clued me in to the “vpd.properties” file. This file lives in the Windows or winnt directory and keeps track of the installed Documentum components. After uninstalling 5.3, you have to delete the lines that start with:

e2d8fde61467a0c5ba79004516db8af4|5|3|113

Yours may vary depending on the specific build you are running. In this case, I was running 5.3 build 113.

Standalone version of Documentum Eclipse plug-in

I’ve been using an older version of Documentum’s
Repository Interrogation Utility, which is an Eclipse plug-in that talks to the Documentum repository. It is real handy to be able to run DQL queries and dump objects without leaving Eclipse. But what I didn’t know is that with their latest release, they’ve included a standalone version. That means if you are working for a client where you cannot use Eclipse you can still get the benefit of the tool.

Documentum kicked off user conference today

Documentum kicked off their annual user conference, Momentum, today at the Mandalay Bay Resort in Las Vegas. I’m here with a couple of colleagues. Patrick Dawson and I are presenting on “How Southwest Airlines Designs High Usage EMC Documentum Applications” tomorrow morning. Tuning and performance is usually a hot topic so I’m hoping for a good turnout.