DCM Configuration Nightmare

I was involved in a DCM implementation that was highly organized, but riddled with validation issues. This was in a highly regulated pharmaceutical company with strict qualifications from the development to QA to Produciton environments. Here's an overview list of the issues:

1. IQs and OQs were dry run by the same users.


2. Developers were asked to run some of the OQs.


3. When moving from Dev (where the app worked) to QA, some of the DCM configuration was entered in manually. Inevitable human error caused many late nights figuring out what changed.

So for issue one, we eventually broke out the OQ dry runs to other users. For issue two, we outsourced all responsibility for running the IQ/OQs for validation. Issue three, was never figured out completely until after the project went to production.



DCM Configuration Issues

Why was configuring DCM an issue? Well, for one reason TBO customizations had certain hard coded conditions with relied on the specific Roles and ACLs, Lifecycle states relied on specific ACLs to function as expected, and the UI configuration relied on specific Roles and ACLs as well. Docapps could bring over Roles, but you can't modified them in the App Builder tool. Also, the App Builder doesn't recognize ACLs that are created in a repository without using Permission Templates.



Within DCM you have the following components (among others) to configure:

• Business Applications (which are part of the DocumentClass object)
• Document Classes (coordinators, contributors, templates)
• Auto Name Schemes
• Lifecycle State Extensions
• Roles
• ACLs
• Auto Processes

With each of these components comes varying amounts of configuration details. The headaches come with Roles, ACLs, and LC Extensions. All you need is a misspelled acl or a forgotten role assignment to cause all sorts of havoc. The question becomes "how do you compare environments?" You dump all the objects and attributes. You can't run DQLs to determine the differences. You have to create an application which uses DFC interfaces to enable access to all the Documentum objects of DCM and expose all of their attributes.

Extracting DCM objects as XML

What we ended up developing is an XML bridge which allowed us to extract all (or a subset) of the DCM objects to XML. The schema allowed us to compare XML extractions from one environment to another. We would then take the extraction and run the configuration end of the application on a new docbase which had the base DCM installed and the docapps applied. This saved weeks of time manually configuring the application. Over the course of building and validating four environments the weeks saved, turns into months of effort saved by using this tool.

The Configurator Utility is available for you needs. If you would like to find out more about this utililty please email me at webber_john@charter.net.