Documentum Application Builder vs. Documentum Composer

First released with Documentum 6, Documentum Composer is a “unified development platform for assembling, configuring, and deploying EMC Documentum applications.”  Currently on version 6.5 SP3, Composer is meant to be a Documentum Application Builder replacement.  Although Documentum is trying to move away from Application Builder and into Composer, Application Builder is still available for use with Content Server version 6.5 applications through the use of Application Builder 5.3 SP6.5.

The following table gives a brief comparison between the major functionality of Application Builder and Composer.

Over the course of the past year, TSG has had the fortunate opportunity to utilize Composer for production deployments into Content Server 6.5 environments.  Here are a few tips to keep in mind while working with Composer:

Artifact/Project Installation

• Artifacts cannot be installed individually like in Application Builder; composer project installations are all or nothing like an Application Builder docapp installation
  • Solution: Break out projects into smaller sub-projects: project for types, project for lifecycles, project for modules, project for ACLs, project for groups, etc.

Installation Parameters and Options

• Sometimes if the user creates and applies a new installation parameter from the parameter selection dialog, the parameter will not actually be applied
  • Solution: Create new installation parameters outside of the parameter selection dialog
• If the user modifies values across multiple tabs of an artifact and saves, only the modifications made on the tab where the save was called will actually be saved
  • Solution: Save any modifications made to a tab before switching to another tab

Folder Artifacts

• Composer does not fully support folder artifacts of a custom type. Importing folder artifacts of a custom type is allowable, but will install as dm_folder. Custom type child folders of a folder artifact will install as dm_folder as well.
  • Solution: Modifying the folder artifact XML manually to designate the custom type is possible; however, manual edits are risky and will only work for a folder that does not have any child sysobjects.
  • Solution: Assuming custom folder type does not require TBO to be fired and child sysobject installation behavior does not depend on the custom type, best work around is to run a post-installation DQL to change the folder type