Fitzpatrick - Working with Documentum Composer and Without ... · 5. Using Composer, click File> Import 6. Select Documentum> Existing Projects into Workspace 7. Set the workspace

EMC Proven Professional Knowledge Sharing 2010

Working with Documentum Composer and without it

Andrew Fitzpatrick

Andrew FitzpatrickInformation Management ConsultantCapgemini UK [email protected]

2010 EMC Proven Professional Knowledge Sharing 2

TABLE OF CONTENTS

INTRODUCTION .......................................................................................................... 3

THE EXPERIENCE ...................................................................................................... 4

Composer Projects .............................................................................................. 4

Source control ...................................................................................................... 6

Default.dardef and dmc_dar.type (partners in crime) .......................................... 7

Folder structure .................................................................................................... 9

Project separation .............................................................................................. 10

THE TOOLS ............................................................................................................. 12

Reposet.............................................................................................................. 12

Repodoc............................................................................................................. 15

THE DEVELOPMENT APPROACH ................................................................................ 20

Agile ................................................................................................................... 20

Scrum................................................................................................................. 21

Additional tools ................................................................................................... 22

The role of Composer ........................................................................................ 23

CONCLUSION .......................................................................................................... 23

Disclaimer: The views, processes or methodologies published in this article are

those of the author. They do not necessarily reflect EMC Corporation’s views,

processes or methodologies.


Introduction

Composer has made huge strides to help developers and analysts develop for

Documentum®; however there are still some issues. The first section of this article

will discuss the issues that I have faced and how I overcame them. The second

section will review two simple tools that I created to complement Composer and

solve some of the issues discussed in the first section. The final section of this article

will detail an agile development methodology, some of the supporting tools, and how

Composer and my tools can be used to achieve agility.

Composer is now the primary way to create Documentum applications; its benefits

have been listed far and wide.1 2 It provides a friendly interface for business analysts

to create artefacts, a development environment to create custom code, and an

extensible platform through plug-ins. I have now used Composer for over a year and

have found it to be a vast improvement on Documentum Application Builder (DAB).

However, I have faced issues. This article will not detail program bugs, but rather will

present issues with fitting Composer to the development process. As my issues have

been process related, I believe that many other developers working with Composer

will also be contending with them. By detailing the solutions I have implemented, I

aim to share my knowledge so it may be re-used in future.

This article is useful for all Enterprise Content Management (ECM) professionals who

are using Composer as their development tool. The information in this article is

presented from a developer’s point of view. However, all roles within the project

lifecycle will be covered within the appropriate sections.

This article will also be useful for project teams who are working to develop ECM but

don’t necessarily fit a particular methodology. I will present one agile approach that

has been used successfully and discuss the role of Composer within that

methodology.

1http://www.emc.com/products/detail/software/composer.htm# 2http://paulcwarren.wordpress.com/2008/11/18/why-composer-is-important-for-documentum-

and-ecm/


The Experience

Composer Projects

A Composer project is the new way to store configuration files that were previously

held as one project in DAB. The big difference between the way Composer and DAB

stores projects is that Composer stores each artefact (e.g., type, permission set, and

module) as separate files that, at the source level, are XML. DAB stores all project

artefacts in a single binary file; this can cause issues on large projects where there is

a need to work concurrently.

Composer is built on Eclipse. Therefore, a Composer project is very similar to a

standard Eclipse project. There are folders containing source, project-specific files

(e.g., project and .classpath), and areas for build files. Composer projects can also

reference other projects, a feature that is especially useful and one that I will

investigate further. Every Composer project has an internal project at its core called

DocumentumCoreProject. This provides all the Documentum artefacts and types that

can be expected to exist in a freshly initialised docbase. All custom Composer

projects reference the DocumentumCoreProject internally, something that is

essential for extending the dm_ types as these must exist but cannot be created. It

also ensures that they are not imported when objects are imported into Composer

from the docbase.

EMC provide a number of reference projects for packages like Records Manager

(RM), Retention Policy Services (RPS), and Physical Records Manager (PRM).

These reference projects are used in a similar way to the DocumentumCoreProject

as they provide a number of artefacts that can be extended and that will not be

duplicated when importing objects from the docbase. However, these projects need

to be explicitly referenced from the Composer project being created.

I have experienced problems with a Composer artefacts project when initialising it

from source control due to the existing project references. Once this error was

reported, no matter how often I cleaned and re-built the project, the errors still

remained. I eventually solved the problem.


I created my workspace and imported projects in a particular order; this is a routine I

now use each time successfully.

1. Create a directory to hold the project workspace

2. Obtain the Composer project and reference projects from source control,

storing them in the root workspace directory

3. Navigate to the reference projects folder, for each reference project .zip file:

a. right click the file

b. extract the file to a folder in the reference projects directory that is the

same name as the zip file, e.g., extract rm.zip to .\rm, rps.zip to .\rps

4. Open Composer and create a new workspace that points to the workspace

folder created above

5. Using Composer, click File> Import

6. Select Documentum> Existing Projects into Workspace

7. Set the workspace as the root directory; a number of projects will be

displayed

8. Select the reference projects:

a. prm

b. rm

c. RM-Default

d. rps

e. TCMReferenceProject

9. Click finish, the DocumentumCoreProject will be created and the reference

projects will be linked to the workspace

10. Click File> Import again

11. Set the workspace as the root directory; a number of projects will be

displayed

12. Ensure that the Composer artefacts project is selected:

a. ObjectModel

13. Click finish, the project will be built and imported into the workspace.

In this section I have detailed the structure of Composer projects, reference projects

that EMC provides, an issue that I have experienced, and the solution that I

employed to solve the issue.


Source control

You usually need to create deliverables that can be migrated from one environment

to the next within an enterprise. This is critical for testing functionality and delivering

in iterations. ClearCase, Subversion, or CVS are mechanisms for controlling source

code and deliverables. With traditional code deliverables, the source would be

labelled or tagged, a view would be created to show files with that tag, and a build

performed using that view. As a Composer project is essentially a collection of XML

files and a dar file is their deliverable, you can manage a Composer project in much

the same way you manage a traditional code project.

A Composer project consists of ‘source’ files (.\artifacts, .\src, .\web services\src),

project definition files (.\dar), library files (.\content), and ‘binary’ files (\.bin, .\bin-dar).

The ‘source’ files are artefact XML files that can be added to source control. Project files can also be added to source control but there can be issues (discussed in a

following section). Content files can be added to source control but with caution. If

the artefact that links to them changes, (e.g., a .jardef file has the jar file removed

and then re-added), the path in the artefact linking to the content may also change

but the old content will not be removed. This can lead to redundant content files

within the source control system. Binary files are the final types of files contained

within a Composer project. These should not be added to source control as they are

generated by Composer’s build routine or by using an ant build file.

Here is the default set of project folders;

all should be added to source control. Here are the folders after a build has

been performed.


Default.dardef and dmc_dar.type (partners in crime)

There is a dar folder within the Composer project that contains two files; one is

dmc_dar.type that defines the dar object type within Documentum. The second is

default.dardef that contains the model for the project defining all artefact files and

installation properties for the dar to be created. I have experienced issues originating

with both of these files when using them with source control.

When our team first started using Composer, each of the developers had different

machine set-ups. Some worked from a C:\dev directory and others from their ‘My

Documents’ folder; this was acceptable until we started sharing the project through

source control. We wanted the opportunity for any developer on our team to update

the object model and deploy into dev repository if needed. When we started working

in this way, we experienced a number of errors when performing local builds of the

project dar file prior to installation. All the errors involved missing artefacts. The paths

given to the artefacts indicated that our personal environment set-ups were being

stored in some way. Further investigation revealed that the definition of the artefacts

in default.dardef stored the absolute path to the artefact that is a location on the

machine where the artefact was created, e.g.

<artifacts xsi:type="dclass:DClass"

href="urn:com.emc.ide.artifact.dclass/simple_type?artifac

tURI=file:/C:/dev/composerproject/Artifacts/Types/simple_

type.type#//@dataModel"/>

This would not be an issue if one developer was responsible for the object model.

However, we wanted to be more agile and less role specific so it was a problem for

us. The solution was simple and involved little change to the developers’ way of

working. By capturing this early, we did not have many artefacts and therefore it only

took approximately half a day to resolve.

First, each developer created a drive using the SUBST command which linked to

their Composer workspace.

SUBST W: C:\dev


Every developer then started Composer using W:\ as the workspace. Within this

workspace, they re-created their artefacts and checked them into source control so

that the project could be shared. On checking the default.dardef again, I observed

that the references were updated so that they were relative to W:\ e.g.

<artifacts xsi:type="dclass:DClass"

href="urn:com.emc.ide.artifact.dclass/simple_type?artifac

tURI=file:/W:/composerproject/Artifacts/Types/simple_type

.type#//@dataModel"/>

At this point, all of the developers found the project built on their machines and that

they could deploy to the target docbase when required.

The second problem involving default.dardef was that when developers were working

concurrently and then committing their changes to source control, there were many

merge issues with the default.dardef file. This was primarily due to the new artefact

definitions that had to be synchronised across updates. Although this issue was

caused by source control, it was never resolved by only merging updates into the

default.dardef file. Instead, I found an unorthodox procedure that works every time:

1. Clean the build in Composer

a. Select Project and uncheck Build Automatically

b. Select Project> Clean, select the target and clean

c. Once complete, close Composer

2. Update the view of the source code repository to retrieve the latest types and

other artefacts

3. If a manual merge is required on the default.dardef file:

a. Use the source code explorer to set the merge as resolved

4. Delete the default.dardef file (the unorthodox bit)

5. Update from source control again to get the latest version of default.dardef

6. Check out the new version of default.dardef

7. Open Composer, a rebuild will automatically happen, default.dardef will be

updated to contain all artefacts for the project

8. Check-in the new version of default.dardef.


My final problem with default.dardef and dmc_dar.type also concerned source

control. If the source control repository being used locks files, like ClearCase,

Composer will report various errors when importing artefacts from the repository if

the default.dardef and dmc_dar.type are not checked out. This can lead to corrupted

projects and development time to resolve the problem. It is best practice for all

developers to perform an unreserved check-out, or similar depending on the source

control system being used, on these files so that all other developers can also check

the files out and work with the project.

Another side effect of not performing checkouts is that updates to the Composer

project will also cause errors because the new artefact files will not be able to be

added to the default.dardef. Although the dmc_dar.type file does not get updated, it

should still be checked out. I have found that by not checking them out, I receive a

number of errors that were not experienced once the file was unlocked.

In this section, I have explored two of the key Composer project files, some of the

problems that I experienced with them, and how they were overcome.

Folder structure

We often need to create a particular folder structure for deployed, test, clone, or live

target environments. It has been critical on projects that follow a file plan

specification, such as the Local Government Classification Scheme3 (LGCS) and

National Archive Classification Scheme4, to get the file plan correct. When the

categorisation layers are well defined, it can mean that optimising the folder

structure isn’t an option as this may break the standard.

Composer provides support for folder structures only by importing artefacts from the

repository. It does not provide functionality for altering folder structures or updating

the folder properties. The developer must first build the folder structure in

Documentum, import it into Composer, build the dar file, and then install it on the

target system to create a folder structure that can be migrated between

environments.

3 http://www.esd.org.uk/standards/lgcs/ 4 http://www.nationalarchives.gov.uk/recordsmanagement/standards.htm


Any changes to the folder structure must be imported to Composer again and re-

installed. This process has an obvious flaw; it is error-prone. Developers are, in

effect, reverse-engineering the source code from the implementation each time the

folder structure is to be migrated. This practice would be frowned upon in normal

software development.

A better way to create folders is to write a script that can be run to create the folder

structure. This would then set required ACLs and any Metadata. I have created a tool

which does a similar job (detailed in a later section of this article).

Project separation

As discussed in the Composer projects section, because Composer is based on

Eclipse it has an inbuilt ability to reference one project from another. This feature is

useful for splitting projects into logical sections that can also aid installation. When

my project team first started working with Composer, we had one project that

contained our Documentum artefacts, Business Object Framework (BOF) code, and

object instances. This soon became unmanageable and introduced many problems

when installations were performed. The most prominent was the time impact of

repeatedly deploying the whole project. I also found that roles and queues we had

created were always overwritten, and the members removed with each install

meaning that the burden of manual configuration grew as functionality was added. A

number of Composer and other projects were created to optimise development.

The first project type was a ‘module.’ It was a standard Java project that contained

the source files for Type Based Objects (TBOs), Service Based Objects (SBOs),

aspects, modules, methods, and all the JUnit tests. Although this project was not a

Documentum project, and the source files could be contained in the ‘module dar’

project, I preferred to separate them out so another IDE could be used for module

coding. This project used an ant build file that created jar files and put them in the

correct target location.

The second type of project stored all of the following artefact types: Jar Definitions,

Java Libraries, Jobs, Methods, and Modules. This project is a ‘module DAR’ as it

contains the Documentum artefacts required to install the ‘module’ project into the

repository. The jar files created there need to be placed in the content folders of this

(module DAR) project. This first happens when the file is selected as the jardef files

created. To find the location where the jar file is stored, right click the .jardef file and


select ‘Open With> Text Editor.’ Towards the bottom of the file will be XML similar to

the following:

<contentStore>

<contentEntries key=" module.jar">

<value filePath="content/19/-1407438819/module.jar"/>

</contentEntries>

</contentStore>

The ‘filePath’ value can then be used in the ant build file for module so that it gets

updated with each build: <copy file="module.jar" todir="content/19/-1407438819"

overwrite="true"/>

This project is generally the quickest to install and is installed most regularly.

The third project type contains the core Documentum object types like: Alias Sets,

Formats, Permission Sets, Relation Types, and Types. This is the ‘object model’

project. This project tends to have the longest install and I have found it the most

likely to fail. Examples of failures are attribute names being too long as Composer

does not validate attribute name length, and invalid updates to types such as

changing supertype. A great deal of work is needed to resolve any of these failures.

You may have to change an object’s supertype generalise the object before

specialising it again.

The fourth project type is a ‘business configuration’ project that references the object

model project and contains roles, groups, and queues. Sysobjects represent pick list

items, configuration objects, and any other artefact instances. The items in this

project tend to be implemented directly in the environment and then imported into

Composer so that they are only installed when releasing the code into other

environments. There may be some manual configuration after deploying these items

as they may require, depending on the artefact install settings, reassigning users to

roles, groups, and queues.

In this section I have discussed how I structure Composer projects and the rationale

behind that structure.


The Tools

Reposet

Composer is not particularly suited to migrating folder structures from one

environment to another. It is easy to make mistakes when importing from the

repository into Composer. There is no easy way to update or control the folder

structures from within Composer, and there can be unexpected behaviour when

installing the folder structure into the target environment that can lead to manual

cleanup routines.

One solution is to write a Composer plug-in with functionality to create and manage

folder structures based on the artefacts existing within that Composer project e.g.,

creating folders of a particular type, in a given location, and with a particular ACL

where the type and ACL are artefacts within the Composer project and the

destination folder is another folder created using the plug-in. Although this is a good

approach, the developer or analyst is tied to Composer and to working within it.

My solution was to create an Excel spreadsheet that analysts or developers could

use to define the structure of the target environment and deploy one item at a time to

that environment, or in batch. The spreadsheet has some VB Script within it to

enable direct updates to the repository. I also wrote a Java backend for processing

the commands issued by the spreadsheet. This platform is also reused by a

command line application that can deploy an entire spreadsheet at once.

The advantages of using a spreadsheet are:

• Small deployment – an Excel file is small in size and can be e-mailed

between people more easily than a whole Composer project.

• Already common – the client on most of the projects I have worked on usually

specify which folders they require in Excel. With minimal instruction, the

users could utilise Reposet to specify any folder structures and this could be

used for a direct load. This fits well with agile practices, something that I will

discuss later.


• Useful features – basing the tool in Excel means that you can use advanced

Excel features such as lookup tables, calculations, and data validation,

improving the quality of the data to be created by reducing errors introduced

through copy and paste.

I imposed a structure within Excel so that the spreadsheets could be processed to

create docbase items. However, this is a very loose structure so as not to limit users.

The constraints I imposed are as follows:

1. Column A is reserved for Reposet

2. The sheet name is the plural form of the commands that it contains e.g., the

‘Folders’ tab contains one or more ‘Folder’ commands.

3. The value passed with the command is a comma delimited list of key/value

pairs and will appear in column B after the command in column A.

With these rules in mind, you could create a new folder with my Excel spreadsheet

using this structure:

This screenshot shows a single ‘folder’ command; there can be one or more of these

on the ‘Folders’ sheet. There are a number of keywords in column A, one of these is

utilized to Reposet but all are used for Repodoc. The ‘folder’ keyword (A7) indicates

that the text that follows in column B (B7) should be passed to the folder command

class. This text is made of key/value pairs. In Excel, this is a calculation based on

cells B9 through to C12, the contents of B7 is as follows:


From a Reposet point of view, cells B9 through to C12 need not be present. From a

usability perspective, they make it easier to read and manipulate the data defining

folder structures.

There are two ways to process the Reposet spreadsheet; the first is directly from

Excel and the second is from a command line. I have created some VB script in

Excel that can communicate with a Java backend via the Java ActiveX bridge. The

backend then communicates with the Documentum Foundation Classes (DFC). The

user selects the required commands – anything from one to a whole worksheet – and

presses the ‘Process Selected’ button on the sheet.

After logging in, the commands are issued and a success indicator appears. I have

created a simple text user interface for command line use that prompts the user for a

number of imports. It then uses the same backend to issue commands to the DFC.

The main difference between launching from Excel and launching from the command

line is that the macro method will only install from a single worksheet at a time

whereas the command line method will install multiple sheets. Also, the command

line method will only install whole sheets whereas the Excel macro method will install

any number of items from a sheet depending on what the user selects.

The following image illustrates the architecture of Reposet; the interfaces, their

command codes, and the Reposet command classes. This illustrates that both

access methods are built on a common platform for issuing commands through DFC.

The Command Line interface (CLI) prompts the user for a number of inputs such as

sheet names and location of the Reposet spreadsheet. It then uses POI5 to read the

spreadsheet for commands and calls the relevant methods in the command classes.

5 http://poi.apache.org/spreadsheet/index.html


I will continue developing Reposet to include functionality such as creating logging

sheets to provide an audit trail of the operations that have been completed, wrapping

the update in a transaction so that the installation process is more resilient to failure,

writing delete functionality to remove all the Reposet generated items from the

repository, and adding support for creating more artefact instances such as queues.

Repodoc

The development team must document the design of the system. This can range

from a simple side of A4 giving a basic overview to an entire Rational Software

Architect (RSA) project with sequence diagrams, user interface designs, and

interaction diagrams. Documenting the design is mandatory regardless of the design

approach. It is often created retrospectively once the system has been implemented.

The ideal scenario occurs when developers and designers can define and document

artefacts and then generate the documentation from them, which is similar to how

Javadoc works.

A similar mechanism for Composer is for analysts and designers to create the object

model directly in Composer rather than an intermediary spreadsheet that is then

translated by developers. The documentation can be auto-generated and the output

used as an API type reference by all members of the project.

Composer artefacts are essentially XML meaning that a number of operations that

can be performed on XML files can also be performed on Composer artefacts. One

interesting operation mentioned on the internet6 is transformation using XSLT. It

transforms data files stored as XML into HTML format using a definition file that lays

out the skeleton HTML and describes where and how elements from the XML should

appear. Below is a diagram describing the process.

6 http://paulcwarren.wordpress.com/2009/05/29/dardocs/


I used this mechanism of XML translation to create Repodoc, a Composer project

document generation tool. Repodoc runs from an ant file which has inbuilt commands

for transforming XML. There are a number of XSL files for performing the translations

of each artefact file. I created Java code that processes the Repodoc output

directories to build an index XML file that can also be transformed using XSL. HTML

is Repodoc’s output. It uses JavaScript to create an expandable or collapsible menu.

Repodoc also interfaces with Reposet to document the artefact instances created as

part of a standard delivery.

There are a number of fields within Composer for ‘Developer Comments.’ An analyst

can document certain features for the developers who will be working with an

artefact. These are also useful for all project team members.

The following screenshots illustrate Repodoc features. The first screen is the

welcome screen; it can be tailored to suit the project being documented. In this

example, Repodoc is run against the DocumentumCoreProject.

If the user clicks one of the blue boxes, it is expanded to show the artefacts that exist

in that section.


The user has clicked types in the following screenshot.

Clicking one of the types gives the details of that type. In this example, the type is

dm_sysobject.


Repodoc interfaces with Reposet to document the items that are to be created within

a docbase. Here is an example of the output produced when Repodoc is run with the

option to document Reposet. Again, the user sees the default welcome screen but

this time the menu on the left includes a Reposet link.

Clicking the Reposet link expands this node and shows the Reposet worksheets that

exist in the spreadsheet.


When the user clicks one of the sheets, they are presented with another expandable

table showing each artefact instance that can be created within the docbase.

You can expand one of the items to display the properties of that item. The Thomas

Jefferson user has been expanded below.


See how this compares to the data held within Reposet with the screenshot below.

Repodoc will continue to be developed with new features, such as a tree to show

type hierarchy, a design that uses the artefact XSD files so that Repodoc is more

resilient to change and ensures less errors, and complete XSLs for all artefact types

whether they are imported from the docbase or Composer types.

The development approach

Agile

Agile development7 is popular. In its purest form, agile is about producing working

software through close collaboration with the client using a design, tools, and

processes that are ‘good enough’. Agility is a difficult balance to achieve and often

there is no one answer that fits all projects all of the time. Some clients have a

required minimum documentation set and there may be strict rules on how it is

7 http://en.wikipedia.org/wiki/Agile_software_development


produced. This would be a poor fit for an agile approach, but you could still adopt

some of the agile practices such as scrums and focusing on working software.

It is critical to have the client present at the start of the project so that they

understand what agile means, how it will benefit them in the long run, and how

important their input is for the project to be a success. By adopting an agile

approach, the development team can react more quickly to requirement changes

and feedback about features that the client suggests.

I have worked on three large projects that followed the 4 key principles of the Agile

Manifesto.8 All three projects were based on packages, one based on FileNet and

two on Documentum. Two of the three received improved client feedback after agile

practices were adopted and the third, which used agile practises from the start,

received very positive feedback throughout the project.

Scrum

We manage development effort using scrum9, which is a way of working iteratively

that works well with agile development. All development tasks for the project are

stored as individual items on a product backlog. At the start of each sprint, we use a

subset of these tasks to create a sprint backlog. We then spend three weeks

implementing the items and the sprint is completed by a demonstration to the client.

At this point, we discuss and decide on the catalogue for the next sprint with the help

of the client. The next sprint begins. This continues until all items are implemented or

enough of the system is implemented to satisfy all the requirements. The developers

hold a daily scrum where they answer three key questions:

• What did you work on yesterday?

• What will you work on today?

• Are there any blockers to your progress?

These scrums focus the developers’ minds for the day ahead and also help to

identify where tasks are slipping so that extra resources can be assigned if needed.

8 http://en.wikipedia.org/wiki/Agile_Manifesto 9 http://en.wikipedia.org/wiki/Scrum_(development)


Documentum development fits scrum well as most development we do is

configuration that can take anywhere from an hour to a number of days to complete.

Without using a management method such as scrum, it is easy to let the shorter

tasks slip into becoming long tasks and then find that there is not enough time to

complete all the work required. The key is to develop ‘just enough.’

We have found that clients are particularly responsive to the end of sprint reviews.

The first couple are always slow and tend to be demonstrations but they quickly

become discussions and are a useful tool for reaching decisions on functionality.

These sessions are particularly valuable if the suggestions are implemented for the

following session as this gives the client a feeling of ownership. I have successfully

used this approach on two Documentum projects and each time the client

commented that they have never seen the final solution so early. Clients prefer this

way of working since seeing the system helps them to make decisions that may

otherwise be based on assumptions.

Additional tools

Tools are essential to support agile development and reduce manual processes.

Some of the tools I use daily:

• Tomcat – application server for developing and testing WDK customisations

• VMware – local image of a Documentum repository snapshot at particular

points in time. This is useful for remote development and is quicker to roll

back than the EMC provided developer edition of the Content Server. This is

also useful for prototyping sessions with the client as changes will not impact

on the development environment.

• Composer – used for Documentum artefact creation, WDK development,

provides error checking, code completion, and has a very good debug tool.

• TRAC Wiki – useful wiki engine I use with plug-ins that enable the wiki to be

saved in PDF format. The creation and maintenance of a wiki is more

collaborative.

• Hudson – a continuous integration package that builds, tests, and deploys all

projects at regular intervals. I have found Hudson to be the easiest to use.


Using some or all of these tools can help development teams produce working code

more quickly and to a higher quality. However, this will only apply if the local

environments are set up correctly.

The Role of Composer

Composer was one of the tools highlighted within the agile approach. Composer can

be the core tool as it can be used by analysts and developers. Analysts use it to

create object types and other Documentum artefacts, configure their display

properties, and document them using developer comments. Developers use

Composer to create code related artefact types, BOF code, and web services. A

documentation set can be generated that represents the Composer project using

Repodoc. This can be run from within Composer by developers or analysts and used

as a reference by all project members. Finally, using Reposet, some of the issues

faced by using Composer can be avoided and you can introduce greater flexibility

into development.

Conclusion

I have detailed some of the experiences I have had with Composer, and how I have

worked around some of the development process problems. I detailed two tools that I

created and use on a daily basis and commented on how they complement

Composer. Finally, I have detailed an agile development approach; in particular what

agile means, how to manage development with scrum, some of the tools that I use,

and how Composer fits in.

Overall, Composer is a useful tool which is a step forward from DAB and, I believe,

unique amongst its peers as I found no similar tool for FileNet. It provides a

development environment for Documentum artefacts with tailored user interfaces,

enables developers and analysts to work concurrently, and can easily be integrated

with source control through using plug-ins. There are some improvements that I

would like to see in Composer, such as the ability to create and manage folder

structures; however Reposet is a viable alternative.