Installing a DocApp multiple times

DocApps are used to package various elements for customization (such as custom Object Types, Lifecycles, etc.) so that they can be ported from one repository to another easily. It is usually not an issue when a DocApp is installed into a repository for the first time. Consider that a DocApp was developed in a DEV repository and then archived and installed into the QA repository. At this point the QA repository contains everything that was packaged in the DocApp.

Suppose that testing in QA exposes a problem with a lifecycle. We go back to DEV and fix the problem. Now, we archive the DocApp again and install it in QA. If we are using the default installation options on the DocApp, this will create a new version of the lifecycle! It is likely to lead to a problem.

A DocApp contains installation options and the options that address conflicts with existing duplicates are called Upgrade Options. Upgrade options include overwrite, version, overwrite if newer, and do not overwrite. Once you start looking at each item within the DocApp the choices may not be very difficult. The problem may arise if you decide to trust the default upgrade options.

In general (there are some exceptions), sysobjects have version as the default upgrade option. The tricky part is that lifecycles and workflow templates are also sysobjects. Usually, one doesn’t version lifecycles and workflow templates. However, default upgrade options will version lifecycles and workflow templates when the DocApp is installed again in a repository after the first time.

If you are creating a DocApp containing lifecycles and/or workflow templates the least you can do is to review the upgrade options for these objects. More often than not, this will be time well spent.

Handy DQL: Find DocApp containing a Type

If several customizations are present in a Documentum repository, it can get tricky to identify where a particular object type comes from. The following DQL can be used to identify the DocApps that contain an object type. Just replace my_object_type with the actual type name below.

select object_name from dm_application
where r_object_id in
(select c.parent_id
from dmr_containment c, dm_app_ref ar, dm_type t
where c.component_id = ar.i_chronicle_id
and ar.application_obj_id = t.r_object_id
and t.name = 'my_object_type')

It is straightforward to modify this DQL to identify containing DocApps for things other than object types.

[UPDATE] The DQL in the original form would only work with DocApps that haven’t been installed more than once in the same repository. The DQL has been corrected by replacing ar.r_object_id with ar.i_chronicle_id.