Post on 10-Sep-2020
EMC Proven Professional Knowledge Sharing 2010
Working with Documentum Composer and without it
Andrew Fitzpatrick
Andrew FitzpatrickInformation Management ConsultantCapgemini UK Plc.andrew.fitzpatrick@capgemini.com
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.
2010 EMC Proven Professional Knowledge Sharing 3
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/
2010 EMC Proven Professional Knowledge Sharing 4
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.
2010 EMC Proven Professional Knowledge Sharing 5
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.
2010 EMC Proven Professional Knowledge Sharing 6
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.
2010 EMC Proven Professional Knowledge Sharing 7
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
2010 EMC Proven Professional Knowledge Sharing 8
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.
2010 EMC Proven Professional Knowledge Sharing 9
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
2010 EMC Proven Professional Knowledge Sharing 10
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
2010 EMC Proven Professional Knowledge Sharing 11
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.
2010 EMC Proven Professional Knowledge Sharing 12
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.
2010 EMC Proven Professional Knowledge Sharing 13
• 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:
2010 EMC Proven Professional Knowledge Sharing 14
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
2010 EMC Proven Professional Knowledge Sharing 15
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/
2010 EMC Proven Professional Knowledge Sharing 16
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.
2010 EMC Proven Professional Knowledge Sharing 17
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.
2010 EMC Proven Professional Knowledge Sharing 18
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.
2010 EMC Proven Professional Knowledge Sharing 19
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.
2010 EMC Proven Professional Knowledge Sharing 20
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
2010 EMC Proven Professional Knowledge Sharing 21
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)
2010 EMC Proven Professional Knowledge Sharing 22
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.
2010 EMC Proven Professional Knowledge Sharing 23
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.