Documentum 6.5 SP1 System Upgrade and Migration Guide

EMC ® Documentum ®
System
Version 6.5 SP1
Upgrade and Migration Guide
P/N 300008607 A02
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748‑9103
1‑508‑435‑1000
www.EMC.com
Copyright© 2008 EMC Corporation. All rights reserved.
Published December 2008
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS
OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up‑to‑date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Table of Contents
Preface ................................................................................................................................. 9
Chapter 1 Upgrade and Migration Overview ................................................................ 11

Upgrade and migration..................................................................................... 11
Understanding migration .................................................................................. 12
Order of new product installation ...................................................................... 12
Order of system updates ................................................................................... 13
System upgrade strategies ................................................................................. 14
Changing the database OS and version .............................................................. 17
Changing the content store location ................................................................... 18
Migrating XML content to the XML store ........................................................... 18
Chapter 2 Planning System Size and Enhancing Performance .................................... 19

Planning the system size ................................................................................... 19
Planning for performance.................................................................................. 20
Common problems in Server performance ......................................................... 21
Common problems in web application performance ........................................... 22
Chapter 3 Planning the System Migration ................................................................... 23

Changes in supported environments.................................................................. 23
Version 6.5 changes that impact Content Server upgrade or migration ................. 24
Migrating objects to lightweight sysobjects (LWSOs) ....................................... 24
Changed behavior for attribute length ........................................................... 25
Maximum accepted string lengths in Documentum query language
(DQL) statements ......................................................................................... 25
Required configuration for machine‑only application access control
tokens .......................................................................................................... 25
Audit trail entries for dm_startedworkitem enhanced ..................................... 25
DFC does not support linked store storage areas ........................................... 26
External storage............................................................................................ 26
DFC does not support optical storage devices ................................................. 26
DFC Full format specifications no longer accepted .......................................... 26
SYNC_REPLICA_RECORDS administration method ...................................... 26
LDIF file changes .......................................................................................... 26
Obsolete dmcl.ini keys .................................................................................. 27
New dfc.properties key to turn off trusted login ............................................. 27
DQL changes................................................................................................ 27
POSITION keyword no longer supported .................................................. 27
CHANGE...OBJECT statement .................................................................. 27
DQL date literals enhancement .................................................................. 27
Behavior change after failed save or checkin ................................................... 28
Trace method migration ................................................................................ 28
New server.ini key ....................................................................................... 28
EMC Documentum System Version 6.5 SP1 Upgrade and Migration Guide 3
Table of Contents
enable_workitem_mgmt obsolete .................................................................. 28

Mapping your current configuration .................................................................. 29
Designing your version 6.5 configuration ........................................................... 32
Addressing hardware concerns ..................................................................... 32
Upgrading third‑party software..................................................................... 33
Planning for global registries ......................................................................... 33
Mapping your version 6.5 configuration......................................................... 34
Planning upgrade and migration to version 6.5................................................... 34
Setting up a test environment ........................................................................ 34
Client‑first migration .................................................................................... 34
Chapter 4 Interoperability and Compatibility ............................................................... 37

Mixed version compatibility .............................................................................. 37
Guidelines for determining mixed version compatibilities ................................... 38
Product‑specific limitations ............................................................................... 40
Cross product dependencies.......................................................................... 43
Webtop, Digital Asset Manager ..................................................................... 43
Extended Search ....................................................................................... 43
Chapter 5 Migrating Content Server ............................................................................ 45

Rebuilding or upgrading fulltext indexes ........................................................... 46
Configuring login tickets for backward compatibility .......................................... 46
Using DQL to migrate content to an XML Store .................................................. 47
Migrating custom Content Server methods......................................................... 47
Migrating DocApps and BOF2 modules ............................................................. 47
Chapter 6 Migrating DFC Customizations .................................................................... 49

Java class changes ............................................................................................. 49
Configuring DFC for native IPv4 operations ....................................................... 49
Migrating customizations to Business Objects..................................................... 49
Migrating DMCL API calls to DFC API calls....................................................... 50
Search service ................................................................................................... 50
Full format specications no longer accepted........................................................ 51
Character string handling improved .................................................................. 51
Aspects, a new BOF module type for developers ................................................ 51
JMX management of DfPreferences and dfc.properties ........................................ 51
DFC deployment .............................................................................................. 52
Conguration for application access control tokens............................................... 52
Setting the maximum number of results per source ............................................. 52
Chapter 7 Migrating WDK and Webtop Applications ................................................... 53

Overview ......................................................................................................... 53
Updating and migrating email messages ............................................................ 54
Java class changes ............................................................................................. 55
Application framework changes ........................................................................ 55
Configuring new accessibility features and timeout warnings.......................... 55
Migrating scoped configurations to presets .................................................... 57
Deployment model changed.......................................................................... 58
Migrating configuration extensions to modifications ....................................... 58
4 EMC Documentum System Version 6.5 SP1 Upgrade and Migration Guide
Table of Contents
Migrating JSP menus to XML menus.............................................................. 59

Application‑wide changes ................................................................................. 62
Placing a custom component in a modal pop‑up dialog ................................... 62
Defining the available pop‑up windows ..................................................... 62
Invoking a modal component in a pop‑up window ..................................... 62
Refreshing the parent window .................................................................. 64
Creating an action postprocessor for actions that sometimes
require modal windows ............................................................................ 64
Using window.location.replace within a modal component ......................... 65
Enabling and configuring IRM support .......................................................... 65
Email conversion to EMCMF format .............................................................. 66
Configuring inline refresh ............................................................................. 66
Lightweight sysobject support ....................................................................... 67
Using strong encryption ................................................................................ 68
Enabling read notifications ............................................................................ 69
Setting roles precedence ................................................................................ 70
Right‑click context menus ............................................................................. 70
Migrating datagrid customizations ................................................................ 70
Supporting row selection .......................................................................... 71
Migrating to resizeable columns ................................................................ 73
Adding fixed column headers ................................................................... 74
Adding right‑click context menus .............................................................. 74
Toolbar hidden by default ............................................................................. 75
Keyboard shortcuts (hotkeys) ........................................................................ 76
Adding a shortcut or modifying existing shortcuts...................................... 76
Specifying a shortcuts mapping properties file ........................................... 77
Adding a shortcut definition in an XML file ............................................... 77
Creating or modifying a shortcuts map ...................................................... 78
Adding your custom shortcut to the component ......................................... 80
Modifying a custom control to support shortcuts ........................................ 80
Tab order configuration ................................................................................ 81
Supporting auto completion .......................................................................... 83
Configuring a custom control that can support autocompletion ................... 83
Adding a ʺStarts with” filter .......................................................................... 84
Displaying invalid actions ............................................................................. 85
Drag and drop improvements ....................................................................... 85
Preferences changes ...................................................................................... 85
Content transfer changes ................................................................................... 86
UCF performance improvements in Webtop ................................................... 86
Enabling deep export .................................................................................... 87
Turning off UCF preload ............................................................................... 87
Enabling PDF byte‑serving ............................................................................ 87
Specifying the content transfer mechanism for a group or role ......................... 88
Enabling and configuring OLE link‑scanning ................................................. 88
Allowing user selection of viewing application for renditions .......................... 89
Configuring ACS and BOCS settings.............................................................. 90
Content transfer applet removed ................................................................... 90
Style changes.................................................................................................... 90
Streamline deprecated .................................................................................. 90
Specific themes deprecated ........................................................................... 91
Feature changes ................................................................................................ 91
Deprecated components ................................................................................ 91
Supporting conditional value assistance in advanced search ............................ 92
Assigning relationships ................................................................................. 93
Lifecycle enhancements ................................................................................ 93
Chapter 8 DFC, BOF and WDK Application Migration to DFS ...................................... 95
Table of Contents
Appendix A Migrating DMCL APIs to DFC ...................................................................... 97

Overview ......................................................................................................... 97
Methods with no corresponding DFC method .................................................... 97
Methods with corresponding DFC methods ....................................................... 98
Appendix B Object Type and Property Changes for version 6.5 ................................... 107
New object types ............................................................................................ 107
Changed object types ...................................................................................... 108
Deprecated or obsolete properties .................................................................... 115
Properties added conditionally ........................................................................ 115
Deprecated or obsolete object types ................................................................. 116
Changed properties ........................................................................................ 117
Appendix C Deployment Settings in WDKbased Application Deployment .................. 119

Appendix D Changes to Webtop Cascading Stylesheets .............................................. 123
Appendix E dfc.properties ............................................................................................ 125
Overview ....................................................................................................... 125
Changes to existing key names ........................................................................ 125
dmcl.ini key migration to dfc.properties ........................................................... 128
Obsolete dmcl.ini and session configuration options ......................................... 129
Obsolete dfc.properties keys............................................................................ 131
Table of Contents
List of Figures
Figure 1. System installation order, new Documentum system .............................................. 13

Figure 2. System update order, existing Documentum system ............................................... 14
Figure 3. System upgrade scenarios ..................................................................................... 17
Figure 4. Conditional value assistance in search.................................................................... 93
Table of Contents
List of Tables
Table 1. Upgrade and migration of product components ..................................................... 11

Table 2. Upgrade strategy highlights .................................................................................. 15
Table 3. Third‑party product versions not supported in this release ...................................... 23
Table 4. Content Server and database server host worksheet ................................................ 30
Table 5. Application server host worksheet ......................................................................... 31
Table 6. Index server host worksheet .................................................................................. 31
Table 7. Client machine worksheet ..................................................................................... 31
Table 8. Customized components worksheet....................................................................... 32
Table 9. Mixed Version Configuration ................................................................................ 38
Table 10. Summary of product‑specific limitations ................................................................ 40
Table 11. Steps to migrate the Content Server from version 6 to version 6.5............................. 45
Table 12. Menu configuration elements ................................................................................ 60
Table 13. Interaction between global versus local row selection settings ................................. 73
Table 14. Hotkeys configuration elements ............................................................................ 77
Table 15. Keys that can be used in a shortcut combination ..................................................... 79
Table 16. Deprecated components ........................................................................................ 91
Table 17. Developing custom applications ............................................................................ 95
Table 18. DMCL API methods and corresponding DFC methods ........................................... 98
Table 19. New Object Types............................................................................................... 107
Table 20. Changed Object Types ........................................................................................ 109
Table 21. Deprecated and obsolete properties ..................................................................... 115
Table 22. Deprecated and obsolete computed properties ..................................................... 115
Table 23. Properties added conditionally ............................................................................ 115
Table 24. Deprecated or Obsolete Object Types ................................................................... 116
Table 25. Mandatory configuration before deployment ....................................................... 119
Table 26. Optional configuration before deployment ........................................................... 119
Table 27. Optional configuration after deployment ............................................................. 120
Table 28. Name changes for existing dfc.properties for version 6.5 ....................................... 125
Table 29. dfc.properties keys migrated from dmcl.ini file..................................................... 128
Table 30. Obsolete session configuration options ................................................................ 129
Table 31. Obsolete dfc.properties keys................................................................................ 131
Preface
This guide focuses on the steps necessary to upgrade or move an existing EMC Documentum 5.3 or
6 implementation to the new EMC Documentum 6.5 platform. This guide does not focus on new
features, except when a new feature changes or replaces existing behavior in custom applications.
Intended Audience
This guide is for EMC Documentum administrators who are tasked with upgrading or moving an
existing EMC Documentum 5.3 or 6 implementation into the EMC Documentum 6.5 platform and
developers who have created custom applications that need to move from EMC Documentum 5.3 or 6
to the EMC Documentum 6.5 platform.
Document scope
This guide shows you how to upgrade a Documentum system and migrate your customizations to
the upgraded Content Server. To assist you in the upgrade process, refer to Content Server Installation
Guide for more detailed planning information.
For migration of your customizations, this guide takes a version 5.3 or 6 implementation and has
it work essentially the same way in version 6.5. You can take advantage of some but not all of
the new features of version 6.5. This guide also shows you how to disable new behaviors where
you do not want them and activate some features that have been deprecated or ʺturned off” by
default for version 6.5. For information on how to implement new features in your custom client
application, refer to the developer documentation for the product, for example, the Web Development
Kit Development Guide for WDK.
The safe harbor releases for migration to version 6.5 are versions 6 and 5.3 SP6. If you are upgrading
from a version earlier than 5.3, you must upgrade first to version 5.3, then to version 6.5.
Additional documentation
This guide provides overview and planning information. For details on specific procedures see
these guides:
• What’s New in Documentum 6.5 SP1
• Content Server Installation Guide
Preface
• Content Server Administration Guide

• XML Store Migration Guide
• Documentum Foundation Classes Development Guide
• Web Development Kit and Webtop Deployment Guide
• Web Development Kit Development Guide
• Webtop Email Migration Guide
• Documentum Foundation Services Development Guide
• Documentum Foundation Services 6.5 Deployment Guide
Revision History
The following changes have been made to this document.
Revision History
Revision Date Description

December 2008 Added more migration information for 6.0 and 6.5 features as well as
migration to 6.5 SP1. Added a ʺsince” description to highlight version
in which a migration possibility was added.
December 22, 2008 Removed procedure for copying global registry repository objects to
a regular repository. The recommended approach is to install the
version of a global registry repository that you need.
Chapter 1
Upgrade and Migration Overview
This chapter covers in broad terms what is meant by upgrade and migration, what this guide covers,
and where you might look for additional information.
These topics are included:
• Upgrade and migration, page 11
• Understanding migration, page 12
• Order of new product installation, page 12
• Order of system updates, page 13
• Changing the database OS and version, page 17
• Changing the content store location, page 18
• Migrating XML content to the XML store, page 18
Upgrade and migration

Upgrade is available for certain Documentum applications such as Content Server. Upgrade changes
an existing installation to a new version. For information on upgrading Content Server, refer to EMC
Documentum Content Server Installation Guide.You can install a new version 6.5 Content Server and
migrate your existing repository to the new Server. For information on migrating your repository,
refer to Chapter 5, Migrating Content Server
In migration, you move your customizations to a new instance. If you install a new Content Server,
you need to migrate existing Server customizations such as DocApps or DAR files, and business
objects. Some applications such as Webtop or the WDK framework require migration rather than
upgrade. Table 1, page 11 shows the components that need migration or upgrade.
Table 1. Upgrade and migration of product components
Component Migrate Upgrade

Content Server (5.3 or higher) X X
Custom DocApp (5.3 or higher) X
SBOs X
TBOs X
Component Migrate Upgrade

Java methods X X
Custom WDK/Webtop apps X
Note: DocApps, SBOs and TBOs (BOF2 version), and Java methods bundled as SBOs will continue to
work in an upgraded Content Server. To edit them, you must create a project. Refer to the ʺManaging
Modules” chapter of Documentum Composer User Guide.
Check the installation or deployment guide for each application that you are upgrading to find
instructions for upgrading or migrating applications to the new version. For information on
migrating WDK‑based customization, refer to Chapter 7, Migrating WDK and Webtop Applications.
Before upgrade and migration, check the interoperability of all products and platforms in the system.
Refer to Chapter 4, Interoperability and Compatibility.
Understanding migration
Migrating from version 5.3 or 6 to version 6.5 is a straightforward process. Your task is to clearly
document your current configuration, plan your version 6.5 configuration, then upgrade the
individual system components in a sequence that will minimize impact on your users.
Migration can be separated into two basic tasks:
• Install and configure version 6.5 software.
• Move configurations and customizations to the new servers.
— Make necessary changes to enable any features you want to keep.
— Make necessary changes to disable any new features you do not want.
— Make necessary changes to enable any new features for existing custom components.
Most of the new features of version 6.5 are enabled by default. For those feature that are not enabled
by default, this guide explains the steps for enabling the new feature.
Order of new product installation

Figure 1, page 13 shows the order in which new Documentum system installations should be installed
and deployed. The ʺserverʺ in this diagram is the host for the RDBMS, Content Server, or Index Server.
Figure 1. System installation order, new Documentum system
Order of system updates

Upgrades to existing Documentum system installations may require uninstallation of some products
that you are upgrading. Check the installation guide for recommendations. WDK‑based clients
version 6 such as Webtop or Web Publisher do not have an installer and thus cannot be upgraded.
For those clients, you must migrate your existing customizations to a new WDK or Webtop runtime
deployment.
For upgrades that require uninstallation, perform the uninstall procedure in the reverse of the order
shown for new installations. For example, if you need to upgrade the LDAP server OS, upgrade the
Webtop application server and its OS, and then migrate your customizations to the new Webtop 6.5,
proceeding in the following order:
1. Uninstall WDK 5.x. (Skip this step if you are migrating from 6.0 to 6.5).
2. Uninstall the WDK application server.
3. Update the LDAP OS.
4. Update the application server OS.
5. Update the application server software.
6. Deploy Webtop 6.5 on the new application server instance.
7. Migrate your WDK‑based customizations to the Webtop 6.5 instance.
Figure 2, page 14 shows the order in which system components should be updated. The ʺserverʺ in
this diagram is the host for the RDBMS, Content Server, or Index Server.
Figure 2. System update order, existing Documentum system
Caution: For Content Server, host OS, or RDBMS upgrades, make sure the product version is
supported by the Content Server version you are installing. For application server OS or server
upgrades, make sure the product version is supported by the WDK‑based application you are
installing. This information is in the product release notes.
Chapter 4, Interoperability and Compatibility provides information on version compatibilities

between interoperating Documentum products. When there are version compatibility restrictions
between interoperating products, upgrading one product requires upgrading the interoperating
product(s) to the same exact version or major version family. In most cases, version compatibility
restrictions result from artifacts that a client product installs into the repository that leverage new
functionality in Content Server. In these cases, upgrading the Content Server before the client
application is especially important.
System upgrade strategies

A typical Documentum system upgrade involves development, test, and production phases. The
development phase emphasizes migration of customizations from old product versions to new
product versions, and functional testing of those customizations. The development phase only
requires deployment of the set of products required for functional testing of the customizations.
The test phase emphasizes setting up and testing of the full set of products that emulates the
production system. The suite of EMC Documentum products and versions comprising the test system
should match the suite of EMC Documentum products and versions targeted for the production
system upgrade. However, the test system can be deployed in a different environment (third‑party
products, physical or virtual hosts) from the production system.
There are two main approaches for moving from the test to the production environment:
• in‑place upgrade
• switch‑over.
For the in‑place upgrade, you shutdown the production system and perform an upgrade using the
same set of physical or virtual hosts comprising the production system. For the in‑place upgrade,
you should use the test environment as a practice environment for performing the production
system upgrade.
For the switch‑over upgrade, you provide the production system user base with different URLs, IP
addresses, and host names corresponding to a different set of physical or virtual hosts comprising
the production system. In this scenario, the test system typically becomes the production system to
which the user base is switched over.
Note: The Content Server/database component (the repository) is the only part of the system for
which there is an upgrade script. All other system product component require a fresh installation.
Note: The upgrade strategies provided in this section address upgrading all products in the system to
the same version number, resulting in a homogenous system. You can also upgrade only the Content
Server/database component (the repository) or the client component, resulting in a heterogeneous
system. Chapter 4, Interoperability and Compatibility provides additional details on mixed version
compatibilities.
Table 2, page 15 summarizes the main differences between the different strategies.
Table 2. Upgrade strategy highlights
Strategy Highlights
upgrade production system • uses existing production system hardware
• production system taken offline during

upgrade
upgrade a copy of the production system and • uses different (physical or virtual) machines
switch it over than production system
• upgrades copy of production repository
• users switched over to a different production

system
create new production system and switch it over • uses different (physical or virtual) machines
than production system
• data migrated to new production repository
• users switched over to a different production

system
Figure 3, page 17 shows the high‑level decision points involved moving from a test system to a
production system. Functional testing of new customizations and manual migration of existing
customizations into new client version is part of the develop phase.
If upgrading the repository, you need to create a copy of the production repository (see Content
Server Installation Guide) in your test system upon which you can run the upgrade. If you want to
change the database operating system, you can using the utilities available through the third‑party
database to export the database and import it into a new database instance on the different operating
system. After running the Content Server configuration program to re‑establish the connection
between the existing Content Server instance and new database instance, run the Content Server to
upgrade the entire repository.
If you are performing a fresh install, instead of an upgrade, you need to migrate your data files to new
Content Server and database instances. There are several known third‑party utilities for performing
this data migration (Crown Partners, Bluefish, FME).
An EMC Documentum system requires a global registry repository that matches the version family of
the system clients. After installing or upgrading the test system repository, install a global registry
repository matching the version of the client applications and install the client software. If your client
software versions are to remain at the same version as your production system, you can copy the
customized files from your production system directly over to the same version client instance
on the test system. If the client version software is different, you need to manually migrate your
customizations over to the new client files.
Upon completing the migration of customizations to the test system, ensure your system is running
properly by conducting your system tests. You are ready to repeat your upgrade process on the
production once all your system tests pass. Generally, you will need to take your production system
off‑line for a weekend while performing the in–place upgrade.
Note: You can use virtual machine hosts for the entire system or system components. Using virtual
machines, you can swap out pre‑upgraded system images on the same physical host to minimize
the downtime of an in‑place upgrade.
The production system contains new content and full‑text indexes generated since the repository was
copied or you migrated your data to the new repository. For the switch–over approach, manually
synchronize your content files and full–text index, then send out new URLs, IP addresses, and host
names to the end user community to affect the switch‑over.
Figure 3. System upgrade scenarios
Changing the database OS and version

When migrating your database to a new OS (host) and database version, complete the migration first,
before upgrading Content Server. Upon completion of the database migration, run the Content Server
configuration program to re‑establish the repository with the new database instance. Then upgrade
the Content Server to upgrade the entire repository.
Refer to the database vendor documentation for information on migrating repository database files
to a new database instance. The Content Server configuration program connects Content Server to
the new database host unless the database connection string, database owner name, or password
has changed.
Changing the content store location

You can move a content store to a new location. Refer to Content Server Administration Guide for
information on moving file storage areas to a new location. The database location cannot be changed.
Migrating XML content to the XML store

For information on migrating XML content to the XML store in Content Server, refer to XML Store
Migration Guide, which is available with other Content Server documentation.
Note: Prior to migrating XML content to an XML store, Content Server must be upgraded and
migrated to version 6.5.
Chapter 2
Planning System Size and Enhancing
Performance
Upgrading a system presents an opportunity to change to new host environments. The following
topics will help you plan your system size and improve performance:
• Planning the system size, page 19
• Planning for performance, page 20
• Common problems in Server performance, page 21
Planning the system size

Use the system sizing spreadsheet available on Powerlink to assist you in planning your system.
On the Powerlink site Support menu, click Technical Documentation and Advisories > Software D
Documentation > Documentum System > System Sizing.
The system sizing spreadsheet takes into account your estimated first‑year and subsequent years
input of common types of documents (Word, PPT, PDF, HTML, XML, images, MPEG), number of
light and heavy users, and number of custom types. These figures are modified by WDK and BPM
configurations. The output is the estimated number of CPUs and memory required for Content
Server, Index agent and server, WDK application server, and RDBMS server. Additional calculations
are performed for a document transformation server and BPS server if selected.
Hardware and network planning are essential for system scalability. For example, a load rate of
125,000 images per hour during an 8‑hour day could lead to a billion objects in less than 5 years. In
a regulated environment, those object may need to be online. The following considerations are
recommended from a billion‑object benchmark study with 1000 concurrent users:
• Set query resource limits in production. If a query uses large table scans, then its response time
will be in terms of hours rather than minutes given the size of the tables.
• Pre‑test every application query on a reasonably‑sized database prior to production.
• Eliminate poorly formed queries. Poorly formed queries in a small application might significantly
degrade when mixed with a larger repository.
• The full‑text index server should allocate three times more storage to the full‑text index than to
the content filestores.
Planning System Size and Enhancing Performance
To determine the system load expectations

1. Determine number and locations of functional users, including end users, administrators, and
developers.
2. Determine average and peak level data traffic (frequency and size of content transfers) for users.
3. Determine rate of ingestion of new content and magnitude of content to be migrated.
4. Determine indexing requirements for new and migrated content.
Planning for performance

There are many factors that affect performance of a Documentum system. These factors include:
• Number of users
• Frequency and duration of user sessions
• Size of files transferred by users
• Network capacity
• Storage and RAM capacity on hosts for RDBMS, Content Server, Index, application server or other
These factors are used by the System Sizing spreadsheet to help you calculate your size needs. On
the Powerlink site Support menu, click Technical Documentation and Advisories > Software D
Documentation > Documentum System > System Sizing.
In Documentum 5 systems, DMCL tracing was used to analyze performance. In Documentum 6, you
create a DFC trace. There are 34 tracing parameters in dfc.properties. Logging and tracing is fully
described in the Content Server Administration Guide. Some sample scripts to convert a trace file to
Microsoft Excel and to analyze repetitive calls are available on the EMC Developer Network.
You can monitor application server memory usage using graphical display tools for Java garbage
collection statistics such as Samurai or the IBM Diagnostic Tool for Garbage Collector. Monitor the
frequency of full garbage collection to determine whether the JVM heap size needs to be adjusted.
You can generate a Java heap dump for out of memory exceptions and analyze them with the Sun
Heap Analyzer Tool (HAT), the IBM Heap Dump Analyzer, or the Your Kit Java Profiler. Classes that
consume memory to check in a heap dump are com.documentum.web.failover.AttributeWrapper,
FormHistory, and NavigationObservable.
Common problems in Server performance

The most common problems in Content Server performance include the following:
• Application design and customization
— Chatty or redundant application code, the most common cause of failure (40% in 1995 IEEE
study)
— Complex object models
— Poor memory and cache management
• Network
— High latency due to physical or logical limitations
— Overburdened shared network
• Undersized Server resources (inadequate memory and CPU size)
• Unmanaged or underused RDBMS resources
— RDBMS not regularly monitored and tuned
— Performance and caching features not used
• Unrealistic expectations (did not use realistic benchmarks)
A highly available infrastructure must be carefully designed to fit your business requirements.
There is no single solution that fits all.
The following solutions are available to help with these problems.
High availability Documentum Server clusters — Server clusters (also called Server sets) can be
active‑active or active‑passive. In an active‑active cluster, there are two active load‑balanced web
application servers, two active sets consisting of a Content Server and connection broker,, one active
RDBMS with clustered standby server, one primary database with one synchronized standby, and
one primary content store with one synchronize standby. In an active‑passive cluster, everything
is the same except that there is only one active Server plus connection broker set, with another
set as standby.
These cluster configurations provide partial high availability coverage with increased scalability.
The clusters can be managed with Documentum Administrator.
Redundant connection brokers — Connection brokers (formerly known as docbrokers) can be

configured to automatically reroute users to Content Servers that are online. Connection brokers can
load balance user connections across multiple Content Servers using identical proximity values for
connection brokers. Refer to Content Server Administration Guide .
Replication — Replication can be configured either as read/write or read‑only.
Disaster recovery — Disaster recovery is not the same as high availability. It assumes a total loss of
the production data center. Disaster recovery servers are separate and independent from the main
center. They share no resources, and each has an independent network infrastructure for WAN
replication. Both systems have the capacity to carry out full normal and emergency workloads. They
must be maintained to be completely compatible.
Failover for disaster recovery is manual, not automatic. Clients will be affected.
Enhancing query performance — The Content Server Administration Guide describes how to
monitor query performance using the Update Statistics administration tool. It also describes how to
limit poorly‑performing subqueries for users who belong to a large number of groups.
Common problems in web application

performance
Performance guidelines for WDK‑based applications are published in the Web Development Kit
Development Guide. These include the following areas:
• Configuration
— Allocate sufficient Java memory
— Limit the number of allowable HTTP sessions
— Set a lower default page size
— Limit browser history
— Turn on value assistance caching
— Configure response compression and caching static elements
• Customization
— Implementing actions
— Creating objects
— Limiting cookie lookup
Search performance — Several search performance guidelines are available in this same guide.
Content transfer performance — The following factors may increase content transfer performance:
• Limit the number of imports per user transaction in the importcontainer configuration
• Increase UCF session timeout, for example, from 250 to 500 seconds, in WEB‑INF/classes/ucf.
server.config.xml.
• On Windows clients, turn off virus scanning for archives.
• On Windows clients, turning off virus scanning for the Documentum/ucf subdirectory of the
user’s home directory, for example, Documents and Settings\my_name\Documentum\ucf.
• On Windows clients, turning off virus scanning for the Java executable directory and subfolders.
Chapter 3
Planning the System Migration
Migrating a system requires planning. You have to know your starting point, choose a destination,
then pick the best route to get there. This chapter provides some practical advice for plotting your
course from version 6 to version 6.5 and later versions. Topics in this chapter include:
• Changes in supported environments, page 23
• Version 6.5 changes that impact Content Server upgrade or migration, page 24
• Mapping your current configuration, page 29
• Designing your version 6.5 configuration, page 32
• Planning upgrade and migration to version 6.5, page 34
Changes in supported environments

Table 3, page 23 shows third‑party product versions that were supported in version 5.3x, but are no
longer supported for version 6.x. Not every item in the table applies to every product. Refer to the
release notes for each product for detailed information on supported software environments.
Table 3. Thirdparty product versions not supported in this release
Product Category Third‑party product Version

Windows 2000 SP2 Update Rollup 1
Mac OS X 10.2.8, 10.3.9
Solaris 8
Operating System
AIX 5.2
HP‑UX HP‑UX 11
Red Hat Enterprise Linux 3.x
Oracle 9i 9.2.0.8, 10.1.0.5
Database SQL Server 2000 SP4
DB2 UDB 8.1 FixPak 14, 8.2 FixPak 7
Product Category Third‑party product Version

BEA WebLogic Server 8.1 SP6
Tomcat 5.0.28
Application Server
IBM WebSphere AS 5.1.1.13, 6.0.2.17
Oracle AS 10g 9.0.4.3, 10.1.2
Mozilla 1.7.13
Browser Netscape 7.2
Safari 1.3.2
Sun JRE 1.4.2_13
JRE (Client) Microsoft JVM 5.0.0.3810
Apple Java 1.3.1 Release 2
Java (Server) Java 1.4.x
BEA WebLogic Portal 8.1 SP6
Portal Server
IBM WebSphere Portal 5.1.0.4
Version 6.5 changes that impact Content Server

upgrade or migration
This section describes miscellaneous changes that may impact the migration to version 6.5.
Migrating objects to lightweight sysobjects (LWSOs)

Lightweight sysobjects (LWSOs) are useful if you have a large number of attribute values that are
identical for a group of objects. This redundant information can be shared among the LWSOs from a
single copy of the shared parent object. For example, Enterprise A‑Plus Financial Services receives
many payment checks each day. They record the images of the checks and store the payment
information in sysobjects. They will retain this information for several years and then get rid of it.
For their purposes, all objects created on the same day can use a single ACL, retention information,
creation date, version, and other attributes. That information is held by the shared parent object. The
LWSO has information about the specific transaction.
The administrative method, MIGRATE_TO_LITE, migrates objects to LWSOs. You specify the type to
turn into a lightweight type and the shareable parent type. One use case is to split a standard type
up so that some attributes are in the parent type and the rest are in the lightweight type. Another
case is to make the entire standard type into the lightweight type and create a brand‑new type as
the shareable parent type. After the method executes, each LWSO has its own private parent, so the
parents are not shared. At this point, you can reparent the LWSOs to shared parents and delete the
now ʺorphanedʺ parents. For full information on migrating objects to LWSOs, refer to Documentum
High Volume Server Developers Guide.
Changed behavior for attribute length

In DMCL/DFC 6 and before, if a value that is too large is set into a string attribute, the excessive data
is silently discarded with no error. For example, if you try setting a 37‑byte value into a 32‑byte
attribute, the last 5 bytes are silently discarded.
This past behavior can be considered data corruption and is often dangerous because the user
typically doesn’t know that it happened. DFC 6.5 now throws an exception if you try to overrun the
size of an attribute. To support backward compatibility DFC has a tunable preference to enable
or disable the new behavior.
You can set the preference dfc.compatibility.truncate_long_values to true to silently throw away data
as in the past. The default for this preference is false. This default is chosen to avoid data loss, even
though it is incompatible with previous versions.
If you prefer to use the pre‑6.5 behavior, set the following dfc preference in dfc.properties to T:
dfc.compatibility.truncate_long_values
When you get this new exception, the preferred solution is to carefully examine the application and
resolve the real source of the problem. Chances are that silently discarding the data is not your
desired result. If fixing the application is not an option, you can set the preference in dfc.properties to
allow truncation.
Maximum accepted string lengths in Documentum

query language (DQL) statements
The maximum length of a character string literal in a DQL statement is now governed by the
maximum allowed by the underlying relational database. In previous releases the DQL parser for
some databases enforced a smaller maximum.
Required configuration for machineonly application

access control tokens
If you are using application access control (AAC) tokens configured to be valid only when sent from
applications on particular host machines, you need to set the dfc.machine.id key in the dfc.properties
file used by those client applications. The key needs to be sent to the machine ID of the host from
which the AAC token is sent.
Audit trail entries for dm_startedworkitem enhanced

For dm_startedworkitem events, the string_4 property of the audit trail object now records the
performer of the work item.
DFC does not support linked store storage areas

In version 6.5, DFC will not support linked store storage areas. As a consequence, the following
items are deprecated:
• The dm_linkedstore object type, which represents linked store storage areas
• The dmi_linkrecord object type, which records the links between a linked storage area and file
stores
• The CLEAN_LINKS administration method, which removes orphaned link records if needed
External storage
If you are using an external storage area and the plugin is configured to execute on the client
host, you need to reconfigure the plugin to execute on the server. In version 6.5, DFC does not
support executing the plugin on the client. To configure the plugin to execute on the server, set the
a_exec_mode property of the storage object to F (FALSE). The storage object is one of dm_extern_file,
dm_extern_free, or dm_extern_url, depending on the type of external storage you are using.
DFC does not support optical storage devices

DFC does not support optical storage devices with version 6.5.
DFC Full format specifications no longer accepted

The DFC methods, such as setFile, that previously accepted a full format specification no longer do
so. As of version 6.5, those methods accept only a format name, such as txt or word, for the format
argument.
SYNC_REPLICA_RECORDS administration method

The SYNC_REPLICA_RECORDS administration method is obsolete. It was used to complete the
migration from DocPage Server 3.x to eContent Server 4.x. Neither of these server versions is
currently supported. References to this method have been removed from the documentation.
LDIF file changes

Use of ʺtrue”, ʺfalse”, ʺ1” or ʺ0” as values for Boolean properties in the LDIF file is deprecated. Also,
the list of accepted properties in the file has been updated.
Obsolete dmcl.ini keys

Two keys added in 5.3 SP4, max_file_size and max_backup_index, are obsolete in the 6.5 release.
New dfc.properties key to turn off trusted login

By default, applications running on the Content Server host are allowed to make repository
connections as the installation owner without presenting a password. This is called a trusted login. If
an application, such as Documentum Administrator, that has an explicit login dialog box is installed
on a Content Server host, a user is able to login as the installation owner without a password using
a trusted login.
This release introduces a new dfc.properties key to turn off trusted logins if you do not want to allow
trusted logins through such applications. The key is:
dfc.session.allow_trusted_login
Setting this key to false requires users to always provide a password, even when logging in as the
installation owner.
DQL changes
The following are changes to the DQL.
POSITION keyword no longer supported
The POSITION keyword, previously supported in SELECT queries against the fulltext index, is
no longer supported.
CHANGE...OBJECT statement
Previously, using the CHANGE...OBJECT statement was restricted to custom object types. With this
release, the statement may be used to change any type so long as the remaining restrictions as listed
in the DQL Reference manual description of CHANGE...OBJECT are not violated.
DQL date literals enhancement
You can now specify ’utc’ in a date literal in a DQL statement. The new syntax for date literals is:
DATE('date_value[utc]' [,'pattern'])
You can define date_value using any of the valid character string formats representing a date, or it can
be one of the keywords that represent dates.
If utc is included, Content Server assumes that the specified date_value is UTC time. The specification
of utc is not case sensitive.
Behavior change after failed save or checkin

In version 6.5, if a save or checkin of an object fails, DFC will revert the object automatically before
returning the object to the application issuing the save or checkin. Reverting the object removes any
changes made to the object before the attempted save or checkin. The application must then reapply
any changes made prior to the save or checkin before reattempting the save or checkin operation. This
behavior is different from how failed saves or checkins were handled by the prior DMCL. The DMCL
in prior releases simply marked the object as in an error state and returned it to the application.
Trace method migration

In version 6.5, the tracing implementation for client‑side tracing is changed and enhanced. The trace
method is replaced with the IDfSession.setServerTraceLevel method. For complete details, refer to the
Content Server Administration Guide.
The Trace API method in existing scripts will continue to work, but its implementation is changed.
In version 6.5, the level 0 turns tracing off and any nonzero value turns tracing on. If a file name is
specified on the Trace method command line, the trace information is recorded in that file. If no file is
specified, the trace information is placed in the file specified in the dfc.properties file, in accordance
with the new tracing implementation.
New server.ini key

Version 6.5 introduces a new server.ini key for Windows platforms. The key allows you to configure
the maximum size of the listener queue for Content Server connection requests.
Content Server creates a socket listener for incoming connection requests with a maximum backlog
set to 200 by default. On Windows platforms, you can reset that maximum if needed. To do so, set the
listener_queue_length key in the server.ini file. Set the key to a positive integer value. Content Server
passes the specified value to the Windows Sockets call listen().
enable_workitem_mgmt obsolete
The enable_workitem_mgmt key controls whether permissions to perform certain workflow actions
are enforced. The affected actions are:
• Acquiring a work item
• Delegating a work item
• Halting and resuming a running activity
• Changing a work item’s priority
If the key is set to T (TRUE), any user can perform those actions. The key is F (FALSE) by default.
Mapping your current configuration

The following system configuration diagrams and sample worksheets provide a starting point for
documenting the infrastructure of your current system. You might already have similar diagrams
from which you can get much of this information. If you do not, be sure to keep a copy of your
version 6 plan to help with future migrations. Take the time to verify that any existing diagrams
reflect the current configuration.
Complete one copy of the table below for each server host and client configuration used in your
current system, for example, Content Server, fulltext indexing server, ECI server, application server.
Table 4. Content Server and database server host worksheet
Item Value
Hardware and
Processors
Memory
Operating system and
version
Content Server version
RDBMS and version
Repository size Number of objects:
Storage space required:
Global Registry? [ ] Yes [ ] No

Java/JRE version
DFC version
Other product version
Table 5. Application server host worksheet
Item Value
Hardware and
processors
Memory
version
HTTP Server version
Java version
DFC version
Other product and
version
Other product and
version
Other product and
version
Table 6. Index server host worksheet
Item Value
Hardware and
processors
Memory
version
HTTP server version
Java version
DFC version
Other product and
version
Other product and
version
Other product and
version
Table 7. Client machine worksheet
Item Value
version
Browser and version
Java version
Other product and
version
Other product and
version
Other product and
version
Table 8. Customized components worksheet
Product Customized Customization Customization Disposition

Components type Description
• 6.5 Compatible
• Needs changes
• Obsolete
• 6.5 Compatible
• Needs changes
• Obsolete
• 6.5 Compatible
• Needs changes
• Obsolete
Designing your version 6.5 configuration

This section discusses some of the design decisions you need to make before implementing your
version 6.5 configuration. Departmental systems are configurations where the Content Server, RDBMS,
and global registry all reside on the same host machine. Enterprise systems are configurations
containing multiple Content Servers, data repositories, and distributed services to improve
performance in high traffic or geographically disbursed environments.
Addressing hardware concerns

Verify that the hardware you are currently using will continue to meet your needs for the foreseeable
future. In particular, if you have been hosting more than one server on a single machine, for example,
Content Server and an application server, this is a good time to divide the functions between two or
more server hosts to boost performance.
Upgrading thirdparty software

Prior to migrating to version 6.5, verify that the third‑party software you are currently using with
version 6 is still supported, and upgrade to supported versions as necessary. See the What’s New in
Version 6.5 document for a list of supported software.
Planning for global registries

You need to designate one of the repositories in your version 6.5 system as the global registry. The
global registry is a central location used to store common objects used by all repositories, such as SBO
(Service‑based Business Object) network locations, BOCS (Branch Office Caching Service) settings,
and user settings. You need to decide which of your repositories will be enabled as the global registry.
If you already have a version 5.3 or 6 global registry, you can use it with a repository that you
upgrade to 6.5. Refer to Table 10, page 40 for compatible versions of Content Server, global registry,
and client applications.
During repository configuration, you are prompted to choose one of the following options:
• Use the current repository as a global registry
You need to provide a user login name and password for the global registry user in the repository
you are currently configuring. Record the login name and password; you will use this login name
and password to configure other repositories in your system to allow them to access the global
registry. The local DFC instance is also configured to access this global registry.
• Specify a different repository as the global registry
You need to provide the repository name and the login credentials (user login name and
password) of the global registry user in that repository. The DFC instance on the current host
is configured to access the remote global registry repository.
• Do later
If you choose this option, you can delete the dfc.bof.registry.repository, dfc.bof,.registry.username,
and dfc.bof.registry.password from the dfc.properties file and rerun the DFC installer on this host
in order to designate the global registry repository at a later time. Version 6.5 requires a global
registry, so clients should not connect to the system until the global registry is configured.
Regardless of whether you designate the repository as a global registry, the global registry user is
created all repositories. The global registry user, who has the user name of dm_bof_registry, is
the repository user whose account is used by DFC clients to connect to the repository to access
required service‑based objects and user information. The user has read access to objects in the
/System/Modules only.
• If you configure the repository as a global registry, you provide the user login name and password
for the user and the user state is set to Active.
This can be any arbitrary user login name and password. Do not use the repository owner’s
credentials or the installation owner’s credentials.
• If you do not configure the repository as a global registry, the user is created with a default value
for the login name and the user state is set to Inactive.
If you later enable the repository as a global registry, use Documentum Administrator to change
the user state to Active and provide the user with a user login name and password that you
choose. Refer to the Content Server Installation Guide for instructions on enabling the repository
as a global registry.
Mapping your version 6.5 configuration

For each server host and client configuration, complete a planning document. You can use the same
forms used for mapping your current configuration (see Mapping your current configuration, page
29).
Planning upgrade and migration to version 6.5

Now that you know your starting point and your destination, you can choose the best upgrade
and migration path. The recommended configuration is a homogeneous version 6.5 system. The
migration paths described below allow your applications to continue working and minimize impact
on your users, but your users will not get the full benefits of version 6.5 features until the migration is
complete.
Setting up a test environment

Before migrating your production system, EMC Documentum recommends that you set up a test
environment that includes the same hardware, RDBMS, and software configurations as your
production system, including a copy of your production repository. This allows you to practice
migrating your systems, as well as troubleshoot any migration problems before committing changes
to your production system.
Clientfirst migration
If your system uses only Webtop, DFS, custom DFC, or custom WDK clients, you have the option of
migrating the client applications first. Refer to the installation or deployment guide for the client
application for detailed instructions.
ACS and BOCS version compatibility and migration — Parallel streaming from ACS will be used
only if both ACS and UCF (WDK or DFS applications) are version 6.5. Parallel streaming from BOCS
will be used only if ACS, BOCS, and UCF are version 6.5.
Note: When you upgrade the BOCS to version 6.5, you must update the BOCS version specification
in the global registry using Documentum Administrator. For BOCS 6.0, specify the version as 2.0. For
BOCS 6.5, specify the version as 2.1.
WDK clients compatibility and migration — WDK‑based clients are compatible with version 5.3
and version 6 Content Server. Some WDK version 6.5 features will be available, such as those that run
in JavaScript on the client. Other features will not be available until you complete the migration to
version 6.5, such as lightweight sysobjects, data partitioning, batch processing and scoping..
These are the steps to migrate from version 5.3 or 6 to version 6.5, migrating the clients first.
1. Upgrade the application server and client browsers.

2. Enable the global registry in a version 6 repository in order to support version 6 client features
that require a global registry. Refer to Documentum Content Server Installation Guide for
instructions. Version 6.5 clients with a version 5.3 global registry is not supported.
3. Upgrade the Content Servers in place.
4. Configure one Content Server as the version 6.5 global registry. If you had a global registry in
version 6, you can upgrade that server in place using the same settings.
Chapter 4
Interoperability and Compatibility
Unless otherwise noted, any 5.3 SP2 (or greater SP) or 6.x SPx product can coexist with any other 5.3
SP2 (or greater SP) or 6.x SPx product on the same host. Mixed versions (5.3 SPx with 6.x SPx) cannot
share the same application instance.
In addition, unless otherwise noted, all 6.x SPx products can interoperate with all other 6.x products.
Interoperability takes place when different client applications perform operations on the same object
instance in a repository.
Mixed version compatibility, page 37, provides detailed information for determining compatibility
between different version client applications and Content Server. The Cross‑product dependencies and
interoperability section of each product’s release notes provides a list of products depended on by a
product and additional products with which a product generally interoperates.
Mixed version compatibility

Under most conditions, 5.3 SP2 (or greater SP) or 6.x SPx clients can work with Content Servers
that are from a different major version family, 6.x SPx or 5.3 SP2 (or greater SP), respectively. This
kind of system configuration is referred to as a mixed version configuration. You might want to set
up a mixed version configuration when you want to migrate only the client or server side of your
production environment to 6.5. In a mixed version configuration, most customers migrate the server
side of their production environment first.
Note: You can also have a mixed version configuration between different products in the same
version family (6.0, 6.0 SP1, and 6.5, for example).
In a mixed version configuration, functionality provided by the higher version product is generally
not available to the lower version product. The mixed version products work fine together, but the
new functionality provided by the higher version product is not exposed or it is disabled. In some
cases (see Guidelines for determining mixed version compatibilities, page 38 and Product‑specific
limitations, page 40), new functionality provided by the higher version product may cause a lower
version product not to work properly.
Guidelines for determining mixed version

compatibilities
The client application, global registry, and Content Server must be 5.3 SP2 or higher. The client
application major version must match the major version of the global registry. The client application
can then connect to any 5.3 SPx or 6.x SPx Content Server. For example, 5.3 SP2 client applications
require a 5.3 SPx global registry to work with a 5.3 SPx or a 6.5 SPx Content Server. Similarly, 6.5
SPx client applications require a 6.5 SPx global registry. They can then connect to a 5.3 SPx or 6.x
SPx Content Server.
Client applications also contain a combination of artifacts (modules, aspects, Type‑Based Objects
(TBOs), or Service‑Based Objects (SBOs)) that contribute to mixed version compatibility or
incompatibility, depending on how these artifacts were developed. Table 10, page 40 lists mixed
version compatibilities and limitations between Documentum client products and Content Server
for the 5.3 SPx and 6.x SPx versions.
In a typical deployment, the application server contains the modules, aspects, and TBOs for a client
application while the global registry contains the SBOs. The application server also contains a version
of Documentum Foundation Classes (DFC), typically installed by the client application. The version
of DFC is the same version as the client application.
For 5.3 SPx client applications, always compile the modules, aspects, and TBOs using the same
JDK version (1.4) used by the Documentum Foundation Classes (DFC) on the application server.
Compiling these artifacts with a higher version JDK (1.5, for example) is not supported, because object
binaries compiled with JDK 1.5 are not guaranteed to run on JDK 1.4.
For 6.x SPx clients applications, compile 6.x SPx artifacts with JDK 1.5, because there might be JDK 1.5
specific calls in the artifact code preventing the artifact from successfully compiling with JDK 1.4.
However, if a module, aspect, or TBO can be successfully compiled using JDK 1.4, then it can run
against DFC 6.x SPx on an application server running JDK 1.5. For SBOs, use JDK 1.4 for 5.3 SPx client
applications and JDK 1.5 for 6.x SPx client applications.
Table 9, page 38 summarizes which combinations of client application, DFC and JDK versions on the
client application server, global registry version, and JDK versions of the modules, aspects, TBOs and
SBOs enable access to Content Server 5.3 SPx or 6.x SPx.
Table 9. Mixed Version Configuration
Client Application JDK Global JDK SBOs Content

Application Server Modules/ Registry Compiled Server
Version Environment Aspects/TBOs Version With Version
Compiled
With
5.3 SPx DFC 5.3 SP2 None 5.3 SPx None 5.3 SPx, 6.x
(or greater SP) SPx
JDK 1.4 JDK 1.4
Note: None indicates that the client application does not have any modules, aspects, TBOs, or SBOs.
Client Application JDK Global JDK SBOs Content

Application Server Modules/ Registry Compiled Server
Version Environment Aspects/TBOs Version With Version
Compiled
With
JDK 1.4
JDK 1.5 5.3 SPx None No valid
Content
JDK 1.4 Server
versions
6.x SPx DFC 6.x SPx None 6.x SPx None 5.3 SPx, 6.x
SPx
JDK 1.5 JDK 1.4, JDK JDK 1.5
1.5
Note: None indicates that the client application does not have any modules, aspects, TBOs, or SBOs.
Productspecific limitations
If a product is not included in this section, then it can be deployed in a mixed version configuration as
described in Table 9, page 38.
Based on the guidelines in Guidelines for determining mixed version compatibilities, page 38, Table
10, page 40 summarizes whether a specific client product version works with a 5.3 SP2 (or greater SP)
repository and a 6.x SPx repository. Unless otherwise noted, 5.3 SPx indicates any of the 5.3 service
packs, SP2 through SP6, and 6.x SPx indicates 6.0, 6.0 SP1, or 6.5.
Note: Many products consist of multiple installed components (WAR file, DAR file or DocApp, for
example). Mixing versions of these components (6.0 WAR file and 6.5 DAR file, for example) for a
particular (6.5) product version is not supported.
Table 10. Summary of productspecific limitations
Product Product Version Supported Unsupported Notes and

Content Server Content Server Exceptions
Versions Versions
Archiving 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Services for SAP
Business Activity 5.3 SPx 5.3 SPx 6.x SPx
Monitor Note 1
6.x SPx 6.x SPx 5.3 SPx
Content 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Intelligence Note 5
Services
Content Services 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
for SAP
Content 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Transformation
Services
Digital Asset 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Manager
Documentum 5.3 SPx 5.3 SPx 6.x SPx
Administrator 6.x SPx 5.3 SPx, 6.x SPx None
Documentum 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Collaborative Note 3
Services
Documentum 5.3 SPx 5.3 SPx, 6.x SPx None
Compliance 6.5 6.0 SP1 or 6.5 5.3 SPx, 6.0 Note 2
Manager
Document Image 6.x SPx 6.x SPx 5.3 SPx
Note 1
Services
File Share 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Services (FSS)

Versions Versions
Forms Builder 5.3 SPx 5.3 SPx 6.x SPx
Note 1
FTP Services 5.3 SPx 5.3 SPx 6.x SPx
Physical Records 6.x SPx 6.x SPx 5.3 SPx Note 2
Manager
Process Builder 5.3 SPx 5.3 SPx 6.x SPx
Note 1
Process Engine 5.3 SPx 5.3 SPx 6.x SPx Note 1
Process 6.5 6.x SPx 5.3 SPx Note 1
Integrator
Process Services 5.3 SPx 5.3 SPx, 6.x SPx None
for SAP 6.0, 6.0 SP1 5.3 SPx, 6.x SPx None
6.5 5.3 SP5, 6.x SPx 5.3 SPx (except
SP5)
Records Manager 5.3 SPx 5.3 SPx, 6.x SPx None
Note 2
Retention Policy 5.3 SPx 5.3 SPx, 6.x SPx None
Services Note 2
Site Caching 5.3 SPx 5.3 SPx 6.x SPx
Services 6.x SPx 6.x SPx 5.3 SPx
TaskSpace 6.x SPx 6.x SPx 5.3 SPx Note 1
Web Publisher 5.3 SPx 5.3 SPx 6.x SPx
Webtop 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None Note 4
WebDav Services 5.3 SPx, 6.x SPx 5.3 SPx, 6.x SPx None
Note 1: Business Activity Monitor, Document Image Services, Forms Builder, Process Builder,
Process Engine, Process Integrator, and TaskSpace must be the same exact version (6.5, for example)
as each other and the Content Server, when all are using the same repository.
Note 2: Physical Records Manager, Records Manager, and Retention Policy Services must be
the exact same version (6.5, for example) as each other when all are using the same repository.
Similarly, any other client (Webtop, for example) that interoperates with objects created by these
products, must be at the same version.
Note 3: Documentum Collaborative Services (DCS) 6.x SPx requires manual installation of a DAR
file in order for Content Server to provide full support for new features in the 6.x SPx DCS client.

Versions Versions
Once this DAR file is installed, only 6.x SPx versions of the DCS client (and other clients) are
supported by the 6.x SPx Content Server.
Note 4: Queue management is not supported when using Webtop 5.3 SP2 (or greater SP) clients
against a 6.x SPx Content Servers in which the 6.x SPx BPM TBO has been installed.
Note 5: CIS 5.3 SP2 (or greater SP) and 6.0 require the same exact version of Documentum
Administrator. CIS 6.x SPx requires Documentum Administrator 6.x SPx.
Cross product dependencies

Note: EMC recommends that you use DARs instead of DocApps whenever possible.
Webtop, Digital Asset Manager

The WDK‑based application WAR file contains scripts to upgrade a 5.3 SP2 (or greater SP) repository
for subscriptions. Run the DQL script subscriptionInstall.dql that is located under the root web
application directory, in webcomponent/install. Taxonomy Manager support scripts are located in
the directory webcomponent/install/admin/tm.
Extended Search
5.3 SPx cannot access Extended Search functionality in a 6.5 Content Server.
Chapter 5
Migrating Content Server
If you are installing a new instance of Content Server 6.5 and migrating data from a previous version
on a separate host, you need to follow a procedure somewhat different from an upgrade.
This chapter addresses any variation from the basic scenario to known issues surrounding the
configuration of your version 6.5 server.
• Rebuilding or upgrading fulltext indexes, page 46
• Configuring login tickets for backward compatibility, page 46
• Using DQL to migrate content to an XML Store, page 47
• Migrating custom Content Server methods, page 47
• Migrating DocApps and BOF2 modules, page 47
Migrating Content Server version 5.3 or 6 to 6.5 occurs in three phases:
• Back up your existing data.
• Run the version 6.5 installer.
• Configure the new Content Server to use your existing repository.
These are the recommended steps for preparing and migrating your version 6 Content Server to
version 6.5.
Table 11. Steps to migrate the Content Server from version 6 to version 6.5
Step Documentation
1. Back up your repository. Several third‑party tools are available for
backup.
2. Clean up your repository. Content Server Administrator’s Guide, Content
Repositories chapter, ʺCleaning up repositories.”
4. Run the Consistency Checker utility. Content Server Administration Guide, Tools and
Tracing chapter, ʺConsistency Checker.”
5. Fix any errors identified by the Consistency
Checker.
6. Back up your cleaned, consistent repository.
7. Install Content Server. See Content Server Installation Guide.

8. Configure Content Server to use your existing See Content Server Installation Guide.
repository.
Rebuilding or upgrading fulltext indexes

If you are migrating from version 5.2.5 to version 5.3, then to version 6.5, you need to rebuild the
fulltext index only once, when you move to 5.3. You do not have to rebuild fulltext indexes when you
subsequently migrate from 5.3 to version 6.5.
If you are upgrading from 5.3 or 5.3 SP1, you need to rebuild your fulltext indexes.
If you are using fulltext indexing, are upgrading from 5.3 SP2 or SP3 and have applied the Get Well
4.3.1 hot fix, or you are upgrading from 5.3 SP4 or later, you do not need to rebuild your fulltext
indexes to migrate to version 6.5.
Refer to the Content Server Administrator’s Guide for fulltext rebuilding and upgrade procedures.
Configuring login tickets for backward

compatibility
In an environment that includes mixed versions of Content Server, the login tickets generated by
a particular Content Server might not be accepted by a Content Server at another version level. A
version 6.5 Content Server can accept a login ticket generated from any Content Server, regardless
of the server’s version level. A pre‑5.3 SP4 Content Server cannot automatically accept login tickets
generated by a Content Server at version 5.3 SP4 or higher. Also, a 5.3 SP4 or 5.3 SP5 Content Server
cannot automatically accept login tickets generated by a version 6.5 Content Server.
When you are upgrading a production environment with multiple repositories or multiple Content
Servers for one repository, there will likely be intervals when the Content Servers are at differing
levels. To ensure that login tickets generated by a Content Server are backward compatible, set the
server_login_ticket_version key in the server.ini file:
• Set the key to 1 to generate login tickets acceptable to a pre‑5.3 SP4 Content Server
This setting is only valid on versions 6.5, 5.3 SP4, and 5.3 SP5 Content Servers.
• Set the key to 2 to generate login tickets acceptable to a 5.3 SP4 or 5.3 SP5 Content Server
This setting is only valid on version 6.5 Content Servers.
• Set the key to 3 to generate login tickets acceptable to version 6.5 Content Servers.
This setting is only valid on version 6.5 Content Servers.
The key defaults to 3 if not set.
Using DQL to migrate content to an XML Store

You can migrate XML files from an existing Documentum file store to an XML Store, between XML
Stores, and out of an XML Store using an update DQL query. To migrate:
• Run DQL Query as UPDATE dm_sysobject OBJECTS set a_storage_type = ’xhive_store_01’ where
a_storage_type = ’filestore_01’ and a_content_type = ’xml’
Note: This procedure migrates only the current version of the object.
Migrating custom Content Server methods

After Content Server upgrade, you must run the configurator tool to configure the internal Java
method server. The configurator will write the location of your Java methods to the internal
method server. The location of the methods directory is written to the file web.xml in the method
server deployment directory, for example, C:\Documentum\jboss4.2.0\server\DctmServer_
MethodServer\deploy\ServerApps.ear\DmMethods.war\WEB‑INF:
<initparam>
<paramname>methodlocation1</paramname>
<paramvalue>C:\Documentum\dba\java_methods</paramvalue>
</initparam>
Your custom Content Server methods located in %DOCUMENTUM%\dba\java_methods (Windows)

or $DOCUMENTUM/dba/java_methods (UNIX and Linux) will continue to work. If you are
migrating to a new Content Server installation, copy the methods from this directory to the same
folder location in the new Content Server installation.
Migrating DocApps and BOF2 modules

BOF version 2 modules and DocApps do not need to be changed when you upgrade a Content
Server 5.3.x or 6.0 to 6.5. If you want to make changes to a DocApp or module on an upgraded 6.5
Content Server, create a project in Composer and add your BOF2 modules or DocApp. Refer to
Documentum Composer User Guide for full instructions on working with modules and Documentum
Archive (DAR) files.
Use the Composer project migration utility to migrate a DocApp or a DocApp archive to a DAR file:
New > Project > Documentum Project > Documentum Project from Repository DocApp. Composer
will generate a DAR file that can be installed in a new instance of Content Server or edited in place
in an upgraded Content Server instance. Complete instructions are in the ʺMigrating DocApps”
chapter of the Composer User Guide.
If you want your version 6.5 BOF2 modules to be used by DFC 5.3 clients, you need to:
1. Compile them for a Java 1.4.x target <javac target=1.4> to make them compatible with older
virtual machines.
2. Compile them against DFC 5.3 rather than DFC 6.5 to ensure they do not accidentally reference
new interfaces.
To migrate custom Business Objects in an environment of 5.3 SP6 clients that access a version 6.x
Content Server, do the following:
• SBO
Install your 5.3 DocApps in the 5.3 SP6 global registry. Do not upgrade this global registry.
• Module or TBO
Make sure your code will work with DFC 5.3 SP6. It must compile with JDK 1.4.2 and must not
use any classes or methods that are new in DFC 6.x.
Chapter 6
Migrating DFC Customizations
The Documentum Java‑Com Bridge (DJCB) and PIA are deprecated as of version 6.
The following topics describe how to migrate customizations of DFC to version 6.5.
Java class changes

New classes, methods and class members as well as changed or deprecated methods and members
are documented in diff files available on Powerlink with the current migration guide. There are diff
sets comparing DFC classes of version 5.3 SP6 to 6.5 SP1 and 6.0 SP1 to 6.5 SP1.
Configuring DFC for native IPv4 operations

Since: version 6.5
To configure DFC installed on a dual‑stack machine for native IPv4 operation, perform the following:
Mitem
• Specify a host with an IPv4 address in the dfc.properties file as the value of dfc.host.name.
• Disable the dual‑stack operation for Java Virtual Machine.
A custom property setting in the Java Virtual Machine determines the communications protocol
used by the operating system. By default, this custom property (java.net.preferIPv4Stack) is
set to False to support dual‑stack communications. To configure a host for native IPv4, set this
property to True.
Migrating customizations to Business Objects

Since: version 6
The Business Object Framework (BOF) provides a framework for your customizations that can be
accessed from various client applications and service‑based architecture. The following kinds of DFC
customizations should be migrated to Business Objects:
• Core custom action execution logic
• Process automation, for example, creating renditions during checkin, creating workflows after
checkin
• Custom data handlers
• Helper methods in utility classes, for example, attaching or detaching a lifecycle, promoting or
demoting a document
• Business validation, for example, permitting an export operation
Examples of BOF classes
Updating attributes of an object based on its location — Generally, you organize documents in a
meaningful folder hierarchy. You can also set one or more attributes on an object based on the
location in which it is imported or created. The BOF module contains a type‑based business object
(TBO) that sets the attribute after the operation, based on the parent folder.
Attaching a lifecycle during a checkin operation — A service‑based business object (SBO) can be
used to perform an operation after checkin, such as attaching a lifecycle. Other possible operations
include promoting a workflow or creating a rendition.
Migrating DMCL API calls to DFC API calls

Since: version 6
The C++ DMCL API has been replaced with the Java‑based DFC API. These core changes, while
extremely significant, are largely transparent to the DFC user. C++ applications that interact directly
with the DMCL continue to work as a copy of DMCL continues to be provided. New Documentum 6
features are not available through DMCL, however.
For a map of DMCL APIs to DFC APIs, refer to Appendix A, Migrating DMCL APIs to DFC.
Search service
The DFC search service replaces prior mechanisms for building and running queries. You can use the
IDfQuery interface, which is not part of the search service, for simple queries.
The search service provides the ability to run searches across multiple Documentum repositories and,
in conjunction with the Enterprise Content Integration (ECI) Services product, external repositories
as well. The Javadocs for the com.documentum.fc.client.search package describe how to use this
capability.
Full format specifications no longer accepted

Since: version 6
DFC methods such as setFile that previously accepted a full format specification no longer do so.
Those methods accept only a format name, such as txt or word, for the format argument.
Character string handling improved

Since: version 6
In previous releases, if you attempted to set a character string property with a value that exceeded
the defined length of the property, DFC quietly truncated the value to the maximum length of
the property and then set the property. For Documentum 6, DFC throws an exception instead of
truncating the value and setting the property.
To use the pre‑Documentum 6 behavior, set the dfc.compatibility.truncate_long_values property in
dfc.properties file to T. This property is false by default.
Aspects, a new BOF module type for

developers
Since: version 6
Documentum 6 supports aspects, a new framework for extending object behavior and attributes.
Aspects are a type of BOF entity that can be dynamically attached to object instances in order to
provide fields and methods beyond the standard ones for the object type. The extended behavior
can include functionality that applies to types across the object hierarchy. For example, an aspect
could label objects as retainable or web‑viewable, and this single aspect could be applied to multiple
distinct object types.
Aspects can speed development and improve code reuse, because the extended attributes and
behavior do not alter the underlying type definitions. You can create aspects and associate them
with an individual object or an object type. If you associate them with an object type, the aspect is
automatically associated with each new object of the specified object type. Aspects can also have
properties defined for them. Properties defined for an aspect appear to users as if they are defined
for the object type of the object to which the aspect is attached.
JMX management of DfPreferences and

dfc.properties
In J2EE DFC‑based applications, active settings in DfPreferences and persistent settings in
dfc.properties are managed by JMX agent and Managed Bean (MBean) components. The settings are
displayed in Documentum Administrator, which separates active settings (in DfPreferences) from
persistent settings (in dfc.properties).
DFC deployment
DFC is deployed with each application or product that requires it, using a standard J2EE deployment
strategy. In the J2EE deployment process, the dfc.jar file and related files are packaged in a product’s
WAR file so that each DFC instance can have its own DFC configuration.
Configuration for application access control

tokens
If you are using application access control tokens configured to be valid only when sent from
applications on particular host machines, you must set the dfc.machine.id key in the dfc.properties
file used by those client applications. Set the key to the machine ID of the host from which the
AAC token is sent.
Setting the maximum number of results per

source
The maximum number of results to retrieve per source by a query search is set in the parameter
maxresults_per_source of the DFCfull.properties as follows:
dfc.search.maxresults_per_source=350
Chapter 7
Migrating WDK and Webtop
Applications
The following topics describe how to migrate your customizations to WDK or Webtop 6.5:
• Overview, page 53
• Updating and migrating email messages, page 54
• Java class changes, page 55
• Application framework changes, page 55
• Application‑wide changes, page 62
• Content transfer changes, page 86
• Style changes, page 90
• Feature changes, page 91
The migration topics are ordered by release version, with the latest release changes first.
Overview
Deploy and configure applications based on WDK or Webtop 6.5 on an application server instance
different from your existing installation and then migrate any customizations to the 6.5 deployment.
Do not migrate any of your existing customizations that new 6.5 functionality can replace. To enable
full 6.5 functionality, you will also need to upgrade the DocApps/DARs in the repositories (including
global registries) that your WDK application accesses. For more information, refer to Chapter 5,
Migrating Content Server.
Effort estimates are based on the average time to perform a configuration (simple effort, measured in
hours) or a custom class (complex effort, measured in days). For multiple customizations of the same
type, multiply the effort estimate by the number of customizations to migrate. For example, if you
have five custom actions for which to add shortcuts, you multiply the simple effort times 5. It is hard
to give an exact time estimate, because it is based on your engineers’ familiarity with WDK and the
scripting or programming tasks required to perform the configuration or customization.
Migrating WDK and Webtop Applications
To migrate WDK and Webtop applications from version 5.3 or 6.0 to 6.5:
1. Back up your customizations, if you have made changes in any of the following:
• Web application customizations:
— APP_SERVER_ROOT/webtop/custom directory
— Compiled custom classes in APP_SERVER_ROOT/webtop/WEB‑INF/classes directory
— Custom tag libraries in the
APP_SERVER_ROOT/webtop/WEB‑INF/tlds directory
See Web Development Kit and Webtop Deployment Guide.
• Application server startup file
Note: Do not migrate settings that the WDK installer added to your application server
startup file.
2. If you have a DFC 5.x application running in the same instance as your 6.5 application, you
must uninstall the DFC 5.x application. For uninstall procedures, refer to the 5.x product
documentation—specifically, the Web Development Kit and Webtop Deployment Guide.
3. If necessary, update your application server software.
Refer to the supported application servers in the release notes for the WDK‑based product.
4. Make the required setup changes to your Webtop WAR file, then deploy the Webtop WAR file.
5. Copy the contents of your previous /custom directory, to the /custom directory on your new
server. Copy custom Java classes and TLDs to the WEB‑INF folder on your new server.
6. Recompile your custom 5.3 classes to ensure that the custom code still works.
7. Migrate your customized features if they are not present in the 6.5 application. Disable any new
features that conflict with your customizations.
Migration is described elsewhere in this guide.
8. Test and fix your web application.
9. Deploy your web application to your production application server.
Updating and migrating email messages

Webtop 6.5 and Documentum 5.3, 6.0, and 6.5 repositories can now support dm_message_archive
objects in the proprietary EMCMF format. This format encapsulates the content, metadata, and
attachment information as a single unit of information.
The following features have been enhanced to support the EMCMF format:
• Import: When a user imports an email message (.msg), the email message converts to EMCMF
format and is stored as a dm_message_archive type. All attachments in the email are imported
and related to the email.
• Export: When a user exports an EMCMF object, the object converts to native email format (.msg)
for viewing by Microsoft Outlook.
• View Properties and Listing pages: The Properties and Listing pages have been enhanced to show
email‑centric attributes such as To, From, Date Sent and Subject.
• Transform: EMCMF messages can be transformed to HTML, XML, or PDF.
Existing email messages of the dm_email_message object type (and its subtypes) and the msg format
must be migrated to the dm_message_archive type (EMCMF) or one of its subtypes. In addition, now
in 6.5, the dm_message archive message_id attribute has been lengthened from 24 to 42 characters.
EMC Documentum provides utilites to perform the migration of dm_email_message objects to
dm_message_archive objects. For instructions on running these utilities, refer to Webtop Email
Migration Guide.
Java class changes

New classes, methods and class members as well as changed or deprecated methods and members
are documented in diff files available on Powerlink with the current migration guide. There are diff
sets comparing WDK and Webtop classes of version 5.3 SP2 to 6.5 SP1, 5.3 SP6 to 6.5 SP1, 6.0 to 6.5
SP1 and 6.0 SP1 to 6.5 SP1.
Application framework changes

This section describes changes that affect how you design your custom application. These changes
may not require migration, but migration is recommended to benefit from these improvements in
application design support.
Configuring new accessibility features and timeout

warnings
Since: version 6.5 SP1
Effort: moderate configuration, multiple JSP pages unless otherwise noted
Several enhancements to the WDK infrastructure support accessibility and section 508 compliance.
Your customizations should take advantage of these additions if your application is compliant with
section 508.
Autofocus — The form tag has an attribute ʺautofocusneeded” that causes the first focusable control
on the page to receive focus. By default this attribute value is false, since all forms in a multi‑frame
view cannot have focus. Set to true for the frame that should receive focus. For example, in Webtop
the JSP page app_general_preferences_ex.jsp calls for autofocus, so that when the preferences
component is launched from the titlebar component, the general preferences tab receives focus:
<dmf:form autofocusneeded='true'>
Enhanced control labels — When a control receives focus, the tooltip or tooltipnlsid attributes
render the HTML title attribute. If this information is not sufficient for the screen reader, additional
context can be provided by a label tag that is associated with the control that needs context. Specify
the label using the associatedcontrolid attribute on the context control. In the following example, a
label control specifies the text for which it provides information:
<dmf:label nlsid="MSG_NAME" associatedcontrolid="object_name"/>
<dmf:text id="object_name" tooltipnlsid="MSG_NAME_DESCRIPTION"/>
Radio, link, datasortlink, datadropdownlist, and checkbox controls can also have a prefix and/or
postfix label to provide context. For these controls, the prefix or postfix label is specified as an
attribute on the control itself. In the following example, each radio control specifies a prefix label that
provides additional context:
<dmf:label nlsid="MSG_APPLICATION"/>
<dmf:radio nlsidid="MSG_APP_1" prefixassociatedlabelnlsid="MSG_APPLICATION_1"
NAME="app1" GROUP="theme"/>
<dmf:radio nlsidid="MSG_APP_2" prefixassociatedlabelnlsid="MSG_APPLICATION_2"
NAME="app2" GROUP="theme"/>
Note: The context label associated with a control will override any tooltip or tooltipnlsid setting.
The sortablelistbox control has three tooltips for the Up, Down, and Remove buttons that enhance
accessibility.
Accessible checkboxes — Effort: none

In accessibility mode, the actionmultiselectcheckbox control renders an Actions link that displays
the available actions.
Datagrid row information — The actions link in a datagrid row can describe possible actions. You
can configure which information about the object in the row is displayed. By default, the object name,
data type, and lock status are added to the title of the actions link in that row. Other columns can be
added using the columnsforaccessibility attribute of datagridRow tag. In the following example, the
name is displayed instead of the object name:
<dmf:datagridRow ... columnsforaccessibility="name">
Import files added or deselected — Effort: simple, single JSP page

The fileselector applet has the accessibilityalertsneeded attribute. When set to true, an alert is
displayed when the user selects or removes files from the list of files to be imported.
Timeout alert — Effort: simple, single XML file

A timeout warning can be configured to warn the user before a timeout occurs. After the timeout, the
usre is informed that the application has timed out, and then the user is redirected to the login page
or last active page if the user’s credentials are saved.
Session warning before timeout is configured in app.xml using <client_warning_session_timeout>.
The following example displays a warning five minutes before timeout:
<session_config>
<timeout_control>
...
<client_warning_session_timeout>5
</client_warning_session_timeout>
</timeout_control>
</session_config>
You can exclude pages from displaying a timeout warning in the <timeout_exclude_list> element. In
the following example, the login page is excluded:
<session_config>
<timeout_control>
...
<timeout_exclude_list>
<exclude>
</exclude>
</timeout_exclude_list>
</timeout_control>
</session_config>
Migrating scoped configurations to presets

Since: version 6
Effort: moderate based on number of configurations replaced, presets editor UI
Presets can be used to replace many customizations that deliver context‑sensitive functionality to
users based on scopes such as user, group, role, folder location, or object type. Presets are applied
during runtime, unlike configuration files, which are defined before deployment. Presets take
precedence over scopes that are defined in configuration files.
If your customizations use qualifiers (scope elements), you can replace them with presets using
the presets editor in Webtop. To enable a user for the presets editor, add the user to the presets
coordinator role.
With presets, you can restrict the UI and behavior in the following ways:
• Restrict actions that are available to specified users, roles, or locations
For example, you can restrict import to a particular folder.
• Set default values for attributes
Default values in presets take precedence over default values in the data dictionary.
• Restrict the object types and formats that are available for creating or importing
• Restrict the workflows, lifecycles, and templates for a group or role
• Restrict the columns that are displayed in listing pages
• Restrict the nodes in the browsertree to certain users
Presets can be used for many of the UI enhancements that were performed using XML configuration
files in prior releases. Before migrating your customizations, check the presets editor to see if your
customization can be accomplished using presets. Presets offer significant benefits in terms of
flexibility and maintainability.
Presets are limited to those that can be defined in the presets editor UI. Presets should not a used to
set security or access to objects. For information on using presets, see the Webtop User Guide.
A new UserQualifier was added to webtop/app.xml to support presets targeted to individual users.
Deployment model changed

Since: version 6
Effort: simple to moderate
In WDK 5.x, the web application was installed by an installer that also installed DFC. In WDK 6.x
applications, the web application is deployed by the standard J2EE method: as a WAR file. DFC is
contained within the WAR file, and more than one DFC‑based application of different DFC versions
can run on the same host if they do not run in the same application instance.
On a Windows system, if DFC version 5 loads first because it is launched by a 5.x application, it will
interfere with applications running DFC 6. In this case, you must uninstall the DFC 5.x application
and DFC 5.x itself.
If a version 5.x DFC‑based application such as Webtop is running in the application server, the
application server startup file or Windows service has been modified by the DFC installer to load DFC
libraries. You must run the 6.x application in a different application server instance with the standard
startup file (not modified by a Documentum installer). On a Windows host, you must make sure that
this new instance is not started by a Windows service that has Documentum‑specific libraries loaded.
Migrating configuration extensions to modifications

Since: version 6
Effort: moderate configuration, multiple XML pages
In earlier versions of WDK, XML configuration elements had to be overridden in their entirety. This
made applications difficult to maintain with a newer version. Each customized application required
its own WDK stack.
With configuration modifications, you can merge XML into an existing configuration file. These
elements modify rather than override target elements in configuration files. The following
modifications can be made on the referenced configuration definition: insert, insertbefore, insertafter,
replace, and remove.
The following example inserts a node in the browsertree and removes another node.
<scope role ="CSI_Investigator">
<component modifies="browsertree:webtop/config/browsertreeex.xml">
<insertbefore path="nodes.docbasenodes.node[componentid=homecabinet_classic]>
<node componentid="investigations">
</insertbefore>
<remove path="nodes.docbasenodes.node[componentid=administration]"/>
</remove>
</component>
</scope>
For full details on extending and modifying configuration files, refer to Web Development Kit and
Client Applications Development Guide.
Migrating JSP menus to XML menus

Since: version 6.5
Effort: moderate configuration, multiple XML files and custom JSP pages
Fixed menus are no longer in JSP pages. They are specified and configured in XML. This allows
you to scope and modify XML‑based menu definitions. JSP‑defined menus are still supported for
backward compatibility.
Actions can be grouped into menus so the set of actions available on a particular object type, user
role, or other qualifier is specified in a single location. Menus can be defined in the JSP page using
<dmf:menu> tags or in a menu configuration file using <menu> elements. The latter type of menu is
preferable because you can extend it and reuse it. This topic describes configuration file menus only.
Individual JSP page menus are supported for backward compatibility.
A menu is defined in a menu configuration file. This menu is included in a JSP page by its id attribute.
In the JSP page, a dmfx:menuconfig tag references the menu, similar to the following:
<dmfx:menuconfig id='my_menu' />
The menu configuration file for this menu has an id that matches the configid attribute on the menu
tag. In the following configuration file, two menus are defined: my_menu and 222_menuconfig. The
second menu is included as a submenu within the top‑level menu:
<config>
<scope>
<menuconfig id='my_menu'>
<menuitem name='aaa' label='Do A'/>
<menu id='111' name='111' label='B menu'>
<menuitem name='b1' label='Do B1' onclick='event_handler'/>
<actionmenuitem name='b2' label='Do B2' action='some_action'/>
</menu>
<menuconfig id='222_menuconfig/>
</menuconfig>
<menuconfig id='222_menuconfig'>
<menu id='222 name='222' label='C menu'>
<menuitem name='ddd' label='Do C'/>
</menu>
</menuconfig>
</scope>
</config>
This example generates a menu with the following hierarchy:
Do A B menu C menu (included menu)

Do B1 Do C
Do B2
The <menuconfig> element defines a menu that can be included within another <menuconfig> or
referenced in a JSP page. In the example above, an empty <menuconfig> element is used to include
the ’C menu’ within the top‑level ’my_menu’. The ’C menu’ can also be used separately in another
component because it is in a <menuconfig> element.
The elements in a menu configuration file, except the <menuconfig> element, generate JSP tags
with the same name. Attributes on the configuration element are generated as attributes on
the tag. For example, <menuitem name=’file_help’ nlsid=’MSG_HELP’ onclick=’onClickHelpr’
runtatclient=’true’/> generates the JSP tag <dmf:menuitem name=’file_help’ nlsid=’MSG_HELP’

onclick=’onClickHelp’ runatclient=’true’/>. Just as for JSP tags, the nlsid key overrides a hard‑coded
label in the label attribute. NLS values are retrieved from the nls bundle of the component that
contains the menu. If the menu item keys are not found in the bundle, then they are retrieved from
the menu NLS bundle specified in custom/app.xml as the value of <menu>.<nlsbundle>.
Table 12, page 60 describes the elements in a menu configuration file that can be used to generate a
menu.
Table 12. Menu configuration elements
Element Description
<menuconfig> Defines a top‑level menu. Contains at least one
<menu> or <menuconfig> element. Has an id
attribute that is used to include the menu into
another menu or a JSP page.
<menu> Defines a menu. If within a <menu> element,
it defines a submenu. Can contain any
combination of <menu> elements, which serve
as submenus, <menuitem>, <actionmenuitem>,
and <menuseparator> elements. Has the same
attributes as the dmf:menu JSP tag.
<menuitem> <menuitem> has the same attributes of the
dmf:menuitem control. The name attribute is
required. The menu item will not do anything
unless you set a value for the onclick attribute.
<actionmenuitem> <actionmenuitem> has the same attributes as
the dmfx:actionmenuitem control. The action
attribute is required and specifies the action
that is launched by the menu item. The action
must match the ID of an action definition in the
application.
<menuseparator> Generates a separator in the menu. Has the
same attributes as dmf:menuseparator.
Menus can be extended and modified using the WDK configuration mechanism. Refer toWDK
Development Guide for information on how to extend a menu configuration or how to insert, remove,
or override a menu item.
Tip: If you are reusing a menu in more than one component, put the menu into a <menuconfig>
element. If you are making simple modifications to a WDK menu you will not be reused in other
components, insert menu elements into the <menuconfig> element or its child elements using the
modification mechanism. In the following example, the sample menu above is modified by inserting
a menu item labeled Do X between Do B1 and Do B2.
<menuconfig modifies="my_menu:custom/config/mycomponent.xml">
<insertafter path="menu[id=111].menuitem[name=b1]">
<menuitem name="xxx" label="Do X" onclick="do_something"/>
</insertafter>
</menuconfig>
To convert a JSP menu to an XML menu

1. Remove the tags contained within the dmf:menu tag on the JSP page.
2. Change the dmf:menu tag to dmfx:menuconfig tag with an id attribute value that references the
id of the <menuconfig> element in the menu definition that you will create.
3. Create the menu definition in an XML file with the primary element <menuconfig>.
4. Replace each dmf:menu JSP tag with a <menu> element.
5. Within the <menu> element, eplace each dmfx:actionmenuitem tag from the JSP menu with
an <actionmenuitem> elemen. Replace each dmf:menuitem and dmf:menuseparator tag with
<menuitem> and <menuseparator> elements as described in Table 12, page 60.
Set the JSP tag attributes on the corresponding XML elements that replace them.
6. For each JSP menu item that is wrapped with a dmf:clientenvpanel tag, wrap the menu item
element in the XML definition with a corresponding <filter> tag. The following example from
the 5.3.x Webtop menubar_body.jsp page hides the New Process action menu item in the portal
environment:
<dmf:menu name='file_new_menu' nlsid='MSG_NEW'>
...
<dmfx:clientenvpanel environment='portal' reversevisible='true'>
<dmfx:actionmenuitem dynamic='genericnoselect' name='
file_newprocess' nlsid='MSG_NEW_PROCESS' action='
newprocess' showifinvalid='true'/>
</dmfx:clientenvpanel>...
This menu item would be defined as follows:
<menu id='file' nlsid='MSG_NEW'>
...
<filter clientenv='not portal>
<actionmenuitem dynamic='genericnoselect' name='
file_newprocess' nlsid='MSG_NEW_PROCESS' action='
newprocess' showifinvalid='true'/>
</filter> ...
</menu>
The menubar component allows you to specify all of the menus in the application menu
bar. Extend the Webtop menubar component and specify the menuconfig IDs for each
menu that should appear in the menu bar. For example, the Webtop menubar definition in
webtop/config/menubar_component.xml inherits the following menuconfig IDs from the
webcomponent menubar definition:
<menuconfigids>
<id>menubar_file_menu</id>
<id>menubar_edit_menu</id>
<id>menubar_view_menu</id>
<id>menubar_tools_menu</id>
<filter entitlement="recordsmanager">
<id>menubar_rpm_menu</id>
</filter>
</menuconfigids>
The following example in a custom menubar component definition modifies the menu to add a
menu item at the end:
<component id="menubar" modifies="menubar:webtop/config/menubar_component.xml">
<insert path='menuconfigids'>
<id>menubar_mymenu</id>
</menuconfigids>
</component>
Applicationwide changes
The following topics describe features that appear in many places in the application. You can change
the support for these features by configuration, as described in each migration topic.
Placing a custom component in a modal popup dialog

Since: version 6.5
Effort: moderate to complex, depending on where events are handled, multiple XML files and
possibly component classes
A custom component can be configured to display within a modal pop‑up dialog. A modal pop‑up
dialog is a child window which requires the user to interact with it before they can return to the
parent application. This feature enhances performance and allows the user to see the context from
where the action was launched. By default components are displayed within the main window unless
they are configured to use a modal pop‑up window.
Disabling modal pop‑up dialogs — Modal pop‑up dialogs are enabled by default. They can be
disabled in app.xml by setting the <enabled> element to false:
<modalpopup>
<filter clientenv='webbrowser'>
<enabled>false</enabled>
</filter>
...
</modalpopup>
Defining the available popup windows
Modal pop‑up windows are defined in app.xml within each <theme> element. The
<theme>.<windowsizelist> element contains one or more windows defined by three child elements:
<name>, <width>, and <height>, the latter two in pixels. For example, the small window is defined
as follows:
<windowsize>
<name>small</name>
<width>400</width>
<height>330</height>
</windowsize>
Invoking a modal component in a popup window

Invoking a modal component launched by an action — The action that invokes the modal
component must be configured to use a modal pop‑up. Add an <invocation> element to the action
definition to specify the pop‑up. In the following example, the action action definition launches the
about component in a small pop‑up window that does not refresh the parent window when the
modal window closes. (The default is to always refresh unless otherwise specified.) The value of the
<windowsize> element must match a defined window in app.xml.
<action id="about">
<params>...</params>
<execution
class="com.documentum.web.formext.action.LaunchComponent">
<component>about</component>
</execution>
<invocation>
<modalpopup>
<windowsize>small</windowsize>
<refreshparentwindow>never</refreshparentwindow>
</modalpopup>
</invocation>
</action>
Invoking a modal component launched by an event handler — If a component is launched by a

control event handler, you must add event arguments to the control, either in the JSP page, in the
server code that generates the control, or in the client event handler:
• In a JSP page:
<dmf:link cssclass="miniButton" onclick="onBrowseLocations"
nlsid="MSG_CHANGE_LOCATION" name="locationlink">
<dmf:argument name="usemodalpopup" value="true"/>
<dmf:argument name="modalpopupwindowsize" value="large"/>
<dmf:argument name="refreshparentwindow" value="onok"/>
</dmf:link>
• In a server‑side event handler, with the Control method addEventArg:

LinkTag linkTag = new LinkTag();
linkTag.setPageContext(pageContext);
linkTag.setName(ctrlName);
linkTag.setLabel(ctrlLabel);
linkTag.addEventArg("usemodalpopup", useModalPopup);
linkTag.addEventArg("modalpopupwindowsize", modalPopupWindowSize);
linkTag.addEventArg("refreshparentwindow", refreshParentWindow);
• In a client event handler:

function onClickPreferences()
{
beginModalPopupMode("content", null, "large", "onok");
<%
if (MainEx.isStreamlineViewVisible() == false)
{
%>
postComponentNestEvent(null, "preferences", "content",
"component", "general_preferences");
<%
}
else
{
%>
postComponentNestEvent(null, "preferences", "content",
"component", "general_preferences", "preferredVersion",
"<%=MainEx.STR_STREAMLINEVIEW_VISIBLE_CFG_VERSION%>");
<%
}
%>
}
beginModalPopupMode arguments are as follows

— strFrameName: Frame in which the postServerEvent method is invoked. If null, the current
frame is used.
— strFormId: ID of the form. If null, the first form in the frame is used.
— strPopupWindowSize: Size as defined in app.xml.
— strRefreshParentWindow: Specifies whether to refresh the parent window when the modal
window closes..
Invoking a modal component to edit attributes — Editing components for attributes can be
launched in a modal pop‑up dialog. Specify the modality in the docbaseobjectconfiguration file. In
the following example, the versionlabels editor for the version label attribute is launched modally:
<attribute name="r_version_label">
<valuehandler>com.documentum.web.formext.control.docbase.
DocbaseAttributeVersionLabelSetValueHandler
</valuehandler>
<editcomponent>versionlabels</editcomponent>
<invocation>
<modalpopup>
<windowsize>small</windowsize>
<refreshparentwindow>onok</refreshparentwindow>
</modalpopup>
</invocation>
</attribute>
You can also specify multiple modal pop‑up window sizes in app.xml. Compare your custom
components to the corresponding 6.5 components to determine whether you want to include the
modal pop‑up dialog elements in your custom component.
Refreshing the parent window
There are three options for refreshing the parent window. The refresh setting can be specified within
the action definition or event handler argument. Use one of the following settings:
• always
The framework always refreshes the parent window when the child window is closed.
• onok
The framework refreshes the parent window when the child window is closed and the return
value is not null. If the user cancels the modal dialog, no refresh occurs. The component developer
must ensure that there is a return value when the component closes.
• never
The framework never refreshes the parent window when the child window is closed.
Creating an action postprocessor for actions that sometimes

require modal windows
Effort: complex, custom class
An action may require a modal window for some conditions and not for others. For example,
the view action for dm_document objects uses a modal window, but for virtual documents a
modal window should not be used. In this case, the action registers a postprocessor in app.xml,
in the <modalpopup>.<actioninvocationpostprocessors> element. The action service checks for a
postprocessor, instantiates it, and calls its getModalPopupProperties() method to overwrite the
default modal popup settings for the action. You can overwrite use modal, modal window size, or
refresh parent window after closing.
The postprocessor is registered with the following syntax:
<postprocessor id="uniqueId" action="yourAction" class="YourActionInvocationPostProcessor"/>
In the example of the view action, the action and postprocessor class are as follows:
<postprocessor id="viewvdm" action="view" class="
com.documentum.web.formext.action.ViewActionInvocationPostProcessor"/>
The postprocessor class implements IActionInvocationPostProcessor and checks whether the object
is a virtual document. If so, it overrides the modal behavior for the view, which was defined in
the view action definition:
public ModalPopupProperties getModalPopupProperties(
ModalPopupProperties modalPopupProp,
ActionService.ActionDef actionDef, ArgumentList itemArgs)
{
boolean useModalPopup = actionDef.getUseModalPopup();
if (itemArgs != null)
{
if ("view".equals(actionDef.getActionId()) && isVirtualDoc(itemArgs))
{
useModalPopup = false;
}
}
return new ModalPopupProperties(
useModalPopup,modalPopupProp.getModalPopupWindowSize(),
modalPopupProp.getRefreshParentWindow());
}
Using window.location.replace within a modal component
If your component executes the JavaScript function window.location.replace() API in a modal popup
window, then you must change it to call navigateToURL(), a function in modal.js. For example, the
loginRedirect JavaScript event handler in the timeout.jsp page of Webtop reloads the login page
as follows:
function loginRedirect()
{
...
var strUrl = addBrowserIdToURL(g_virtualRoot+"/component/main");
navigateToURL(strUrl, "timeout", targetWindow);
...
}
Enabling and configuring IRM support

Since: version 6.5 SP1
Effort: simple, single XML fileSupport for rights management has been added to Content Server
and WDK applications. This feature provides additional persistent security for documents managed
within a repository. Working with an IRM Server, Rights Management implements this security
by adding IRM profiles and IRM permissions.
By default, IRM support is not enabled in WDK applications. You must enable it in your custom
app.xml by adding the following lines:
<irmsupport>
<enabled>true</enabled>
<tickettimeout>2</tickettimeout>
</irmsupport>
Change the ticket timeout (minutes) to a setting appropriate for your network throughput.
When you enable IRM, Webtop displays an extra tree node called Rights Management under the
repository node. Some IRM‑specific menus for IRM protection and profiles are also displayed.
Email conversion to EMCMF format

Since: version 6.5
Effort: simple, one or two XML files
For information on updating email messages to the new EMCMF format and enabling conversion of
messages on import in WDK applications, refer to Updating and migrating email messages, page 54.
The following new actions and components have been created to display EMCMF email messages:
• Import
emfimport is a new component in the import container. If you have customized the import
container, add this component to your custom importcontainer definition.
• Export (for example,
export (type dm_message_archive) is a new action. Requires no migration.
• View Properties and Listing pages
The attributes of type dm_message_archive are displayed. Requires no migration.
• Search
Search for type dm_message_archive are supported. Requires no migration.
Configuring inline refresh

Since: version 6 and 6.5
Effort: simple to moderate, single XML file and possibly multiple JSP pages
Webtop improves performance by reducing the amount of refreshes using the AJAX framework. For
example, a user chooses a folder in the browser tree to view a list of content contained in the folder.
Before Webtop 6, there was first a refresh of the browser tree control and then there was a refresh of
the content list. In Webtop 6, there is no refresh of the browser tree.
Controls that refresh inline — Four controls have a new inlinerefresh attribute: tree and
showhide in dmform_1_0.tld and docbaseattributelist and multiobjectsdocbaseattributelist in
dmformext_1_0.tld. Refresh can be turned off by setting this attribute value to false in the JSP page
(default is true).
Turning off inline refresh of the Webtop browser tree — The browsertree (version 6.0) Webtop
component is a new component, defined in webtop/config/browsertreex_component.xml.
jumpToBrowserTreeLocationAction is a new action related to this feature. Custom browsertree
components should extend the browsertree component in webtop/config/browsertreeex_component.
xml (new file).
You can turn off inline refresh by modifying classic.jsp in webtop/classic. Change from true to false
in the following line:
String strBrowsertreeArgs = "?inlineRefresh=true";
Using the new showhide control — The showhide control, new in WDK 6.5, can replace existing
refresh features. For example, extendedpermissions.jsp in 5.3 used a link to reload the page when the
user clicked the link:
<!restrictions show/hide>
...
<dmf:link name='<%=ExtendedPermissions.RESTRICTIONS_PERMIT_IMAGE%>'
onclick='onShowOrHideRestrictions'
tooltipnlsid='MSG_SHOW_RESTRICTIONS_TIP'/>
<dmf:link name='<%=ExtendedPermissions.RESTRICTIONS_PERMIT_LINK%>'
onclick='onShowOrHideRestrictions' cssclass='showMoreHideMoreLink'
tooltipnlsid='MSG_SHOW_RESTRICTIONS_TIP'/>
In WDK 6.5, the links are replaced with a faster refresh through the showhide control:
<dmf:showhide name='restrictions_showhide'
panelname='<%=ExtendedPermissions.RESTRICTIONS_PANEL%>'
shownlsid='MSG_SHOW_RESTRICTIONS'
hidenlsid='MSG_HIDE_RESTRICTIONS'
showtooltipnlsid='MSG_SHOW_RESTRICTIONS_TIP'
hidetooltipnlsid='MSG_HIDE_RESTRICTIONS_TIP'/>
The showhide control is associated with a panel control that is displayed when the user clicks Show.
Specify the name of the associated panel in the panelname attribute of the showhide control.
Lightweight sysobject support

Since: version 6.5
Effort: simple to moderate, single XML file and possibly multiple JSP pages
Lightweight sysobjects (LWSOs) store metadata, common to many different (but similar) child
objects, at the parent object level. This dramatically reduces the storage footprint and ingestion
processing required for the child objects.
With email archiving, individual emails can be grouped by user. Metadata common to all emails
would be stored at the parent (user) level. Thus the user would be the parent, and all of the user’s
emails would be the LWSO children.
The following 6.5 components have been changed to display LWSO features:
• Browsing
When a user browses through cabinets and folders, he or she sees neither parents nor children
associated with LWSOs.
• Simple Search
When a user performs a simple search, the results display shared parent objects only. Children are
not displayed.
• Advanced Search
When a user performs an advanced search, the results display children, but NOT the parents,
associated with LWSOs.
• Attributes
From search results, a user can open the properties of a LWSO and edit its properties. When any
attribute is changed, the LWSO materializes into a full object.
• Properties
Properties panels show all attributes associated with a child along with any attributes inherited
from the parent.
Displaying LWSO shared parent — To turn on the display of shared parents is listing and locator
pages, add the following lines to your custom app.xml file:
<lightweightsysobject>
<hidesharedparent>false</hidesharedparent>
</lightweightsysobject>
Using strong encryption

Since: version 6
Effort: simple, XML files and Java utility
The TrustedAuthenticatorTool utility now encrypts passwords in the application using triple DES
strong encryption. An encryption and decryption key is generated for each user and is stored in a
keystore file that can be secured using OS security. The location of the keystore is specified in a
properties file, and the encrypted password can be used for Java EE single sign‑on, preferences
repository user, and presets repository user. The encryption is also used to store user credentials
when saved credentials are enabled.
Use the TrustedAuthenticatorTool tool to encrypt passwords for the drl, drlauthenticate, and
virtuallinkconnect components. You can also use this tool to encrypt passwords for the preferences
repository user (dmc_wdk_preferences) and the presets repository user in app.xml.
To use the password encryption tool

1. From the command line, with com.documentum.web.formext.session.TrustedAuthenticatorTool
and the Java SDK in your classpath, run the following command on a single line. Substitute the
actual path to the class and the repository password to be encrypted:
java classpath "%CLASSPATH%;path_to_WEBINF/classes;path_to_WEBINF/classes/
dfc.jar;path_to_WEBINF/classes/commonsio1.2.jar" TrustedAuthenticatorTool
password
The output will look similar to the following:
Encrypted: [d7d1d6e383d6d4e1d0], Decrypted: [my.pwd6\]
2. For Java EE principal authentication, paste the encrypted form of the password into the file
TrustedAuthenticatorCredentials.properties located in WEB‑INF/classes/com/documentum/web/
formext/session. Each repository must have an entry for the superuser, encrypted password, and
domain if needed. Substitute the actual repository name in the sample entries below. If no
domain is needed for login, then type the following: Repository_name.domain=
Repository_name.user username
Repository_name.new‑pw password
Repository_name.domain domainname
For example:
mydocbase.user=superuser1 mydocbase.newpw= d7d1d6e383d6d4e1d0 mydocbase.domain=
3. For preferences or presets repository passwords, paste the encrypted form of the password
into the file app.xml in the custom directory. Insert the encrypted preferences password
into <preferencesrepository>.<password> or the encryped presets password into the
<presets>.<password> element.
4. The symmetric keys for encryption and decryption are stored in a file named
wdk.keystore. This file must be stored in a secure location on the application
server file system. Open the file KeystoreCredentials.properties, located in
WEB‑INF/classes/com/documentum/web/formext/session, and specify your keystore location.
You must also override the use of the default DFC config dir in order to substitute this
new location, for example: keystore.file.location=C:/Documentum/config/wdk.keystore
use_dfc_config_dir=false
By default, the keystore file location is created in the DFC config directory, which contains
dfc.properties and is specified as the value of dfc.config.dir in dfc.properties. The default location
is WEB‑INF/classes.
Note: Entries that were encrypted by the 5.3.x encryption tool and entered into the field .password
instead of the .new‑pw field will be decrypted by the 5.3.x encryption tool.
The WDK samples and testbed have been removed from the application to prevent cross‑site
scripting. These files are available as a separate download on the download site.
Enabling read notifications

Since: version 6.5
Effort: simple, multiple JSP pages
Two kinds of notifications are enabled in webcomponent/app.xml: event notification and read
notification. These notifications require a valid SMTP server configured for the Content Server:
smtp_server_attribute of dm_server_config object. The user who requests notification as well as the
user whose activity generates a notification must each have a valid email address configured in the
dm_user object.
Enabling change notification — Users can request change notification for a Content Server event on
one or more objects. Any API, workflow, or lifecycle event can be notified. Notification is available on
dm_sysobject and its subtypes from the Webtop menu or the right‑click context menu. Notification
on replica and reference (shortcut) objects is not supported. The user who has selected change
notification on an object will receive a notification in the Documentum inbox, and by email. If an
event that is configured in app.xml does not exist in a particular repository, that event is ignored by
the event notification mechanism for users who are logged into that repository.
Add notification for an event by copying the entire <notification> element from
webcomponent/app.xml to your custom app.xml and adding an <event> element for each notifiable
element. Server events are listed in an appendix of Documentum Content Server Administration Guide.
Enabling read notification — A user can select any object in a list view and turn on read notification
to notify the user when the document has been read. The default event for notification is dm_getfile,
and the minimum permission for read notification is configured in app.xml.
Add notification for read access to objects by copying the entire <readnotification> element from
webcomponent/app.xml to your custom app.xml and specifying the name of the read event (default
dm_getfile) and the minimum permission required to request read notification. Server events are
listed in an appendix of Documentum Content Server Administration Guide.
Setting roles precedence

Since: version 6
Effort: simple to complex, depending on the number of roles in the enterprise
When the configuration service evaluates a user’s role in order to apply configuration scopes or
presets, it is impossible to determine the order of roles to follow. This may result in a user having the
wrong context. You can specify the precedence in which roles should be evaluated for a user. In the
following example, role abc takes precedence over role def if a user is assigned both roles.
<rolesprecedence>
<role>abc</role>
<role>efg</role>
</rolesprecedence>
Copy the entire <rolemodel> element from /wdk/app.xml to your custom app.xml and add your
appropriate rolesprecedence element.
Rightclick context menus

Since: version 6
Right‑click context menus have been added to datagrids. For information on how to add or remove
actions from the right‑click menu, and how to turn off right‑click menus, refer to Adding right‑click
context menus, page 74 in the datagrid customizations topic.
Migrating datagrid customizations

Since: version 6
Effort: Moderate configuration, multiple JSP pages
Several substantial improvements have been made to the look and behavior of datagrid controls. The
improvements include mouse or keyboard row selection (one or more objects), right‑click context
menus, fixed column headers, and resizable columns.
Turning off new datagrid features — The new datagrid features can be reverted with the following
addition to your custom app.xml:
<desktopui>
<datagrid>
<richui>false</richui>
</datagrid>
</desktopui>
Note: Cells spanning multiple columns are not permitted.
Placing content below the datagrid — A datagrid without a height attribute value will span
the entire height of the window. If you have content to place below the datagrid, put it within a
dmf:datagridFooter tag within a dmf:datagridRow tag.
The following topics describe migrating your custom components to use the new datagrid features.
Supporting row selection

Users click rows to select objects rather than a check box at the left margin. This feature is enabled
by default and requires no migration effort for datagrids that leverage the ActionMultiSelect and
ActionMultiSelectCheckbox controls to drive row and object selection.
Replacing <td> with <datagridRow> — Every <td> tag within the custom datagrid dmf:datagridRow
tag must be replaced with dmf:datagridRowTd tag. For example, in the 5.3 page acllist.jsp, the
description column in the datagrid is as follows:
<td class="doclistfilenamedatagrid">
<dmf:label datafield='description'/>
</td>
In version 6, the cell is changed as follows:

<dmf:datagridRowTd cssclass="doclistfilenamedatagrid" style="
minwidth: 100px">
<dmf:label datafield='description'/>
</dmf:datagridRowTd>
Handling a double‑click event in a datagrid row — If your datagrid row supported a link
event (single or double click), you must either migrate the link to a right‑click context menu or
to a datagridRowEvent tag. The following example wraps a WDK 5.x double‑click event with a
datagridRowEvent. The event arguments, which in 5.x were passed in the actionmultiselectcheckbox,
are passed in argument tags:
<dmf:datagridRowEvent eventname='dblclick' eventhandler='
onClickObject' runatclient='true'>
<dmf:link onclick='onClickObject' name='
objectLink' runatclient='true' datafield='object_name'>
<dmf:argument name='id' datafield='r_object_id'/>
<dmf:argument name='type' datafield='r_object_type'/>
<dmf:argument name='isFolder' datafield='isfolder'/>
</dmf:link>
</dmf:datagridRowEvent>
Note: A datagridrow tag can contain only one datagridrowevent tag.
Handling a single‑click event (selection) in a datagrid row — The following example handles a
single‑click event (selecting the row). The event handler for a select event must be client‑side:
<dmf:datagridRowEvent eventname='select' eventhandler='
onSelectObject' runatclient='true'>
<dmf:argument name='id' datafield='r_object_id'/>
<dmf:argument name='name' datafield='object_name'/>
</dmf:datagridRowEvent>
The event object that is passed to the JavaScript handler has the following properties:
• type
Event type, such as select or init
• datagrid
Datagrid object instance
• startIndex
Index of the selected or deselected item, starting with 1
• count
Count of selected items
An event handler gets the item arguments, either for single or multiple selection, as shown in the
following example:
function onSelectObject(event)
{
//for single item selection
if (event.count == 1
{
var args = event.datagrid.data.getItemActionArgs(
event.startIndex, event.type);
//handle args
}
//handle multiple select
else
{
for (var i=0; I < event.count; i++)
{
var args = event.datagrid.data.getItemActionArgs(
event.startIndex + i, event.type);
//handle args
}}}
Turning off row selection per datagrid — You can turn off row selection for an individual datagrid
by setting the rowselection attribute value to false on the datagrid control in a JSP page. The app.xml
file’s <desktopui>.<datagrid>.<richui> element must be set to true to enable this attribute. The
following table describes the interaction between the global row selection flag in app.xml and the
datagrid attribute rowselection attribute.
Table 13. Interaction between global versus local row selection settings
app.xml dmf:datagrid Result

<rowselection> rowselection
false true or false Checkboxes rendered, no
mouse/keyboard row selection
or context menus on any
datagrid
true true No checkboxes rendered, row
selection and context menus
enabled for the datagrid
true attribute not specified No checkboxes rendered, row
(for example, migrated selection and context menus
customizations) enabled for the datagrid
true false Checkboxes rendered, no
mouse/keyboard row selection
or context menus on current
datagrid
Migrating to resizeable columns

Your custom datagrids can be migrated to support column resizing.
To make a column in the datagrid resizeable, add resizable=ʺtrueʺ:
<dmf:datagridTh resizable="true">
. . .
</dmf:datagridTh>
If your listing component extends the DocList component, it inherits support for resizeable
columns. If not, you must add the initColumnWidths method to the implementation of
the component class and call it when the component initializes. Your class must import
DatagridColumnWidthPreferenceHelper:
...
import
com.documentum.web.form.control.databound.DatagridColumnWidthPreferenceHelper;
...
public void onInit(ArgumentList args)
{
. . .
initColumnWidths();
}
protected void initColumnWidths()

{
m_widthsHelper = new DatagridColumnWidthPreferenceHelper
(this, <preference id string>, CONTROL_GRID);}
private DatagridColumnWidthPreferenceHelper m_widthsHelper;
Adding fixed column headers
Headings now stay in place while the user scrolls through the items in the datagrid. To enable this
behavior, custom components must implement header rows using the new element datagridTh. For
example, in the 5.3 component acllist, the datagrid contains a header for the name column:
<th align='left' scope='col' class="doclistfilenamedatagrid">
<b>
<dmf:datasortlink name='sortcol1' nlsid='MSG_NAME' column='
object_name' mode='caseinstext' cssclass='doclistbodyDatasortlink'/>
</b>
</th>
The <th> tag is replaced in WDK 6 as follows:

<dmf:datagridTh width='30%' scope='col' cssclass="
doclistfilenamedatagrid nowrap leftAlignment">
<b>
<dmf:datasortlink name='sortcol1' nlsid='MSG_NAME' column='
object_name' mode='caseinstext' cssclass='doclistbodyDatasortlink'/>
</b>
</dmf:datagridTh>
To globally disable fixed column headers in the application, add the following element to
/custom/app.xml:
<desktopui>
<datagrid>
<fixedheaders>false</fixedheaders>
</datagrid>
</desktopui>
Adding rightclick context menus
Effort: simple, multiple XML files

WDK 6 provides access to commonly used commands via a right‑click context menu. The actions
that are displayed in the context menu are filtered by any presets that apply to the user context.
This functionality provides an interface that is more familiar to users than the Streamline interface,
which is now deprecated.
Context menus work in datagrids that configured for row selection (that is, rows that do not use
check boxes). To turn off context menus, you must also turn off all datagrid enhancements in your
custom app.xml:
<desktopui>
<datagrid>
<richui>false</richui>
</datagrid>
</desktopui>
Context menus are defined in the <menuconfig> element of an action configuration file for a specific
object type. For example, the configuration file dm_folder_actions.xml contains the menu items that
are available for folder (the dm_folder type). The element <actionmenuitem> identifies an action that
can be performed on the object type . You can create submenus within the <menuconfig> element by
nesting a <menu> element with its own <actionmenuitem> elements.
The following example from dm_folder_actions.xml defines a context menu for actions on selected
dm_folder objects. The Properties menu item is followed by a View submenu that contains
three actions: relationships, locations, and topics. Note that some actions support multiple
selection (the dynamic attribute is set to ʺmultiselectʺ) and some support only single selection
(dynamic=ʺsingleselectʺ).
<menuconfig id="contextmenu">
<actionmenuitem dynamic="multiselect" action="
subscribe" .../>
unsubscribe" .../>
...
<menuseparator/>
<actionmenuitem dynamic="singleselect" action="
properties" .../>
...
<menu menu nlsid="MSG_VIEW_MENU">
<actionmenuitem dynamic='multiselect' action='
relationships' .../>
locations' .../>
showtopicaction' .../>
</menu>
</menuconfig>
You could add a custom menu item to the top level menu and one to the View menu as follows:
<menuconfig id="contextmenu">
subscribe" .../>
unsubscribe" .../>
...
<menuseparator/>
properties" .../>
firstcustomaction" .../>
...
<menu menu nlsid="MSG_VIEW_MENU">
relationships' .../>
locations' .../>
showtopicaction' .../>
<actionmenuitem dynamic='singleselect' action='
nextcustomaction' .../>
</menu>
</menuconfig>
Toolbar hidden by default

Since: version 6
Effort: simple, single JSP page
The toolbar is no longer necessary with the introduction of the right‑click menu, and so has been
hidden by default. It is still present in the webtop\classic\classic.jsp JSP page, but its frame height is
set to 0. You can display the toolbar by changing the line
String strRows = "0,*";
to
String strRows = "22,*";
Keyboard shortcuts (hotkeys)

Since: version 6
Effort: moderate, one XML file and custom JSP pages
Keyboard shortcuts, also called hotkeys, are supplied and supported in version 6. A shortcut calls an
action or invokes a control. You can turn off this feature in app.xml, or you can configure shortcuts to
add, change or remove a shortcut. You can add shortcut support to a custom control (effort: complex).
To disable hotkeys, add the following to a modifications file, for example, custom/config/app_
modifications.xml:
<application modifies="wdk/app.xml">
<replace path="hotkeys">
<hotkeys>
</hotkeys>
</replace>
...(remainder of your modifications to app.xml)
Adding a shortcut or modifying existing shortcuts
Controls that support shortcuts have a hotkeyid attribute, for example:

<dmfx:actionmenuitem... action='checkin' hotkeyid='HOTKEY_CHECKIN'/>
The hotkeyid value is resolved by a lookup in the shortcuts (hotkeys) definition in hotkeys.xml.
This file defines an NLS key for each hotkey ID. The key is then resolved to a key combination
in the hotkeys properties file HotKeysNlsProp.properties. The properties files can be localized
for locale‑specific key combinations.
Caution: When focus is on a user‑entry control such as text, shortcuts are not enabled. If you
set initial focus in the UI to a user‑entry control, shortcuts will not be enabled until the user
moves off the control.
To create your own shortcuts mapping

1. Specify your hotkeys mapping file in app.xml. Refer to Specifying a shortcuts mapping properties
file, page 77.
2. If you are adding shortcuts to custom actions, create a definition by extending or modifying
hotkeys.xml. This file will have a hotkey ID for each hotkey action. Refer to Adding a shortcut
definition in an XML file, page 77.
3. Create a map (properties file) that maps each hotkey ID to a key combination. You can include
the WDK map and simply make your changes in your custom properties file. Refer to Creating or
modifying a shortcuts map, page 78.
4. Add your shortcut to a custom control on the JSP page. Refer to Adding your custom shortcut
to the component, page 80.
Specifying a shortcuts mapping properties file
The <hotkeys> element in your custom app.xml file specifies a mapping file that maps key
combinations to actions. You must specify the location of your properties file in your custom app.xml.
If your file is located in WEB‑INF/com/mycompany, for example, you would specify the location in
an <nlsbundle> element as follows in app.xml:
<hotkeys>
<nlsbundle>com.mycompany.HotKeysNlsProp</nlsbundle>
</hotkeys>
Adding a shortcut definition in an XML file
The hotkeyid value for a control is resolved by a lookup in the hotkeys configuration file hotkeys.xml,
located in webcomponent/config. The corresponding key NLSID value is resolved by a lookup
in a shortcut mapping file.
Tip: If you are changing existing shortcut combinations, you do not need a hotkeys definition file. If
you are adding shortcuts for your custom actions or removing shortcuts to WDK actions, a hotkeys
definition XML file is required. You can use the modification mechanism to do this.
To insert a shortcut, create a modification XML file in custom/config, for example,

hotkeys_modification.xml. This file modifies the WDK hotkeys definitions and adds custom keys.
For example:
<hotkeys modifies="hotkeys:webcomponent/config/hotkeys.xml">
<insert>
<hotkey id=HOTKEY_CUSTOM_ACTION1>
<keynlsid>_#HOTKEY_CUSTOM_ACTION1</keynlsid>
</hotkey>
</insert></hotkeys>
Table 14, page 77 describes the hotkeys configuration elements.
Table 14. Hotkeys configuration elements
Element Description
<hotkeys id=...> The id attribute on this element facilitates more
than one hotkeys definition for the application
Element Description
<hotkey id=...> The id attribute on this element is referenced by
a control on the JSP page and contains a key for
lookup of the hotkey combination. The ID must
be unique to the definition. Contains <keynlsid>
and, optionally, <labelnlsid>.
<keynlsid> Specifies an NLS key that is resolved in the
hotkeys NLS properties file.
<labelnlsid> (Optional) Specifies an NLS key for a label that
to be displayed for the shortcut
To add your new shortcut to the JSP page

1. Find every instance of a control that launches your custom action in your JSP page.
2. Add the hotkeyid attribute to match the mapping that you set up for your custom shortcut. In
the following example, the menu item launches the custom action ʺmyaction” and maps to the
shortcut with the id HOTKEY_CUSTOM_ACTION1:
<dmf:menuitem id="custom_menu" name='custom_item'
nlsid="MSG_CUSTOM_ACTION" onclick="onClickCustomAction"
runatclient="true" hotkeyid="HOTKEY_CUSTOM_ACTION1"/>
In the next example, the shortcut to a delete action is specified:
<dmfx:actionimage name="delete" dynamic="multiselect" action="
delete" hotkeyid="HOTKEY_DELETE" .../>
Creating or modifying a shortcuts map
A Java NLS properties file specifies the key combinations for each hotkey ID. Make sure your custom
app.xml file specifies the fully qualified path name for this NLS properties file as described in
Specifying a shortcuts mapping properties file, page 77. If you add shortcuts to custom actions, then
create NLS IDs for your shortcut IDs in a custom hotkeys configuration file as described in Adding
a shortcut definition in an XML file, page 77.
To include the WDK or Webtop shortcuts — When you change or add hotkey combinations,
include the WDK properties file in your own properties file so that you inherit the WDK shortcuts.
Include the WDK map as follows:
NLS_INCLUDES=com.documentum.webcomponent.keyboardshortcut.HotKeysNlsProp
To add a new shortcut combination — Add a new shortcut similar to the following, which specifies
that the shorcut with the NLS id _#HOTKEY_CUSTOM_ACTION maps to the keystrokes Ctrl and
Shift and X:
_#HOTKEY_CUSTOM_ACTION=Ctrl+Shift+k
To modify an existing shortcut — In your custom mapping properties file, add an entry for the
shortcut with the keystroke combination. This entry will override the entry in the WDK mapping file.
The following example changes the keyboard shortcut for Export from Shift + E to Shift + X:
_#HOTKEY_EXPORT=Shift+X
In your key combinations, a single keyboard key can be combined with another key such as Ctrl
(Windows), Cmd (Macintosh), Shift, or Alt. Table 15, page 79 describes the single keys that can be
used in a shortcut combination. Shortcut definitions are case‑insensitive.
Table 15. Keys that can be used in a shortcut combination
Key Description
alphanumeric A‑Z or 09
navigation and command Home, End, Enter, Insert
punctuation The following punctuation keys can be used:
; = , . / ’ [ ] \ ‘
function keys Unreserved function keys are valid
Tip: Do not use a shortcut combination that is reserved for browsers, such as Ctrl+c for copy in IE.
WDK will not attempt to override reserved shortcuts.
The NLS ID value that is used to specify the shortcut combination can have .MAC added to provide
an alternate shortcut combination for the Macintosh platform, for example:
_#HOTKEY_COPY_FILE=Shift+V
_#HOTKEY_COPY_FILE.MAC=Shift+C
To add or change a shortcut combination

The following example changes a shortcut definition for Add to Clipboard on Windows from Shift+C
to Shift+X and adds a shortcut for a custom action.
1. Add your NLS bundle reference to app.xml in your custom directory, for example:
<hotkeys>
<nlsbundle>com.mycompany.HotKeysNlsProp</nlsbundle>
You will create this file in step 6.
2. Create a file hotkeys_modification.xml in custom/config and open the file for editing.
3. Add the required XML structure:
<?xml version="1.0" encoding="UTF8" standalone="no"?>
<config>
<scope>
</scope></config>
4. Add your <hotkeys> element as follows:

<hotkeys modifies="hotkeys:webcomponent/config/hotkeys.xml">
<insert>
</insert></hotkeys>
5. Within the insert element, add <hotkey> elements for the new shortcut. You do not need to
modify the definition to replace a shortcut, because you can use the same keynlsid and just
provide a new string in the properties file.
<insert>
<hotkey id="HOTKEY_MYACTION">
<keynlsid>_#HOTKEY_MYACTION</keynlsid>
</hotkey>
</insert>
<replace>
6. Create a HotKeysNlsProp.properties file in WEB‑INF/classes/com/mycompany. The following

example adds an entry for the new hotkey ID and maps it to the key combination of the alt key
and the x key. It changes the shortcut for the copy action:
NLS_INCLUDES=com.documentum.webcomponent.keyboardshortcut.HotKeysNlsProp
_#HOTKEY_MYACTION=Alt+X
_#HOTKEY_ADD_TO_CLIPBOARD=Shift+X
7. Add the hotkeyid attribute value HOTKEY_MYACTION to the component JSP page, in the
control that calls your custom action, for example:
<dmfx:actionlink name="mylink" action="myaction" hotkeyid="HOTKEY_MYACTION"...>
8. Restart the application server for changes to NLS properties files. If your changes are to XML
files only, refresh memory by navigating to wdk/refresh.jsp.
9. Test your shortcut combination in the appropriate component.
Shortcuts are bound to the top level window of the application, so you must ensure that all shortcuts
are uniquely defined in the <hotkeys> configuration elements across your application. This will be
easier to manage in a single shortcuts mapping file. If two controls are assigned the same shortcut, the
second assignment will be used. Shortcuts are not invoked when the keyboard focus is on an input
field such as text, textarea, or password. For these controls, use the escape key to access shortcuts.
Adding your custom shortcut to the component
In every JSP page that contains your custom control, you must add the new shortcutid attribute. In
the following example, the custom action has a shortcut with the ID HOTKEY_CUSTOM_ACTION,
as defined in the properties mapping file:
<mytld:customactions name="customactiona" dynamic="singleselect" action="
action1" hotkeyid="HOTKEY_CUSTOM_ACTION1" .../>
Modifying a custom control to support shortcuts
The base Control class supports shortcuts with the public methods setHotKey, setHotKeyLabel,
getHotKey, and getHotKeyLabel. The following WDK controls support shortcuts: ActionMenuItem,
ActionButton, ActionLink, ActionImage, Button, Link, and MenuItem.
If your custom control extends a WDK control with shortcut support, add the hotkeyid attribute to
the tag library descriptor that contains your control and then set the hotkeyid value on the control
in the JSP page.
To set a shortcut combination programmatically on a control that supports shortcuts, use the API
setHotkey(String hotKey) where the parameter is a key combination, for example: setHotkey(ʺalt+xʺ);
If your control does not extend a control with shortcut support, add support to the tag class by calling
either the renderHotKey() or renderHotKeyHandler() from renderEnd().
The keyboard events that are handled are keyup, keydown, and keypress. WDK JavaScript handlers
for each of these keyboard events retrieve the shortcut commands and invoke the corresponding
actions.
To add shortcut support to a custom control

1. Add a hotkeyid attribute for the custom control to your control tag library descriptor as follows:
<attribute>
<name>hotkeyid</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
</attribute>
2. At the end of renderEnd() in the control tag class, add a call to renderHotKey() or
renderHotKeyHandler().
• For a control that launched as client JavaScript event, for example, a click, call
renderHotKey(StringBuffer buf, String eventName) and provide the event name, for example,
onClick. The Javascript code for the shortcut will be rendered by the framework.
The following example from ButtonTag checks whether the control is enabled and, if so,
adds the renderHotKey JavaScript function key to the output. In the Button class, the
EVENT_ONCLICK is the onclick event:
if (button.isEnabled())
{
StringBuffer buf = new StringBuffer(256);
renderHotKey(buf, Button.EVENT_ONCLICK);
out.print(buf.toString());
}
• For an action control,, call renderHotKeyHandler(StringBuffer buf, String hotkeyHandler).

Specify a hotkey JavaScript handler that will be invoked for the shortcut and provide
your handling in the referenced JavaScript handler. In the following example from
ActionButtonTag, a handler method getClientEventFunctionCall is specified (provide your
own method):
if ((isButtonGraphic(button) && button.isEnabled(
)) || !isButtonGraphic(button))
{
renderHotKeyHandler(buf, getClientEventFunctionCall());
}
Note: The handler getClientEventFunctionCall is implemented in ActionControlTag to pass

on the dynamic attribute value of an action control. If your control is not an action control,
you can call a custom handler in your tag class to render your JavaScript reference.
3. Follow the steps in Adding a shortcut or modifying existing shortcuts, page 76 to set up and
test the shortcut for your control.
Tab order configuration

Since: version 6
WDK supports the HTML attribute tabindex to determine the order in which controls receive focus
when the user types the tab key. The following WDK controls support tab ordering in version 6:
• Text (also XFormsText, FileBrowse)
• Password
• TextArea (also XFormsTextArea)

• Button
• Link
• ActionButton
• ActionLink
• ActionImage
• Tree
• CheckBox
• Radio
• Image
• DropDownList (also DataDropDownList, ListBox, DataListBox)
• DateInput
• DateTime
Tab ordering is enabled by default. Tab ordering can be turned on or off for different environments in
app.xml. We recommend that you turn off tab ordering in portal applications.
When a component is included within another component, elements may have the same tabindex
value. Place the included component in the page based on your preferred tab ordering among the
elements in the parent page. WDK will ensure that tabindex collisions are resolved and elements
are navigated in the order they appear in the character stream.
Tip: As a general rule, you should assign index values incrementally based on the order of elements
in the source code for the page. Use the tab key ordering to support a different tabbing requirement.
Do not use tab ordering to ʺfixʺ a bad page design. In the latter case, alter the order of the content
in the markup itself instead of altering the order using tabindex.
Supporting tab index in a custom control

1. Open the tag library descriptor for the custom control.
2. Add the tabindex attribute within the tag definition as follows:
<attribute>
<name>tabindex</name>
</attribute>
3. Add tabindex attribute values on the JSP pages that contain the custom tag.
4. If the custom control provides its own rendering rather than that of a parent that supports tab
index, call renderTabIndex(StringBuffer) API from the base ControlTag class in the rendering
method.
5. Save the tag library descriptor and JSP files and restart the application server
Supporting auto completion

Since: version 6
The auto complete feature provides value assistance for drop‑down list and text controls. The values
are read from the data dictionary. Completion lists are stored by autocompleteid for each user. The
values are not specific to an object type or repository.
Auto complete is enabled by default. Auto complete can be disabled for the entire application by
setting the <auto_complete>.<enabled> attribute to false in the app.xml file.
Configuring a custom control that can support autocompletion
Even when autocomplete is turned off for the application, it can be turned on for an individual
control. Set autocompleteenabled=ʺtrueʺ for the control. Controls that have the same value for
autcompleteid share the same autocomplete list. The maximum autocompletion items to be displayed
is set by the maxautocompletesuggestionsize attribute. The autocompletetarget attribute specifies the
name of the frame where the completion list should be displayed. By default, the popup appears in
the same frame.
If no autocompleteid is specified, the autocompleteid setting defaults to the form name concatenated
with the control name. In this care, every control on the page will have a different autocompletion list.
Adding autocompletion support to a text or dropdown list control — You can add auto complete
functionality to any control that extends the WDK text or dropdown list controls. Add the four
autocompletion attributes to your control definition in your custom tag library. For example:
<attribute>
<name>autocompleteenabled</name>
</attribute>
<attribute>
<name>autocompleteid</name>
</attribute>
<attribute>
<name>maxautocompletesuggestionsize</name>
</attribute>
<attribute>
<name>autocompletetarget</name>
</attribute>
Adding autocompletion support to a non‑text control — You can create custom controls that do
not extend text or dropdown list but can support auto complete (effort: complex). To implement
autocompletion in these controls, implement IAutoCompleteEnabledControl in the control class.
The method getInputValue() should get the value that the user has entered and add it to the
autocompletion list. For example, the Text class implements the method in the following way:
public String getInputValue()

{
return getValue();
}
The tag class must bind the autocomplete object during rendering. The following example from the
TextTag class calls a rendering method from renderEnd:
protected void renderEnd(JspWriter out)
throws IOException
{
//...
if (text.isAutoCompleteEnabled())
{
// generate the JavaScript to support AutoComplete
// generate the auto complete list
renderAutoCompleteTextBinding(buf, Text.EVENT_ONVALUECHANGE, null);
}
Your control class must manage autocompletion data, inclusing retrieving or storing data, managing
list, and flushing old data when needed. You can use AutoCompleteService, which provides the
following APIs:
• public synchronized static AutoCompleteService getInstance ()
• public List getAutoCompleteEntries(String key)
• public void addAutoCompleteEntry(String key, String value)
• public void clearAutoCompleteEntries()
• public int getAutoCompleteMaxSuggestionSize ()
• public Option getAutoCompleteOption ()
• public static void setAutoCompleteOption (Option option)
Add the autocompletion attributes to the tag library descriptor entries for your custom tag.
Adding a "Starts with” filter

Since: version 6
Effort: simple to moderate, multiple JSP pages
A new control, <dmf:datacolumnbeginswith>, allows you to filter the selection in datagrids
and dropdown lists. The filter is bound to the containing control on the JSP that implements
IDataboundControl. Filtering is case‑insensitive by default.
In the following example from myobjects_list_body.jsp, the filter adds a text box that filters on object
name starting with the text entered by the user:
<dmf:datacolumnbeginswith name='namecolumnbeginswith' column='
object_name' autocompleteid='ac_namecolumnbeginswith' size="
24" nlsid="MSG_BEGINSWITH_FILTER"/>
The data source that will be filtered is specified in the column attribute of the datacolumnbeginswith
control. The column must match a column that is specified within a <column> element of the
component definition. For example, to enable filtering on the object name, the value of the column
attribute should be ʺobject_nameʺ.
In the following example, the datacolumnbeginswith control is bound to a datadropdownlist:

<dmf:datagrid ...>
<dmf:datadropdownlist ..>
<dmf:datacolumnbeginswith ../>
</dmf:datadropdownlist ..>
</dmf:datagrid>
Displaying invalid actions

Since: version 6
Effort: simple, single XML file
By default, actions that are invalid for the user are hidden. Your can display them with a setting in
/wdk/app.xml, <display>.<hideinvalidactions>. This setting overrides theshowifinvalid setting on action
controls. Set this element to false to display ctions that are not valid in the user’s current application
context, regardless of the setting in the showifinvalid attribute of the action control.
Drag and drop improvements

Since: version 6.5
Users can select multiple files and perform a drag and drop. The multi‑select drag and drop
functionality is available for all areas where single file drag and drop was previously available. For
example, users can multi‑select files and drag and drop them to another location in the repository.
Multi‑select drag and drop also works when exporting and importing multiple files to and from
the local file system.
These improvements require no migration.
You can turn off drag and drop for the application, to improve performance. In your custom app.xml,
add the following lines:
<dragdrop>
</dragdrop>
Since: version 6
When a user drags a document into a directory with an item of the same name, a popup menu
displays to allow the user to choose between creating a new rendition of the repository file, or
replacing the content of the existing file with the dropped file.
This feature does not require migration.
Preferences changes
Since: version 6
Effort: none to simple (single XML
User preferences are now stored in the global registry in addition to local cookies. Preference storage
in the repository enables users to see their preferences on more than one machine. This feature
does not require migration.
The cookie size has been streamlined for scalability. This enhances reliability and makes the user’s
customized settings available from any client machine.
Saving preferences in a separate repository — By default, user preferences are stored in the global
registry. You can specify a different repository for preferences storage in your custom app.xml
file. Copy the <preferencesrepository> from wdk/app.xml to your app.xml and add the name of
your preferences repository to the child element <repository>. You can add a triple‑DES encrypted
password to the <password> element using the utility class TrustedAuthenticatorTool. With the class
com.documentum.web.formext.session.TrustedAuthenticatorTool in your path, execute the following
command. Substitute the actual password (pwd below) for the user dmc_wdk_preferences_owner:
java com.documentum.web.formext.session.TrustedAuthenticatorTool pwd
Paste the resulting encrypted password into the <password> element in app.xml.
Specifying cookies that are not persisted — User preferences that should not be stored (cookie only)
should be added to the <non_repository_preferences> element. Use this for preferences that should
not be stored in a repository and should be stored only in a cookie, such as login preferences. These
cookies are used before the preferences are downloaded from the preferences storage repository.
Within the <non_repository_preferences> element, each <preference> element contains a value that
corresponds to the XML path to the element within a configuration file that defines the cookie
(nonrepository) preference. If an element has an ID, it must be specified, as in the following example
from the login component:
component[id=login].username
Content transfer changes
UCF performance improvements in Webtop

Since: version 6.5
Effort: none to moderate: for PDF byte‑serving, one XML file plus all PDF files in repository
UCF content transfer is more usable and performs better. These enhancements require no migration.
The following lists the UCF enhancements for Documentum 6.5:
• Reduction in the number of round trips between the UCF client and server. This feature is
especially effective for improving transfer performance for smaller files over a high latency WAN.
• The following UCF client initialization/startup improvements:
— Sharing a JVM instance across multiple web sessions
— Starting JVM upon login
• Support for PDF byte streaming through a native viewer. Refer to Enabling PDF byte‑serving,
page 87 for information on configuring this feature.
• Use of parallel streams to increase content transfer rate. This feature is especially effective for
improving content transfer performance of large files over a high latency WAN (outbound and
inbound).
• Freeing up stuck threads to optimize resources and increase concurrency.
• Reduction in unnecessary WDK UCF client calls.
Enabling deep export

Since: version 6.5
WDK provides the ability to export one or many folders, keeping the same folder structure if the user
has at least read permission on the files and browse permission on the folders.
By default, deep export is disabled, and you must enable it in app.xml. Add the following lines to
your custom app.xml:
<deepexport>
</deepexport>
Turning off UCF preload

Since: version 6.5
The UCF invoker component preloads the Java browser plugin and UCF process for each user.
This preload makes content transfer faster in a multi‑frame application. It is enabled out of the
box in Webtop.
To preload UCF in a custom application that is not based on Webtop, you must include the component
in a hidden frame of the application frameset. Add the residentucfinvoker frame as shown below to
your application frameset in the main application JSP page. The example is taken from the Webtop
frameset defined in mainex.jsp:
<dmf:frameset ... onunload='onUnload()'>
<dmf:frame name="timeoutcontrol" .../>
<dmf:frame name="residentucfinvoker"
src="/component/residentucfinvoker" marginwidth="0"
marginheight="0" scrolling="no" .../>
<dmf:frame nlsid="MSG_TITLEBAR" name='titlebar' .../>
<dmf:frame nlsid="MSG_CLASSICVIEW" name='view' .../>
<dmf:frame nlsid="MSG_MESSAGEBAR" .../>
</dmf:frameset>
Enabling PDF byteserving

Since: version 6 SP 1
Effort: simple to moderate: one XML file plus all PDF files in repository
PDF documents can be streamed to the browser so that the user can read a document before it has
fully downloaded to the browser. This feature is available for PDF documents served from Content
Server 6 SP1 repositories if the user has configured preferences to view PDF documents inline.
To enable PDF byteserving

1. Administrator: Enable PDF documents for fast web view. This is done in Adobe Acrobat. Choose
File > Properties and check Yes for Fast Web View.
2. Administrator: Enable ACS read in app.xml. It is enabled by default, but if your custom
app.xml turns if off, PDFs will not be served incrementally. To enable it, set the value of
<accelerated‑read>.<enabled> to true in custom/app.xml..
3. User: Select inline viewing for PDF documents. In Webtop Preferences, choose the Formats tab
and click Add. For Choose object type, choose All types. For Primary Format, choose Acrobat
PDF. For Would you like this content to appear in the web browser? choose Yes.
Specifying the content transfer mechanism for a group

or role
Since: version 6.5
Webtop 6.5 enables administrators to specify HTTP or UCF content transfer for different users within
the same Webtop installation. Before Documentum ECM 6.5, all users within the same Webtop
installation had to use either HTTP or UCF content transfer.
Configure the content transfer mechanism with a role qualifier filter. Copy the <contentxfer> element
from wdk/config to your custom app.xml file and add configuration for each role that will have a
content transfer mechanism different from the default. In the following example, the contributors are
assigned to the role of ucfgroup with UCF content transfer while consumers are assigned to the role
of httpgroup which has HTTP content transfer:
<contentxfer>
<filter role="ucfgroup" >
<mechanism>ucf</mechanism>
</filter>
<filter role="httpgroup" >
<mechanism>http</mechanism>
</filter>
<defaultmechanism>ucf</defaultmechanism>
...
</contentxfer>
Enabling and configuring OLE linkscanning

Since: version 6 SP1
For WDK‑based applications that use UCF content transfer, scanning for linked documents in
Microsoft compound documents can be enabled. Link scanning may have a performance impact.
On import or checkin of a document with linked documents, a dialog will displayed asking if the
user wants to scan for linked documents. When linked documents are imported, the parent and
children are internally treated as virtual documents, but the user will not be able to reorder the linked
documents within the compound document.
The following formats will be scanned for links and the linked documents will be imported or
checked in:
• Microsoft Word
• Microsoft Excel
• Microsoft Powerpoint
The following versions of these Office documents are supported: 2003 and 2007.
Note: Content linked with the Office hyperlinks feature is not included in an import or check‑in.
Link scanning is OFF by default, because most documents do not include links. To enable link
scanning, add the following lines to the <contentxfer> element in your custom app.xml file:
<embeddedlinksscan>
enabled>false/enabled>
</embeddedlinksscan>
You can disable link‑scanning for a particular type of document in the configuration file for the action.
For example, to disable link scanning on the view action, extend the view action definition and copy
in the definition from webcomponent/config/actions/dm_sysobject_actions.xml. Uncomment the
following line:
<!<olecompound enabled="false"/>>
Allowing user selection of viewing application for

renditions
Since: version 6
In previous versions, the path to a rendition viewing application had to be the same for every user.
This feature can now be configured in app.xml to use the user’s preferred viewing application set in
the format preferences UI.The <preferred_renditions> element in wdk/app.xml contains elements that
specify the default list of renditions (document type and format combinations) and the application to
be used for viewing or editing a specific document type and format combination. Users can override
these settings using the preferred renditions component UI.
To enable the user to specify a personal viewing application, copy the <preferred_renditions> in
wdk/app.xml to your custom app.xml and set the value of <rendition>.<app> to blank.
Configuring ACS and BOCS settings

Since: version 6
You can enable or disable ACS and BOCS write operations in the application configuration file
app.xml. If you enable BOCS write, you can set the mode to synchronous, asynchronous, or both. If
you enable both, you can set the default mode, and business users will see a UI on import and checkin
in which they can select the mode of transfer. ACS supports only synchronous writes.
These settings replace the <acs> configurations in 5.3 app.xml. Following are the default settings.
Copy the entire <contentxfer> element from wdk/app.xml to your custom app.xml and make changes
required by your business environment. Accelerated read uses ACS and, where optimal, BOCS to
download content to the user. Accelerated‑write performs the same optimization for uploaded
content. Other settings are described fully in the WDK Development Guide.
<acceleratedread>
<attemptsurrogateget>true</attemptsurrogateget>
<maintainvirtuallinks>true</maintainvirtuallinks>
</acceleratedread>
<acceleratedwrite>
<bocswritemode>prohibitasync</bocswritemode>
<allowoverridebocswritemode>false</allowoverridebocswritemode>
</acceleratedwrite>
Content transfer applet removed

Since: version 6
Effort: complex
The content transfer applet is no longer supported. We recommend that you upgrade your custom
applications to use the UCF file transfer utility.
Style changes
The following topics describe changes that affect the style of the UI in recent releases. For information
on CSS style changes, refer to Appendix D, Changes to Webtop Cascading Stylesheets.
Streamline deprecated
Since: version 6
Effort: simple to revert, possibly complex to migrate
The streamline interface was designed to provide quick access to the most commonly used
commands. Version 6.5 introduces the right‑click context menu, which provides the same ease of use
in a way that is familiar to most users. The streamline interface is now obsolete and is disabled by
default. However, it still ships with our product for backward compatibility. If you would like to
enable the streamline interface, use one of these methods:
• To re‑enable streamline view for all users and all HTTP sessions, add the following setting
in /custom/app.xml:
<streamlineviewvisible>true</streamlineviewvisible>
• To re‑enable streamline view for one HTTP session, launch the main component with the
parameter entryPage set to streamline.
For example, Webtop can be launched using a URL similar to
http://localhost:8080/webtop/component/main?entryPage=streamline
Once the streamline view is enabled, it cannot be disabled again within the same HTTP session.
Specific themes deprecated

Since: version 6
Effort: complex if custom theme is not based on the base documentum theme
Version 6 introduces a new version of the documentum and high contrast themes. These themes enhance
performance and maintainability, and provide additional ʺlook and feelʺ benefits. Any 5.3 theme can
be enabled in app.xml, but features that are new in version 6 or 6.5 will not display a custom theme
that extends a 5.3 theme. If you want to use a custom theme that extends the documentum or high
contrast theme, you will need to adjust your JSP pages to match the changes introduced in the JSP
page design. Refer to the WDK stylesheet changes in the appendix of this document.
Feature changes
The following are changes to the implementation of controls or specific components in WDK/Webtop
applications. Most of these features are enabled by default. These topics tell you how to disable the
new behavior if you prefer not to use it.
Deprecated components
The following component configuration files are deprecated. Customization to the old components
should be updated to point to new component xml files in order to pick up bug fixes and new features.
Table 16. Deprecated components
Component Name Old definition New definition Changed in

(ends in _component. (ends in _component.
xml) xml)
browsertree browsertree browsertreeex 6.5
login (wdk layer) login loginex 6.5

login (webtop layer) login loginex 6.5
main main mainex 6
display_preferences display_preferences display_ 6
preferences_ex
dqlsearchdelegate dqlsearchdelegate none (removed) 6
dqlsearchdelegate dqlsearchdelegate none (removed) 6
all drilldown drilldownXXX same, deprecated 6
components
general_preferences general_preferences general_ 6
preferences_ex
search (webtop layer) searchex_component. search60 6
xml
search (webcomponent search_component. search60 6
layer) xml
To disable 5.3 customizations that you may have added to a WDK 6 application, copy this element to
your custom app.xml and remove the <version> element for 5.3:
<supported_versions>
<version>6.0</version>
<version>5.3</version>
</supported_versions>
Supporting conditional value assistance in advanced

search
Since: version 6
Effort: moderate, in one JSP page
Conditional value assistance is supported. It requires your custom advanced search component to
use individual search attribute controls. The searchattributegroup tag provides only simple attribute
assistance.
The lists of conditional values are set in Documentum Composer. Query value assistance can use a
reference ($value(attribute)), for example:
SELECT "MyDocbase"."MyTable"."MyColumn1" FROM "MyDocbase"."MyTable"
WHERE "MyDocbase"."MyTable"."MyColumn2" = '$value(MyAttribute)'
The following example lists four attributes, three of which have conditional value assistance lists that
were set up in Documentum Composer. The drop‑down list for Make determines the list available for
Model. The drop‑down lists Fuel and Year both depend on Model.
Figure 4. Conditional value assistance in search
This UI was generated from the following set of controls in the JSP page:
<tr>
<td>Make:</td>
<td><dmfxs:searchattribute name='make' attribute="make"/></td>
</tr>
<tr>
<td>Model:</td>
<td><dmfxs:searchattribute name='model' attribute="model"/></td>
</tr>
<tr>
<td>Year:</td>
<td><dmfxs:searchattribute name='year' attribute="year"/><td>
</tr>
<tr>
<td>Fuel:</td>
<td><dmfxs:searchattribute name='fuel' attribute="fuel"/></td>
</tr>
Assigning relationships
Since: version 6
Effort: none
A user can create a relationship between any two documents in the repository. A user can also
delete a relationship between two documents. This feature requires a version 6.5 Content Server
and repository.
Lifecycle enhancements
Since: version 6
Effort: none
Lifecycle is now displayed on the Properties Screen (part of the default attribute set). Lifecycle is
exposed as a column in object lists. Users are able to apply a lifecycle on documents at creation time
(and Import, Create, Checkin), or later, via the Properties screen. The process of applying a lifecycle to
a document has been enhanced to include the ability to specify the initial lifecycle state and the alias
set. The current success/error messages for the lifecycle‑related actions displayed on the Message Bar
that involve a lifecycle state change (Apply, Detach, Promote, Demote, Suspend and Resume) will be
enriched to contain pertinent information about the object lifecycle state (previous and current).
Chapter 8
DFC, BOF and WDK Application
Migration to DFS
Documentum Foundation Classes (DFC), Business Object Framework (BOF), and WDK‑based
application customizations are a part of many enterprise applications. Documentum Foundation
Services (DFS) is the new EMC Documentum service‑oriented architecture that facilitates application
development and produces high quality, maintainable systems. Should existing applications migrate
to DFS? There is no single answer that applies to all custom applications. Table 17, page 95 will help
you decide whether to migrate your applications to the new service‑oriented architecture. Details
for these decisions are provided after the table.
Table 17. Developing custom applications
Existing Custom Application Migrate to DFS Do not migrate

DFC or BOF custom Can migrate to DFS if you have No migration if you do not
applications a web services client have a web services client
WDK‑based application Migrate if you have few UI Do not migrate f you have
customizations and a preferred major UI customizations or no
web services client web services client
TaskSpace application Migration not recommended Continue development with
WDK and BOF modules
Existing DFC and BOF custom application — DFS does not involve rendering or application‑specific
logic. DFS is a DFC client and supports all BOF customizations. DFS requires a consumer of web
services to render the UI. If your custom application uses DFC, with or without custom BOF services,
it may be rewritten to use DFS if the features you use are available in DFS. You will need to build DFS
services to expose your BOF code. BOF TBOs and aspects are natively supported by DFS.
Existing DFC and BOF custom applications can be migrated to DFS if you have a web services client
to render the custom application such as Struts, JSF, ASP.NET, or Flex.
Note: BOF modules cannot consume DFS services directly.
Existing WDK‑based custom application — If DFS provides feature parity and your WDK‑based
application does not have a heavily customized UI, it can be replaced by DFS and a web services
client to render the custom application such as Struts, JSF, ASP.NET, or Flex. If you migrate the
application to DFS and a web services client, you will not be able to apply service packs or future
releases of WDK, Webtop, or the Webtop‑based application.
DFC, BOF and WDK Application Migration to DFS
Heavily customized WDK‑based applications would generally require much work to replace features
using DFS and a web services client. For new customizations of a WDK‑based application, move
business logic to BOF modules or aspects so that they can easily be reused when you migrate to
web services at a later time.
Existing TaskSpace custom application — TaskSpace is built on WDK, so the guidelines above for
WDK‑based applications would apply to customized TaskSpace applications. If you migrate the
application to DFS and a web services client, you will not be able to apply service packs or future
releases of TaskSpace.
Developing new custom logic in your applications — Whether your existing application is
DFC‑based or WDK‑based, you should develop custom business logic by building BOF services and
aspects. When you deploy your service on the global registry, your logic is available to all applications
using the global registry, and your custom logic will be easily migrated to a web service in the future.
Moving an existing application to a web services UI — If you have identified a web services UI
for your custom application, you can migrate the application to DFS. Note the guidelines above
for DFC, BOF and WDK custom applications.
Appendix A
Migrating DMCL APIs to DFC
This chapter provides information that can help you migrate a DMCL‑based application to a DFC
application. Please also consult the Documentum Foundation Classes Version 6.5 Release Notes for any
known limitations or exceptions to the material in this appendix.
Overview
There are essentially three languages used to access the platform: Java, DocBasic, and C++.
If you are using Java for your customizations, they will continue to work in version 6.5. There have
been no changes to the methods or interfaces of existing classes.
In previous releases, DocBasic applications accessed the DMCL via dmcl40.dll (on Windows).
In version 6.5, DocBasic applications will automatically access the new dmcl.dll, which passes
instructions back and forth to DFC via an emulator.
C++ accesses DMCL through dynamic links. Applications can be configured to work with dmcl40.dll,
which ships with version 6.5 for backward compatibility. The applications will continue to work,
but they will be working with, in essence, the 6.0 version of DMCL (with some bug fixes). C++
applications using the dmcl40.dll will not have access to methods or interfaces introduced in version
6.5 and future releases.
Methods with no corresponding DFC method

The following methods are not implemented in DFC 6.5:
• Listmessage
• Lpq
• Reset
• Unprint
Methods with corresponding DFC methods

Table 18, page 98 lists the DMCL API methods and the corresponding DFC methods. The listing is
intended to help you migrate a DMCL‑based application to DFC. It is not intended as a complete
listing of all DFC methods.
Table 18. DMCL API methods and corresponding DFC methods
DMCL API method DFC correspondence

Interface Method name
Abort, for transactions IDfSession abortTrans
IDfSessionManager abortTransaction
Abort, for work flow IDfWorkflow abort
Acquire IDfWorkItem acquire
Addigsignature IDfSysObject addDigitalSignature
Addesignature IDfSysObject addESignature
Addactivity IDfProcess addActivity
Addlink IDfProcess addLink
Addnote IDfSysObject addNote
IDfPackage appendNote
Addpackage IDfWorkflow addPackage
IDfWorkitem addPackageEx
Addpackageinfo IDfActivity addPackageInfo,
addPackageInfoEx
Addport IDfActivity addPort
Addrendition IDfSysObject addRendition, addRenditionEx,
addRenditionEx2,
addRenditionEx3,
Addroutecase IDfActivity addRouteCase, addCondition‑
RouteCase
Anyevents IDfSession hasEvents
Append IDfTypedObject appendBoolean, appendInt,
appendDouble, appendId,
appendString, appendTime,
appendValue
Appendcontent IDfSysObject appendContent, appendCon‑
tentEx
Appendfile IDfSysObject appendFile
Appendpart IDfSysObject appendPart

Appendstate IDfPolicy appendState
Apply IDfSession, IDfQuery apply, in IDfSession
execute, in IDfQuery
Archive IDfSession archive
Assemble IDfSysObject assemble
Assume IDfSession assume
Attach IDfSysObject attachPolicy, detachPolicy
Audit IDfAuditTrailManager registerEventForType,
registerEventForObject,
registerEvents, register
EventsFromQuery,
registerEventsInFolder
Authenticate IDfClient authenticate
IDfSession
IDfSessionManager
Begintran IDfSession beginTrans
IDfSessionManager beginTransaction
Bindfile IDfSysObject bindFile
Branch IDfSysObject branch
Cachequery IDfQuery execute
Changepassword IDfSession changePassword
Checkin IDfSysObject checkin
Checkinapp IDfSysObject checkinEx
Checkout IDfSysObject checkout, checkoutEx
Close IDfCollection close
Commit IDfSession commitTrans
IDfSessionManager commitTransaction
Complete IDfWorkitem complete, completeEx,
completeEx2
Connect IDfSessionManager newSession
IDfClient
Count IDfTypedObject getAttrCount
Create IDfSession newObject, newObjectWithType
Createaudit IDfAuditTrailManager createAudit

Datatype IDfTypedObject getAttrDataType
Delegate IDfWorkitem delegateTask
Demote IDfSysObject demote, scheduleDemote,
cancelScheduleDemote
Dequeue IDfSession dequeue
Dereference IDfReplica dereferenceReplica
IDfMirror dereferenceMirror
Describe IDfSession describe
Destroy IDfPersistentObject destroy
Disassemble IDfSysObject disassemble
Disconnect IDfSession disconnect (in IDfSession)
IDfSessionManager release (in IDfSessionManager)

Dump IDfTypedObject dump
Dumpconnection IDfSessionManager Use getStatistics method in
IDfSessionManager to return
an IDfStatisticsManger object,
which has the getDocbases
and getSessions methods,
which return information
equivalent to that returned by
Dumpconnection
Dumploginticket
Encryptpass IDfClient encryptPassword
Execquery IDfQuery execute
Execsql
Execute IDfWorkflow execute
Fetch IDfSession getObject, getObjectWith‑
Caching
Flush IDfSession flush
Flushcache IDfSession flushCache
Flushconnectpool IDfSessionManager clearIdentities
Freeze IDfSysObject freeze

Get IDfTypedObject getBoolean, getInt, getDouble,
getId, getString, getTime,
getValue
getRepeatingBoolean, getRe‑
peatingInt, getRepeatingDouble,
getRepeatingId, getRepeat‑
ingString, getRepeatingTime,
getRepeatingValue
Getconnection IDfSessionManager newSession
Getcontent IDfSysObject getContent
Getdocbasemap IDfDocbrokerClient getDocbaseMap
getDocbaseMapFromSpecific‑
Docbroker
Getdocbrokermap IDfDocbrokerClient getDocbrokerMap
Getevents IDfSession getEvents
Getfile IDfSysObject getFile, getFileEx, getFileEx2
Getlastcoll IDfSession getLastCollection
Getlogin IDfSession GetLoginTicket, getLoginTicke‑
tEx, getLoginTicketForUser
Getmessage IDfSession getMessage
Getpath IDfSysObject getPath, getPathEx, getPathEx2

Getservermap IDfDocbrokerClient getServerMap
getServerMapFromSpecific‑
Docbroker
Grant IDfSysObject grant,
see also grantPermit

Halt IDfWorkflow halt, haltEx, haltAll
Id IDfSession getIdByQualification (in
IDfSession)
IDfTypedObject
getObjectId (in IDfTypedObject)
Initcrypto IDfClient initCrypto
Insert IDfTypedObject insertBoolean, insertInt,
insertDouble, insertId,
insertString, insertTime,
insertValue
Insertcontent IDfSysObject insertContent, insertContentEx

Insertfile IDfSysObject insertFile, insertFileEx
Insertpart IDfSysObject insertPart
Insertstate IDfPolicy insertState
Install IDfActivity, IDfPolicy, install
IDfProcess
Invalidate IDfActivity, IDfPolicy, invalidate
IDfProcess
Iscached
Kill IDfSession killSession (for sessions)
flushObject (for SysObjects)

Link IDfSysObject link
Listconnection IDfSessionManager Use getStatistics method in
IDfSessionManager to return
an IDfStatisticsManager object,
which has the getDocbases and
getSessions methods, which
return information equivalent to
that returned by Listconnection
Locate IDfTypedObject findBoolean, findInt, findDouble,
findId, findString, findTime,
findValue
Lock IDfPersistentObject lock
Mark IDfSysObject mark
Mount IDfSysObject mount
Movestate IDfPolicy moveState
Next IDfCollection next
Offset IDfTypedObject findAttrIndex
Pause IDfWorkitem pause
Print IDfSysObject print
Promote IDfSysObject promote, schedulePromote,
cancelSchedulePromote
Prune IDfSysObject prune
Publish_dd IDfSession publishDataDictionary
Purgelocal IDfSession purgeLocalFiles
Query_cmd IDfQuery execute
Query IDfQuery execute

Queue IDfSysObject queue
IDfWorkflow
IDfWorkitem
Readquery IDfQuery execute
Refresh IDfReplica refreshReplica
IDfMirror refreshMirror
Register IDfSysObject registerEvent
Reinit IDfSession reinit
Remove IDfTypedObject remove
Removeactivity IDfProcess removeActivity
Removecontent IDfSysObject removeContent
Removelink IDfProcess removeLink
Removenote IDfSysObject removeNote
Removepackage IDfWorkitem removePackage
Removepackageinfo IDfActivity removePackageInfo
Removepart IDfSysObject removePart
Removeport IDfActivity removePort
Removerendition IDfSysObject removeRendition,
removeRenditionEx,
removeRenditionEx2
Removeroutecase IDfActivity removeRouteCase
Removestate IDfActivity removeState
Repeat IDfWorkitem repeat
Repeating IDfTypedObject isAttrRepeating
Resolvealias IDfSysObject resolveAlias
IDfSession
Restart IDfSession restart
IDfWorkflow restartAll (for work flow)

Restore IDfSession restore

Resume for lifecycles: IDfSysObject resume, scheduleResume,
cancelScheduleResume
IDfworkflow (IDfSysObject)
IDfWorkitem resume, resumeAll
(IDfWorkflow)
resume (IDfWorkitem)
Retrieve IDfSession getIdByQualification (in
IDfSession)
IDfTypedObject
getObjectId (in IDfTypedObject)
Revert IDfPersistentObject revert
Revoke IDfSysObject revoke
see also revokePermit

Save IDfPersistentObject save
Saveasnew IDfSysObject saveAsNew
Seek IDfContentCollection seek, seekEx
Set IDfTypedObject setBoolean, setInt, setDouble,
setId, setString, setTime, setValue
setRepeatingBoolean, setRe‑
peatingInt, setRepeatingDouble,
setRepeatingId, setRepeat‑
ingString, setRepeatingTime,
setRepeatingValue
Setbatchhint IDfSession setBatchHint
Setcontent IDfSysObject setContent, setContentEx,
setContentEx2
Setcontentattrs setContentAttrs
Setdoc IDfSysObject setIsVirtualDocument
Setfile IDfSysObject setFile, setFileEx
Setoutput IDfWorkitem setOutput, setOutputByActivi‑
ties
Setpath IDfSysObject setPath
Setperformers IDfWorkflow setPerformers
Setpriority IDfWorkitem setPriority
Setsupervisor IDfWorkflow updateSupervisorName
Shutdown IDfSession shutdown
Signoff IDfPersistentObject signoff

Suspend IDfSysObject suspend, scheduleSuspend,
cancelScheduleSuspend
Trace IDfSession TraceDMCL
Truncate IDfTypedObject removeAll, truncate
Type IDfSession getTypeDescription
Unaudit IDfAuditTrailManager unRegisterEvent,
unRegisterEventForType,
unregisterEvents,
unRegisterEventsFromQuery,
unRegisterEventsInFolder,
unRegisterAllEvents
Unfreeze IDfSysObject unfreeze
Uninstall IDfActivity, IDfPolicy, uninstall
IDfProcess
Unlink IDfSysObject unLink
Unlock IDfSysObject cancelCheckOut
Unmark IDfSysObject unMark
Unregister IDfSysObject unRegisterEvent
Updatepart IDfSysObject updatePart, updatePartEx
Useacl IDfSysObject useACL
Validate IDfActivity, IDfPolicy, validate, validateProcessAndAc‑
IDfProcess tivities
Values IDfTypedObject getValueCount
Vdmpath IDfObjectPath getAccessPath, getAccessible‑
FolderIds
Vdmpathdql IDfObjectPath getAccessPath, getAccessible‑
FolderIds
Verifyaudit IDfPersistentObject verifyAudit
Verifyesignature IDfSysObject verifySignature
Appendix B
Object Type and Property Changes for
version 6.5
These tables describe types and properties that are new, changed, deprecated, or obsolete in version
65.
New object types

Table 19, page 107 lists the new object types for version 6.5.
Table 19. New Object Types
Type Name Description

dm_bocs_config Records configuration information for a BOCS server
dm_client_registration Records a client instance’s registration, for use in authorizing
permission and privilege escalation requests
dm_client_rights Records the privileged roles a client instance is allowed to assert.
dm_cont_transfer_config Defines content transfer capabilities for a distributed environment
dmc_class Added with Smart Container DAR file.
dmc_constraint_set Added with Smart Container DAR file.
dmc_metamodel Added with Smart Container DAR file.
dm_dms_config Records configuration information for a DMS server
dm_lightweight Serves as a supertype for all user‑defined lightweight object types.
This is a ’pseudo’ type in that there are no repository tables for this
type and instances of this type cannot be created.
This type is only for internal use in 6.5.

dm_message_route_user_ Records route‑specific user information for an email message
data
dm_validation_descriptor Used internally in distributed environments
dmc_preset_package Installed with the Preset DAR file during repository configuration.
Used by WDK‑based applications
Object Type and Property Changes for version 6.5

dmc_preset_info Installed with the Preset DAR file during repository configuration.
Used by WDK‑based applications
dmc_relationship_def Defines a relationship. This provides a higher level of abstraction
for relationships, allowing easier management and querying of
relationships by applications.
dmc_scope_config_ Installed with the Preset DAR file during repository configuration.
relation Used by WDK‑based applications
The following object types These types support the ability to add structured data to a workflow.
are added to support a
new workflow feature:
dmc_wfsd_element
dmc_wfsd_element_
boolean
dmc_wfsd_element_date
dmc_wfsd_element_
double
dmc_wfsd_element_
integer
dmc_wfsd_element_string
dmc_wfsd_parent
dmc_type_info
dmc_wfsdrp_boolean
dmc_wfsdrp_date
dmc_wfsdrp_double
dmc_wfsdrp_integer
dmc_wfsdrp_string
dmc_wfsdrp_parent
The following types These types are installed with the Collaboration Services DocApp.
are added to support
Collaboration Services:
dmc_calendar
dmc_calendar_event
dmc_datatable
dmc_datatable_row
dmc_datatable_schema
dmc_datatable_settings
dmc_xfm_adaptor_config Records information about a forms adaptor.
Changed object types

Table 20, page 109 lists the changes to existing types.
Table 20. Changed Object Types

dm_acs_config Added the following properties:
• server_major_version
• server_minor_version
Modified the following properties:

• acs_rw_capability
• is_cache_acs
dm_activity Added the following properties:
• activity_group_flag
• activity_group_id
• exec_retry_interval
• exec_retry_max
• post_timer_calendar_flag
• post_timer_calendar_id
• pre_timer_calendar_flag
• pre_timer_calendar_id
• r_performer_cond_id
• r_performer_cond_name
• r_performer_cond_user
• r_port_type, from string(8) to string(16)
• sd_element_flag
• sd_element_name
The following string properties were lengthened to 128:

• r_package_name
• resolve_pkg_name
The following properties have new values added to their valid

values:
• exec_err_handling
• exec_subtype

dm_aspect_type Added the following properties:
• i_attr_def
• is_data_shared
dm_audittrail Added the following property:
• attribute_list_old
dmi_audittrail_attrs Added the following property:
• attribute_list_old
dmc_completed_workitem Lengthened the following property:
• act_name
dmr_content Added the following properties:
• i_parked_state
• other_file_size
dm_dd_info Added the following property:
• fulltext_support
Note: Used only for lightweight object subtypes.
The reference_kind property, previously unused, is now used by

Collaboration Services for internal purposes.
dm_dd_attr_info Added the following new property:
• ftindex_attrs
Note: Used only for lightweight object subtypes.
The reference_kind property, previously unused, is now used by

Collaboration Services for internal purposes.
dm_docbase_config Added the following properties:

• audit_old_values
• docbase_roles
• r_normal_tz
• approved_clients_only

dm_format Added the following property:
• a_page_plugin_name
Modified the following property:

• mime_type
This property was lengthened from 64 to 256 in 5.3 SP5.

dm_func_expr Lengthened the following property:
• object_alias
dm_group Added the following properties:
• i_nondyn_supergroups_names
• is_module_only
• is_protected
dm_ldap_config Added the following properties:
• failover_ldap_config_ids
• failover_use_interval
• map_rejection
• retry_count
• retry_interval
Modified the following properties:

• map_val_type
Added support for the value ʺE” (meaning expression) for this
property
dm_media_profile Added the following properties:
• filter_names
• filter_values
• related_objects_only
• src_obj_type
dm_message_address The addr_type property was lengthened from string(1) to string(2)
dm_message_route The following property was added:
• route_user_data_hash_id
dmc_module Added the following properties:
• a_is_privileged
• a_privilege_roles

dm_process Added the following properties:
• act_performer_from
• act_performer_rule
• act_performer_to
• calendar_id
• execution_flag
• post_timer_calendar_flag
• post_timer_calendar_id
• pre_timer_calendar_flag
• pre_timer_calendar_id
• sd_element_acl
• sd_element_default_acl
• sd_element_default_value
• sd_element_name
• sd_element_options
• sd_element_parent_id
• sd_element_type

• act_choose_by
• act_choose_for
• act_choose_name
• r_link_dest_act
• r_link_src_act
dm_public_key_certificate Modified the following properties:
• key_type
• private_key_identifier
dmi_queue_item Lengthened the following property:
• task_name

dm_relation_type Added the following property:
• a_controlling_kind
dm_retainer Added the following property:
• aging_method
dmc_routecase_condition Lengthened the following property:
• a_object_alias
dm_smart_list Added the following new properties:
• has_results
• query_type
• results_count
• selected_sources
dm_sysobject The a_extended_properties property is no longer used to record
the object ID of the room governing the object if the object is in
a room. A SysObject’s governing room is now recorded in the
a_gov_room_id property, which is an aspect property associated
with the SysObject when the Sysobject is placed in the room.
dmc_transition_condition Lengthened the following property:
• r_object_alias
dm_type Added the following new properties:
• attr_identifier
• attr_restriction
• next_attr_identifier
• type_category
dmi_type_info Added the following new properties:
• i_type_features
• type_version
• default_aspects
dmc_aspect_type Added the following new properties:
• i_attr_def
• is_data_shared

dm_workflow Added the following new properties:
• correlation_identifer
• initiate_act
• parent_act_name
• parent_act_seqno
• parent_id

• r_act_name
• r_perf_act_name
dmi_workitem Added the following properties:
• r_exec_retried_count
• r_handling_instruction
• r_next_retry_date
• r_target_task_id
The following string property was lengthened to 128:

• r_runtime_state
dmc_workqueue Lengthened the following string property to 128:
• package_name
dmc_wf_package_skill Added the following new property:
• skill_info_ids
dmi_wf_timer Added the following new properties:
• r_calendar_id
• r_calendar_status
Lengthened the following string property to 128:

• r_act_name
dmc_workqueue_policy Added the following new properties:
• calendar_id
• increment_priority_method
• increment_priority_mode
Deprecated or obsolete properties

Table 21, page 115 lists the persistent properties that are either deprecated or obsolete as of version 6.5.
Table 21. Deprecated and obsolete properties
Object type Property Deprecated or obsolete

session config docbase_scope obsolete
Table 22, page 115 lists the computed properties that are either deprecated or obsolete as of version 6.5.
Table 22. Deprecated and obsolete computed properties
Object type Property Deprecated or obsolete

_content_buffer S obsolete
Properties added conditionally

The properties listed in Table 23, page 115 are only added to an object type under certain conditions.
The description of each property explains the property’s use and the conditions under which it
appears in a object type definition.
Table 23. Properties added conditionally
Property Datatype Single/ repeating Description

i_shared_status integer S This property is added to the
object type definitions of types
that are created as shareable
types. Only dm_sysobject or its
subtypes can be shareable types.
Note: Shareable types are
currently only used internally.
Users and applications cannot
create shareable types.
The property indicates whether

an instance of the object type
is shared by any lightweight
object. Valid values are:
0, the object is not shared
1, the object is shared
Property Datatype Single/ repeating Description

i_property_bag string(2000) S This property is added to an
object type if the type definition
contains a NONQUALIFIABLE
property. The property can also
be explicitly added by altering
the object type.
The property stores the

names and values of
NONQUALIFIABLE properties.
It is also used to store the
names and values of aspect
properties if the properties are
added to the aspect with the
OPTIMIZEFETCH option.
r_property_bag string(2000) S This property is added to an
object type if the type definition
contains a NONQUALIFIABLE
property. Altering a type to
add i_property_bag also adds
r_property_bag automatically.
This property stores any

overflow from i_property_bag.
Deprecated or obsolete object types

Table 24, page 116 lists the changes to existing types.
Table 24. Deprecated or Obsolete Object Types
Type Name Deprecated Obsolete

dmi_linkrecord X
dm_linked_store X
dm_router X
enable_workitem_mgmt Boolean Previously used to enable
workqueue use
Changed properties
The implementation of the local_diskfull_limit property in the non‑persistent objects that define a
session configuration’s configuration has changed. Previously, the limit specified in this property was
expressed as a percentage. For version 6.5, the limit value is now expressed as a number of megabytes.
Valid values are now from 0 and 100. Values from 1 to 100 are interpreted as megabytes. For example,
a value of 50 means that the client local area is limited to 50MB in size. A value of 0 means that
the size is unlimited.
Appendix C
Deployment Settings in WDKbased
Application Deployment
These tables list the mandatory and optional configuration elements that can be set before, during,
and after deployment of WDK‑based applications. Because WDK‑based applications encapsulate
DFC, you can also configure DFC settings as described in dfcfull.properties located in the
WEB‑INF/classes directory of the WDK‑based application. Functions marked with an asterisk (*)
must be performed for every deployment.
Table 25, page 119 lists the configuration elements that must be set before deploying a WDK‑based
application, such as Webtop or TaskSpace. Not all of these elements must be set for every deployment,
but if you wish to support the function in the first column, you must enable it before deployment.
Refer to Web Development Kit and Webtop Deployment Guide for more information on these settings.
Table 25. Mandatory configuration before deployment
Function Element Location

Turn off tag pooling (Tomcat, servlet.init‑param web.xml
Oracle)*
Global registry indications* dfc.docbroker.host dfc.properties in
dfc.globalregistry.repository WEB‑INF/classes
dfc.globalregistry.username
dfc.globalregistry.password
WAS compiler and classloader* Classloader order WAS admin console
useJDKCompiler
Table 26, page 119 lists the optional configuration settings that can be set before deployment.
Table 26. Optional configuration before deployment

WAS failover NoAffinitySwitchBack WAS cluster configuration
WAS global security Security policies and Download from Powerlink if
environment variables needed
UCF to use file, not Windows registry.mode ucf.installer.config.xml
registry
Deployment Settings in WDKbased Application Deployment

Default content transfer option ucf.installer.config.xml
directories for client
Unsigned SSL certificates option ucf.installer.config.xml
Proxy servers http11.chunked.transfer ucf.server.config.xml in
WEB‑INF/classes
Set content transfer mode contentxfer.default‑mechanism custom/app.xml
Add filter for groups contentxfer.mechanism
Change ACS and BOCS contentxfer.accelerated‑read custom/app.xml
behavior contentxfer.accelerated‑write
Locale settings language custom/app.xml
Java EE principal principal credentials TrustedAuthenticator‑
authentication Credentials.properties in
WEB‑INF/classes/com/docu‑
securityconstraint mentum/web/formext/session
web.xml in WEB‑INF
Table 27, page 120 lists the configuration settings that can be changed after deployment. For
non‑deployment related configuration, refer to WDK and Webtop Reference Guide. This guide lists all
configurable elements in WDK and configuration files and tag libraries and notes in which release
the change was introduced.
Table 27. Optional configuration after deployment

App server timeout sessionconfig web.xml in WEB‑INF
Cached pages init‑param web.xml in WEB‑INF
Deep export deepexport custom/app.xml
Default repository authentication.docbase custom/app.xml
Email message archive messageArchive‑support custom/app.xml
Enable accessibility accessibility custom/app.xml
Encrypt passwords for com.documentum.
drl, drlauthenticate, and web.formext.session.
virtuallinkconnect TrustedAuthenticatorTool
Failover: turn off failover.enabled custom/app.xml
IRM support irm‑support custom/app.xml
Lightweight sysobject parent lightweight‑sysobject custom/app.xml
display
Modal popup modalpopup custom/app.xml
Preferences repository (default preferencesrepository custom/app.xml
= global registry)

Presets repository (default = presets custom/app.xml
global registry)
Saved credentials save_credentials custom/app.xml
Timeout warning timeout_control custom/app.xml
UCF mechanism contentxfer custom/app.xml
Appendix D
Changes to Webtop Cascading
Stylesheets
The majority of styles used in Webtop are defined in webforms.css. To see new styles that you can
use in your JSP pages, you can use a differencing utility to compare the stylesheets from your old
application to the 6.5 application.
The following selectors were removed from webforms.css:
.buttonLink
{
fontfamily: Trebuchet MS, Verdana, GillSans, Arial;
color: #333333;
textdecoration: none;
fontsize: 12px;
lineheight: 14px;
fontweight: normal;
}
.buttonDisabledLink
{
color: #999999;
fontsize: 12px;
lineheight: 14px;
}
.actionButtonLink
{
color: #333333;
fontsize: 12px;
lineheight: 14px;
}
.actionButtonDisabledLink
{
color: #999999;
fontsize: 12px;
lineheight: 14px;
}
.bannerbox
{
background: white url("../images/banner/top_left.gif") norepeat top
left;
Changes to Webtop Cascading Stylesheets
Appendix E
dfc.properties
These topics re included:

• Overview, page 125
• Changes to existing key names, page 125
• dmcl.ini key migration to dfc.properties, page 128
• Obsolete dmcl.ini and session configuration options, page 129
• Obsolete dfc.properties keys, page 131
Overview
In version 6, DFC replaced the Server API as the API for Content Server. As part of this change,
the dmcl.ini file became obsolete and its relevant entries were migrated to the dfc.properties file.
In addition, the naming conventions for entries in the dfc.properties file were standardized. This
appendix describes the changes to the dfc.properties file.
Changes to existing key names

Table 28, page 125, describes the changes to existing key names. Both new and old names are listed.
For backward compatibility, both new and old names continue to work in version 6.5. Invalid entries
do not generate an error, but have no effect on functionality.
Table 28. Name changes for existing dfc.properties for version 6.5
Old name New name

dfc.acs.avail.refresh.frequency dfc.acs.avail.refresh_interval
dfc.acs.config.refresh.frequency dfc.acs.config.refresh_interval
dfc.acs.network_location.refresh.frequency dfc.acs.network_location.refresh_interval
dfc.admin.ldif.file.charset dfc.admin.ldif_file_charset
dfc.appledouble.resource.file.extension dfc.appledouble.resource_file_extension
dfc.cacs.check.http.method dfc.bocs.check.http_method
dfc.properties
Old name New name

dfc.cacs.check.keep.number dfc.bocs.check.keep_number
dfc.bocs.config.refresh.frequency dfc.bocs.config.refresh_interval
dfc.cache.append.name dfc.bof.cache.append_name
dfc.bof.cacheconsistency.interval dfc.bof.cache.currency_check_interval
dfc.bof.registry.connect.attempt.interval dfc.globalregistry.connect_attempt_.interval
dfc.bof.registry.preload.enabled dfc.bof.cache.enable_preload
dfc.bof.registry.password dfc.globalregistry.password
dfc.bof.registry.repository dfc.globalregistry.repository
dfc.bof.registry.username dfc.globalregistry.username
dfc.cache.ddinfo.globalCacheSize dfc.cache.ddinfo.size
dfc.cache.dir dfc.cache_dir
dfc.cache.object.globalCacheSize dfc.cache.object.size
dfc.cache.query.globalCacheSize dfc.cache.query.size
dfc.core.truncate_long_values dfc.compatibility.truncate_long_values
dfc.config.timeout dfc.config.check_interval
dfc.checkout.dir dfc.data.checkout_dir
dfc.data.dir dfc.data.dir
dfc.docbase.max_deadlock_retries dfc.session.max_deadlock_retries
dfc.docbase.max_error_retries dfc.session.max_error_retries
dfc.exception.include_decoration No change
dfc.exception.include_id No change
dfc.exception.include_stack No change
dfc.export.dir dfc.data.export_dir
dfc.housekeeping.cleanup.interval dfc.resources.cleanup_interval
dfc.max.vdm.children.flush.count dfc.vdm.max_children_flush_count
dfc.recordInlineDescendants dfc.xml.record_inline_descendants
dfc.registry.file No change
dfc.registry.mode No change
dfc.resources.diagnostics.enabled dfc.diagnostics.resources.enable
dfc.search.docbase.brokers dfc.search.docbase.broker_count
dfc.search.ecis.adapter.domain No change
dfc.search.ecis.brokers dfc.search.ecis.broker_count
dfc.search.ecis.enable No change
dfc.search.ecis.host No change
dfc.search.ecis.password No change
dfc.properties
Old name New name

dfc.search.ecis.port No change
dfc.search.ecis.access.timeout dfc.search.ecis.request_timeout
dfc.search.ecis.name dfc.search.ecis.rmi_name
dfc.search.ecis.login dfc.search.ecis.username
dfc.search.formatcache.timeout dfc.search.formatcache.refresh_interval
dfc.search.fulltext.enabled dfc.search.fulltext.enable
dfc.search.ecis.max.results dfc.search.ecis.max_results
dfc.search.sourcecache.timeout dfc.search.sourcecache.refresh_interval
dfc.search.typecache.timeout dfc.search.typecache.refresh_interval
dfc.session.dynamic_delay No change
dfc.session.pool.enabled dfc.session.pool.enable
dfc.session.pool.timeout dfc.session.pool.expiration_interval
dfc.session.surrogate.check.interval dfc.session.surrogate.check_interval
dfc.session.surrogate.mode No change
dfc.storagepolicy.diagnostics.enabled dfc.diagnostics.storagepolicy.enable
dfc.storagepolicy.ignore.rule.errors dfc.storagepolicy.ignore_rule_errors
dfc.storagepolicy.validation.interval dfc.storagepolicy.validation_interval
dfc.strictURI dfc.xml.use_strict_uri
dfc.tracing.baseTraceFileName dfc.tracing.file_prefix
dfc.tracing.compactModeBufferSize dfc.tracing.compact_mode_buffer_size
dfc.tracing.enabled dfc.tracing.enable
dfc.tracing.entrancePointExprs dfc.tracing.method_name_filter
dfc.tracing.loggingMode dfc.tracing.file_creation_mode
dfc.tracing.maxFileSize dfc.tracing.max_file_size
dfc.tracing.maxThreadsToTrace dfc.tracing.max_threads_to_trace
dfc.tracing.maxUsersToTrace dfc.tracing.max_users_to_trace
dfc.tracing.mode No change
dfc.tracng.rpcCountingEnabled dfc.tracing.display_rpc_count
dfc.tracing.scriptableMethodsMarked dfc.tracing.display_scriptable_mark
dfc.tracing.stackDepth dfc.tracing.max_stack_depth
dfc.tracing.threadNameExprs dfc.tracing.thread_name_filter
dfc.tracing.timestampDateFormat dfc.tracing.date_format
dfc.tracing.timingStyle dfc.tracing.timing_style
dfc.tracing.traceFileDirectory dfc.tracing.dir
dfc.properties
Old name New name

dfc.tracing.userNameExprs dfc.tracing.user_name_filter
dfc.user.dir dfc.data.user_dir
dfc.validation.expr.currency.check dfc.validation.expr.currency_check_interval
dfc.validation.expr.debug.all No change
dfc.validation.expr.debug.code No change
dfc.validation.expr.debug.eval No change
dfc.validation.expr.debug.tree No change
dfc.validation.expr.disable_java No change
dfc.validation.overrides.currency.check dfc.validaton.overrides.currency_check_
interval
dmcl.ini key migration to dfc.properties

Table 29, page 128 describes the dmcl.ini keys that migrated to the dfc.properties file in version 6.5.
Table 29. dfc.properties keys migrated from dmcl.ini file
dmcl.ini key Corresponding new dfc.properties key

application_code dfc.application_code
auto_request_forward dfc.docbroker.auto_request_forward
batch_hint_size dfc.batch_hint_size
backup_host dfc.docbroker.host
backup_port dfc.docbroker.port
backup_protocol dfc.docbroker.protocol
backup_service dfc.docbroker.service
backup_timeout dfc.docbroker.timeout
castore_write_max_attempts dfc.content.castore.write_max_attempts
castore_write_sleep_interval dfc.content.castore.write_sleep_interval
client_date_format dfc.date_format
client_locale dfc.locale
connect_pooling_enabled dfc.session.pool.enable
connect_retry_interval dfc.session.connect_retry_interval
connect_retry_limit dfc.session.connect_retry_limit
debug_dbid dfc.docbroker.debug.docbase_id
debug_host dfc.docbroker.debug.host
debug_port dfc.docbroker.debug.port
dfc.properties
dmcl.ini key Corresponding new dfc.properties key

debug_service dfc.docbroker.debug.service
docbroker_search_order dfc.docbroker.search_order
ini_file_path dfc.config.file
local_clean_on_init dfc.data.local_clean_on_init
local_diskfull_check dfc.data.diskfull_check
local_diskfull_limit dfc.data.diskfull_limit
local_path dfc.data.local_dir
local_purge_on_diskfull dfc.data.local_purge_on_diskfull
max_collection_count dfc.session.max_collection_count
max_session_count dfc.session.max_session_count
primary_host dfc.docbroker.host
primary_port dfc.docbroker.port
primary_protocol dfc.docbroker.protocol
primary_service dfc.docbroker.service
primary_timeout dfc.docbroker.timeout
re_binding_label dfc.reference.binding_label
secure_connect_default dfc.session.secure_connect_default
token_storage_path dfc.tokenstorage.dir
token_storage_enabled dfc.tokenstorage.enable
umask dfc.data.umask
use_compression dfc.content.use_compression
use_content_server dfc.content.use_content_server
Obsolete dmcl.ini and session configuration

options
Table 30, page 129 lists the dmcl.ini keys that are obsolete in version 6.5 and have no equivalent to set
in dfc.properties. It also lists properties formerly present in the session configuration objects that
are obsolete in version 6.5.
Table 30. Obsolete session configuration options
Entry Source Comments

block_during_rpc dmcl.ini Is specific to native code
DMCL.
client_codepage dmcl.ini none
dfc.properties

client_os_codepage dmcl.ini none
connect_callback_enabled api config and session config none
objects
connect_failure_callback api config and session config none
objects
connect_failure_data api config and session config none
objects
connect_success_callback api config and session config none
objects
connect_success_data api config and session config none
objects
content_callback_data api config and session config none
objects
content_callback_function api config and session config none
objects
local_diskfull_warn dmcl.ini none
network_callback_data api config and session config none
objects
network_callback_function api config and session config none
objects
new_connection_callback none
new_connection_data none
nfs_enabled dmcl.ini
r_trace_file dmcl.ini Replaced by new tracing
implementation—refer to the
Content Server Administrator’s
Guide for information.
r_trace_level dmcl.ini Replaced by new tracing
client_cache_size dmcl.ini Implementation now allows
per‑session caches to
dynamically adapt to free
memory.
connect_timeout dmcl.ini Is specific to native code
DMCL.
connect_recycle_interval dmcl.ini Is specific to native code
DMCL.
exception_count Is specific to native code
DMCL.
dfc.properties

exception_count_interval Is specific to native code
DMCL.
terminate_on_exception Is specific to native code
DMCL.
i_override_list
cache_queries
max_connection_per_session
use_local_always dmcl.ini Option to use server common
area is not available in DFC 6.5,
so this becomes unneeded
use_local_on_copy dmcl.ini Option to use server common
area is not available in DFC 6.5,
so this becomes unneeded
Obsolete dfc.properties keys

Table 31, page 131 lists the dfc.properties keys that are obsolete in version 6.5. Setting these keys
have no effect on DFC 6.5.
Table 31. Obsolete dfc.properties keys

dfc.tracing.combineDMCL dfc.properties Replaced by new tracing
dfc.tracing.compactMode dfc.properties Replaced by new tracing
dfc.tracing.recordParameters dfc.properties Replaced by new tracing
dfc.tracing.recordReturnValue dfc.properties Replaced by new tracing
dfc.properties

Index
A migration, 49
ACS dfc.compatibility.truncate_long_values, 25
configuration, 90 dfc.machine.id, 25
attribute, 25 dfc.properties, 25, 27
auto complete, 83 dfc.session.allow_trusted_login, 27
DFS, migration to, 95
differences
B DFC Java classes, 49
BOCS WDK Java classes, 55
configuration, 90 dm_bof_registry, 33
BOF, 49 dm_extern_file, 26
BOF2 modules dm_linkedstore, 26
migrating, 47 dm_startedworkitem, 25
dmcl.ini‑keys, 27
dmi_linkrecord, 26
C DocApps
CHANGE...OBJECT statement, 27 migrating, 47
CLEAN_LINKS, 26 DocList component, 73
<client_warning_session_timeout>, 56 DQL
column resizing, 73 CHANGE...OBJECT statement, 27
conditional value assistance, 92 date literals, 27
configuration migrating content, 47
WDK, 119 POSITION keyword, 27
configuration service extensions, 58 drag and drop, 85
consistency checker utility, 45 dump and load, 17
Content Server dynamic filters, 84
listener queue length, configuring, 28
content store
changing location, 18 E
content transfer applet, 90 email migration
introduction, 54
EMCMF
D displaying, 66
database enable_workitem_mgmt (server.ini
changing location, 17 key), 28
changing version, 17 export, deep, 87
datacolumnbeginswith, 84
datagrid enhancements, 70
date literals, 27 F
deep export, enabling, 87 fixed column headers, 74
DFC classes fixed menus, 59
Index
G menus
global registry fixed, 59
defined, 33 migrating
BOF2 and DocApps, 47
migrating content with DQL, 47
H migration
hotkeys, 76 overview, 12
key combination map, 78 modal popuup. See pop‑up, modal
XML definition, 77 modules
<hotkeys>, 77 migrating, 47
HotKeysNlsProp, 78
O
I OLE, enable scan, 88
IDfSession.setServerTraceLevel, 28 optical storage devices, 26
insertbefore, 58
installation order
new system, 12
P
IPv4 configuration, 49 performance
IRM support, 65 planning, 20
Server, common problems, 21
web application, 22
K planning worksheet
keyboard shortcuts, 76 application server host, 31
Planning worksheet
client machine, 31
L Content Server host, 30
LDIF file, 26 customized components, 32
lifecycle, 93 index server host, 31
lightweight sysobjects pop‑up, modal
migrating to, 24 disabling, 62
support in WDK, 67 invoking, 62
link scan, enable, 88 overview, 62
linked store storage areas, 26 refresh parent, 64
listener_queue_length, 28 window.location.replace, 65
listener_queue_length (server.ini key), 28 POSITION keyword, 27
login tickets preference persistence, 85
backwards compatibility, 46 presets, 57
LWSO
support in WDK, 67
LWSOs Q
migrating to, 24 query
performance enhancement, 22
M
max_backup_index, 27 R
max_file_size, 27 relationships, 93
memory renditions
application server usage, 20 viewing application per user, 89
DFC usage, 20 resizeable columns, 73
<menu>, 59 right‑click menus, 74
Index
row selection, 71 TBO, 49

themes, 91
timeout warning, 56
S Toolbar component, 75
safe harbor, 9 tracing, memory
SBO, 49 DFC, 20
server.ini file
enable_workitem_mgmt key, 28
server_login_ticket_version (server.ini U
key), 46 upgrade
shortcuts overview, 11
key combination map, 78
showifinvalid, 85
showinvalidactions, 85
V
Streamline, 90 value assistance, conditional, 92
SYNC_REPLICA_RECORDS, 26
system W
sizing, 19 WDK classes
system updates migration, 55
order, 13 work flow
enable_workitem_mgmt (server.ini
T key), 28
tab order, 81

Documentum 6.5 SP1 System Upgrade and Migration Guide

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Documentum 6.5 SP1 System Upgrade and Migration Guide

Transféré par

Droits d'auteur :

Formats disponibles

EMC ® Documentum ®

Upgrade and Migration Guide

P/N 300­008­607 A02

Chapter 1 Upgrade and Migration Overview ................................................................ 11

Chapter 2 Planning System Size and Enhancing Performance .................................... 19

Chapter 3 Planning the System Migration ................................................................... 23

enable_workitem_mgmt obsolete .................................................................. 28

Chapter 4 Interoperability and Compatibility ............................................................... 37

Chapter 5 Migrating Content Server ............................................................................ 45

Chapter 6 Migrating DFC Customizations .................................................................... 49

Chapter 7 Migrating WDK and Webtop Applications ................................................... 53

Migrating JSP menus to XML menus.............................................................. 59

Chapter 8 DFC, BOF and WDK Application Migration to DFS ...................................... 95

Appendix A Migrating DMCL APIs to DFC ...................................................................... 97

Appendix C Deployment Settings in WDK­based Application Deployment .................. 119

Figure 1. System installation order, new Documentum system .............................................. 13

Table 1. Upgrade and migration of product components ..................................................... 11

• Content Server Administration Guide

Revision Date Description

Upgrade and migration

Table 1. Upgrade and migration of product components

Component Migrate Upgrade

Component Migrate Upgrade

Order of new product installation

Figure 1. System installation order, new Documentum system

Order of system updates

Figure 2. System update order, existing Documentum system

Chapter 4, Interoperability and Compatibility provides information on version compatibilities

System upgrade strategies

Table 2. Upgrade strategy highlights

• production system taken offline during

• upgrades copy of production repository

• users switched over to a different production

• data migrated to new production repository

• users switched over to a different production

Figure 3. System upgrade scenarios

Changing the database OS and version

Changing the content store location

Migrating XML content to the XML store

Planning the system size

To determine the system load expectations

Planning for performance

Common problems in Server performance

Redundant connection brokers — Connection brokers (formerly known as docbrokers) can be

Replication — Replication can be configured either as read/write or read‑only.

Common problems in web application

Changes in supported environments

Table 3. Third­party product versions not supported in this release

Product Category Third‑party product Version

Product Category Third‑party product Version

Version 6.5 changes that impact Content Server

Migrating objects to lightweight sysobjects (LWSOs)

Changed behavior for attribute length

Maximum accepted string lengths in Documentum

Required conﬁguration for machine­only application

Audit trail entries for dm_startedworkitem enhanced

DFC does not support linked store storage areas

DFC does not support optical storage devices

DFC Full format speciﬁcations no longer accepted

SYNC_REPLICA_RECORDS administration method

LDIF ﬁle changes

Obsolete dmcl.ini keys

New dfc.properties key to turn off trusted login

P/N 300008607 A02

Appendix C Deployment Settings in WDKbased Application Deployment .................. 119

Table 3. Thirdparty product versions not supported in this release

Required conﬁguration for machineonly application

Upgrading thirdparty software

Table 10. Summary of productspeciﬁc limitations

Placing a custom component in a modal popup dialog

Deﬁning the available popup windows

Invoking a modal component in a popup window