Documentum Composer: What’s in an Install?

A couple of people have asked after and commented on my blog about the install process and specifically about the dmc_dar type that Composer installs.  They all said that an overview of the install process would be helpful.  So, I will try to oblige.  I will keep this quite high level at this stage so if anything herein stimulates further questions then please do comment.

Composer was designed from the ground as an offline system of record.  Each Docbase type typically has an artifact equivalent as it’s offline record.  Each artifact has a URN (or a unique ID) and artifacts can be linked together via references to their URNs.  References can and do cross project boundaries.

A Project groups together a meaningful set of artifacts.  Because the artifacts it contains have dependencies so too for the Project that depend on the upstream Projects holding the referenced artifacts.  A Project goes through a build process to ensure its artifacts are valid for install.  The “validated & built” artifacts of a Project are exported into a dar file (Documentum ARchive) as a unit of distribution.  A Project can be installed, modified and then re-installed many times throughout its lifetime.  In many ways a Project is similar to an OSGi bundle (or an eclipse plug-in if you’d prefer).

So to the install.  Regardless of how it happens; through the UI or from via ant, the install procedure is basically the same.  The installer will:-

  1. Check that all referenced projects are already installed in the target Docbase.  From their dmc_dar records it will also build a URN to Object ID map which is used later on in the install process
  2. Attempt to resolve Parameters artifacts to real Docbase objects
  3. Run any pre (and afterwards post) install procedures (really this is for backward compatibility with DAB that often used pre & post install tasks to set or finalize the Docbase)
  4. Perform a two pass install.  First pass handles attributes.  Second pass handles references using the above mentioned URN->OID map
  5. Apply each artifact’s install options; set acl, link folders and owner assignment

Now as you will probably be aware your Documentum project contains a couple of extra artifacts, hidden from normal view; the project’s dardef artifact and the dmc_dar type definition artifact.

The dardef artifact (standing for dar definition) stores metadata about the dar which is used during installation.  It is system managed and should not be modified by hand.

The dmc_dar type defines a new “system” type.  It is the equivalent of DAB’s dm_application type.  The artifact is built and added to your Project’s dar and ultimately ends up in the install queue along with all your artifacts.  It’s install intent is set to IGNORE therefore it will get installed, if required, otherwise not.  At the end of the installation an instance of this type is created to record the installation.  Some metadata from the dardef is recorded in the instance’s attributes and two pages of content are added.  Page 0 is actually the dar itself.  Page 1 is the URN->OID map.  This map will be used in subsequent “upgrade” installs or by the install processes of other dependee Projects to help resolve their references.  Over time this type should become a standard system type but initially we wanted to be masters of our own destiny and hence we decided to define it as a type in the Project.

I must emphasize at this point that I don’t consider dmc_dar, its attributes or any of its content pages to be public at the moment.  So I would not advise writing any scripts or other programs against them that you’re not prepared to maintain at least.

Happy Composing!

3 thoughts on “Documentum Composer: What’s in an Install?

  1. Hi Paul,
    I came across your blog when I am looking for DAR installation problems. This post is very informative.

    I am facing an issue with installing a DAR file in Live system. I think you might have some clues about this problem.

    It’s something to do with DAR installation and Datadictionary job.

    When we install a DAR file with Types, Lifecycles and other artifcats it was taking forever, we waited for more than 12 hours and then killed the process.

    Someone suggested that we should replace the Datadictionary method with a dumm,y method during the DAR installation, and then enable and run the Datadictionary job. This process seem to have worked at least once.

    Now the project has several more artifacts, and the above process does no longer work.

    I believe the DAR installation might wait for DataDictionary job completetion and verify the DD information before it can install some types of artifacts. So I think the DD job should be just inactive, and asscoaited with it’s correct method.

    Do you think it’s correct to replace the Datadictionary job method?


    How does DAR installation use DataDictionary job?
    Appreciate if you have any inputs on this issue.

    Kind regards

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s