Documentum Composer: Smart Containers

My colleague David Louie, the Composer product manager, posted a nice demo on the EDN site demonstrating how to build and use a smart container.

One way toconsider a smart container is as a composite application object model.   These can be defined in Composer.  WDK Webtop includes some generic runtime support and together these can be used for rapid prototyping.

From this demo you can hopefully extrapolate either WDK Webtop customizations adding specific runtime support for the Police Case Folders (i.e. File->New-> Police Case Folder, etc) or even a purpose built rich client bound to DFS web services, generated from the smart container model!

Anyway, here is the EDN page.  I recommend you take a look.  The demo is the .exe link at the bottom of the page.

Hat tip to Dave for producing this.

Happy Composing!

Advertisement

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!

Documentum Composer: What’s in a Documentum Project and what should I check in?

I have received a few comments asking what resources are in a Documentum Project, what needs to go into version control and what doesn’t?   I think because Composer contributes some “source” artifacts to the project it is not immediately obvious what the set that needs source control actually is.  So, let’s have a look.

Create a new Documentum Project and then open the Navigator view.  For those new to eclipse the Navigator view will give you an unfiltered view of the projects in your workspace.  You should see something like this:-

Let’s start at the bottom and work up.  All the dot files hold metadata about the project; .project and .classpath are managed by eclipse itself; .dmproject, .dfsproject are managed by the Documentum Artifact project system and .dfsproject is managed by the DFS (Documentum Foundation Services) project system.  Please feel free to have a look inside these but unless you know what you are doing I wouldn’t necessarily modifying them.  They are system managed and modification (of the Documentum ones at least) by hand isn’t a supported operation.

Artifacts is artifact source folder.  It contains a default folder structure for you to store your source artifacts in.  Artifacts must be stored in this folder but it is totally up to you how it is structured.  We chose to mirrored DABs folder structure so it was familiar to migrating user’s.  At some point in the future I am hoping we will be able to add a project template facility that may show other structures and include sample artifacts for a specific problem domain.

As the project is also a regular java project src is the registered java source folder.  Java source can go in here.  If your project contains a module artifact, for example, as per this post and this one.

The resources in both of these folders get “built” into bin.   From here the set of built artifacts get packaged into the dar in bin-dar, normally hidden.  Some artifacts can also have content which is stored in content, again hidden.  The dar folder, also again normally hidden, contains the source dardef artifact (i.e. dar manifest – system managed) and the dmc_dar type; instances of which store information about the installed application (artifact URN->OID mappings, etc).  This will be the subject of my next post actually.

Installation Parameter Files is an optional place to store parameter/value maps for installing into different docbases.

Lastly, Web Services/src is the source folder for DFS Web Services (described in this post and this one).  Web Services/gen-src contains the java source of the generated JAX-WS web service (a DFS web service produces a JAX-WS web service which is then built) and Web Services/bin contains the built version of that web service along with all of its associated web resources.

So, to the check-in question.  A derived resource is any resource that is generated from source artifacts as part of the build process.  That also includes new source that is generated from your source; i.e. Web Services/gen-src.  These don’t need to be checked in because they will get re-built.  So the set of resources that you do need to check-in is highlighted in red:-

For those that asked I hope that helps clarify the situation.

Happy Composing!