Filenet P8 vs.

Documentum, a comparison

Having worked with both Filenet P8 versions 3.x - 4.x and

Documentum 4.x - 6.x, I would like to share a quick comparative
functional review of the two ECM platforms. It would be particularly
useful for people having experience with one, and starting to work on
the other. In each case, it requires some prior knowledge of one of
them.

End-user's perspective

• The repository is called an Object Store in Filenet and a Docbase

in Documentum. Filenet users tend to create several object stores
while Documentum users usually create cabinets within a single
Docbase.
• Filenet Workplace and Documentum Webtop are the web-based
applications used by the majority of users. Documentum Webtop has
a Streamline view (portal-like) as well as the Classic view (Windows
Explorer like), the users can switch between the two. Filenet
Workplace is more like Webtop Streamline view and does not offer a
Classic view. For that, you have to use the newer web-based
application called Workplace XT.
• Although Documentum also has roles, they don't differ much
from the groups in the way they are employed in Webtop. Filenet
Workplace, on the other hand, has its own roles which are used for
portal-like security to provide or restrict access to different Workplace
features.
• Documentum has a Desktop client while there exists no
comparable desktop application in Filenet P8 for the end-users.
Documentum Desktop client is integrated in Windows Explorer.
• Document Types represent the object types in Documentum
while they are called Document Classes in Filenet.
• The main Document Types are Document (dm_document) and
Folder (dm_folder) while the main Document Classes are Document,
Folder and Custom Object. Custom Objects are content-less objects
used specifically for saving data only.
• In Filenet, it is possible to use Association Property which allows
you to select a related object as the property value. This is useful for
creating relationships between objects. In Documentum, you would
have to customize the application to obtain similar functionality.
• Check-out/in and content versioning mechanisms are
comparable in the two, however Filenet versions start from 0.1 while
Documentum documents start from version 1.0.
• ACL's exist in both, in Documentum you would use permission
sets to facilitate security application while Filenet employs security
templates associated with lifecycles or sets of ACE's in entry
templates.
• Documentum ACL's are used to provide access while Filenet
ACL's can additionally be used to restrict access. Even an alternative
and explicit way of restricting access in Filenet is by using Marking
Sets.
• Filenet assumes that the users have access to Document
templates locally and does not provide them in the framework of the
repository. The document is created locally with the native authoring
application from or without a template and imported into the
repository. Documentum, on the other hand allows the use of
document templates per document type and format for document
creation directly in the repository.
• Filenet provides Entry Templates which are wizards for creating
documents or other types of objects. They simplify the process of
document creation through pre-filled property values, predefined
ACE's and Workflow launching. This functionality is unique for Filenet
and does not exist in OOTB Documentum.
• Workflow tasks are received in the personal Inbox in both,
Filenet has additional public inboxes which can be made accessible to
multiple users/groups.
• Document binders are called Virtual Documents in Documentum
and Compound Documents in Filenet.
Administrator's perspective

• While Documentum content and process server components are

integrated within the Content Server, they are separated in Filenet in
Application Engine (AE), Content Engine (CE) and Process Engine
(PE).
• Server startup and shutdown procedures are more elaborate in
Filenet. In Documentum, you start (after Directory Services and
database server) Connection Broker followed by the Docbase and
then the Webtop server components, while in Filenet P8 v4 it is in the
sequence: Content Engine > Process AE Services Manager > IMS
ControlService > PE Services Manager > Process Service >
Component Manager.
• In order to package the configuration in Filenet and to deploy the
package in other environments (Acceptance, Production, etc.), you
have to use an Export Manifest, importing which is much more
limited, error-prone and time-consuming than packaging and
deploying a DocApp in Documentum. On the other hand, it is also
possible to export and import content in an Export Manifest while an
additional Export-Import tool is needed in Documentum for content
migration.
• In Filenet the object types are configured using Enterprise
Manager, while in Documentum it can be done with Application
Builder or from Webtop Administrator or directly with DQL.
• Filenet Properties and Choice Lists are also objects which can be
configured separately and reused in Classes, Documentum allows to
configure these objects within the scope of a Document Type only.
• If Filenet AE and CE language packs are installed, the property
names and choice list values can be easily configured in multiple
languages using Enterprise Manager. In Documentum, there seems
to be no OOTB way to do this, in one of my last Documentum
projects we did it by using a third-party product McLaren Enterprise
Engineer together with Documentum.
• Tables in external databases can be registered in Documentum
as Registered Tables which in turn can be used by property
configurations to populate lookup lists. This ability does not exist in
Filenet.
• All objects in a Documentum docbase can be queried from
Webtop (Administrator) or from a tool like Samson using DQL. DQL is
a handy query language which lets you execute SELECT, CREATE,
UPDATE and DELETE statements on Documentum objects. Such a
query language does not exist for querying Filenet object store.
• DQL is very useful in configuring validation of property value
input by querying registered tables or other repository objects
holding data, and things like duplicate check at the time of document
creation. In Filenet, you can achieve this only through cumbersome
customization.
• Documentum users (dm_user) and groups (dm_group) are
objects like any other object in the docbase, the authentication
occurs against Windows domain user. Filenet does not have users
and groups as objects but uses the Active Directory users.
• Documentum approach of methods and jobs does not exist in
Filenet, which allows easy scheduling of certain tasks via Webtop
Administrator.
• Filenet BPM Process Designer and Process Administrator are Java
applets accessible from within Workplace, while in Documentum the
workflows are created using a client application.
• Documentum Workflows are often used in conjunction with
Lifecycles while this is not the case for Filenet Workflows. OOTB
Filenet lifecycles are very minimalistic and don't offer much
functionality.
• Filenet BPM Component Manager allows you to easily deploy
custom developed BPM components which automate several workflow
tasks. Documentum BPM does not offer a similar sophistoicated
function to deploy and manage the components.
• Filenet offers the subscription feature for document classes, and
lets you specify events on document classes (such as creation, check
in, etc.) which can in turn trigger BPM workflows. OOTB Documentum
does not have this feature.