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:-
- 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
- Attempt to resolve Parameters artifacts to real Docbase objects
- 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)
- Perform a two pass install. First pass handles attributes. Second pass handles references using the above mentioned URN->OID map
- 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.