Documentum Composer

As posted previously we’ve been using Composer quite a lot on our current project and have set up a development environment which the dev team should be proud of. There is no doubt in my mind that Composer is a big step forward in the Documentum development process. Being able to work on artifacts which are stored on a filesystem and then having this controlled through a code management tool such as Subversion is a big benefit.

Our environment

The approach to development has been to give the developers access to an image of the Documentum server side components, namely the Content Server and Web Application we’re using, RMA. Each developer starts with an identical image, i.e. the products are all the same and they work locally against the image in their own space. When they’re happy with their work it gets checked in to Subversion and then deployed to the central development server.

Point 1: We have not achieved my ultimate goal of continuous build and automated deployment into the central development server. This would help us enormously; as we are working to some of the Agile principles this may be something we bite the bullet on as the Technical Debt we face may prove expensive in the long run. This is not due to any technical problems, just time as we have been focussing on some user demonstrations and addressing some of the technical components of the solution.

Point 2: We have not achieved the goal of using a single product for all Documentum development. Problems with the WDK development have meant that we still use a true version of Eclipse for WDK development and Composer for some of the Documentum based configuration/development.

Point 3: We had to have the developers have their own version of tomcat running locally on the PC, not within the image. Well I say we had to but we took the decision this was the most efficient, enabling us to deploy much easier and also to run in Debug mode better.

Point 4: We have had problems with Forms, creating them in Forms Builder and then bringing them into the Composer project to deploy has caused us grief. Support has been raised on this one but our workaround has been to revert to using DAB as the vehicle for moving Forms from one repository to another.

Point 5: Forms, and Process Builder, again. Okay it would be too much for the early release but it would be really good if we can start to see Process Builder and Forms Builder being integrated into Composer. If I’m developing an application which is based on a process and uses a form which requires some validation, or another level of adaptor, then I’ve got 3 products up and running. Plus the Form and the Process are still being built in the repository. Not a complaint but more of something to add to the wish list!

Overall the product gets a big thumbs up though, huge step in the right direction from EMC and when the next release comes out with Forms and Process plug-ins which can be licensed separately then I’ll raise a glass.

Advertisements

3 thoughts on “Documentum Composer

  1. Good thoughts. A good compliment to my post from before.

    My biggest problem is having to install in the application everything to have one minor update. I’ve only come up with ugly solutions, none of which are worth the effort. It could just be my apps are too heavy in BOF objects and that is the source of the problems.

    • Hi Pie,

      You know that Composer has basic support for reference projects right? So you can split a large projects into several smaller ones. The design-time support for this is ok. The install-time support sucks at the moment but we are looking into how best to support this; perhaps a DAS; i.e. Documentum Archive Solution – a collection of DARs. Not sure yet.

      FYI we are also investigating smart/selective install were the user can select a subset of artifacts to install or where Composer decides what the subset is. There are actually some interesting problems rolled up in this one. But the good news is that there is momentum to solve this particular problem as it is seen as a particular pain point at the moment and it is also an enabler for other use cases; i.e. synchronization.

  2. Hi Lee,

    Re #2 – can you expand on the problem you highlight here pls? Did you try adding the Composer plugins to the eclipse for WDK install? Dependency issues perhaps? Would a Documentum update site help you achieve a single development environment?

    Re #4 #5 – I know, I know. I feel your pain on this one. I have been voicing my concerns on this since before v1. My take on it is that we (Documentum) really needs to hear from the user community on the importance of having an integrated, all inclusive set of tools, built on a common tooling platform that can be surfaced in multiple places; Composer, web-based tools, etc.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s