Fixing the Deprecated api exec for Lifecycles

A few months ago I came across a deprecated api that I was trying to use to uninstall a dm_policy or lifecycle. What I needed to do was uninstall the LC apply a new ACL to the LC object and install it. I searched EMC's dev discussions and found a few references to this, but no real solutions. I knew that the App Builder dealt with lifecycles, so I took a look at the DDS.jar files to see if there was something of interest. There was.

Here's the deprecate code I was trying to fix:

obj = (IDfSysObject)m_session.getObject(idObj);
m_objectId = idObj.toString();
// Uninstall this LifeCycle Object
m_session.apiExec("uninstall",m_objectId);
obj.setACLName(sAcl);
IDfACL idAclObj = (IDfACL)(m_session.getObject(getDocbaseObjectIDIfExists
("dm_acl WHERE ( object_name = '" + sAcl + "' )")));
sAclDomain = idAclObj.getDomain();
obj.setACLDomain(sAclDomain);
obj.save();
m_session.apiExec("install",m_objectId);

In the 5.3 DFC eclipse IDE, the "apiExec" was crossed out. I could compile the code, but the runtime environment needed to be very controlled. After digging into the DDS.jar file of the App Builder I fould a "policy" object which looked useful.

The following is the fixed code:

import java.beans.PropertyVetoException;
import com.documentum.policy.data.*;
try{
obj = (IDfSysObject)m_session.getObject(idObj);
m_objectId = idObj.toString();
// Uninstall this LifeCycle Object
IDfPolicy policy = new DfPolicy();
policy.setDocbaseContext(m_session);
try{
policy.open(new DfId(m_objectId), 1);
policy.uninstall();
obj.setACLName(sAcl);
IDfACL idAclObj = (IDfACL)(m_session.getObject
(getDocbaseObjectIDIfExists("dm_acl WHERE ( object_name = '" + sAcl +
"' )")));
sAclDomain = idAclObj.getDomain();
obj.setACLDomain(sAclDomain);
obj.save();
policy.validate();
policy.install();
}catch(IOException ioe){
}catch(PropertyVetoException pve){ }
}catch(DfException e) { }

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.