Documentum 5.3 System Migration Guide

Transcription

Documentum 5.3 System Migration
Guide
Version 5.3
March, 2005
Copyright © 1994-2005 EMC Corporation
Table of Contents
Preface
Chapter 1
Chapter 2
.......................................................................................................................... 11
Documentum Overview
......................................................................... 13
What is Enterprise Content Management? ....................................................
Introducing the Documentum System ..........................................................
What Does a Typical Documentum 5 Installation Look Like? .....................
What is Content Server? ..........................................................................
What is Documentum Administrator?......................................................
What is ECI Services?..............................................................................
What are Documentum Application Builder and Application
Installer? ................................................................................................
What is DFC? .........................................................................................
What is Web Development Kit (WDK)? ....................................................
What is Documentum Desktop? ..............................................................
What is Webtop? ....................................................................................
13
13
14
14
15
15
.....................................................................
About Documentum Users ..........................................................................
What is a User?.......................................................................................
What is a Group? ....................................................................................
What is a Role? .......................................................................................
What are User Capabilities? ....................................................................
Core Concepts ............................................................................................
What is a Repository? .............................................................................
How Are Repositories and Servers Related? .............................................
What is Content? ....................................................................................
What is Your Checkout Directory? ...........................................................
What is a Workflow? ...............................................................................
What is Your Inbox?................................................................................
What is a Document Lifecycle? ................................................................
What is a Permission Set? ........................................................................
Work Queues Overview ..........................................................................
How Does Object Versioning Work? ........................................................
What Are Virtual Documents? .................................................................
Why Use Virtual Documents?..............................................................
Virtual Document Structure ................................................................
Introduction to Webtop ...........................................................................
Core Documentum End-User Tasks .............................................................
How Do You Connect to a Repository?.....................................................
What are Check-ins and Check-outs? .......................................................
How Do You Create or Alter Objects in the Repository? ............................
About Creating or Importing Objects ...................................................
About Editing Objects .........................................................................
About Moving Objects ........................................................................
About Copying and Pasting Objects .....................................................
About Deleting Objects .......................................................................
About Organizing Objects in Folders and Cabinets ...............................
21
Core Concepts and Tasks
16
17
18
19
20
21
21
22
22
23
23
23
24
25
25
26
26
26
27
27
28
30
31
31
33
33
33
33
34
34
35
35
35
35
36
3
Table of Contents
Chapter 3
Chapter 4
Chapter 5
4
How Do You View or Modify Information About Objects in the
Repository? ............................................................................................
36
The Documentum Security Model .........................................................
User Privileges ...........................................................................................
39
39
Object Permissions......................................................................................
Folder Security ...........................................................................................
Table Security .............................................................................................
ACLs .........................................................................................................
ACL Entries ...........................................................................................
Categories of ACLs .................................................................................
Template ACLs.......................................................................................
40
41
42
43
43
44
45
Trusted Content Services Security Features ..................................................
45
Preparing to Migrate ..............................................................................
What Is Migration? .....................................................................................
Planning Your Migration .............................................................................
Planning Infrastructure Changes .............................................................
Considerations ...................................................................................
Mapping Your Current Configuration ..................................................
Upgrade Roadmap .............................................................................
Determining Your Documentum 5 Configuration .................................
Planning for Changes Required by Mixed-Version Environments ..............
About Running Mixed-Version Environments ......................................
About Enabling RPS and Collaboration Features ..................................
Planning for Global Registries .............................................................
What are Service-Based Business Objects? ........................................
What are Type-Based Objects? .........................................................
Do You Need a Global Registry in Your Documentum
System? .........................................................................................
Preparing for the Business Objects Framework Global
Registry .........................................................................................
Backward Compatibility for Customized Applications ..........................
Overview of Major Migration Tasks .........................................................
47
47
48
48
48
49
51
51
52
52
57
58
58
58
Sample Pre-Migration Checklists and Worksheets.........................................
System Analysis Worksheets ...................................................................
Customization Analysis Worksheets ........................................................
62
62
66
Planning for Full-Text Indexing ..............................................................
Overview ...................................................................................................
Index Agent ...............................................................................................
Index Agent Modes ................................................................................
69
69
70
70
Index Server ...............................................................................................
About the Indexing Process .........................................................................
Full-Text Indexing Components Configuration Options ................................
Sharing the Drives Where Content Files are Located .....................................
Which Ports to Use for the Index Agent........................................................
71
71
71
71
72
Which Ports to Use for the Index Server .......................................................
Choosing Languages for Grammatical Normalization ...................................
Disk Space Requirements for Index Server ...................................................
Memory Requirements for Index Server .......................................................
72
72
73
73
58
60
60
60
Table of Contents
Planning for a New Repository ....................................................................
Installation Order ...................................................................................
Planning for Full-Text Migration..................................................................
Migrating Verity Customizations .............................................................
When to Migrate the Full-Text Indexing System........................................
Planning for Pre-Upgrade Migration........................................................
Installation Order for a Pre-Upgrade Migration ....................................
Planning for Post-Upgrade Migration ......................................................
Installation Order for a Post-Upgrade Migration ...................................
Chapter 6
Chapter 7
Migrating Content Server
73
74
74
74
75
75
76
77
78
...................................................................... 79
What’s New in Content Server? ...................................................................
The Content Server 5.3 Documentation Set ...................................................
Architecture Changes For Content Server .....................................................
Planning Your Migration .............................................................................
Supported Upgrade Paths .......................................................................
Overview of Migration Tasks...................................................................
Pre-upgrade Migration of Full-Text Indexes .........................................
Post-upgrade Migration of Full-Text Indexes ........................................
Changes to Server Features and Implementation ..........................................
Changes to Full-Text Indexing .................................................................
Obsolete Content Attributes ....................................................................
Additions to System Events .....................................................................
Changes to Existing Events .....................................................................
dm_startedworkitem ..........................................................................
dm_addrendition ...............................................................................
Addition of dm_retainer as a Target .....................................................
New Extended Permission for Users ........................................................
Privileged Groups ..................................................................................
Utility Changes and Additions ................................................................
New and Changed Object Types ..............................................................
New and Changed Attributes ..................................................................
Changed API calls ................................................................................
Changed Administration Methods .........................................................
DQL Changes .......................................................................................
SELECT statement changes ...............................................................
Obsolete Server.ini Keys ...................................................................
New DQL Hint .................................................................................
New Full Text Index Query Syntax ....................................................
Obsolete and Deprecated Types and Attributes ..........................................
Fulltext Index Object Type.....................................................................
Relation Object Type .............................................................................
Server Config Object Type .....................................................................
TDK Index Object Type .........................................................................
TDK Collect Object Type .......................................................................
Workflow Object Type ..........................................................................
79
80
81
82
82
82
85
86
86
86
87
87
88
88
88
88
89
89
90
90
97
101
102
104
104
104
105
105
105
105
108
108
109
109
109
Migrating WDK-based Applications .....................................................
What’s New in Web Development Kit and Webtop? ....................................
The WDK 5.3 Documentation Set ...............................................................
The Webtop 5.3 Documentation Set............................................................
111
111
114
114
Architecture Changes ...............................................................................
Planning Your Migration ...........................................................................
Supported Migration Paths ...................................................................
115
115
116
5
Table of Contents
Chapter 8
6
Overview of Migration Tasks for WDK-based Applications .....................
Overview of Migration Tasks for Customized Webtop
Applications.........................................................................................
Adding New 5.3 Features to Existing WDK Custom Applications ................
New User-Selected Columns Feature .....................................................
About Component Versioning ...............................................................
Implementing New Content Transfer Functionality ................................
About Implementing UCF in Existing WDK-based
Applications.....................................................................................
Enabling UCF Content Transfer for Components ............................
Using WDK 5.2.5 Content Transfer Components .............................
Specifying Which Content Transfer Mode Your
Application Uses ..........................................................................
Content Transfer Components, Classes, and Associated
JSP Pages .....................................................................................
Content Transfer Component Mapping (WDK 5.2.5 to 5.3) ..............
Implementing Multi-repository Support for Components........................
What is Multi-Repository Support? ....................................................
Replica (mirror), Reference, and Foreign Objects.................................
Adding Multi-Repository Support to a Component ............................
Scoping and Preconditioning Actions on Remote Objects ....................
Session Management with Multiple Repositories ................................
Configuring Roles and Client Capability ...............................................
Migrating Search Features .....................................................................
About Migrating Custom Search Components to WDK 5.3 ..................
New and Changed Search Components, Classes, and Layout
Files .................................................................................................
Migrating Virtual Document Manager Components ...............................
What’s New in Virtual Document Manager for WDK 5.3?....................
New and Changed VDM Components, Classes, NLS
Properties, and Layout Files ..............................................................
Adding Failover Support to Existing Applications ..................................
Configuring Global Failover Support ................................................
Controlling Session Data Serialization ................................................
Enabling Failover for Individual Components ....................................
Enabling Container Component Failover............................................
Adding Drag and Drop Support ............................................................
Enabling Drag and Drop for Individual Actions .................................
Migrating Existing Components for Location and Navigation .................
126
135
142
142
142
143
144
145
145
147
148
Migrating DFC or BOF-based Custom Applications ............................
What’s New in DFC? .................................................................................
New Interfaces and Types .....................................................................
Deprecated Features and Interfaces........................................................
Deprecated Methods .........................................................................
BOF Deployment Through DBOR ......................................................
Overriding Methods in TBOs ............................................................
Methods to override when implementing TBOs ..................................
Avoid Casting to Concrete Classes .....................................................
What’s New in BOF? .................................................................................
The DFC 5.3 Documentation Set ................................................................
Architecture Changes in DFC ....................................................................
Planning your Migration ...........................................................................
Who Should Migrate? ...........................................................................
Overview of DFC Migration Tasks .........................................................
Migrating from pre-5.2.x Versions of DFC ..........................................
179
179
180
180
180
181
181
183
186
187
187
187
188
188
188
189
116
119
122
122
123
123
124
124
125
126
150
160
160
161
172
172
173
173
174
174
175
176
Table of Contents
Chapter 9
Migrating from DFC 5.2.x .................................................................
Overview of BOF Migration Tasks .........................................................
Post Migration Tasks .................................................................................
189
189
191
Migrating to Web Publisher 5.3 ............................................................
What’s New in Web Publisher? ..................................................................
New or Changed Methods ....................................................................
New Jobs .............................................................................................
New or Changed Relation Types............................................................
Changes to Existing Features .....................................................................
Advanced Content Widget ....................................................................
193
193
195
195
196
196
196
The Web Publisher 5.3 Documentation Set..................................................
Web Publisher 5.3 Architecture ..................................................................
Planning Your Migration ...........................................................................
Supported Migration Paths ...................................................................
Overview of Migration Tasks for Web Publisher .....................................
Migrating Customizations .........................................................................
196
197
197
198
198
200
Post-Migration Tasks ................................................................................
Verify Custom Jobs ...............................................................................
203
203
Appendix A
Product and Terminology Name Changes
........................................... 205
Appendix B
Documentum Clients Feature Comparison
......................................... 207
7
Table of Contents
List of Figures
Figure 1–1.
Figure 1–2.
Figure 2–1.
Documentum 5.3 System .................................................................................
Documentum System with WDK-based Application .........................................
Version History of a Single Document in a Repository.......................................
14
19
28
Figure 2–2.
Figure 2–3.
Figure 2–4.
Figure 4–1.
Figure 4–2.
30
32
32
50
Figure 4–3.
Figure 6–1.
Branching Versions in a Repository ..................................................................
Parent/Child Relationships in Virtual Documents .............................................
Virtual Document Structure in Virtual Document Manager ...............................
Sample Initial System Configuration Diagram ..................................................
Documentum 5.3 System Diagram with Full-Text Index Server Host
Machine .....................................................................................................
Recommended Sequence of System Migration Tasks .........................................
Content Server 5.3 with Index Server and Index Agents ....................................
52
61
81
Figure 6–2.
Figure 7–1.
Figure 7–2.
Figure 7–3.
Figure 7–4.
Figure 7–5.
Content Server Migration Task Overview .........................................................
Typical 5.3 WDK-based System .....................................................................
Migration Tasks for a Customized WDK-based Application ............................
Customization Folders in WDK-based Applications........................................
Migration Tasks for a Customized Webtop-based Application .........................
84
115
116
117
119
120
Figure 8–1.
Figure 8–2.
Figure 9–1.
Figure 9–2.
Figure 9–3.
DFC 5.3 Architecture ....................................................................................
Migration Tasks for Custom BOF Objects .......................................................
Typical 5.3 Web Publisher System Configuration ............................................
Migration Tasks for Web Publisher ................................................................
188
190
197
198
201
8
Table of Contents
List of Tables
Table 3–1.
Table 3–2.
Table 3–3.
User Privilege Levels ......................................................................................
Object Permission Levels .................................................................................
Permissions Required Under Folder Security ....................................................
40
41
42
Table 3–4.
Table 4–1.
Table 4–2.
Table 4–3.
Table 4–4.
Table 4–5.
Table 4–6.
Table Permits..................................................................................................
Initial System Configuration ............................................................................
Initial Software Configuration .........................................................................
Migration Roadmap for Documentum Products ...............................................
Client Applications Compatibility Matrix .........................................................
System Architecture Analysis Worksheet .........................................................
Documentum System Analysis Worksheet .......................................................
42
50
50
51
53
62
64
Table 4–7.
Table 4–8.
Table 6–1.
Table 6–2.
Table 6–3.
Table 6–4.
Documentum Customization Analysis Worksheet ............................................
Custom Objects Inventory Worksheet ..............................................................
New System Events ........................................................................................
Privileged Groups Created During Repository Configuration ............................
New Object Types Introduced in Release 5.3 .....................................................
Additions to Existing Object Types in Release 5.3 ..............................................
66
67
87
89
90
97
Table 6–5.
Table 6–6.
Table 6–7.
Table 6–8.
Table 6–9.
Table 6–10.
Table 7–1.
Table 7–2.
New or Enhanced DMCL APIs ......................................................................
Changes to Administration Methods Suite .....................................................
Obsolete Administration Methods ................................................................
Obsolete Server.ini Keys ...............................................................................
Attributes Defined for the Fulltext Index Type ................................................
Deprecated Attributes of dm_server_config ....................................................
Browse for File .............................................................................................
Cancel Checkout...........................................................................................
102
102
103
105
106
109
126
127
Table 7–3.
Table 7–4.
Table 7–5.
Checkin .......................................................................................................
Checkout .....................................................................................................
Edit .............................................................................................................
128
129
130
Table 7–6.
Export..........................................................................................................
131
Table 7–7.
Table 7–8.
Table 7–9.
Table 7–10.
Table 7–11.
Table 7–12.
Table 7–13.
Table 7–14.
Import .........................................................................................................
Prompt for Input ..........................................................................................
View ............................................................................................................
WDK 5.2.5 to 5.3 Content Transfer Component Comparison ............................
Search Component Map for Component Configuration Files ...........................
Search Component Map for NLS Properties Files ............................................
Search Component Map for Java Classes ........................................................
Search Component Map for Layout Files ........................................................
132
134
134
135
150
153
155
157
Table 7–15.
VDM 5.2.5 -5.3 Component Mapping .............................................................
161
9
Table of Contents
Table 7–16.
Table 7–17.
Table 8–1.
VDM 5.2.5 -5.3 NLS Properties Mapping ........................................................
VDM 5.2.5 -5.3 Java Class Mapping................................................................
Methods to override when implementing TBOs ..............................................
165
168
182
Table 8–2.
Table 8–3.
Table 8–4.
Table A–1.
Table B–1.
Methods of DfSysObject ................................................................................
Methods of DfPersistentObject ......................................................................
Methods of DfTypedObject ...........................................................................
Product and Terminology Name Changes ......................................................
Documentum Client Functionality Matrix ......................................................
183
186
186
205
207
10
Preface
This manual presents a "whole-system" overview of migrating your Documentum 5.2.5 system to
Documentum 5.3. This book is intended to help you plan your migration, offer advice about best
practices, and address cross-product and cross-platform migration issues.
This Guide will be reissued at intervals, both to incorporate new information about best practices and
case studies, and also to include products from future releases of the Documentum 5.3 product set.
Intended Audience
This manual is primarily intended for system installers and system administrators.
Revision History
The following changes have been made to this document.
Revision History
Revision Date
Description
March, 2005
Initial publication.
11
Preface
12
Chapter 1
Documentum Overview
This chapter introduces the basics of enterprise content management and the Documentum system.
•
What is Enterprise Content Management?, page 13
•
Introducing the Documentum System, page 13
What is Enterprise Content Management?
Documentum is an enterprise content management system (ECM) that stores and
manages content of various types in a repository by:
•
Using permissions to keep content secure
•
Providing version control for objects
•
Providing search tools to locate content
•
Controlling content from creation to final archiving through automated business
lifecycles
A Documentum system can also assemble and deliver personalized content through
Web-based applications. It integrates with a number of popular tools, such as Adobe
Acrobat and Microsoft Word, as well as other enterprise systems, such as Lotus Notes or
SAP.
Introducing the Documentum System
This section describes the core Documentum product set, and provides system
configuration diagrams that show how the various products interact.
13
Documentum Overview
What Does a Typical Documentum 5 Installation Look
Like?
The following diagram shows a complete Documentum 5 system, with a Content Server,
DFC, ECI Services, Web clients, Desktop clients, application server, index server, and a
repository.
Figure 1-1. Documentum 5.3 System
The following sections describe each of the Documentum products shown in Figure
1–1, page 14.
What is Content Server?
Content Server is the foundation of Documentum’s content management system. It
allows users to create, capture, manage, deliver, and archive enterprise content.
It also provides process management services, security for the content and metadata in
the repository, and distributed services. Content Server’s content management services
include the following: library services (check in and check out), version control, and
archiving options.
Content Server uses an extensible object-oriented model to store content and metadata in
a repository. Everything in a repository is stored as objects. The metadata for each object
14
Documentum Overview
is stored in tables in the underlying RDBMS. Content files associated with an object
can be stored in file systems, in the underlying RDBMS, in content-addressed storage
systems, or on external storage devices. For more information about Content Server and
a detailed description of the repository data model, see Content Server Fundamentals.
What is Documentum Administrator?
Documentum Administrator allows you to monitor, administer, configure, and maintain
Documentum Servers, repositories, and federations located throughout your company
from one system running a Web browser.
For example, using Documentum Administrator you can:
•
Monitor repository system and resource usage
•
Configure a repository
•
Create or modify repository users and groups
•
Create or modify repository object types
•
Create or maintain permission sets (also known as access control lists, or ACLs)
•
Create or modify repository federations
•
Create or modify formats
•
Monitor repository sessions
•
Run server APIs and issue DQL queries
•
Create or modify storage areas
•
Create and run methods and jobs
For more information about Documentum Administrator, see the Documentum
Administrator User Guide.
What is ECI Services?
Documentum Enterprise Content Integration Services (ECIS) provides content
integration features:
•
Cross-repository searches
•
Multi-repository-attribute display
•
Results Relevancy
•
Import Content
•
Saved Queries
•
Extend simple search to allow for cross-repository and virtual repository searches
15
Documentum Overview
•
Expand search results to display content from all repositories
•
Display relevance and location
•
View content from any repository
•
Import or include content from any repository into DCTM repository
Access to ECIS extended search capability is provided within WDK-based clients.(such
as WDK for Portlets, Webtop, DAM, DCM, Web Publisher, etc.). Users can collaborate
on search results; incorporate external objects in EDM, WCM, DCM, Process Portal, or
Records Management solutions.
What are Documentum Application Builder and
Application Installer?
Documentum Application Builder (DAB) is the principal tool for managing server
applications. Its object type and attribute editors enable you to define new object types
and their attributes. Its Document Lifecycle Editor enables you to create document
lifecycles (DLCs). Its explorer (a tree view of all server application elements) and its
other editors enable you to:
•
View and organize all parts of the server application.
•
Create and modify many parts of the server application.
•
Import objects from the Docbase into the Application Builder (some server
application parts cannot be modified from within Application Builder).
•
Refer symbolically to users, groups, permission sets, and Docbase locations that have
roles in the server application.
•
Designate some parts of the server application as global, that is, available for use
outside the context of a specific object type.
Application Builder stores information about the types you create in the data dictionary.
After you build and test a server application, Application Builder helps you package
it into a DocApp archive, a file that contains the server application in a form that an
administrator, using Application Installer, can install in another Docbase. Using
aliases, which assign actual values to symbolic parameters of the server application, the
administrator can tailor the DocApp archive to the target Docbase.
Note: Several ways in which the DocApp archive is installed into the target Docbase are
determined by the developer who created the DocApp and archive using Application
Builder; if you are not the one who created the DocApp, you might need to communicate
with the developer of the DocApp to resolve any issues.
You use Application Installer to deploy DocApp archives to Docbases. A DocApp
encapsulates Docbase-related objects and processes that are specific to a business or
department. You use Application Builder to create a DocApp archive; a DocApp archive
16
Documentum Overview
is the DocApp archive folder (with the same name as the DocApp) and the set of files
that the Application Installer uses to install the DocApp.
For more information about Documentum Application Builder, see the Documentum
Application Builder User Guide.
For more information about Documentum Application Installer, see the Documentum
Application Installer User Guide.
What is DFC?
Documentum Foundation Classes (DFC) is an object oriented application programming
interface (API) and framework for accessing, customizing, and extending Documentum
functionality.
Documentum has implemented DFC as a set of Java interfaces and implementation
classes. DFC also provides the Documentum Java-COM bridge (DJCB) to make the
interfaces available in Microsoft’s Component Object Model (COM) environment. The
DFC primary interop assembly (PIA) provides access to DFC from the .NET environment.
The business objects framework (BOF) is a key part of DFC. BOF enables you to embody
business rules and patterns in reusable elements, called type based objects (TBOs)
and service based objects (SBOs). BOF makes it possible to extend some of DFC’s
implementation classes. As a result, you can introduce new functionality in such a way
that unmodified existing programs begin immediately to deliver the new functionality.
You can use DFC in any of the following ways:
•
Access Documentum functionality from within one of your company’s enterprise
applications.
For example, your corporate purchasing application can retrieve a contract from
your Documentum system.
•
Customize or extend Documentum products like Documentum Desktop or Webtop.
For example, you can modify Desktop functionality to implement one of your
company’s business rules.
•
Write a method or procedure for Content Server to execute as part of a workflow
or document lifecycle.
For example, the procedure that runs when you promote an XML document
might apply a transformation to it and start a workflow to subject the transformed
document to a predefined business process.
The Documentum Content Server Fundamentals manual provides a conceptual explanation
of the capabilities of Content Server and how they work. DFC provides a framework for
17
Documentum Overview
accessing those capabilities. Using this framework makes your code much more likely to
survive future architectural changes in the Documentum system.
The core of DFC is a set of Java classes, but it includes other elements as well:
•
Shared libraries to support DFC functionality.
•
A type library for accessing DFC via COM from Visual Basic or Visual C++.
For more information about DFC and BOF, see the Documentum Foundation Classes
Development Guide.
What is Web Development Kit (WDK)?
WDK is a toolkit you use to develop Web-based content management applications. It
uses the standard J2EE development platform, runs on top of third-party application
servers (such as BEA WebLogic or IBM WebSphere), and consists of a framework and a
component library. WDK uses Documentum Foundation Classes (DFC) and Business
Object Framework (BOF) to implement business logic.
WDK is the underlying technology for Documentum 5 Web clients. You can use WDK to
customize these Web clients, or to create new custom applications that integrate with a
Documentum system. Figure 1–2, page 19 shows how WDK-based applications fit into a
standard Documentum system:
18
Documentum Overview
Figure 1-2. Documentum System with WDK-based Application
What is Documentum Desktop?
Documentum Desktop provides an easy-to-use environment for performing basic
document management tasks. Documentum Desktop supports integration with standard
desktop applications such as Microsoft Office (Word, Excel, and PowerPoint). You can
access documents and other objects in the repository using either Documentum Desktop
or an integrated application.
Documentum Desktop gives you access to the Docbases in your company’s Documentum
installation. Documentum Desktop resides on the personal computers used by
individuals, while Docbases reside on the servers, which are shared computers accessed
over a network by many individuals at once from their personal computers.
Documentum Desktop is integrated with Windows Explorer. When you use Windows
Explorer to browse your computer’s file system, you can use file management commands
on Explorer’s menus to open, copy, delete, or move files. When you connect to a
repository from Explorer, Documentum Desktop’s document management commands
replace Explorer’s menus. You use the document management commands to create,
check in, check out, copy, or delete documents in a repository.
When you need a document from a repository, you start Documentum Desktop and
browse the repository for the document, much as you would use Windows Explorer to
19
Documentum Overview
browse your computer. When you double-click the document, Documentum Desktop
locks the document in the repository and copies it from the repository to the Local Files
folder, which is located on your personal computer. When you are finished working
with the document, you use Documentum Desktop to return it to the repository, assign it
a version label and other properties and handle all advanced document management
functions, such as creating virtual documents, applying document lifecycles, and
starting workflows.
You can also connect to Docbases without starting Documentum Desktop. Integrated
applications such as Microsoft Word and Excel can access Docbases directly. You can
check documents in to and out of Docbases, edit document properties, and search
Docbases from these integrated applications by using commands on an application’s
File menu. However, you must use Documentum Desktop for advanced Documentum
functions such as workflows, document lifecycles, and virtual documents.
For more information about Desktop, see the Documentum Desktop User Guide.
What is Webtop?
A WDK-based application is an application that lets you access an EMC | Documentum
repository through a Web browser. a Documentum client application is a WDK-based
application.
Through your browser, Webtop gives you access to viewing, editing, and managing
repository content (a repository is a virtual storehouse for the content you work on
and share with other employees). Through WDK functionality, you can distribute
content electronically through automated business procedures; restrict access to content
according to permission sets; and assign version numbers to content to help you keep
track of revisions.
WDK functionality can provide access across multiple repositories and across different
departments, sites, and computer platforms. Webtop is built on Web Development
Kit (WDK) functionality.
20
Chapter 2
This chapter contains information about basic Documentum concepts. Topics discussed include:
•
About Documentum Users, page 21
•
Core Concepts, page 23
•
Core Documentum End-User Tasks, page 33
About Documentum Users
This section introduces the Documentum user model, client capabilities, and defines
users, roles, and groups.
What is a User?
A user is typically an individual person. To access objects in a repository, a person must
be represented by a dm_user object in the repository. Repository users have two states,
active and inactive. An active user can connect to the repository and work. An inactive
user is not allowed to connect to the repository.
A user can be a virtual person. That is, you can create a user object for a user who doesn’t
exist in reality. Doing this may be useful; for example, if you want an application to
process certain user requests and want to dedicate an inbox to those requests. The virtual
user can be registered to receive events arising from the requests, and the application
can read that user’s inbox.
21
What is a Group?
Groups are sets of users, groups, or a mixture of both. They are used to assign
permissions or client application roles to multiple users. There are three kinds of groups
in a repository: standard groups, role groups, and domain groups.
A standard group consists of a set of users. The users can be individual users or other
groups. A standard group is used to assign object-level permissions to all members of the
group. For example, you might set up a group called engr and assign Version permission
to the engr group in an ACL applied to all engineering documents. All members of the
engr group then have Version permission on the engineering documents.
Standard groups can be public or private. When a group is created by a user with
Sysadmin or Superuser user privileges, the group is public by default. If a user with
Create Group privileges creates the group, it is private by default.
What is a Role?
A role is a group that contains a set of users, other groups, or both that are assigned a
particular role within a client application domain. A role group is created by setting the
group_class attribute to role and the group_name attribute to the role name. A domain
group represents a particular client domain. A domain group contains a set of role
groups, corresponding to the roles recognized by the client application.
For example, suppose you write a client application called report_generator that
recognizes three roles: readers (users who read reports), writers (users who write and
generate reports), and administrators (users who administer the application). To support
the roles, you create three role groups, one for each role. The group_class is set to role
for these groups and the group names are the names of the roles: readers, writers, and
administrators. Then, create a domain group by creating a group whose group_class
is domain and whose group name is the name of the domain. In this case, the domain
name is report_generator. The three role groups are the members of the report_generator
domain group.
When a user starts the report_generator application, the application is responsible for
examining its associated domain group and determining the role group to which the
user belongs. The application is also responsible for ensuring that the user performs only
the actions allowed for members of that role group. Content Server does not enforce
client application roles.
A group, like an individual user, can own objects, including other groups. A member
of a group that owns an object or group can manipulate the object just as an individual
owner. The group member can modify or delete the object.
22
What are User Capabilities?
Documentum end-users are divided into three categories that correspond to the types of
tasks they typically perform as part of their job responsibilities:
•
Coordinator
A coordinator typically manages the organization of information in a repository by
defining and managing lifecycles, creating workflows and workflow templates, and
creating and managing virtual documents.
•
Contributor
A contributor typically owns and contributes content to group projects. A contributor
creates and edits documents, and uses existing templates, workflows, and lifecycles.
•
Consumer
A consumer searches for content in a repository and views it, but does not usually
edit or create documents.
Core Concepts
This section describes key concepts for using the Documentum system.
What is a Repository?
A repository is a virtual storehouse for the content you work on and share with other
employees. Each repository provides security, tools, and processes for sharing content
among many users. Processes control the automated routing of content and assign
document lifecycles to content. Processes allow you to create, edit, and forward content
regardless of your technical expertise.
A repository stores two kinds of information for a content file:
•
The content — which is the text, graphics, sound, video, binary content, or other
content — that makes up the file.
•
The properties, which are descriptive characteristics about the file, such as creation
date, author, version number, and other information. Property values can only be
edited by the file’s creator or a user with high enough security settings.
The highest level of organization in a repository is the repository’s nodes. The nodes
provide access to different repository functions and to different ways to organize a
repository’s content. All content in a repository can be accessed through the repository’s
Cabinets node, which organizes the content into cabinets and cabinet folders. Other
23
nodes provide other organizational schemes for giving you access to content, such as
according to the files you use most often, the files you have used recently, or other
schemes configured by your organization.
In each repository, you have a home cabinet with your name on it. Only you can see or
access your home cabinet. Your home cabinet is where you store personal documents.
Several repositories can be grouped into a federation. A federation is a way of
configuring a group of repositories to simplify administration.
In each repository, you have an Inbox node. Your Inbox displays tasks that have been
assigned to you and displays any notifications you have requested when specific actions
occur. Tasks and notifications can include attached files. In a repository federation, you
have one Inbox for the whole federation.
When you want to modify a file, you check it out from the repository. This locks the
file so only you can modify it. Other users can view it but cannot make changes to it.
When you complete your changes to the file, you check it back into the repository, which
replaces the previous version of the file in the repository with the updated one. Checking
in also unlocks the file so that other users can modify it.
When you create a file in the repository, a Documentum client application gives it a
version number. A new file is assigned the version number 1.0. a Documentum client
application automatically increments the version number by a decimal point every time
you check out the file and then check it back in. You can choose not to increment, which
keeps the same version number and overwrites the existing version.
In addition to content, a repository also stores other items, such as workflows (the
automated sequences for routing files), permission sets, and user profiles. Every item in
a repository — whether content or not — is stored as a repository object with a defined
object type. Content files, for example, typically have an object type of dm_document. The
object type determines the types of properties associated with the object.
How Are Repositories and Servers Related?
Repositories are comprised of object type tables, type indexes, content files, and full-text
indexes. The type tables and type indexes are tables in an underlying relational database.
The content files are typically stored in directories on disks in your installation. However,
content files can also be stored in the database or on external storage devices.
Users access repositories through servers. The servers receive queries from clients in the
form of API methods or DQL statements and make the actual call to the underlying
RDBMS or the file directories. Every repository must have at least one active Content
Server. If a repository does not have an active server, then users cannot access that
repository.
24
What is Content?
Content conveys information to a user, and is stored in a repository as a file of a
particular type, such as:
•
a Microsoft Word or PDF document
•
a Web page
•
an XML document
•
a report
•
an executable file
•
an engineering drawing
•
a scanned image
•
an audio or video file
•
a thumbnail file
What is Your Checkout Directory?
Your checkout directory is the location on your computer where a Documentum client
application copies files when you access them for editing — i.e., "check them out”
— from the repository. When you check out a repository file, a Documentum client
application copies the file to your computer’s checkout directory.
The Checkout directory location can be edited in your Preferences’s General tab. The
default location of the checkout directory varies on your local operating system:
Windows — //Documentum/Checkout
Macintosh OS X — Root:Users:<user_name>:Documentum:Checkout
Once downloaded to your computer, the file stays there until you check it back into
the repository. You can open and close the file directly from your checkout directory,
whether or not you are connected to the repository. When you are ready to save the file
back to the repository, you check it back in.
In some cases, when you check out a file, a Documentum client application might not
copy it to your computer but instead "stream” it to your computer. Whether this happens
depends on the file’s editing application. If a Documentum client application streams the
file to your computer, it is not saved to your local machine. For more information on
checking out files, see the section of this guide on Checking Out and Editing Files.
25
What is a Workow?
A workflow is a process that electronically passes documents and instructions from
user to user. For example, an employee might initiate a travel expense report; another
employee might review it and return it for revision; and a third employee might approve
it. A workflow automates the process, ensuring that the right file goes to the right people
in the right order.
To start a workflow, you choose the workflow template that includes the sequence of
tasks you want performed. Depending on how the template is set up, the template might
specify each user who is to perform each task or might prompt you to select each user.
A workflow might include automatic tasks, which are tasks performed by the system,
such as promoting or publishing a file.
When you start a workflow, you can attach repository files. A workflow can include
several attached files.
What is Your Inbox?
Your Inbox contains the tasks and notifications sent to you. Tasks are electronic
assignments sent to you as part of a workflow. When you receive a task, you choose
whether to accept it or reject it. When you complete a task, you forward it. The workflow
notifies the next user in sequence. Tasks can include attached files.
Notifications are messages letting you know when a specific action has occurred on a
document. You choose to be notified about certain events by selecting the appropriate
notification option in the document’s properties.
What is a Document Lifecycle?
A document lifecycle is a sequence of states a file goes through between its creation and
expiration. When you create a file, the system assigns a document lifecycle to the file and
puts the file into the first state in the lifecycle.
Typical lifecycle states include WIP (Work In Progress), indicating a document is in its
draft phase, and Staging, indicating a document is complete and ready for approvals. By
default, a Documentum client application does not let you make changes to an item that
is in the Staging lifecycle state.
A file advances through its lifecycle states through either manual or automatic
promotion. Typically, a document lifecycle is incorporated into a workflow, and you are
alerted to your role in a file’s lifecycle when a workflow task appears in your Inbox.
26
What is a Permission Set?
A permission set determines who can access a particular item in a repository. Each item
in the repository has an associated permission set, determining who can access the item
and what actions each user with access can perform. Your access to a repository item is
determined by the permission set assigned to the item.
A permission set lists the users and groups who have access. The permission set assigns
one of the following seven access levels to each user and group listed. Each access level
includes all the permissions of the preceding levels:
•
None: No access to the item.
•
Browse: Users can view the item’s properties (but not its content).
•
Read: Users can view the item’s content.
•
Relate: Users can annotate the item.
•
Version: Users can modify and check in new versions of the item.
•
Write: Users can modify and check in the item as the same version.
•
Delete: Users can delete items.
Work Queues Overview
A work queue holds tasks that are to be performed by available users from a defined
pool of users. When a user is ready for a new task, the user request the task. a
Documentum client application assigns the user the single next highest priority task
from all the work queues the user is a member of.
a Documentum client application assigns tasks to users based on priority. Managers
monitor queues. Your organization can create different queues for different purposes
and organize them into queue categories.
A work queue policy contains the management logic a work queue uses, including
threshold settings.
A work queue doc profile defines a unique work queue policy for a
work-queue/document pair.
To access work queues, you must belong to one of the following roles
•
Queue_admin: creates work queues and queue policies. Queue_admin’s do not
by default have the administrator role.
•
Queue_manager: monitors work queues and assigns users to work on queue items.
Queue managers can reassign and suspend tasks.
Queue managers who have CREATE_GROUP privileges can create work queues.
27
•
Queue_processor: works on items from one or more work queues.
•
Process_report_admin: runs historical workflow reports.
How Does Object Versioning Work?
Content Server provides comprehensive versioning services for all objects except folders
and cabinets and their subtypes. (Folders and cabinets cannot be versioned.)
Versioning creates a historical record of a document. Your business rules may require
you to keep copies of all old versions of a document. Each time you check in or branch
a document or other object, Content Server creates a new version of the object without
overwriting the previous version. Figure 2–1, page 28 shows multiple versions of an
XML document stored in a Documentum repository. Because the Documentum system
records who checked the document in and when the document was checked in, you can
always tell when documents were changed, the changes that were made from version to
version, and who changed the document.
Figure 2-1. Version History of a Single Document in a Repository
All the versions are stored in a hierarchy called a version tree. Each version on the tree
has its own numeric version label. The server automatically provides numeric version
labels and keeps track of the current version on the tree.
When you check a document in to a repository, you are asked to choose between a
major or minor version number and optionally assign a descriptive version label for the
document. Version numbers are controlled by the Documentum system, but you can
assign a descriptive version label to help you to identify a particular version.
A document always receives version number 1.0 when it is first checked in to the
repository. When you check in subsequent versions, you decide whether to check the
document in as a major revision or a minor revision. Major revisions are incremented by
whole numbers, so that the first major revision will be 2.0, the second 3.0, and so on.
Minor versions are incremented by tenths. If you check out version 1.0 of a document
and check it in as a minor revision, the document will be stored as version 1.1. The
28
next minor revision is version 1.2. If you then decide that the next revision was a major
revision, the version number would jump from 1.2 to 2.0.
If you have the right permissions, you also have the choice to check in an edited version
with the same version number as the one you checked out. Checking in an edited version
as the same version will overwrite the original document with that version number.
In addition to a version number and optional version label, the document that you check
in will be marked CURRENT. It is always the current document that is displayed, unless
you choose to view all versions.
You can use the Document Info pane to find out about different versions of a document.
Select the document, then either choose View→Document Information (in Documentum
Desktop) or click the Document Info icon
(in Webtop-based clients). In the Document
Info pane, choose All Versions to display all versions of the document.
If you edit a version of a document other than the one marked CURRENT, the
Documentum system creates a branch. In Figure 2–2, page 30 , the different versions are
annotated with numbers corresponding to the order in which they were created.
First, user John Smith edits version 1.0 and checks in the revision as minor version 1.1.
When John edits version 1.1 for the first time, he checks the revised version in as minor
version 1.2.
Susan Jones edits version 1.1 after John creates version 1.2. When she checks in the
revision of version 1.1, a branch is created and the newly checked-in document receives
version number 1.1.1.0.
John then edits version 1.2, and checks in the revision as major revision 2.0.
When Susan edits version 1.1.1.0, the new version is checked in as minor version 1.1.1.1.
Susan then makes more revisions to version 1.1.1.1 after John creates major version 2.0
and she checks in the new version as major version 3.0.
29
Figure 2-2. Branching Versions in a Repository
When you check in a branch version of the document, you have the choice of whether
or not to make that the new current version. If it does become the current version, the
document with the higher version number will still be listed when you view all the
versions of that document.
What Are Virtual Documents?
Virtual documents are documents that are composed of other documents, or components.
For example, you could have a virtual document corresponding to a book, containing
a number of other documents corresponding to chapters. Each chapter could itself be
a virtual document, containing other components corresponding to the sections of the
chapter.
Each component can have a different file format. For example, you could combine an
Excel spreadsheet, a Word document, and a TIFF image to create a virtual document.
You can arrange the components of the virtual document in any order you wish. The
components stay in that order unless you rearrange them.
You use Virtual Document Manager to create and manage virtual documents.
30
Note: XML documents that contain file entities are stored as virtual documents in the
repository. The structure can be viewed but should not be modified in Virtual Document
Manager.
Why Use Virtual Documents?
Virtual documents are particularly useful in the following cases:
•
You want to access a group of files as one unit.
•
Several people need to work concurrently on components of a document.
•
Your set of documents is too large to combine into a single file.
•
The files that you want to group as a unit have more than one owner.
•
The files are in more than one format (for example, a Word document and an Excel
spreadsheet).
•
You want to publish a set of documents in a particular order (such as the chapters of
a book).
•
You want to include the same information (such as salary scales or other reference
information) in many different documents, but you want to control which version of
the information gets included each time.
•
You want to keep revising documents but need to keep track of the version you
produced at certain milestones.
•
You have a collection of Microsoft Office documents that you want to store together
in the repository and publish as a group.
Here are some examples in which virtual documents could play a valuable role:
•
A new drug application will be composed of many sections drawn from different
sources, some of which are included in the application for the United States but not
in the application for France.
•
Each sales presentation includes only the products relevant to that potential
customer.
•
You want to share portions of your content with other departments in the company,
but they want to structure it differently and add some of their own content.
•
You want to archive a particular version of a document that was released to the
public, while you continue to update the document internally.
Virtual Document Structure
The document on which you base a virtual document is called the root of the virtual
document. When you add components to the virtual document, the components become
31
the children of the root document. Any document can be a component of several virtual
documents.
In a single virtual document, each child document has only one parent. Each parent in a
virtual document can have many children, and documents other than the root document
can be parents.
Figure 2–3, page 32 shows the structure of a three-layer virtual document. Component
A is the root document and the parent of components B and C. Components B and C are
children of the root document A. Component C is another virtual document that is nested
under virtual document A. Component C is the parent of component D, and D is the
child of C. Components B, C, and D are all descendants of the root document A.
Figure 2-3. Parent/Child Relationships in Virtual Documents
When viewed in Virtual Document Manager, a virtual document’s structure is
represented as shown in Figure 2–4, page 32:
Figure 2-4. Virtual Document Structure in Virtual Document Manager
32
Introduction to Webtop
Webtop is a browser-based application that lets you access and process your
organization’s documents through Documentum 5. Webtop lets you perform a myriad of
document management tasks, from a document’s creation to its archiving, and everything
in between. Documentum 5 automates numerous document management tasks to
provide automatic routing, renditioning, versioning, securities and many other functions.
Documentum 5 uses the Documentum Content Server to store and process content
within a content repository, called a Docbase™
Core Documentum End-User Tasks
This section describes core concepts for users of Documentum client products. For
step-by-step instructions for performing each kind of task using a particular product,
refer to the User Guide for that product.
How Do You Connect to a Repository?
To view or change items in a repository, you must first connect to the repository using a
login ID. To do this, you must be defined as a repository user.
To log in to a Documentum client product, you must have the following information. If
you do not have the information, ask your Documentum administrator:
•
The URL or location where your client product is installed
•
Name of the repository you are logging into
•
Your user name and password for the repository
•
If applicable: the Windows domain name for the repository
•
If applicable: the language of the application that you are running
What are Check-ins and Check-outs?
When you want to modify a document, you check it out of the repository. Checkout
locks the document so that only you can modify it, although other users can still view
the document as it existed when you checked it out. After you modify it, you check
the document back in. Your changes are saved to the repository and the document is
no longer locked. When another user accesses the document after you check it in, the
document contains the changes you made.
33
Checking a document out of a repository is similar to checking a book out of the library.
When you check a book out of the library, you can take the book home to read, and while
you have the book checked out, no one else can check it out.
After you edit and save the document, you can then check it back in to the repository to
make it available to others.
Documentum client applications put copies of the files you check out in a designated
folder on your local hard disk so that you can edit them. A padlock icon appears next to
any checked-out files in the repository.
Cancelling a checkout unlocks the checked-out document in the repository. To cancel a
checkout, use the Cancel Checkout command. Use Cancel Checkout when you:
•
Check out a document that you decide not to edit
•
Check out and edit a document, but decide that you want to discard the revisions
Unless the checked-out document was originally a local copy, cancelling a checkout
removes the document from your local files folder. If you cancel a checkout, you lose any
changes you have made to the checked-out document, unless you move that document
out of the Checkout folder first.
How Do You Create or Alter Objects in the Repository?
Everything that is stored in a repository is stored as an object.
This section discusses creating or importing objects, deleting objects, copying and
pasting objects, creating folders and cabinets, and moving objects.
About Creating or Importing Objects
You can create documents directly in a repository or you can create single or multiple
files, or a folder of files, on your personal computer and import them into a repository.
Documents consist of a content file and properties, regardless of whether the content file
is a word processing file, a graphics file, a database file, or a text file.
Note: When you create a new document, you must assign an object name to the
document. Do not include these characters in the object name: ? \ : * ? " < > |.
If you create a document or folder directly in a Documentum client, other users may
view the document, but they cannot edit it until you check the object in to the repository.
(If you import a new document into the repository, there is no checkin process involved.)
After an object is checked in or imported, other users can edit the document, and you can
use Documentum’s document management functions to control the document.
34
About Editing Objects
You may need to edit a document in a repository, whether you created it and checked it
in or another repository user created it. To edit the document, you must check it out of
the repository. After you check a document out of a repository, you can then edit the
document when you are connected to the repository or when you are in offline mode.
•
When you are connected to a repository, double-click the document in the repository
or in your Local Files folder.
•
When you switch to offline mode, double-click the document in your Local Files
folder.
After you edit and save the document, you can then check it back in to the repository to
make it available to others.
About Moving Objects
When you move a document or other object, you change its location in the repository.
The document is removed from its original location and relocated elsewhere. You move
documents using standard commands such as cut and paste.
About Copying and Pasting Objects
When you copy a document, you create a duplicate that is independent of the original
document and has its own properties. Editing the duplicate does not affect the document
you copied. You may need to copy a document in order to use it as the basis of a new
document or in order to create an archive copy of the document.
Note: If you create the copy in the same folder as the original document, depending on
which Documentum client application you use, the copy will either have the same name
as the original (even though the Documentum object IDs are different), or the copy may
be called "Copy of" plus the original document name. For example, if you create a copy
of a document named ChapterOne.doc in the folder containing ChapterOne.doc, the
copy is named Copy of ChapterOne.doc.
About Deleting Objects
There are many circumstances in which you may need to delete a document from the
repository. A document might no longer be needed. You may wish to remove older
versions of a document because only the current version should be used. You might
35
have imported the wrong document from your personal computer. Documentum client
applications provide you with several ways to delete documents.
Using Documentum client applications, you can delete one document at a time or you
can delete multiple documents. You can also delete the current version or all versions of
the selected document. When you decide to delete a document, you can find the delete
options on the selected document’s Actions page. For example, some client applications
allow you to delete snapshots.
About Organizing Objects in Folders and Cabinets
Organizing documents in a repository is similar to organizing documents on your
personal computer. You use Documentum clients to create new folders and to copy or
move files in a repository.
Organizing documents in a repository is similar to organizing documents on your
personal computer.
You create new folders to help you group documents in a logical way. Grouping
documents makes it easier for you and other users to find documents with a minimum of
searching. For example, if you are involved with five major projects, each project can
have its own folder (or cabinet, if you have Create Cabinet privileges). Within each
project folder, you can have folders corresponding to major aspects of the project or
to document format. If you were involved in a project called Project Milky Way, for
example, within the Project Milky Way cabinet (or folder) you might have a folder called
Spreadsheets, another called Word Processing Documents, and a third called Graphics
and Sound Files. You could also set up your folders to correspond to the departments
contributing to each project. In this case, you could have folders called Accounting,
Graphics, Engineering, and Marketing within the Project Milky Way cabinet.
How Do You View or Modify Information About Objects
in the Repository?
Properties (also known as metadata) are descriptive characteristics, such as a document’s
creation date, creator, most recent editor, versions, format, and status in a lifecycle.
You can use the Document Info pane to find out about a document’s properties. Select
the document, then either choose View→Document Information (in Documentum
Desktop) or click the Document Info icon
(in Webtop-based clients). Depending on
36
your permissions, you can edit certain fields and modify existing information, such
as keywords or subject.
37
38
Chapter 3
The Documentum Security Model
Documentum security protects the information in each repository, controlling access to cabinets,
folders, documents, and other objects by using a combination of client capability levels, user
privileges, object permissions, and repository security.
Client capability levels define a user’s overall ability to use certain Documentum features. See About
Documentum Users, page 21 for additional information on client capability levels. Each user also
has a user privilege level, which determines the user’s ability to create repository objects other than
documents. Each object in a repository has permissions, and repository security determines how the
system enforces the object permissions. You can also control access to the RDBMS tables represented
by registered tables in the repository.
The following sections present a high-level overview of how security works in a Documentum
repository. For detailed information and procedures for setting privileges and permissions, see
Chapter 4, Security Services, in Content Server Fundamentals, and Chapter 12, Protecting Repository
Objects, in the Content Server Administrator’s Guide .
•
User Privileges, page 39
•
Object Permissions, page 40
•
Folder Security, page 41
•
Table Security, page 42
•
ACLs, page 43
•
Trusted Content Services Security Features, page 45
User Privileges
When user accounts are set up in a Documentum installation, a user receives one of six
privilege levels. The level determines the user’s ability to create objects in the repository
other than documents and folders and to perform administrative tasks. The user
privilege levels are listed in Table 3–1, page 40.
39
Table 3-1. User Privilege Levels
Privilege Level
What You Can Do
None
No privileges
Create Type
Create user-defined object types
Create Cabinet
Create, modify, and remove cabinets
Create Group
Create groups and modify and delete groups you own
Repository Administrator
Create groups and modify and delete groups you
own; create, modify, and delete system permissions
sets; create types and cabinets; perform repository and
full-text administrative functions; manage workflows
and document lifecycles (business policies)
Superuser
Exercise repository administrator privileges plus break
locks, modify or drop other users’ user-defined object
types, register and unregister database tables, grant
and revoke repository Administrator and Superuser
privileges, and perform other administrative functions
Object Permissions
Object permissions determine what actions a particular user can perform on a specific
object. Object permissions are a special kind of property. You view and modify
permissions on an object’s Permissions pagethe Security tab of the Properties dialog box.
You can only change the permissions for an object if you are the owner of the object or
you have Superuser privileges. The object owner is typically the person who created the
object in the repository.
Object permissions are controlled by permissions sets, which specify what permission
for an object is granted to each user or group with access to the repository. Permissions
sets are assigned by the owner of each object. See "Permissions Sets” on page 9-5 for
additional information on permissions sets.
Table 3–2, page 41 describes object permission levels and what you can do with an object
when you have a given permission level. Each permission level includes the capabilities
of all preceding permission levels.
40
Table 3-2. Object Permission Levels
Permission
What You Can Do to an Object
None
Nothing. You will not even see the object.
Browse
View properties.
Read
View properties and any content.
Relate
View properties and view and annotate content.
Version
View properties; view and annotate content; modify
content and properties after you create a new version.
You cannot overwrite an existing version.
Write
View and change properties; view and annotate content;
modify content whether or not you create a new version.
Delete
View and change properties and permissions; view,
annotate, and modify content; create a new version;
delete the object.
Folder Security
Folder security is an additional level of security that repository administrators or
users with Superuser privilege can use to supplement the existing repository security.
Implementing this security option further restricts allowable operations in a repository.
For information about assigning folder security to a repository, refer to the Content Server
Administrator’s Guide.
When folder security is in use, operations such as copying or moving documents may
require you to have Write permission or greater for one or more of the following:
•
The cabinet or folder from which you access the object
•
The destination cabinet or folder
•
The object’s primary folder
An object’s primary folder is initially the folder or cabinet in which the object is
created. If the object is subsequently linked to other places and unlinked from its
initial location, the folder with the oldest current link is the primary folder
Table 3–3, page 42 lists the actions affected by folder security. Consult your repository
administrator for information on whether folder security is in use in your Documentum
installation.
41
Table 3-3. Permissions Required Under Folder Security
Action
Requires at Least Write Permission for
Create an object
Cabinet or folder in which you create the new object
Import a file(s) or folder
Cabinet or folder to which you import the file(s) or folder
Move an object
Both the cabinet or folder from which you remove the
object and the destination folder or cabinet
Copy an object
Destination cabinet or folder
Link an object
Destination cabinet or folder
Unlink an object
Cabinet or folder from which you unlink the object
Delete one version of a
document
The document’s primary folder
Delete all versions of a
document
Delete unused versions of a
document
Note: Folder security does not add any restrictions to your ability to create a new
version of a document.
Table Security
The table permits control access to the RDBMS tables represented by registered tables in
the repository. To access an RDBMS table using DQL, you must have:
•
At least Browse access for the dm_registered object representing the RDBMS table
•
The appropriate table permit for the operation that you want to perform
Note: Superusers can access all RDBMS tables in the database using a SELECT statement
regardless of whether the table is registered or not.
There are five levels of table permits, described in Table 3–4, page 42.
Table 3-4. Table Permits
42
Level
Permit
Description
0
None
No access is permitted
1
Select
The user can retrieve data
from the table.
Level
Permit
Description
2
Update
The user can update
existing data in the table.
4
Insert
The user can insert new
data into the table.
8
Delete
The user can delete rows
from the table.
The permits are not hierarchical. For example, assigning the permit to insert does not
confer the permit to update. To assign more than one permit, you add together the
integers representing the permits you want to assign and set the appropriate attribute to
the total. For detailed information about table permits, see Chapter 4, Security Services, in
Content Server Fundamentals, and Chapter 12, Protecting Repository Objects, in the Content
Server Administrator’s Guide .
ACLs
Access control lists, or ACLs, are the mechanism that Content Server uses to impose
object-level permissions on SysObjects. Each SysObject has an ACL, identified in the
acl_name and acl_domain attributes of the object. The entries in the ACL define who can
access the object and the level of access accorded to that user or group.
The ACL itself is stored in the repository as an object of type dm_acl. An ACL’s entries
are recorded in repeating attributes in the object.
After an ACL is assigned to an object, the ACL is not unchangeable. You can modify the
ACL itself or you can remove it and assign a different ACL to the object.
ACLs are typically created and managed using Documentum Administrator. However,
you can create them through the API or DQL also. For instructions on creating and
assigning ACLs, refer to the Content Server Administrator’s Guide.
ACL Entries
The entries in the ACL determine which users and groups can access the object and the
level of access for each. There are several types of ACL entries:
•
AccessPermit and ExtendedPermit
•
AccessRestriction and ExtendedRestriction
•
RequiredGroup and RequiredGroupSet
•
ApplicationPermit and ApplicationRestriction
43
AccessPermit and ExtendedPermit entries grant the base and extended permissions.
Creating, modifiying, or deleting AccessPermit and ExtendedPermit entries is supported
by all Content Servers.
The remaining entry types provide extended capabilities for defining access. For
example, an AccessRestriction entry restricts a user or group’s access to a specified
level even if that user or group is granted a higher level by another entry. (For a full
description of all the permit types, refer to the Content Server Administrator’s Guide.) You
must have installed Content Server with a Trusted Content Services license to create,
modify, or delete any entry other than an AccessPermit or ExtendedPermit entry.
Note: A Content Server enforces all ACL entries regardless of whether the server was
installed with a Trusted Content Services license or not. The TCS license on affects the
ability to create, modify, or delete entries.
Categories of ACLs
ACLs are either external or internal ACLs. They are also further categorized as public
or private.
External ACLs are ACLs created explicitly by users. The name of an external ACL
is determined by the user. External ACLs are managed by users, either the user who
creates them or superusers.
Internal ACLs are created by Content Server. Internal ACLs are created in a variety of
situations. For example, if a user creates a document and grants access to the document
to HenryJ, Content Server assigns an internal ACL to the document. (The internal ACL is
derived from the default ACL with the addition of the permission granted to HenryJ.) The
names of internal ACL begin with dm_. Internal ACLs are managed by Content Server.
The external and internal ACLs are further characterized as public or private ACLs.
Public ACLs are available for use by any user in the respository. A public ACL created
by the repository owner are called system ACLs. System ACLs can only be managed
by the repository owner. Other public ACLs can be managed by their owners or a user
with Sysadmin or Superuser privileges.
Private ACLs are created and owned by a user other than the repository owner.
However, unlike public ACLs, private ACLs are available for use only by their owners,
and only their owners or a superuser can manage them.
44
Template ACLs
A template ACL is an ACL that can be used in many contexts. Template ACLs use aliases
in place of user or group names in the entries. The aliases are resolved when the ACL is
assigned to an object. A template ACL allows you to create one ACL that you can use in
a variety of contexts and applications and ensure that the permissions are given to the
appropriate users and groups. (For more information about aliases, refer to .)
Trusted Content Services Security Features
If you install Content Server with a Trusted Content Services license, the following
security options are available:
•
Encrypted file store storage areas
•
Digital shredding of content files
•
Electronic signature support using the Addesignature method
Note: Electronic signatures are not supported on the Linux or Itanium platforms.
•
Ability to add, modify, and delete the following types of entries in an access control
list (ACL):
— AccessRestriction and ExtendedRestriction
— RequiredGroup and RequiredGroupSet
— ApplicationPermit and Application Restriction
Using encrypted file stores provides a way to ensure that content stored in a file store is
not readable by users accessing it from the operating system. Encryption can be used on
content in any format except rich media stored in a file store storage area. The storage
area can be a standalone storage area or it may be a component of a distributed store. ,
describes encrypted storage areas in detail.
Digital shredding provides a final, complete way of removing content from a storage
area by ensuring that deleted content files may not be recovered by any means. provides
a brief description of this feature.
Addesignature is the way to implement an electronic signature requirement through
Content Server. Addesignature creates a formal signature page and adds that page as
primary content (or a rendition) to the signed document. The signature operation is
audited, and each time a new signature is added, the previous signature is verified first.
For complete details on how this feature works, refer to Content Server Fundamentals.
The additional types of entries that you can create in an ACL if you have a Trusted
Content Services license provide maximum flexibility in configuring access to objects.
For example, if an ACL has a RequiredGroup entry, then any user trying to access
45
an object controlled by that ACL must be a member of the group specified in the
RequiredGroup entry. For more information about the permit types that you can define
with a TCS license, refer to Content Server Fundamentals.
46
Chapter 4
Preparing to Migrate
This chapter provides an overview of the typical tasks and planning processes that result in a
successful migration to Documentum 5.
This release contains many new features, such as changes to the security model and scalable full-text
indexing, as well as improvements to multi-repository session management, searching, and content
transfer operations (such as check in and check out). By migrating your server and applications to the
latest version, your applications can take advantage of new features, as well as the new look-and-feel
of the Webtop and WDK user interfaces.
The following topics are presented in this chapter:
•
What Is Migration?, page 47
•
Planning Your Migration, page 48
•
Sample Pre-Migration Checklists and Worksheets, page 62
•
Backward Compatibility for Customized Applications, page 60
What Is Migration?
A migration consists of the upgrades of the various components that make up the
Documentum 5 system, including customized applications built with Documentum’s
development tools (WDK, DFC, and DDS). Two main components of migration are:
•
Migrating content objects, configuration objects, etc.
•
Migrating customizations
For existing Documentum systems, migrating may require you to:
•
upgrade server and client products to the most current versions
•
convert obsolete components to newer components
•
rewrite customizations created for now-obsolete components
•
validate or verify the new system
47
Planning Your Migration
The process of planning your migration to Documentum 5 should include a thorough
analysis of your existing system, listing the resources required to migrate, and
determining what additional resources or information may be required for the various
tasks.
In addition, you should allow for enough time and resources to make several full backups
at various steps along the way, enabling you to roll back your changes if necessary.
The following sections present some of the major tasks and considerations, and provide
sample worksheets to help you plan your migration.
Planning Infrastructure Changes
Before beginning the actual migration process, we recommend you take the time
to perform a thorough analysis of your requirements, organization, and existing
Documentum system. The following sections describe some of the most common
considerations in planning a system migration, and provide sample system configuration
diagrams and sample worksheets for recording your infrastructure and software
configuration.
Considerations
When planning your system migration, keep the following considerations in mind.
•
Include all the required team members in the planning process
Depending on how your organization is structured, you may need information
and resources from many different groups. For example, in some organizations,
host machines, relational databases, and repositories are administered by three
different groups.
•
Identify requirements for each application and object
•
Analyze the risks for your particular system
Because of the wide variation in Documentum systems, there’s no one-size-fits-all
list of risk factors. However, here are a few of the most common risks to take into
consideration when planning a migration:
— Delays in product availability
— Compatibility issues
— Obsolete components
48
For example, Documentum 5 no longer supports WSServer.dll or Documentum
WorkSpace DocManager.
— Loss of functionality in new products or product versions
— Java version compatibility issues
•
Identify customizations requirements
For some products, you must back up your customizations before upgrading, then
merge the customized files and folders with the newly-upgraded product. If you
are migrating from an obsolete product, such as Intranet Client, to its replacement,
Webtop, you must map your customizations and rewrite them for the new product.
•
Understand future enhancement requirements
•
Review all the upgrade paths available
•
Consult with all the appropriate technical and managerial resources
•
Ensure the hardware and network resources are comparable to your production
system
•
Give each team member their requirements in detail so they can independently
complete their assigned tasks
•
Define Test Plans that will stress the most functionality
•
Follow the installation guide and release notes suggestions for each product you
want to upgrade or migrate
•
Document all workarounds to issues
•
Create an issue log
•
Create flowcharts that depict your current Documentum system, with
inter-dependencies represented
•
For large or complex systems, set up a test environment to practice migration
•
Prepare a rollback plan that allows you to re-test an upgrade multiple times
•
Identify new reserved words in your customized code
Mapping Your Current Conguration
The following system configuration diagrams and sample worksheets can help you
document the infrastructure of your existing Documentum system.
To evaluate what hardware and software you will need to add to your current
infrastructure for successful migration to Documentum 5, use the preinstallation
requirements listed in the installation guides and Release Notes for the products you
want to upgrade or install.
49
Figure 4–1, page 50 shows a sample diagram that illustrates how to create a system
configuration diagram that describes what products are installed in your system, and
where those products reside.
Figure 4-1. Sample Initial System Conguration Diagram
The worksheets in Table 4–1, page 50 and Table 4–2, page 50 can help you to make a
detailed record of operating system versions, memory, disk space, and installed products.
Table 4-1. Initial System Conguration
Hardware
Memory
Operating System
Repository Size
Number of objects:
Storage space required:
Table 4-2. Initial Software Conguration
Component
Product
Version
Java
Java Run-Time Environment
RDBMS
Application Server
Documentum Products
to upgrade:
Content Server
DFC
Documentum Desktop
Documentum Administrator
WDK
Webtop
Web Publisher
50
Upgrade Roadmap
This section describes the supported upgrade paths for Documentum products.
Table 4-3. Migration Roadmap for Documentum Products
Product Name
Supported Versions for Upgrade to 5.3
Content Server
5.2.5 (with any service pack)
Documentum Foundation Classes (DFC)
Web Development Kit (WDK)
Web Publisher
Webtop
Determining Your Documentum 5 Conguration
This section describes some of the requirements for upgrading to Documentum 5.3,
and discusses decisions you must make about installing or upgrading Documentum 5
products.
Figure 4–2, page 52 shows how your system configuration might change during a
migration from a Documentum 5.2.5-based system to a Documentum 5.3 system. The
biggest changes are:
•
The addition of a host machine to handle full-text indexing
This additional host machine is required for Windows-based Content Server 5.3
installations, and recommended for Unix-based Content Server 5.3 installations.
•
Documentum 4i clients are not supported with Content Server 5.3
If you are still running Intranet Client or WorkSpace DocManager, you will need to
migrate to supported versions of Webtop or Documentum Desktop.
For information useful for determining which Documentum 5 client will work best
for you, see Appendix B, Documentum Clients Feature Comparison. For information
about migrating from Documentum 4i clients to Documentum 5 clients, see the
Documentum 5 System Migration Guide for version 5.2.5.
51
Figure 4-2. Documentum 5.3 System Diagram with Full-Text Index Server Host Machine
Planning for Changes Required by Mixed-Version
Environments
Some of the features in this release of the Documentum system affect multiple products.
Some, like global registries and setting up collaboration features, involve some planning
steps.
About Running Mixed-Version Environments
When planning your upgrade, you may want to upgrade in stages. Table 4–4, page 53
shows what client application versions are supported with Content Server 5.3.
Important facts to remember:
52
•
Documentum 5.3 products are not supported against any 4.x version of Content
Server.
•
If Retention Policy Services (RPS) or other BOF 5.3-based features (such as the
collaboration feature) are enabled in a repository (either on upgrade or when
a new repository is created), only version 5.3 and later clients can access that
repository. If this restriction is undesirable, you can manually set the value for the
oldest_client_version attribute in the Docbase config object to allow pre-5.3 clients
to connect. However, allowing pre-5.3 clients to connect to the repository may
circumvent the RPS security features.
Table 4-4. Client Applications Compatibility Matrix
Product Name
Product
Version
Compatible
with Content
Server 5.2.5,
5.2.5 SPx?
Compatible
with Content
Server 5.3?
Notes
Business
Process
Manager
5.2.5 SP2
Yes
No
5.2.5 SP3
Yes
Partial
5.3
No
Yes
Partially
compatible
means that
a 5.2.5 SP3
BPM user can
connect to a
Documentum
5.3 repository,
but will not be
able to open
workflows that
contain BPM
5.3-specific
features.
Business
Process
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Content
Intelligence
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Content
Rendition
Services
5.2.5, 5.2.5 SPx
Yes
Yes
Content
Services for
SAP
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Documentum
Administrator
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Documentum
Application
Installer
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
53
Product Name
Product
Version
Compatible
with Content
Server 5.2.5,
5.2.5 SPx?
Compatible
with Content
Server 5.3?
Documentum
Application
Builder
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Digital Asset
Manager
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Documentum
ADO.NET
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Documentum
Compliance
Manager
5.2.5, 5.2.5 SPx
Yes
Partial
Notes
DCM 5.2.5 SP1
is supported
with a 5.3
Documentum
repository
unless a BOF
5.3-based
product is
installed in that
Documentum
repository (for
example, RPS
or CCM).
If RPS or CCM
are installed,
the oldest_
client_version
attribute is set
in the Docbase
cofig object
to prevent
any pre-5.3
clients from
connecting.
Documentum
Client for
Microsoft
Outlook
54
5.3
Yes
Yes
Product Name
Product
Version
Compatible
with Content
Server 5.2.5,
5.2.5 SPx?
Compatible
with Content
Server 5.3?
Documentum
Portlets
5.2.5, 5.2.5 SPx
Yes
Yes
Documentum
Foundation
Classes
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Documentum
Desktop
5.2.5, 5.2.5 SPx
Yes
Yes
Document
Transformation
Services (DTS)
5.3
Yes
Yes
ECI Services
4.0
Yes
Yes
5.3
Yes
Yes
7.0 or higher
Yes
Yes
7.3
Yes
Yes
File Share
Services
5.2.5, 5.2.5 SPx
Yes
Yes
Forms Builder
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Import
Manager
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Learning
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Media
Transformation
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
eRoom
FTP Services
Notes
BOF 5.3 is only
compatible
with Content
Server 5.3.
55
Product Name
Product
Version
Compatible
with Content
Server 5.2.5,
5.2.5 SPx?
Compatible
with Content
Server 5.3?
PDF
Annotation
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Records
Manager
4.1, 4.1.1
Yes
Yes
5.2.5 SP1
Yes
Yes
Retention
Policy Services
5.3
No
Yes
Site Caching
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Site Delivery
Services
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Web
Development
Kit
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
WDK for
Portlets
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
WebDAV
Services
56
Notes
RPS supports
Content Server
5.3 only.
Product Name
Product
Version
Compatible
with Content
Server 5.2.5,
5.2.5 SPx?
Compatible
with Content
Server 5.3?
Notes
Workflow
Manager
5.2.5, 5.2.5 SP 1,
5.2.5 SP2
Yes
No
5.2.5 SP3
Yes
Partial
5.3
Yes
Partial
Partially
compatible
means that
a 5.2.5 SP3
BPM user can
connect to a
Documentum
5.3 repository,
but will not be
able to open
workflows that
contain BPM
5.3-specific
features.
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Web Publisher
Portlets
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Webtop
5.2.5, 5.2.5 SPx
Yes
Yes
5.3
Yes
Yes
Web Publisher
About Enabling RPS and Collaboration Features
If Retention Policy Services (RPS) or other BOF 5.3-based features (such as Collaborative
Services) are enabled in a repository (either on upgrade or when a new repository is
created), only version 5.3 and later clients can access that repository. Please take this
into account if you want to continue using existing 5.2.x client applications with your
5.3 repository.
If this restriction is undesirable, you can manually set the value for the
oldest_client_version attribute in the Docbase config object to allow pre-5.3 clients to
connect. However, allowing pre-5.3 clients to connect to the repository may circumvent
the RPS security features.
57
Planning for Global Registries
The business object framework global registry is part of the DFC 5.3 deployment
mechanism for service-based business objects and type-based business objects.
When you install Content Server or a Documentum 5.3 client application, the installer
will prompt you to specify a repository as your global registry. Your choice will also
apply to subsequent DFC and BOF-based clients that use the same DFC instance, for
example, if you have multiple clients running on the same PC, then they will all use the
repository you specified the first time you ran the installer.
What are Service-Based Business Objects?
A service-based business object (SBO) is the association of a service name (by convention,
a BOF interface name) and an implementation class that extends the DfService class and
implements IDfService. SBOs are not associated with a Docbase objects. You instantiate
them with the newService method of IDfClient, which requires you to pass it a session
manager.
You can use SBOs to implement utility functions to be called by multiple type-based
objecs (TBOs). For example, you can implement an SBO so that an application server
component can call the SBO, and the SBO can obtain and release Docbase sessions
dynamically as needed. You can also use SBOs to implement functionality (for example,
an inbox) that applies to more than one Docbase type.
For detailed information about SBOs, see the Documentum Foundation Classes (DFC)
Development Guide.
What are Type-Based Objects?
A type-based object (TBO) is the association of a user-defined Docbase type (normally a
subtype of dm_document) and an implementation class that extends the appropriate
Documentum class (normally, DfDocument).
For detailed information about TBOs, see the Documentum Foundation Classes (DFC)
Development Guide.
Do You Need a Global Registry in Your Documentum System?
When the business objects framework global registry is installed, you can deploy
service-based objects automatically from a central repository. Install the global registry
during repository configuration if you intend to deploy SBOs from that repository. There
is no limit to how many repositories may be configured as global registries.
58
You will need to configure a global repository if any of the following conditions are true:
•
You plan to install a Documentum application, such as Business Process Manager or
Retention Policy Services, that require SBOs.
The following Documentum client applications require you to set up a global
registry:
— Business Process Manager (BPM)
— Documentum Compliance Manager (DCM)
— Retention Policy Services (RPS)
This is a separately-licensed feature for Documentum Administrator.
— Webtop with Collaborative Services enabled
This is a separately-licensed feature for Webtop.
— Webtop with Rich Text Attributes enabled
This is a separately-licensed feature for Webtop.
•
You have a custom application that deploys any BOF 5.3 SBOs
To set up a global registry:
1.
Designate one or more repositories as a global registry.
You may need more than one global registry if you have applications that have
very different user access levels. For example, you might have a customized client
application that uses a particular set of SBOs where only a limited group of users
have access to the application. In this case, you mayt want to set up a global
repository for that application and application server. A second global registry can
then be used for a Webtop application that serves the general population of users.
2.
Create a BOF global user.
If you designated a repository as a global registry, the installer prompts you to enter
a user login name and password.
A user name of dm_bof_registry is created with the user login name and password
that you designate. The user state is set to ACTIVE but the repository access for this
user is limited to Read permission in the /System/Modules folder only. This makes
the business object framework services in the /System/Modules folder accessible to
the user.
3.
Ensure that when you install DFC on a client machine, you provide that DFC
installation with the BOF global user account info. (Desktop or WDK-based client
on app server host)
The BOF global user is automatically created in the repository when you designate
a global registry.
59
Preparing for the Business Objects Framework Global Registry
During repository configuration, you are asked whether to designate the repository as
a business objects framework global repository and the business objects framework
user is created in the repository.
The business objects framework 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 stored in a global registry in the repository. This
user has Read access to objects in the /System/Modules only, and no other objects.
This user is created in all repositories, regardless of whether the repository is configured
as a global registry:
•
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. You must then provide the
user login name and password to DFC clients during DFC installation on client hosts.
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
default values for the user login name and password 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.
Backward Compatibility for Customized Applications
Any applications you created or customized using previous releases of Documentum
5.2.x will still work if you choose not migrate; however, you will not be able to use any of
the new Documentum 5.3 features with applications that have not been migrated.
If you created or customized applications using WDK 4.x, you must migrate your
customized components to Documentum 5.3. This is because all WDK 4.x code has been
removed from the runtime, and WDK 4.x customizations are therefore not supported
with WDK 5.3. For example, the com.documentum.wc package, WDK 4.2 configuration
files and WDK 4.2 JSP pages have been removed from WDK 5.3.
Overview of Major Migration Tasks
Planning your migration to Documentum 5.3 involves the following major tasks:
60
•
Documenting your current customizations and configurations
•
Scheduling pre-migration tasks, such as backups and repository cleanups.
•
Upgrading to supported versions of Documentum 5.2.5 clients if you are running
earlier versions
•
Upgrading to Documentum 5.3 for existing products.
For example, use Upgrade In Place for the server.
•
Installing new Documentum 5.3 products.
•
Migrating customizations
In general, you should always upgrade Content Server and Documentum Administrator
first. Then, depending on which Documentum 5 products you want to install, you may
need to install supporting third-party products, such as a J2EE application server. Each
product-specific chapter in this book outlines the major tasks and prerequisites for
upgrading and migrating to the Documentum 5.3 version of that product.
Once you have upgraded Content Server, keep in mind that some Documentum 5
configurations are "all or nothing” upgrades. For example, Web Content Management
products, such as Web Publisher, must be upgraded as a set. Web Publisher 5 requires
other Documentum 5 products to run , and is not compatible with the 4.x versions of
those supporting products.
Figure 4–3, page 61 shows the recommended sequence of tasks for a typical migration
from a Documentum 5.2.5 system to a 5.3 system.
Figure 4-3. Recommended Sequence of System Migration Tasks
The following chapters explain the tasks shown in Figure 4–3, page 61 in greater detail.
61
Sample Pre-Migration Checklists and
Worksheets
This section presents some sample pre-migration worksheets you can adapt for your
own system. All of the items presented in the sample worksheets may not apply to your
particular Documentum system. You may also need to add rows to include information
about customized components.
System Analysis Worksheets
Use the following worksheets to document your current system.
Table 4–5, page 62 allows you to list your existing systems, and categorize them by
type and purpose. Your system may not contain all of the environments listed in Table
4–5, page 62, which are defined as follows:
•
Test
Used only for testing new software releases and examining different configuration
options before installing or migrating the development environment. The purpose of
the test environment is to minimize disruption to a production environment.
•
Development
Used for development or customization work, and as the point of entry for
deployment of custom applications to the production platform.
•
Staging
Used for load testing and user acceptance testing of custom applications.
•
Production
Used for the live deployment of applications and data.
Table 4-5. System Architecture Analysis Worksheet
62
Server
Type
Environment
Server
Name
Web
Servers
Production
Name:
Staging
Name:
Development
Name:
Test
Name:
O/S
CPUs
RAM/Disk Space
Server
Type
Environment
Server
Name
Application
Servers
Production
Name:
Staging
Name:
Development
Name:
Test
Name:
Production
Name:
Staging
Name:
Development
Name:
Test
Name:
repositories
O/S
CPUs
RAM/Disk Space
63
Table 4-6. Documentum System Analysis Worksheet
Documentum Product
Associated
Components
Your Information
Content Server
Host machine names
or IP addresses:
Host 1:
Host 2:
Host 3:
Host machine
operating system
version:
Host 1:
Host 2:
Host 3:
RDBMS
Type:
Oracle/Sybase/SQL Server/DB2
Version:
DBA Username:
DBA Password:
Unicode-enabled? Y/N
Content Server version
Version:
Installation owner name:
Installation owner password
Repository Name
Repository 1:
Repository 2:
Repository 3:
Custom Server
Methods?
Method Name 1:
Method Name 2:
Method Name 3:
Method Name 4:
Custom object types?
Custom type 1:
Custom type 2:
Custom type 3:
64
Documentum Product
Associated
Components
Your Information
Custom type 4:
Custom DQL scripts?
Custom DQL Script Name 1:
State of Docbase
Report (if Upgrading
from 5.2x - to show
object breakdown and
content formats)
Web Products
Application Server
Version?
Application Server:
Host machine names
or IP addresses:
Host 1:
Version:
Host 2:
Host 3:
Web Server Operating
System?
O/S:
Browser Operating
Systems?
• Operating System #1:
• Number of clients:
Customizations?
• Type:
• Location/Changed Files:
• Type:
• Type:
Documentum Web
Clients?
Webtop:
eConnector for Application Servers:
Custom DFC Clients?
Transaction Server?
Server:
65
Documentum Product
Associated
Components
Your Information
Business Logic
Components
Component 1:
Component 2:
Component 3:
Customization Analysis Worksheets
Table 4–7, page 66 presents a sample pre-migration worksheet you can adapt for your
own system. All of the items presented in the sample worksheet may not apply to your
particular Documentum system.
The following sample worksheet includes some sample entries. Replace these entries
with your own information. You may also need to add rows or columns to include
information about customized components.
Table 4-7. Documentum Customization Analysis Worksheet
66
Customization or Component ID
Customization Type
Tools Used
Customization ID or
Location
Description
checkout
role-based
action
WDK,
Webtop
path to custom
folder
Restrict checkout of
documents even if the
user has VERSION
permission. Only
contributors can check
out documents: This is
applied through a role
precondition.
002
query
DQL
AutoRender
Pro queue
check
Searches AutoRender
Pro queues for
repository to
determine how many
rendition requests are
pending.
Customization or Component ID
Customization Type
Tools Used
Customization ID or
Location
Description
srch-001
change how
search results
are displayed
in Webtop
WDK
Search Component extension: This
class extends
com.documentum.webcomponent.library.
search.Search
and implements
IClientUpdateEvent.
Adds a Classic view
(UI presentation)
of search results,
and uses the
webcomponent UI
as the streamline view.
The following worksheet is intended to help you decide whether you need a global
registry for your BOF objects.
Table 4-8. Custom Objects Inventory Worksheet
Custom Object
Located in
Docbase:
Supertype?
Type-based
Object?
Service-based
Object?
67
68
Chapter 5
Planning for Full-Text Indexing
Full-text indexes enable users to search a repository for specific text found in stored documents or the
attributes of documents. EMC Documentum’s implementation of full-text indexing requires the user
to make a number of configuration decisions before installing or upgrading a repository.
This chapter contains the following information:
•
Overview, page 69
•
Index Agent, page 70
•
Index Server, page 71
•
Full-Text Indexing Components Configuration Options, page 71
•
Sharing the Drives Where Content Files are Located, page 71
•
Which Ports to Use for the Index Agent, page 72
•
Which Ports to Use for the Index Server, page 72
•
Choosing Languages for Grammatical Normalization, page 72
•
Disk Space Requirements for Index Server, page 73
•
Memory Requirements for Index Server, page 73
•
Planning for a New Repository, page 73
•
Planning for Full-Text Migration, page 74
Overview
The full-text indexing implementation consists of three software components: Content
Server, the index agent, and the index server.
Content Server manages the objects in a repository, generates the events that trigger
full-text indexing operations, queries the full-text indexes, and returns query results to
client applications. For a complete description of the full-text indexing process, refer to
"Full-Text Indexing” in the Content Server Administrator’s Guide.
69
Each repository in which full-text indexing is enabled requires its own index server
and index agent.
Full-text indexing is not supported for installations on Microsoft Cluster Services.
Index Agent
The index agent exports documents from a repository and prepares them for indexing.
The index agent is a Web application running in an instance of the Apache Tomcat servlet
container. Installing the index agent also installs Tomcat. Each index agent runs in
its own Tomcat instance.
A particular index agent runs against only one repository. The index agent can be
installed on the Content Server host or remotely. If installed remotely, the index agent
must be installed on a supported operating system. Refer to the Content Server Release
Notes for a list of the support operating systems.
Index Agent Modes
The index agent is typically run in one of two modes, migration mode or normal mode.
In migration mode, the index agent prepares all indexable objects for indexing in object
ID order. A single queue item records the ID of the most recent object indexed. The
index agent reads the value in the queue item, exports the next object, and updates the
queue item. The index agent can run in migration mode to create new indexes against a
5.2.5.x, or 5.3 repository.
Content Servers 5.3 and later generate a queue item any time an event such as a check-in
or save requires that a new or modified object must be indexed. In normal mode, the
index agent reads the queue item, prepares the object for indexing, and updates the
queue item. When the index agent submits the object for indexing, the index agent
deletes the queue item from the repository. The index agent can run in normal mode
only against a 5.3 repository.
The index agent can also be run in file mode, which is compatible with any other
operational mode, to resubmit objects for indexing. For information on using file mode,
refer to the section in Chapter 8 entitled Resubmitting Objects for Indexing.
70
Index Server
The index server creates full-text indexes and responds to full-text queries from Content
Server. A particular index server runs against only one repository.
The index server’s operations are processor- and memory-intensive, and it is therefore
recommended that you install the index server on a host remote from the Content Server
host. The index server must be installed on a supported operating system. Refer to the
Content Server Release Notes for a list of the support operating systems.
About the Indexing Process
The indexing process is not destructive to existing content or attributes in the repository.
Full-Text Indexing Components Conguration
Options
Documentum supports the following two configurations for the full-text indexing
components:
•
Content Server, repository, index agent, and index server on a single host
•
Content Server and repository on one host with the index agent and index server
on a separate host
The index agent and index server must be installed on the same operating system as
Content Server. For example, if Content Server and the repository are on a Windows
host, the index agent and index server for that repository must also be on Windows.
Each repository requires its own index agent and index server. For example, if you have
multiple repositories in a single Content Server installation, you must install a separate
index agent and index server for each repository.
Sharing the Drives Where Content Files are
Located
The index server requires access to the content files in a repository. For performance
reasons, it is recommended, but not required, that you mount or share the drive or drives
where the repository’s file stores are located with the host where the index server is
located. Refer to the documentation for your operating system for instructions.
71
Which Ports to Use for the Index Agent
The index agent runs in the Apache Tomcat servlet container. When an index agent
instance is configured, you must designate two ports for the index agent and Tomcat to
use. The default ports for the first index agent on a host are 9081 and 9008. If the index
agent is on the Content Server host, ensure that the ports are not the ports used for
the Java method server.
Which Ports to Use for the Index Server
The index server requires a contiguous range of 4000 (four thousand) free ports. You
must designate which ports to use during installation. The default range is from 13000
to 17000.
Choosing Languages for Grammatical
Normalization
The full-text indexing system automatically provides multilingual search capabilities.
For the languages in which you search most often, it is recommended that you enable
grammatical normalization. This loads special dictionaries into the index server host’s
memory and improves the ability of the search and indexing components to accurately
retrieve terms. Grammatical normalization ensure that all forms of a word are indexed
and that a search for one form of a word also returns other forms of a word. For example,
a search for "cars” also returns "car” if nouns are normalized.
The following combinations of parts of speech can be normalized:
•
Nouns
•
Nouns and adjectives
•
Nouns, adjectives, and verbs
•
Nouns and verbs
Grammatical normalization is enabled automatically for Chinese, Japanese, and Korean.
Grammatical normalization can be optionally enabled for the following languages:
72
•
German
•
English
•
Spanish
•
French
•
Hungarian
•
Italian
•
Norwegian
•
Polish
•
Portuguese
•
Russian
The memory requirements for the additional dictionaries may result in lower search
and indexing performance.
Disk Space Requirements for Index Server
The index server requires a minimum of 3 GB of free space on the drive where it is
installed. This is an operational, rather than installation, requirement.
In addition, there must be sufficient free disk space for the indexes.
Memory Requirements for Index Server
The index server requires 2 GB of RAM available after taking into consideration all other
RAM utilization requirements on the index server host.
Planning for a New Repository
If you are creating a new repository in which full-text indexing is enabled, you must
make the following decisions:
•
Which hardware to use for running the index agent and the index server
It is recommended that you use a host other than the Content Server host for the
index server.
The index agent and the index server must be installed on the same supported
operating system as Content Server. The index agent and index server are not
required to be installed on the same host.
•
Which configuration to use.
Refer to Full-Text Indexing Components Configuration Options, page 71 for more
information.
•
Whether to mount or share the drives where content files are located
73
Refer to Sharing the Drives Where Content Files are Located, page 71 for more
information.
Installation Order
This is the high-level procedure for installing the server and full-text indexing
components for a new installation:
1.
Choose hardware.
2.
Install Content Server and configure a repository.
Use the instructions in Chapter 6, Express Installation, or Chapter 7, Custom
Installation.
3.
Install the index server and index agent configuration program.
Use the instructions in Chapter 8, Installing the Full-Text Indexing Components.
4.
Configure an index agent instance in normal mode.
5.
Start the full-text indexing process.
Use the instructions in Chapter 8 in the section Creating the Full-Text Index.
Planning for Full-Text Migration
Content Server releases before 5.3 used the Verity full-text engine for full-text indexing.
Content Server releases 5.3 and later use the index agent and index server for full-text
indexing. Migrating to Content Server 5.3 or later requires that you make some decisions
before migrating to the new implementation.
Migrating Verity Customizations
Existing Verity thesaurus and lex files can be migrated to the new full-text indexing
implementation. Contact Documentum Professional Services for full information on
how to migrate the files.
The new implementation does not use stop words. All words are indexed in order to
support searching by phrase. The new implementation does not use topic trees. Existing
stop files and topic trees do not need to be migrated.
74
When to Migrate the Full-Text Indexing System
Two models are supported for migrating to the new full-text implementation:
•
Pre-upgrade migration
In this model, the index agent and the index server are installed and run against the
pre-5.3 production repository or a copy of the pre-5.3 production repository. The
new index is created before Content Server is upgraded. After the index is created,
the server and repository are upgraded and the new index is used. The full-text
indexing system is completely available and up-to-date after Content Server is
upgraded. For more information about planning for a pre-upgrade migration, refer
to Planning for Pre-Upgrade Migration, page 75.
Pre-upgrade migration is recommended for very large repositories or for any
repository where it is a business requirement that the full-text system is available in
a consistent state immediately after the upgrade.
•
Post-upgrade migration
In this model, Content Server and the repository are upgraded first. The index
agent and the index server are installed and the new index is created. The full-text
system is in an inconsistent state until the index is created. For more information on
post-upgrade migration, refer to Planning for Post-Upgrade Migration, page 77.
Post-upgrade migration is recommended for small repositories (fewer than 100,000
documents) or for any repository where it is acceptable for the full-text system to be
in an inconsistent state immediately following the repository upgrade.
Planning for Pre-Upgrade Migration
If you use pre-upgrade migration, you must make the following decisions:
•
Whether to index the production repository or a copy of the repository
To test a Content Server upgrade, it is recommended that you create a copy of the
repository and test the server and repository upgrade on the copy. You can create
the new full-text index by indexing either the copy or the production repository.
If the repository is extremely large, creating new indexes takes a significant period of
time. You may prefer to test the time and space required for creating new indexes
on a copy or on the production repository. If you decide to index a copy of the
repository, use the instructions in , to create a repository copy.
You are not required to create a copy of the content files, even if you create a
repository copy. Instead, the file stores can be shared with the repository copy.
•
75
index server. If you index the production repository rather than a copy, this is
strongly recommended because creating new indexes is processor-intensive.
The index agent and the index server must be installed on an operating system that
is supported for 5.3. If the production repository is installed on an older operating
system that is not supported for the index agent and the index server, you must
install the index agent and the index server on one or more remote hosts.
The index agent and the index server must be installed on the same supported
operating system as Content Server. The index agent and index server are required
to be installed on the same host.
On Windows systems, you cannot install more than one version of DFC and the
index agent requires DFC 5.3. You must therefore install the index agent and index
server on a host other than the Content Server host.
On UNIX systems, you can install the index agent and index server on the Content
Server host, provided the operating system is supported. You must ensure that the
environment variables are set so that the existing Content Server continues to use the
older DFC with which it was installed and the index agent uses DFC 5.3.
•
information.
•
information.
Installation Order for a Pre-Upgrade Migration
If you use pre-upgrade migration, the overall procedure, including decisions to be
made, is:
1.
Decide whether to index the production repository or a copy.
2.
Choose hardware for the index agent and index server.
3.
If you are indexing a repository copy, create the copy.
Use the instructions in Chapter 4 in the section Creating a Repository Copy to Test
an Upgrade.
4.
Install the index server and configure an index agent in migration mode.
5.
76
Create the full-text indexes.
6.
Run the migration integrity tool.
Use the instructions in Chapter 8 in the section Verifying the Full-Text Indexes.
7.
If any documents were not indexed, resubmit those documents for indexing.
Use the instructions in Chapter 8 in the section Resubmitting Objects to the Index
Agent.
8.
Upgrade the repository.
Use the instructions in Chapter 9, Upgrading Content Server.
9.
Shut down the migration-mode index agent and delete it.
10. Configure an index agent in normal mode.
Ensure that the index agent is pointed to the correct index server instance.
Planning for Post-Upgrade Migration
Post-upgrade migration assumes that new full-text indexes are created using the
production repository, not a copy. If you choose post-upgrade migration, you must make
the following decisions:
•
index server. If you index the production repository rather than a copy, this is
strongly recommended because creating new indexes is processor-intensive.
The index agent and the index server must be installed on an operating system that
is supported for 5.3. The index agent and the index server must be installed on the
same supported operating system as Content Server. The index agent and index
server are not required to be installed on the same host.
•
information.
•
information.
77
Installation Order for a Post-Upgrade Migration
If you use post-upgrade migration, the overall procedure, including decisions to be
made, is:
1.
Choose hardware for the index agent and index server.
2.
Upgrade the repository.
Use the instructions in .
3.
Install the index server.
4.
Configure an index agent in migration mode.
5.
Create the full-text indexes.
6.
Delete the migration-mode index agent.
7.
Configure an index agent in normal mode.
8.
Run the migration integrity tool.
Use the instructions in Chapter 8 in the section Verifying the Full-Text Indexes.
9.
If any documents were not indexed, resubmit those documents for indexing.
Use the instructions in Chapter 8 in the section Resubmitting Objects to the Index
Agent.
78
Chapter 6
This chapter provides server-specific information about upgrading and configuring Content Server.
The following topics are discussed:
•
What’s New in Content Server?, page 79
•
The Content Server 5.3 Documentation Set, page 80
•
Architecture Changes For Content Server, page 81
•
•
Changes to Server Features and Implementation, page 86
•
Obsolete and Deprecated Types and Attributes, page 105
What’s New in Content Server?
Content Server 5.3 contains the following new and enhanced features. For information
about changes from the initial release of Content Sever version 5.2.5 through the latest
5.2.5 Service Pack, see the Release Notes for the specific Service Pack version you are
interested in.
•
The ability to use SSL communications between Content Server and client libraries is
now part of the standard server package. It is no longer controlled by the Trusted
Content Services license.
•
Enhancements to ACLs that provide additional flexibility in assigning object-level
security
•
Ability to define groups as dynamic groups
•
Support for Java in lifecycle entry criteria, actions on entry, post-entry actions, and
validation programs
•
New workflow functionality, including
— Support for XPath specifications in route case conditions
— New workflow timer implementation, including the ability to use a timer to
automatically resume suspended activities
79
— Support for work queues
— Ability to define the number of tasks required to complete an activity 95.2.5 SP1)
— Ability to limit the number of output ports selected by a user upon completion of
a task (5.2.5 SP1)
— Ability to define transition behavior when multiple, contradictory (revert and
forward) ports are selected (5.2.5 SP1)
— Ability to define a task subject, using parameters resolved at runtime, to provide
more information for task owners (5.2.5 SP1)
— Ability to record a component name in the package object, for use in the task
subject (5.2.5 SP1)
•
Global login tickets and application access tokens
•
Ability to schedule jobs in a sequence
•
A change to the connection pooling implementation that changes how the
connect_recycle_interval value in the dmcl.ini file is interpreted
•
New querying ability called FTDQL.
FTDQL is a subset of the SELECT statement syntax that queries the fulltext index
rather than the repository. Using FTDQL provides performance benefits. For details,
refer to the SELECT statement description in the Content Server DQL Reference Manual.
The Content Server 5.3 Documentation Set
The Content Server documentation set for the 5.3 release consists of the following:
80
•
Content Server Installation Guide, version 5.3
•
Content Server Release Notes, version 5.3
•
Content Server Administrator’s Guide, version 5.3
•
Content Server API Reference Manual, version 5.3
•
Documentum Content Server Combined Index, version 5.3
•
Distributed Configuration Guide, version 5.3
•
Content Server DQL Reference Manual, version 5.3
•
Content Server Fundamentals, version 5.3
•
Content Server Object Reference Manual, version 5.3
Architecture Changes For Content Server
The biggest change in Content Server 5.3 is a changed architecture for handing the new
full-text indexing system. Full-text indexing is now handled by a separate index server
and index agents, as shown in Figure 6–1, page 81:
Figure 6-1. Content Server 5.3 with Index Server and Index Agents
For performance reasons, we recommend that you set up and run the new full-text index
agent and index server on a separate machine. If you are running Content Server on a
Windows system, setting up a separate host machine for index agent and index server
is required, due to the restrictions of running different DFC versions on the same host
machine.
The index agent prepares documents in a repository for full-text indexing. (Full-text
indexing allows users to easily locate documents containing specific text.) There can be
one or more index agents running against a particular repository, on the Content Server
host or a remote host.
81
The index server creates and maintains full-text indexes and responds to full-text queries
from Content Server. There can be one or more index servers on the network, for
scalability and improved performance.
This section describes supported upgrade paths from previous releases of Content
Server, and provides an overview of typical migration tasks for a Content Server
installation with one or more content repositories (formerly known as Docbases).
Supported Upgrade Paths
You can only upgrade to Content Server 5.3 from Content Server versions 5.2.5 (with
any Service Pack).
If you are running a Documentum 4i system, you must first upgrade to Content Server
5.2.5 before upgrading to Content Server 5.3.
For information about migrating from Documentum 4i to Documentum 5, see Chapter 3,
Migrating Servers and Docbases, in the Documentum 5 System Migration Guide for version
5.2.x.
Overview of Migration Tasks
If you are upgrading from an earlier version of Content Server, your repository’s full-text
indexes were created using the Verity full-text engine. This release of Content Server
uses a different third-party index server, and you will have to migrate your repositories
to the new full-text indexing implementation.
There are three supported migration models for this release of Content Server:
•
Pre-upgrade migration of full-text indexes
In this case, the full-text migration happens before you upgrade Content Server.
You install and run the index agent and index server against your 5.1.x or 5.2.x
content repositories. After the indexing operation completes, you then upgrade your
Content Server and repositories, and connect the newly upgraded repository to the
previously created full-text index. This strategy ensures that even if it takes some
time to create the full-text index, there will be little or no down-time of the full-text
index subsystem, because it is entirely built before the upgrade.
•
82
Pre-upgrade migration of full-text indexes using a copy (or clone) of your repository
If you choose to test your Content Server and repository upgrade against a test
system before upgrading your production system, you may be able to run the index
agent and index server against a copy of your repository.
Testing your upgrade and migration with a test system may also help you with
planning the upgrade of your production system by providing some performance
benchmarks.
•
Post-upgrade migration full-text indexes
In this case, you upgrade your Content Server and repositories, then re-index
the content in the repository. This means that full-text sub-system will be in an
inconsistent state from the time of the upgrade to the time when re-indexing
operation completes.
Tip: If you have very large content repositories, we recommend performing pre-upgrade
migration of full-text indexes.
Figure 6–2, page 84 shows the task sequence for the pre-migration full-text indexing
option:
83
Figure 6-2. Content Server Migration Task Overview
84
Pre-upgrade Migration of Full-Text Indexes
If you choose to re-index your repositories before upgrading, you will have a usable
full-text index immediately after upgrade. This decision means you can continue using
the old full-text indexes while the new indexes are being created, resulting in less down
time.
1.
Optionally, create a copy of your production repository to use as a test system.
2.
Decide where to locate the index agent and index server.
Tip: For performance reasons, we recommend that you run the index agent and
index server on a separate machine. (This is required if you are running Content
Server on Windows servers).
3.
Mount or share the drives where the content files are located.
The content file drives must be made local to the index server and index agent. We
strongly recommend that you mount these drives as read-onlẏ.
4.
Install the index agent and index server on the location you decided earlier.
You must install the index agent and index server as the Content Server installation
owner.
5.
Create the new full-text indexes using the instructions in the Content Server
Installation Guide.
6.
Verify the completeness of the newly-created indexes using the Full-Text Integrity
too.
For detailed information, see the section named "Verifying Full-Text Index
Migration,” in Chapter 8, Migrating Full-Text Indexes, in the Content Server Installation
Guide.
7.
Upgrade to Content Server 5.3.
For detailed information and step-by-step instructions for upgrading Content Server,
see the Content Server Installation Guide.
8.
If you chose to upgrade on a test system first, verify that the upgrade and migration
were successful, then repeat upgrade of Content Server and repositories for your
production system.
9.
If you created your full-text indexes on a test system, connect the newly upgraded
repository to the previously created full-text index.
85
Post-upgrade Migration of Full-Text Indexes
1.
Upgrade to Content Server 5.3 and upgrade your content repositories to 5.3.
For detailed information and step-by-step instructions for upgrading Content Server,
see the Content Server Installation Guide.
2.
Decide where to locate the index agent and index server.
Best practice recommendation: for performance reasons, run the index agent and
index server on a separate machine (this is required if you are running Content
Server on Windows due to DFC restrictions).
3.
Mount or share the drives where the content files are located.
The content file drives must be made local to the index server and index agent. We
strongly recommend that you mount these drives as read-onlẏ.
4.
Install the index agent and index server on the location you decided earlier.
5.
Create the new full-text indexes using the instructions in the Content Server
Installation Guide.
6.
Verify the completeness of the newly-created indexes using the Full-Text Integrity
tool.
For detailed information about the Full-Text Integrity tool, see the Content Server
Installation Guide.
Changes to Server Features and
Implementation
This section describes changes made in this release to Content Server features,
architecture, and the object model.
Changes to Full-Text Indexing
The following changes have been made for the new full-text indexing implementation:
86
•
Case-sensitive searching is not supported.
•
The content files associated with all SysObjects are indexed.
•
All SysObject attributes are indexed, regardless of data type, including the attributes
of custom subtypes of SysObjects.
•
Objects in all storage areas are indexed.
Obsolete Content Attributes
The following content attributes are now obsolete:
•
fulltext_index
•
index_format
•
index_formats
•
index_operations
•
index_pages
•
index_parent
•
index_parents
•
index_set_times
•
index_subtypes
•
i_index_format
Additions to System Events
Table 6–1, page 87 lists the new system events recognized by Content Server 5.3. For
information about system events, see Content Server Fundamentals and Appendix B,
System Events, in the Content Server API Reference Manual.
Table 6-1. New System Events
Event
Description
dm_add_dynamic_group
Generated by a session call that adds a user to a dynamic
group.
dm_addattachment
Generated when an attachment (a wf attachment object) is
added to a workflow.
dm_addretention
Object placed under control of a retention policy
dm_changedactivityinstancestate
Generated when an automatic activity changes state
because the error handling flag is set to 0 and the work
item returns a non-zero value.
dm_move_content (5.2.5
SP2)
Generated when a content file is moved from one storage
area to another by a MIGRATE_CONTENT administration
method.
dm_pauseworkitem
Generated when a work item is paused.
87
Event
Description
dm_remove_dynamic_
group
Generated by a session call that removes a user from a
dynamic group.
dm_removeattachment
Generated when an attachment (wf attachment object) is
removed from a workflow.
dm_removeretention
Object removed from control of a retention policy
dm_resumeworkitem
Generated when a work item is resumed.
dm_setretentionstatus
Change to status of a retainer object.
Additionally, the string_3 attribute for the dm_startedworkitem event was modified to
include values from work queue-related functionality, when the work item performer is
a user from a work queue.
Changes to Existing Events
The following system events were changed for this release of Content Server.
dm_startedworkitem
The string_3 attribute for the dm_startedworkitem event was modified to include values
from work queue-related functionality, when the work item performer is a user from
a work queue.
dm_addrendition
The audit trail record for the dm_addrendition event now uses the string_2 attribute.
It stores the value "Replace Old Rendition” if the added rendition replaces an existing
rendition or "Save New Rendition” if the added rendition is new and does not replace an
existing rendition.
Addition of dm_retainer as a Target
Many existing events were enhanced to accept dm_retainer as the target of the audited
event.
88
New Extended Permission for Users
There is one new extended permission for users: delete_object. This permission allows a
user to delete an object but does not give the user the hierarchical permissions accorded
to a user with the base delete permission. That is, a user with delete_object permission
for an object may delete that object but cannot necessarily version or overwrite the object.
Privileged Groups
This release introduces privileged groups — system-defined groups whose members
are allowed to perform privileged operations that the group members do not have the
privileges as individuals to perform. Table 6–2, page 89, lists the new groups.
Table 6-2. Privileged Groups Created During Repository Conguration
Group
Members
dm_browse_all
Members of this group can browse any object in the repository.
This group has no default members.
dm_browse_all_
dynamic
This is a dynamic group whose members can browse any
object in the respository.
dm_retention_
managers
Members of this group can own retainer objects (representing
retention policies) and add and remove a retainer from any
SysObject.
This is a dynamic group.
dm_retention_users
Members of this group can add retainers (retention policies)
to SysObjects.
89
Group
Members
dm_superusers
Members of this group are treated as superusers in the
respository.
dm_superusers_
dynamic
A dynamic group whose members are treated as superusers
in the respository.
Utility Changes and Additions
The following new utilities were added to this release:
•
dmtkgen
This utility is used to generate application access tokens for storage on client
and application server hosts. For more information, refer to the Content Server
Administrator’s Guide.
•
dcf_edit
This utility allows you to edit the file used when executing job sequences. For more
information, refer to Content Server Administrator’s Guide.
New and Changed Object Types
Table 6–3, page 90 lists the new object types in release 5.3.
Table 6-3. New Object Types Introduced in Release 5.3
90
Object Type
Description
dm_acs_config
This object type is added to support a future releases.
Objects of this type are neither created nor used in the
first release of Content Server 5.3.
dmc_aspect_relation
This is a new object type currently not supported for
external use.
dmc_aspect_type
This is a new object type currently not supported for
external use.
Object Type
Description
dmc_comment
Records a comment in a discussion. Used by
Collaborative Services.
dmc_completed_workflow
This new object type supports the Workflow Reporting
utility in Webtop. Instances of the type record
information about a completed workflow. They are
generated by the dm_WfReporting method.
dmc_completed_workitem
This new object type supports the Workflow Reporting
utility in Webtop. Instances of the type record
information about a completed workitem. They are
generated by the dm_WfReporting method.
dmc_composite_predicate
This new object type supports XPath expressions in
route case conditions for automatic activity transitions.
Objects of this type are created internally when a user
defines a route case condition that includes an XPath
expression. (The user must be using BPM to define
the route case condition.)
dm_ftindex_agent_config
This is a new object type. There is one ft index agent
config object associated with each index agent. The ft
index agent config object records information about
the index agent is updated periodically by the index
agent.
dmc_jar
This new object type is a subtype of dm_sysobject. A
jar object represents a jar file stored in the repository.
The file is stored as the content of the jar object. The
object type is installed by a script when Content
Server is installed, and instances are created through
Documentum Application Builder.
dmc_java_library
This new object type is a subtype of dm_folder. Each
java library object represents one third party library
used by a business object module. The library files are
stored inside the java library folder. The object type is
installed by a script when Content Server is installed
and instances are created through Documentum
Application Builder.
91
92
Object Type
Description
dm_job_sequence
This new object type is a subtype of dm_sysobject.
A job sequence object stores information about
a job that belongs to a set of jobs executed in a
particular sequence. Sequenced jobs are executed
using the dm_run_dependent_jobs method, which
can be invoked by another, controlling job or on the
command line. Job sequence objects are created using
Documentum Administrator.
dmc_module
The module object type is a new object type. A
module object represents a business object module.
The information in the attributes describe the module.
The object type is installed by a script when Content
Server is installed. Instances of the type are created
using Documentum Application Builder.
dmc_module_config
The module config object type is a new object type.
A module config object references a business object
module called to implement a workflow timer. It also
stores parameter values to pass to the business object
module. The object type is installed by a script when
Content Server is installed. Module config objects are
created internally when workflow timers are set up
using BPM.
dmc_notepage
Represents documents that are the subject of a
discussion but do not require versioning services.
Objects of the type are used by Collaborative Services.
dmc_readcomment
Used to manage unread comments in a discussion.
Objects of the type are used by Collaborative Services.
dmc_richtext
This new object type represents rich text content
associated with a SysObject. Objects of the type are
used by Collaborative Services.
dmc_room
This is a new object type supporting Collaborative
Services as exposed in Webtop. Rooms are a subtype
of folders. They provide an additional layer of access
control for documents used in collaborative projects.
dmc_rps_authority
This object type is added when the Retention Policy
Services (RPS) DocApp is installed. RPS is an optional
product that allows you to define retention policies
governing document retention in the repository.
Object Type
Description
dmc_rps_base_date
dmc_rps_child_strategy
dmc_rps_condition
dmc_rps_contact
dmc_rps_disposition_
method
dmc_rps_event
dmc_rps_hold
dmc_rps_phase_rel
dmc_rps_retainer
93
94
Object Type
Description
dmc_rps_retainer_event_rel
dmc_rps_retention_policy
dmc_tcf_activity
This new object type supports the use of Java for entry
criteria and actions in lifecycles. Objects of this type
are created internally when a user defines the actions
on entry for a state. Objects of this type may not be
created manually.
dmc_tcf_activity_template
This new object type supports the use of Java for
entry criteria and actions in lifecycles. Each tcf
activity template object represents one action that
may be performed on an object when it enters a state.
Installing Lifecycle Editor installs a system-defined
suite of actions and creates the corresponding tcf
activity template objects in the repository. Objects of
this type may not be created manually.
dmc_transition_condition
This new object type supports XPath expressions in
route case conditions for automatic activity transitions.
Objects of this type are created internally when a user
defines a route case condition that includes an XPath
expression. (The user must be using BPM to define the
route case condition. Only BPM allows the definition
of an XPath expression in a route case condition.)
dmi_wf_attachment
This new object type supports workflow attachments.
A wf attachment object represents an object that is
attached to a running workflow. The type is created
through a script when Content Server is installed.
Objects of the type are created automatically when
an object is attached to a workflow. (Attachments
are added to or removed from workflows using DFC
methods.)
Object Type
Description
dmc_wf_package_schema
This is a new object type. A wf package schema object
stores the URI that points to a particular XML schema
used to resolve an XPath expression in a workflow
transition condition. The type is created through a
script when Content Server is installed. Instances of
the object type are created and managed internally,
through BPM.
dmi_wf_timer
This new object type supports workflow timers. The
object type is created created through a script when
Content Server is installed. Instances of the object
type represent individual timers and are created and
managed internally, as needed when a workflow
executes.
dmc_workqueue
This new object type represents workqueues for
workflow tasks. The type is installed through a script
when Content Server is installed. Work queues are
created and managed using BPM.
dmc_workqueue_category
This is a new object type. A workqueue category
object identifies a category of workqueue. The type
is installed through a script when Content Server
is installed. Workqueue categories are created and
managed using BPM.
dmc_workqueue_doc_profile
The workqueue doc profile object type is a new object
type. A workqueue doc profile object identifies a
particular kind of document. The internal name of the
object type is dmc_workqueue_doc_profile. The type
is installed through a script when Content Server is
installed. Workqueue doc profile objects are created
and managed using BPM.
dmc_workqueue_policy
The workqueue policy object type is a new object type.
A workqueue policy object identifies how tasks placed
on a particular work queue are handled. The type
is installed through a script when Content Server is
installed. Workqueue policy objects are created and
managed using BPM.
95
96
Object Type
Description
dmc_workqueue_user_
profile
The workqueue user profile object type is a new object
type. A workqueue user profile records information
about a user who performs tasks on a workqueue. The
type is installed through a script when Content Server
is installed. Workqueue user profile objects are created
and managed using BPM.
dm_network_location_map
This object type is added to support a future releases.
Objects of this type are neither created nor used in the
first release of Content Server 5.3.
dm_relation_ssa_policy (5.2.5
SP1)
This new object type is a subtype of dm_relation.
Instances of the type are used to associate a content
assignment policy (as represented by a ssa policy
object) with an object type. This new type supports
Content Storage Services.
dm_retainer
This object type is added to support Retention Policy
Services, an optional product that allows you to define
retention policies governing document retention in
the repository.
dm_ssa_policy (5.2.5 SP1)
This a new object type is a subtype of dm_sysobject.
Instances of the type are created internally when
a user creates a content assignment policy using
Documentum Administrator. A Content Storage
Services license is required to create a content
assignment policy.
dm_topic
Objects of this type are used by Collaborative Services.
dm_xfm_form
This is a new object type supporting EMC
Documentum Forms Builder. An xfm form object
stores information about a form template. The object
type is installed when the DocApp provided with
Forms Builder is installed. Instances of the type are
created internally when EMC Documentum Forms
Builder is used to create a form template.
Object Type
Description
dm_xfm_instance
Documentum Forms Builder. A xfm instance object
contains information about one form. The object
type is installed when the DocApp provided with
EMC Documentum Forms Builder is installed.
Instances of the type are created internally when EMC
Documentum Forms Builder is used to create a form.
dm_xfm_schema
Documentum Forms Builder. An xfm schema object
represents an XML schema used with a form. The
object type is installed when the DocApp provided
with EMC Documentum Forms Builder is installed.
Instances of the type are created internally when EMC
Documentum Forms Builder is used to create a form.
New and Changed Attributes
Table 6–4, page 97 lists the additions to existing object types.
Table 6-4. Additions to Existing Object Types in Release 5.3
Object
Type
New or Changed Attributes
Datatype
dm_acl
i_has_access_restrictions
Boolean
i_has_required_groups
Boolean
i_has_required_group_set
Boolean
r_application_permit
string 128
r_permit_type
integer
97
Object
Type
Datatype
dm_activity
pre_timer_increment
integer
r_package_flag
integer
pre_timer_action
ID
pre_timer_repeat_last
Boolean
post_timer_increment
integer
post_timer_action
ID
post_timer_repeat_last
Boolean
r_predicate_id
ID
transition_max_output_cnt
integer
(added in 5.2.5 SP1)
transition_eval_cnt
integer
transition_flag
integer
task_subject
string 255
dm_audittrail
audited_obj_id
ID
i_audited_obj_class
integer
dmi_
audittrail_
acl
application_permit
string 128
permit_type
integer
dmi_
audittrail_
group
is_dynamic
Boolean
is_dynamic_default
Boolean
dm_ca_
store
a_storage_params
string(1024)
(added in
5.2.5 SP1)
98
(attribute was lengthened from
string(64) and the second index
position ([1]) is reserved for future
use)
Object
Type
Datatype
dmi_
change_
record
group_change_count
integer
user_change_count
integer
dm_docbase_ check_client_version
config
login_ticket_cutoff
Boolean
Date
i_ticket_crypto_key
string 255
trust_by_default
Boolean
trusted_docbases
string 255
auth_failure_interval
integer
dir_user_sync_on_demand
Boolean
r_module_mode
integer
r_module_name
string 32
macl_security_disabled
Boolean
r_storage_mode
integer
dm_dump_ r_is_complete
record
r_is_more
Boolean
dm_extern_store
integer
a_platform
Boolean
Now accepts two new values:
• 6, to identify the client platform
as Linux
• 7, to identify the client platform
as Itanium
dm_fulltext_index
ft_engine_id
dm_group** is_dynamic
dm_ldap_
config
ID
Boolean
is_dynamic_default
Boolean
group_native_room_id
ID
group_directory_id
ID
group_display_name
string 255
first_time_sync
Boolean
99
Object
Type
Datatype
dm_load_
record
load_parameter
string 255
dmi_
package
r_package_flag
integer
dm_policy
java_methods
Boolean
system_actions
ID
user_action_service
string 128
user_criteria_service
string 128
user_postprocessing_service
string 128
user_validation_service
string 128
dmi_
queue_
item
i_event_flags
integer
dmr_
content
r_content_hash
string(256); Reserved for future use
dm_relation_type*
permanent_link
Boolean
copy_child
integer
Now accepts a new option,
-generate_event, that allows you to
turn off notification to the fulltext
index user for the save event when
an object is loaded into the target
repository
dm_server_ fulltext_location
config
application_access_control
session
config
100
string 64
Boolean
max_login_ticket_timeout
integer
restrict_su_ticket_login
Boolean
ldap_config_id
ID
extra_directory_config_id
ID
projection_netloc_enable
Boolean
projection_netloc_id
string(80)
dynamic_groups
string 32
Object
Type
Datatype
dm_store
compression_mode
integer; Reserved for future use
content_dupl_pref
content_hash_mode
digital_shredding
Boolean
i_retainer_id
ID
r_aspect_name
string 64
governing_room_id
ID
i_retain_until
Date
user_login_name
string 80
user_login_domain
string 255
user_password
string 256
restricted_folder_ids
ID
user_os_name
string 32
user_os_domain
string 15
user_source
string 16
user_state
integer
a_held_by
string 32
a_wq_doc_profile
string 64
a_wq_flag
integer
a_wq_name
string 32
a_wq_policy_id
ID
dm_sysobject
dm_user**
dmi_
workitem
* These two attributes are used by the 5.3 DFC. They control how the DFC handles
an instance of a relationship when the parent object is copied or versioned. For more
information, refer to the Content Server Object Reference Manual.
** This list does not include attributes that were added as "reserved for future use”.
Changed API calls
Table 6–5, page 102, lists the new or changed DMCL API methods.
101
Table 6-5. New or Enhanced DMCL APIs
Method
Description
Addesignature (5.2.5 SP1)
This method may now be executed against a source
document through a replica.
Addpackageinfo
This method is enhanced to support the new
r_package_flag attribute for workflow packages.
Complete
This method is enhanced to allow users to enter time
and cost values for a workflow task.
Dumploginticket
This is a new method that dumps the information
recorded in a login ticket or application access token.
Connect
This method is enhanced to support global login
tickets and application access tokens.
Getlogin
This method is enhanced to support global login
tickets and application access tokens.
Grant
This method is enhanced to support the enhancements
to ACLs.
Halt
This method is enhanced to support the specification
of a suspension interval for the workflow activity
being halted.
Queue
This method is enhanced to allow an event to be
queued to a work item.
Revoke
This method is enhanced to support the enhancements
to ACLs.
Verifyesignature (5.2.5 SP1)
This method may now be executed against a source
document through a replica.
Changed Administration Methods
Table 6–6, page 102, lists the changes to the suite of administration methods.
Table 6-6. Changes to Administration Methods Suite
102
Method
Change Description
IMPORT_TICKET_KEY
New method that imports a login ticket key into a
repository
Method
Change Description
EXPORT_TICKET_KEY
New method that exports a login ticket key from a
repository
RESET_TICKET_KEY
New method that resets a login ticket key in a repository
MARK_FOR_RETRY
An existing method; The syntax is changed to remove the
UPDATE_COUNT argument.
CHECK_RETENTION_
EXPIRED (5.2.5 SP1)
New method that reports on objects in content addressed
storage areas whose retention period has expired
RECOVER_TIMEOUT_
TASKS (5.2.5 SP2)
New method used to recover for execution timed-out
automatic workflow tasks in a repository.
MIGRATE_CONTENT
An existing method; The method is enhanced to:
• Execute against either SysObjects or content objects
• Execute against storage areas in either read/write or
read-only state
• Execute against content in content-addressed storage
areas
SET_OPTIONS
An existing method; Two new options are added:
• file_store_trace, to trace digital shredding operations.
• ticket_trace, to trace export and import operations for
login ticket keys and operations on single-use login
tickets
MODIFY_TRACE
The "Verity” value for the VALUE argument is no longer
accepted.
Table 6-7. Obsolete Administration Methods
Method Name
ADOPT_FTINDEX
CHECK_FTINDEX
CLEAN_FTINDEX
CLEAR_PENDING
DUMP_FTINDEX
LOAD_FTINDEX
GET_FTINDEX_SIZE
GETSTYLE_FTINDEX
103
Method Name
MARK_ALL
RESET_FTINDEX
RMSTYLE_FTINDEX
SETSTYLE_FTINDEX
UDPATE_FTINDEX
DQL Changes
This section describes new, changed, and removed or deprecated DQL syntax.
SELECT statement changes
The FT_OPTIMIZER clause is removed from the syntax. However, to maintain
backwards compatibility, queries that include this clause will still execute, but the rules
applied to the query will be the rules applied for FTDQL queries.
The SEARCH TOPIC clause is deprecated. For backwards compatiblity, queries that
contain the clause will continue to execute. Content Server will pass the clause the index
server, which will convert the clause to its query language. Note that the index server
may not be able to translate all Verity Query Language to matching functionality in the
current indexing functionality.
A new variant of SELECT is introduced, called an FTDQL SELECT query. This variant is
a subset of the syntax accepted for a standard SELECT statement. When used, the query
is executed directly and only against the fulltext index. Using FTDQL queries enhances
query performance.
Obsolete Server.ini Keys
Table 6–8, page 105 lists the keys that have become obsolete in 5.3.
104
Table 6-8. Obsolete Server.ini Keys
Key
Datatype
Comments
verity_default_codepage
string
Not used in 5.2 or higher.
verity_locale
string
None
New DQL Hint
This release adds a DQL hint named UNCOMMITTED_READ. This hint is useful in read
only queries, to ensure the query returns quickly even though the tables it touches may
be locked by another database session. The hint is useful on MS SQL Server, DB2, and
Sybase databases.
New Full Text Index Query Syntax
FTDQL is a subset of the SELECT statement syntax that queries the fulltext index rather
than the repository. Using FTDQL provides performance benefits. For details, refer to
the SELECT statement description in the Content Server DQL Reference Manual.
Obsolete and Deprecated Types and Attributes
This section lists the object types and attributes that have been made obsolete in release
5.3.
Fulltext Index Object Type
This object type has been re-architected to comply with the needs of the new fulltext
indexing architecture. The following attributes of the object type are obsolete.
105
Table 6-9. Attributes Dened for the Fulltext Index Type
Attribute
Datatype
Single/
Repeating
Description
a_server_config
string(32)
S
This is used if the index is a
shadow index. It identifies
the server with which the
shadow index is associated.
The default is the name of
the server to which the user
was connected when the
fulltext index object for the
shadow index was created.
(A server’s name is the
value in the object_name
attribute of the server’s
server config object.)
If the index is not a shadow
index, this is a single blank.
106
i_implementation
_object
ID
S
Object ID of the TDK index
object for this index.
is_closed
Boolean
S
Indicates whether the
index is open or closed.
(A storage area can have
multiple indexes but only
one can be open.) The
default value is FALSE.
is_shadow
Boolean
S
Indicates whether this
index is a shadow index.
If set to TRUE, the index
is a shadow index; if set to
FALSE, it is a regular index.
The default is FALSE.
locale
string(64)
S
Identifies the Verity locale
for the index. Valid values
are any locale value found
in the dmfulltext.ini file.
Attribute
Datatype
Single/
Repeating
Description
location_name
string(64)
S
Name of the location object
that specifies the actual
directory location of the
index.
r_batch_count
integer
S
Used internally to manage
index updates.
r_next_update
DATE
S
Used internally to manage
update operations. This
field is set to the current
time whenever an update
operation is requested
while a previous update
operation is still in progress.
(For information about how
updates are implemented,
refer to in the Content Server
Administrator’s Guide.)
r_store_id
ID
S
Object ID of the storage
area object with which this
index is associated.
r_update_count
integer
S
Number of times this index
has been updated.
r_update
_inprogress
Boolean
S
Set to TRUE if you have
started an update for
this index but it has not
completed.
r_update_server
string(32)
S
Name of the Content Server
that started the update or
clean index operation.
This attribute is set only
for the duration of the
operation. It is cleared
when the operation
completes. If the server
crashes during the
operation, this remains
set until the server is
restarted.
107
Attribute
Datatype
Single/
Repeating
Description
store_name
string(64)
S
Name of the storage
object for the storage area
with which the index is
associated.
timeout_unit
integer
S
Specifies how long the
server will wait for an
update operation to index
100 documents. The
default value is 0, meaning
wait forever. You can
override this value with
an UPDATE_FTINDEX
argument.
Values are interpreted in
minutes.
Relation Object Type
The permanent_link attribute defined for the dm_relation object type is deprecated. For
5.3, this attribute continues to be recognized and used by the DMCL and by pre-5.3
DFC-based applications. However, the 5.3 DFC uses the new attributes, permanent_link
and copy_child, defined for the dm_relation_type object type instead of this attribute.
Server Cong Object Type
The following attributes of this object type have been deprecated.
108
Table 6-10. Deprecated Attributes of dm_server_cong
Attribute
Datatype
Single/
Repeating
Description
verity_location
string(32)
S
Name of the location object
that identifies the directory
containing the Verity
installation.
This is set to verity271 after
headstart.ebs runs in a new
or upgraded repository.
TDK Index Object Type
The dmi_tdk_index object type is removed from the object type hierarchy. Objects of this
type are removed from a repository when the repository is upgraded to 5.3
TDK Collect Object Type
The dmi_tdk_collect object type is removed from the object type hierarchy. Objects of
this type are removed from a repository when the repository is upgraded to 5.3
Workow Object Type
The following two attributes of the dm_workflow object type are deprecated:
•
r_pre_timer
•
r_post_timer
109
When a repository is upgraded, for all workflows in the repository, the values
in these attributes, if any, are copied into r_pre_timer_increment[0] and
r_post_timer_increment[0], respectively.
110
Chapter 7
Migrating WDK-based Applications
This chapter provides information about upgrading and configuring Web Development Kit (WDK)
and migrating WDK-based custom applications from WDK or Webtop 5.2.x. The following topics are
discussed:
•
What’s New in Web Development Kit and Webtop?, page 111
•
The WDK 5.3 Documentation Set, page 114
•
The Webtop 5.3 Documentation Set, page 114
•
Architecture Changes, page 115
•
•
Adding New 5.3 Features to Existing WDK Custom Applications, page 122
What’s New in Web Development Kit and
Webtop?
This section provides a brief, high-level description of the major new features in this
release of Web Development Kit (WDK). For detailed information about these features,
including lists of new or changed components, controls, JSP pages, and Java classes,
see the Adding New 5.3 Features to Existing WDK Custom Applications section of the
Documentum 5.3 System Migration Guide.
The major new features are:
•
Content Transfer Enhancements
This release of WDK uses Unified Client Facilities (UCF) to work around the need in
previous releases to deploy content transfer applets to browser clients. UCF allows
for a single client-side executable for content transfer. This executable can be shared
by multiple Documentum applications and provides a single location on the client
for storing contextual information about content library services, such as import,
export, check-in, and checkout, for WDK-based applications.
111
With this release, WDK now supports three modes of content transfer:
— HTTP (Zero footprint)
This mode of content transfer requires no applets downloaded to your Web
browser.
— UCF (Unified Client Facilities)
This is the recommended mode of content transfer in WDK 5.3
— Content Transfer Applets (included for backwards compatibility with previous
releases)
•
Anonymous Login
Virtual links have been enhanced to support anonymous login, The anonymous
account is set up on the Content Server, and the credentials for the account are
configured in the virtuallinkconnect component definition.
•
Failover support
In clustered environments, WDK now supports session failover to other servers
running the same WDK application. It works by making the user session data
persistent and retrying the last HTTP request. In case of a server crash, the load
balancer mechanism routes the request to the secondary server. WDK Failover
support is also available for custom WDK applications such as Webtop and
Documentum Administrator.
•
Redesigned Virtual Document Manager (VDM)
New and enhanced VDM features include:
— Browser tree updated to include display of VDM as ‘containers’
— Classic view navigation updated to support VDM as containers
— You can now add and reorder children components using drag and drop
— Snapshots (formerly known as assemblies) are now supported.
•
Multi-repository Operations
New and enhanced multi-repository operation features include:
— Reuse of stored repository credentials for seamless capability
— A unified Inbox for users in a federated configuration.
The user is given the option to set their Inbox view to a home Inbox
— Multi-repository searching
•
Collaboration Components and Controls
New components include support for integrating the following features in your
WDK-based application:
112
— Rooms
— Discussions
— Threads
— Notes
— Enhanced Folders
— Rich text editor
•
Search Component Enhancements
New components offer support for:
— Multi-repository searches
— Searching external sources (such as subscription databases or Google), if you
install ECI Services with Content Server 5.3
— Targeted searches, which allow you to specify searches on particular folders
within a repository.
— Saved search preferences, which allow you to store preferences, such as which
repositories you want to search in a multi-repository search
— Importing search results obtained from external sources into the repository
— Authentication prompting for external search sources that require a login
•
User Experience for WDK-based clients:
The following new features have been added:
— User-selected Columns
Users can select the columns that appear in folder listings, search results, My
Files, subscription, and Inbox.
— Visible Repositories
Users can select which repositories appear in the user interface.
— Version Listing
Users can choose Show All Versions and view the version number of objects in
a Repository without customization.
— Drag and Drop support for Internet Explorer browsers
Internet Explorer users can drag items from their desktop to folders in the
system as well as drag items within the Webtop application.
— Subscription Notification
Users receive notification when an item on their subscription list has changed.
Administrators can make any server event available for notification.
113
— Credential Save
Users can save their login credentials, thus preventing the system from
requesting additional logins on subsequent visits
— Preferred Rendition Support
The user can determine which application is used for a particular content type.
— Layout Improvements
Minor changes to the user interface layout result in a significantly more usable
interface.
— Forms Integration
Provides native forms integration for a seamless user experience.
•
Application Connectors
EMC Documentum Application Connectors (AppConnectors) are installed on the
client to make repositories available within content authoring applications such as
Microsoft Word, Excel, and PowerPoint. Authentication options are configurable in a
single location within a WDK-based application such as Webtop and then installed
on the client within the content authoring application. The AppConnectors are
installed on the client using a GUI installer or an SMS command-line installation
process. Previous Documentum integrations into Microsoft Office applications are
disabled at the time of the installation. For more information on installation, see Web
Development Kit and Applications Installation Guide.
The WDK 5.3 Documentation Set
The WDK documentation set for the 5.3 release consists of the following:
•
Web Development Kit Release Notes for version 5.3
•
Web Development Kit and Applications Installation Guide for version 5.3
•
Web Development Kit and Applications Tutorial for version 5.3
•
Web Development Kit and Client Applications Development Guide for version 5.3
•
Web Development Kit and Client Applications Reference Guide for version 5.3
The Webtop 5.3 Documentation Set
The Webtop documentation set for the 5.3 release consists of the following:
114
•
Webtop Release Notes for version 5.3
•
Webtop User Guide for version 5.3
•
•
Webtop Development Guide for version 5.3
Architecture Changes
Figure 7–1, page 115 shows a typical WDK-based system, with application server and
WDK-based clients:
Figure 7-1. Typical 5.3 WDK-based System
This section contains the following information:
•
Supported migration paths
•
Overview of major migration tasks with task flowchart
115
Supported Migration Paths
If you are currently using pre-5.2.5 versions of Webtop, you must first upgrade to Webtop
5.2.5 [with any Service Pack] before upgrading to Webtop 5.3.
If you created or customized applications using WDK 4.2, you must migrate your
customized components to Documentum 5.3. This is because the 4.2.x backward
compatibility bridge component bridge has been removed in Documentum 5.3.
Overview of Migration Tasks for WDK-based
Applications
This section describe typical migration tasks for a customized WDK-based application.
Figure 7-2. Migration Tasks for a Customized WDK-based Application
To migrate customized WDK-based applications:
1.
116
If required, upgrade your application server and other supporting components of
your WDK/Webtop environment.
The Requirements chapter in your product’s Release Notes specifies which
environments are supported for a particular WDK or WDK-based application
version.
2.
Install 5.3 WDK in a environment separate from your 5.2.x WDK-based application.
You must install WDK to a separate instance of the application server host machine
(if Unix) or a separate application server host machine (if Windows). This is because
the startup classpath will contain different classes than those used by WDK 5.2.x.
Also, the DFC version used by the application will be different.
This step provides a WDK 5.3 development environment and installs the following
items, which are helpful for migration and customization:
3.
•
Webtop JSP pages with developer comments that highlight changes and
additions
•
source code for WDK and Webtop components
•
the WDK 5.3 developer documentation set
•
WDK and Webtop Javadocs
Copy the folders containing your customizations from your 5.2.x custom folders.
Customizations are typically stored in the following folders and subfolders in your
WDK-based application, as shown in Figure 7–3, page 117:
Figure 7-3. Customization Folders in WDK-based Applications
These folders and subfolders contain the following customized items:
•
/custom/xml
Contains customized XML files
•
/custom/string
Contains customized properties files
•
/WEB-INF
Contains custom classes, tag definition libraries, etc.
117
— /WEB-INF/classes/custom/com/documentum
Contains Documentum classes
— /WEB-INF/classes/custom/com/your_name
Contains your custom classes, if any.
— /WEB-INF/tld
Contains custom tag definition libraries, if any.
— /WEB-INF/lib
Contains custom JAR files, if any
4.
Update your 5.2.5 customizations, as follows.
•
If you defined a custom qualifiers element in the app.xm file, you must add
two new qualifiers as sub-elements:
— ClientEnvQualifier before the existing AppQualifier entry
— VersionQualifier after the existing AppQualifier entry
•
If your 5.2.5 customizations contain non-serializable objects, you must turn off
the failover feature by setting the failover.enabled flag in the app.xml file.
•
If you extended the Webtop 5.2.5 browsertree component, turn off the
fallback identity feature, IDfSessionManager.setIdentity(*), by setting the
fallback_identity.enabled Boolean flag in the app.xml file.
For more information about these settings in the app.xml file, see the Web
Development Kit and Client Applications Development Guide for version 5.3 .
5.
Test your custom application in its new 5.3 environment.
For each WDK or Webtop 5.2.5 component that you extended, any existing
customizations to 5.2.5 components will still work.
Tip: If you want to replace customized features in your application with new 5.3
features, then you must create new customizations to extend the 5.3 components. In
this case, we recommend that you deprecate your 5.2.5 WDK customization, and
replace it with a new 5.3 customization.
6.
Add new 5.3 functionality to your existing application.
For example, you may want to add new UI elements, failover support,
multi-repository support, or queue management features. Adding New 5.3 Features
to Existing WDK Custom Applications, page 122 lists new features and lists the
components associated with these features. For information about how to implement
these features, see the WDK Development Guide.
118
Overview of Migration Tasks for Customized Webtop
Applications
This section describe typical migration tasks for a customized Webtop application.
Figure 7-4. Migration Tasks for a Customized Webtop-based Application
To migrate customized Webtop-based applications:
1.
If required, upgrade your application server and other supporting components of
your WDK/Webtop environment.
The Requirements chapter in your product’s Release Notes specifies which
environments are supported for a particular WDK or WDK-based application
version.
119
2.
Install the 5.3 WDK-based application in a environment separate from your 5.2.x
WDK-based application.
You must install WDK to a separate instance of the application server host machine
(if Unix) or a separate application server host machine (if Windows). This is because
the startup classpath will contain different classes than those used by WDK 5.2.x.
Also, the DFC version used by the application will be different.
3.
Run the WDK 5.3 installer, and point at the location you specified for the application
in .
This step provides a WDK 5.3 development environment and installs the following
items, which are helpful for migration and customization:
•
Webtop JSP pages with developer comments that highlight changes and
additions
•
source code for WDK and Webtop components
•
the WDK 5.3 developer documentation set
•
WDK and Webtop Javadocs
4.
When prompted by the WDK installer, choose to customize an existing application
and select the name of the out-of-the-box 5.3 WDK-based client you installed in .
5.
Copy the folders containing your customizations from your 5.2.x custom folders.
•
/custom/xml
•
120
/custom/string
Contains customized properties
•
/WEB-INF
— /WEB-INF/tld
— /WEB-INF/lib
Contains custom JAR files, if any.
6.
Update your 5.2.5 customizations, as follows.
•
If you defined a custom qualifiers element in the app.xm file, you must add
two new qualifiers as sub-elements:
— ClientEnvQualifier before the existing AppQualifier entry
— VersionQualifier after the existing AppQualifier entry
•
If your 5.2.5 customizations contain non-serializable objects, you must turn off
the failover feature by setting the failover.enabled flag in the app.xml file.
•
If you extended the Webtop 5.2.5 browsertree component, turn off the
fallback identity feature, IDfSessionManager.setIdentity(*), by setting the
fallback_identity.enabled Boolean flag in the app.xml file.
For more information about these settings in the app.xml file, see the Web
Development Kit and Client Applications Development Guide for version 5.3 .
7.
Test your custom application in its new 5.3 environment.
For each WDK or Webtop 5.2.5 component that you extended, any existing
customizations to 5.2.5 components will still work.
Tip: If you want to replace customized features in your application with new 5.3
features, then you must create new customizations to extend the 5.3 components. In
this case, we recommend that you deprecate your 5.2.5 WDK customization, and
replace it with a new 5.3 customization.
You can deprecate a component by adding the attribute version="5.2.5" to the
component element in your component definition.
8.
Add new 5.3 functionality to your existing application.
For example, you may want to add new UI elements, failover support,
multi-repository support, or queue management features. Adding New 5.3 Features
121
to Existing WDK Custom Applications, page 122 lists new features and lists the
components, classes, and JSP pages associated with these features.
For detailed information on the configuration of these features, see the WDK
Development Guide and WDK Reference Guide. The development guide also provides
information on adding drag and drop and failover support to your components.
Adding New 5.3 Features to Existing WDK
Custom Applications
This section provides an in-depth description of the major new features in WDK 5.3,
and provides information you need for integrating these new features into existing
WDK-based custom applications. The following topics are covered in this section:
•
New User-Selected Columns Feature, page 122
•
About Component Versioning, page 123
•
Implementing New Content Transfer Functionality, page 123
•
Implementing Multi-repository Support for Components, page 142
•
Configuring Roles and Client Capability , page 145
•
Migrating Search Features, page 147
•
Migrating Virtual Document Manager Components, page 160
•
Adding Failover Support to Existing Applications, page 172
•
Adding Drag and Drop Support, page 174
•
Migrating Existing Components for Location and Navigation, page 176
For each new feature, where applicable, you will find lists of new and changed
components, actions, classes, and JSP files, as well as information about architectural
changes, if any.
New User-Selected Columns Feature
If you created customizations to display custom lists of attributes for repository objects
in pre-5.3 versions of WDK or Webtop, these customization are now obsolete, and have
been replaced by the user-defined display columns feature in Webtop. Your pre-5.3
customizations will still work, however, they are probably no longer needed with
addition of this new feature.
For information about how users can choose which columns to display in Webtop, see
Chapter 4, Setting Preferences, in the Webtop User Guide for version 5.3.
122
For detailed information about the WDK preferences components, see the section
named "Configuring User Column Preferences,” in Chapter 2, Configuring and Deploying
Applications, of the Web Development Kit and Client Applications Development Guide.
About Component Versioning
Component and action definitions, or any other configuration within a <config> element,
can have more than one version. The version is denoted by a version attribute on the
primary element , for example, <component id="checkin" version="5.2.5".
A <component> or <action> element with a version attribute value of "CURRENT”, or no
version attribute present, will be dispatched by default. Non-current versions of WDK
components can be extended but not invoked by URL or called with a setComponentXXX
method. For example, the WDK 5.3 components have no version attribute, so they are
dispatched by default. If you have developed a custom component that extends a WDK
5.2.5 component, your component will be launched instead of the current component.
Note: A component is considered a version of another component only if both
components have the same ID and scope. In the following example, both definitions
are current and can be addressed directly:
<config version='1.0'>
<scope>
<component id="test-1">...</copmponent>
</scope>
</config>
<config version='1.0'>
<scope type="dm_document">
<component id="test-2" version="5.2.5">...</copmponent>
</scope>
</config>
The version number has the form n.n.n.n where n is an integer. This version number
can be assigned to a component or any other primary element, such as an action or
attribute list.
Implementing New Content Transfer Functionality
This section explains how to update existing applications to use the new WDK 5.3
UCF-based content transfer functions. This release of WDK supports three different
content transfer modes:
•
Content transfer applets
This is the content transfer method for pre-5.3 releases of WDK
123
•
UCF
UCF is a lightweight client-based service that performs the following functions:
— Standardizes content handling across infrastructure and applications
— Simplifies XML and compound document processing in a Web environment by
decoupling DFC and WDK and by providing an open framework for content
analysis
— Improves reliability, maintainability, and performance of WDK content transfer
— Uses native, Windows-specific implementation with a very small client-side
footprint.
•
HTTP-based content transfer
This is a "zero footprint” content transfer method that does not require a Web
browser applet. HTTP content transfer is typically used in portal applications to
import a single file to the a repository. For example, you might implement HTTP
content transfer on a custom Import page that allows a user to browse for a file and
upload it from a client machine to the application server.
About Implementing UCF in Existing WDK-based Applications
Content transfer components are a set of WDK 5.3 components that perform tasks in a
Documentum repository which involve transfer of content between the client and the
repository (such as import, check in, check out, view, edit, or export). These content
transfer components support operation in modes utilizing either UCF or pure HTTP
methods of transport in application server and portal server environments.
For more information about UCF in the WDK framework, content transfer listeners,
content transfer service classes, content transfer results, content transfer control
initialization, using pre-5.3 content transfer components, streaming content to the
browser, or content transfer progress, see Chapter 15, Content Transfer, in the Web
Development Kit and Client Applications Development Guide.
For more information about the individual content transfer applet controls and
components, see the Web Development Kit and Client Applications Reference Guide.
Enabling UCF Content Transfer for Components
Enabling a component to use UCF is done in the component configuration file. The
component definition must contain a <ucfrequired/> element. No DFC is required on the
client. The ucfrequired element turns UCF for all pages by default. Optional settings
in this configuration are:
124
<ucfrequired enabled="true|false">
<events>
<page name="onInit" enabled="true|false"/>
</events>
<pages>
<page name="page-name-1" enabled="true|false"/>
<page name="page-name-n" enabled="true|false"/>
...
</pages>
</ucfrequired>
Using the page name option, you can selectively disable UCF for parts of the component.
All elements inside the ucfrequired element are optional.
Using WDK 5.2.5 Content Transfer Components
UCF content transfer is new in WDK 5.3. The WDK 5.2.5 content transfer components
are still present in the WDK runtime to support your customizations until you migrate
them. You cannot address a WDK 5.2.5 content transfer component by URL or jump to
it in a component class, because the components are versioned. If the content transfer
component is launched by URL, component nest or jump, or action, the new content
transfer components will be launched by default.
To launch your customized WDK 5.2.5 content transfer component, give your content
transfer component and container a different name from the WDK component or
container that it extends. Also give the action that launches them a custom name. For
example, if you customized import by extending the WDK 5.2.5 import component and
container, you can create a custom component named myimport and a container named
myimportcontainer, similar to the following:
<component id="myimport"
extends="import:webcomponent/config/library/importContent/import_component.xml">
…</component>
The action definition looks similar to the following:
<action id="myimport">
…
<execution ..>
<!— copy WDK 5.2.5 action definition contents here—>
<selection>
<component>myimport</component>
<container>myimportcontainer</container>
</selection>
</action>
If you want to extend WDK 5.3 content transfer components, their definitions are located
in /webcomponent/config/library/contenttransfer.
125
Specifying Which Content Transfer Mode Your Application Uses
You can choose to continue using the 5.2.x content transfer mechanism, or you can
specify that your application use the new UCF content transfer mechanism. To set the
application-wide content transfer mechanism and compression for content transfer
operations on the client, use the <contentxfer> and <contentxfer>.<common> elements in
the WDK application configuration file, app.xml.
The <default-mechanism> element sets the content transfer mechanism for the
application. Valid values for this element are : http (pre-5.3 applications) or ucf
(5.3 applications). If one or more of your custom components extend pre-5.3 applet
components, specify ucf.
For information about the app.xml file, see the section named "Configuring an
Application,” in the Web Development Kit and Client Applications Development Guide
For a detailed description of the content transfer-related elements, see Chapter 8, Content
Transfer, in the Web Development Kit and Client Applications Development Guide.
Content Transfer Components, Classes, and Associated JSP Pages
This section provides a quick reference to the new WDK 5.3 components used to
implement UCF content transfer. Table 7–1, page 126 through Table 7–9, page 134 are
organized by WDK feature.
Table 7-1. Browse for File
126
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
locatelocalfile
locatelocalfile_
component.xml
locateLocalFile.jsp
LocateFile.java
locatelocalfilecontainer
locatelocalfilecontainer_component.xml
/wdk/container/
dialogcontainer.jsp
(inherited)
LocateFileContainer.java
Table 7-2. Cancel Checkout
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
cancelcheckout
cancelcheckout/
cancelcheckout_
component.xml
checkout/checkout.
jsp
cancelcheckout.
CancelCheckout.
java
cancelcheckoutcontainer
cancelcheckout/cancelcheckoutcontainer_component.xml
(inherited) /wdk/
container/combocontainer.jsp
/wdk/container/comboautocommitex. jsp
cancelcheckout.CancelCheckoutContainer.java
httpcancelcheckout
cancelcheckout.
httpcancelcheckout_component.xml
cancelcheckout/
cancelCheckout.jsp
cancelcheckout.
CancelCheckout
cancelcheckout/
httpcancelcheckoutcontainer_component.xml
127
Table 7-3. Checkin
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
checkin
checkin/checkin_
component.xml
checkin/checkin.jsp
checkin.
UcfCheckin.java
checkincontainer
checkin/
checkincontainer_
component.xml
(inherited) /wdk/
checkin.
CheckinContainer.
java
httpcheckin
/checkin/
httpcheckin_
component.xml
checkin/checkin.jsp
checkin.
HttpCheckin.java
checkin/httpcheckincontainer_component.xml
128
locatecheckinlocalfile
checkin/locatecheckinlocalfile_component.xml
locateLocalFile.jsp
LocateFile.java
locatecheckinlocalfilecontainer
checkin/locatecheckinlocalfilecontainer_component.xml
/wdk/container/
dialogcontainer.jsp
LocateFileContainer.java
Table 7-4. Checkout
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
checkout
checkout/checkout_
component.xml
checkout/checkout.
jsp
checkout.Checkout.
java
checkoutcontainer
checkout/
checkoutcontainer_
component.xml
(inherited) /wdk/
checkout.CheckoutContainer.java
httpcheckout
checkout/
httpcheckout_
component.xml
checkout/checkout.
jsp
checkout.
HttpCheckout
httpcheckoutcontainer
checkout/
httpcheckoutcontainer_component.xml
(inherited) /wdk/
checkout.
CheckoutContainer
129
Table 7-5. Edit
130
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
edit
edit/edit_
component.xml
checkout/checkout.
jsp (inherited)
edit.Edit.java
editcontainer
edit/editcontainer_
component.xml
(inherited) /wdk/
edit.EditContainer.
java
httpedit
edit/httpedit_
component.xml
checkout/checkout.
jsp (inherited)
edit.HttpEdit.java
httpeditcontainer
edit/
httpeditcontainer_
component.xml
(inherited) /wdk/
edit.EditContainer
Table 7-6. Export
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
export
export/export_
component.xml
export/
selectDestFolder.
jsp
export/export.jsp
export.Export.java
exportcontainer
export/
exportcontainer_
component.xml
export/
selectDestFolder.
jsp
/wdk/container/
combocontainer.jsp
/wdk/container/
comboautocommit.
jsp
export.UcfExportContainer.java
httpexport
export/httpexport_
component.xml
export/export.jsp
export/HttpExport.
java
httpexportcontainer
export/httpexportcontainer_component.xml
(inherited) /wdk/
/wdk/container/comboautocommitex.jsp
export.HttpExportContainer
131
Table 7-7. Import
132
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
httpimport
/importcontent/
httpimport_
component.xml
importcontent/
httpfileselection.jsp
importcontent.
ImportContent
httpimportcontainer
importcontent/httpimportcontainer_component.xml
importcontent/
httpfileselection.jsp
importcontent/
folderselection.jsp
/wdk/container/
combocontainer.jsp
importcontent.HttpImportContainer.java
import
importcontent/
import_component.
xml
importcontent/
fileselection.jsp
importcontent/
importFolder.jsp
importcontent/
importContent.jsp
importcontent.
ImportContent.java
importcontainer
importcontent/
importcontainer_
component.xml
importcontent/
importcontainer.jsp
importcontent.UcfImportContainer.java
locateimportlocalfile
importcontent/locateimportlocalfile_component.xml
importcontent/
folderselection.jsp
LocateFile
(inherited)
locateimportlocalfilecontainer
importcontent/locateimportlocalfilecontainer_component.xml
/wdk/container/
dialogcontainer.jsp
(inherited)
LocateFileContainer (inherited)
externalresultimportcontainer
importcontent/externalresultimportcontainer_component.xml
importcontent/
fileselection.jsp
/importcontent/
folderselection.jsp
/wdk/container/
combocontainer.jsp
importcontent.ExternalResultImportContainer.java
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
httpimportrenditioncontainer
importrendition/httpimportrenditioncontainer_component.xml
(inherited) /wdk/
importrendition.ImportRenditionContainer.java
importrendition
importrendition/
importrendition_
component.xml
importrendition/
importRendition.
jsp
importrendition.UcfImportRendition.java
importrenditioncontainer
importrendition/importrenditioncontainer_component.xml
(inherited) /wdk/
importrendition.ImportRenditionContainer.java
httpimportrendition
importrendition/httpimportrendition_component.xml
importrendition/
importRendition.
jsp
importrendition.HttpImportRendition.java
importrendition/httpimportrenditioncontainer_component.xml
(inherited) /wdk/
importrendition.ImportRenditionContainer
133
Table 7-8. Prompt for Input
Component ID
XML
Configuration File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.
documentum.
webcomponent.
library.
contenttransfer.)
promptinput
promptinput_
component.xml
promptInput.js
PromptInput.java
promptinputcontainer_component.xml
/wdk/container/
dialogcontainer.jsp
promptinputcontainer
PromptInputContainer.java
PromptInputContainer
Table 7-9. View
134
Component ID
XML
Configuration
File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.documentum.
webcomponent.library.
contenttransfer.)
httpviewcontainer
view/httpviewcontainer_component.xml
(inherited)
/wdk/container/combocontainer.jsp
view.ViewContainer.java
httpview
view/httpview_
component.xml
export/export.jsp
view.HttpView.java
Component ID
XML
Configuration
File
(path:
/webcomponent/
config/
library/
contenttransfer)
UI File
(path:
/webcomponent/
library/
contenttransfer)
Component Class
(path: com.documentum.
webcomponent.library.
contenttransfer.)
viewcontainer
view/
viewcontainer_
component.xml
(inherited)
/wdk/container/combocontainer.jsp
view.ViewContainer.java
view
view_
component.xml
export/export.jsp
view.View.java
Content Transfer Component Mapping (WDK 5.2.5 to 5.3)
This section presents a comparison between WDK 5.2.5 features and components, and
their WDK 5.3 counterparts.
Table 7-10. WDK 5.2.5 to 5.3 Content Transfer Component Comparison
WDK 5.3
WDK 5.2.5
Component ID
XML File
Component ID
XML File
cancelcheckout
/webcomponent/
config/library/
contenttransfer/
cancelcheckout/
cancelcheckout_
component.xml
cancelcheckout
/webcomponent/config/
library/cancelcheckout/
cancelcheckout_
component.xml
/webcomponent/config/library/contenttransfer/can-
library/cancelcheckout/
cancelcheckoutcontainer_
component.xml
135
WDK 5.3
Component ID
WDK 5.2.5
XML File
Component ID
XML File
celcheckout/cancelcheckoutcontainer_component.xml
136
checkin
/webcomponent/
config/library/
contenttransfer/
checkin/checkin_
component.xml
checkin
library/checkin/checkin_
component.xml
checkincontainer
/webcomponent/config/library/contenttransfer/checkin/
checkincontainer_component.xml
checkincontainer
/webcomponent/
config/library/checkin/
checkincontainer_
component.xml
checkout
/webcomponent/
config/library/
contenttransfer/
checkout/
checkout_
component.xml
checkout
library/checkout/
checkout_component.xml
checkoutcontainer
/webcomponent/config/library/contenttransfer/checkout/checkoutcontainer_component.xml
checkoutcontainer
library/checkout/
checkoutcontainer_
component.xml
edit
/webcomponent/
config/library/
contenttransfer/
edit/edit_
component.xml
edit
library/edit/edit_
component.xml
WDK 5.3
WDK 5.2.5
Component ID
XML File
Component ID
XML File
editcontainer
/webcomponent/
config/library/
contenttransfer/
edit/
editcontainer_
component.xml
editcontainer
library/edit/editcontainer_
component.xml
export
/webcomponent/
config/library/
contenttransfer/
export/export_
component.xml
export
library/export/export_
component.xml
exportcontainer
/webcomponent/
config/library/
contenttransfer/
export/
exportcontainer_
component.xml
exportcontainer
/webcomponent/
config/library/export/
exportcontainer_
component.xml
httpcancelcheckout
/webcomponent/config/library/contenttransfer/cancelcheckout/httpcancelcheckout_component.xml
N/A
N/A
httpcancelcheckoutcontainer
/webcomponent/config/library/contenttransfer/cancelcheckout/httpcancelcheckoutcontainer_component.xml
httpcancelcheckoutcontainer
/webcomponent/config/library/httpcancelcheckout/httpcancelcheckoutcontainer_component.xml
137
WDK 5.3
138
WDK 5.2.5
Component ID
XML File
Component ID
XML File
httpcheckin
/webcomponent/
config/library/
contenttransfer/
checkin/
httpcheckin_
component.xml
N/A
N/A
httpcheckincontainer
/webcomponent/config/library/contenttransfer/checkin/
httpcheckincontainer_component.xml
httpcheckincontainer
library/httpcheckin/
httpcheckincontainer_
component.xml
httpcheckout
/webcomponent/
config/library/
contenttransfer/
checkout/
httpcheckout_
component.xml
httpcheckout
library/httpcheckout/
httpcheckout_action_
component.xml
httpcheckoutcontainer
/webcomponent/config/library/contenttransfer/checkout/httpcheckoutcontainer_
component.xml
N/A
N/A
httpedit
/webcomponent/
config/library/
contenttransfer/
edit/httpedit_
component.xml
N/A
N/A
WDK 5.3
WDK 5.2.5
Component ID
XML File
Component ID
XML File
httpeditcontainer
/webcomponent/config/library/contenttransfer/edit/httpeditcontainer_component.xml
N/A
N/A
httpexport
/webcomponent/
config/library/
contenttransfer/
export/
httpexport_
component.xml
httpexport
library/httpexport/
httpexport_action_
component.xml
httpexportcontainer
/webcomponent/config/library/contenttransfer/export/httpexportcontainer_component.xml
N/A
N/A
httpimport
/webcomponent/
config/library/
contenttransfer/
importcontent/
httpimport_
component.xml
N/A
N/A
httpimportcontainer
/webcomponent/config/library/contenttransfer/importcontent/httpimportcontainer_component.xml
httpimportcontainer
/webcomponent/
config/library/
httpimportcontent/
httpimportcontainer_
component.xml
139
WDK 5.3
140
WDK 5.2.5
Component ID
XML File
Component ID
XML File
httpimportrendition
/webcomponent/config/library/contenttransfer/importrendition/httpimportrendition_component.xml
N/A
N/A
/webcomponent/config/library/contenttransfer/importrendition/httpimportrenditioncontainer_component.xml
/webcomponent/config/library/httpimportrendition/httpimportrenditioncontainer_component.xml
httpview
/webcomponent/
config/library/
contenttransfer/
view/httpview_
component.xml
httpview
library/httpview/
httpview_component.xml
httpviewcontainer
/webcomponent/config/library/contenttransfer/view/
httpviewcontainer_component.xml
N/A
N/A
import
/webcomponent/
config/library/
contenttransfer/
importcontent/
import_
component.xml
import
library/importContent/
import_component.xml
WDK 5.3
WDK 5.2.5
Component ID
XML File
Component ID
XML File
importcontainer
/webcomponent/
config/library/
contenttransfer/
importcontent/
importcontainer_
component.xml
importcontainer
library/importContent/
importcontainer_
component.xml
importrendition
/webcomponent/
config/library/
contenttransfer/
importrendition/
importrendition_
component.xml
importrendition
library/importrendition/
importrendition_
component.xml
/webcomponent/config/library/contenttransfer/importrendition/importrenditioncontainer_component.xml
/webcomponent/config/library/importrendition/importrenditioncontainer_component.xml
view
/webcomponent/
config/library/
contenttransfer/
view/view_
component.xml
view
library/view/view_
component.xml
viewcontainer
/webcomponent/
config/library/
contenttransfer/
view/
viewcontainer_
component.xml
viewcontainer
/webcomponent/
config/library/view/
viewcontainer_
component.xml
141
Implementing Multi-repository Support for Components
This section describes the new multi-repository support features in WDK 5.3 and
describes how to implement multi-repository support for components.
What is Multi-Repository Support?
Multi-repository support allows you to perform operations, such as searches,
transparently across multiple Documentum repositories.
The following multi-repository support is provided in WDK:
•
Objects can be copied or linked across repositories
Copy creates a new object that is a copy (replica or mirror object) of the selected
version of the source object. Deep folder copy is supported. Link creates a reference
object (shortcut). Move is not supported.
•
Content transfer actions on replica and reference objects can be performed
•
Inbox and workflow can include objects in other repositories
Only the current repository is queried. Users can select attachments from multiple
repositories to attach to a workflow. These distributed attachments are treated as
foreign objects.
•
Search can operate on multiple repositories
•
My Files lists the user’s recently used replica objects and checked out replica,
reference, or foreign objects in other repositories.
Only the current repository is queried for My Files. When the user checks out an
object in another repository, a reference object is created in the user’s home cabinet.
For information on creating federations and managing replication, see the Distributed
Configuration Guide for Content Server.
Note: Subscriptions are not supported on reference, or foreign objects. You must log in
to the source repository in order to subscribe to an object.
To see multi-repository objects in the inbox or workflow, the remote repositories must
configure a dm_DistOperations job. See the Distributed Configuration Guide for details.
Replica (mirror), Reference, and Foreign Objects
The WDK application will attempt to get a session in the source repository using the
current username and credentials in order to perform actions on replica, reference, or
142
foreign objects. The action will fail if the user credentials are not the same for the current
and source repositories.
A replica object is a mirror of the object in the source repository. Replication objects
are created by a replication job on the Content Server. Replica objects are displayed
in drilldown and list views of objects, and write operations on replica objects can be
performed on the source object. Apply lifecycle on a replica object is not supported.
A reference object consists of a shortcut to an object in another repository. The reference
object mirrors the attributes of the remote object. Reference objects can be created by
the user with Paste as Link action across repositories. The Content Server also creates
reference objects for distributed checkout, distributed workflow, and distributed virtual
documents.
A foreign object is an object ID that is the same as a the object ID of an object in a remote
repository. Foreign objects are available in distributed workflows and multi-repository
search:
•
Workflow tasks do not perform a query, so that attributes on the foreign object are
not accessible.
•
Search queries the object in the remote repository for text or attributes that meet the
search criteria. When the user performs an operation on a foreign object in search
results, the operation is performed after login to the repository in which the object is
located.
Many actions can be performed on reference objects and on foreign objects, for example:
checkin, checkout, cancel checkout, edit, view properties ( local properties), comment,
and find target action (jump to the source to perform other actions). To determined
whether an action on a reference or foreign object is supported, check the lists of
unsupported actions in mirror_undefined_actions and foreign_undefined_actions. For
more information, see Scoping and Preconditioning Actions on Remote Objects, page 144.
Adding Multi-Repository Support to a Component
Objects from multiple repositories will be exposed in your custom components if you
display the contents of a cabinet or folder, objects that have been modified by a user, or
inbox/workflows. In the JSP page, include a <dmf:argument> tag for i_is_replica and
i_is_reference so that icons will display properly for all reference or replica objects.
For example, the relationships_classic.jsp page adds these arguments to the action
multiselect checkbox:
<dmfx:actionmultiselectcheckbox name="check" value="false">
<dmf:argument name="objectId" datafield="r_object_id"/>
...
<dmf:argument name="isReference" datafield="i_is_reference"/>
<dmf:argument name="isReplica" datafield="i_is_replica"/>
</dmfx:actionmultiselectcheckbox>
143
These attributes must also be added to the query. In the same example class,
Relationships, the attributes are added to the query parameter:
private static final String INTERNAL_ATTRS = "
sysobj.r_object_id,...i_is_reference,i_is_replica ";
If you are adding an icon that represents the object type, add the isreplicadatafield
and isreferencedatafield attributes to the control, similar to the following from
relationships_classic.jsp:
<dmfx:docbaseicon ...isreplicadatafield='i_is_replica'
isreferencedatafield='i_is_reference' size='16'/>
If your component needs to perform an operation on the object in the remote repository,
such as running a query, add the <setrepositoryfromobjectid> element to true. By default,
all actions in the context of the component are performed on the local replica object,
reference object, or foreign object ID. This element should be set on the container rather
than on the component, if your component exists within a container.
Note: Containers and components must have the same repository session.
The following utility classes can provide information to your component:
•
DocbaseUtils::isForeign(String strObjectId)
Returns true if the object ID is a foreign object
•
DocbaseUtils::isReference(String strObjectId)
Returns true if the object ID is a reference object
•
DocbaseUtils:getDocbaseNameFromId(IDfId objectId)
Returns the repository name in which the source object exists
Scoping and Preconditioning Actions on Remote Objects
Two pseudo-types have been created to support scoping of actions or components
for mirror or foreign objects: mirror_dm_sysobject and foreign_dm_sysobject. The
DocbaseTypeQualifier method getParentScope() returns the r_object_type for the source
of the mirror or foreign object.
The WDK configuration files that scope actions by the remote object
pseudotypes are in /wbcomponent/config/actions: mirror_undefined_actions and
foreign_undefined_actions. You can add actions to these files to prevent an action from
operating on a replica or foreign object. You cannot remove an action from these files
unless you create a custom action that effects the action in the remote repository.
You can add preconditions to an action that allow the action to execute only if the object
is a reference or foreign object. RemoteObjectPrecondition::queryExecute returns true if
the object is a replica or foreign object. ReplicaObjectPrecondition::queryExecute returns
true if the object is a replica.
144
Session Management with Multiple Repositories
DMCL manages multiple connections for a single session. The user logs in once, and
then the username and password are saved and used for remote connections. The
username and password must be the same for the remote repository when the user
attempts an action on a replica, reference, or foreign object.
Some actions on foreign IDs, replicas, or references are directed to the source object:
checkout, checkin, and cancel checkout. Remote queries or transactions are not
performed except in search, which queries all selected sources.
To query a remote repository, don’t use Component::getDfSession(). Instead, use the
following:
IDfSessionManager sessionManager = SessionManagerHttpBinding.
getSessionManager();
IDfSession session = null;
try
{
session = sessionManager.getSession(remote_repository”);
// code to construct query against foreign repository
…
query.execute(session, IDfQuery.DF_CACHE_QUERY);
…
}
catch
{
ErrorMessageService.getService().setNonFatalError(…);
}
finally
{
if (session != null)
sessionManager.release(session);
}
Conguring Roles and Client Capability
This section presents an overview of role configuration in WDK 5.3, and provides
references to where you can find detailed information about implementing the following
functionality in your WDK-based application:
•
the client capability plugin
•
the repository role plugin
•
Role-based actions
•
Role-based filters
•
Role-based UI
In the Documentum 5 system, roles are defined as a special type of group. The
group_class attribute on the group is set to ’role’, and the group_name attribute is set
145
to the role name. (See the Content Server Administrator’s Guide for more information on
role groups.)
Webtop and WDK components can be configured to use any role that is defined in the
repository. If no roles for the user are configured in the repository, or if the repository
is pre-5.1, Webtop defaults to using the client capability model with the following
client_capability attributes on the dm_user object: consumer, contributor, coordinator,
and administrator. (For more information, see the section named "Client Capability
Plugin” in Chapter 6, Configuring Roles and Client Capability , in the Web Development Kit
and Client Applications Development Guide.)
If the user has no client capability level set, the role service assigns the user the consumer
role.
The client application, such as Webtop, Web Publisher, or your custom application,
enforces role capabilities through configuration. You can configure roles in WDK to
perform the following role-based presentation:
•
Role-based actions
You can restrict actions to users who belong to a specified role. For example, you
can restrict the checkout action in the action definition to contributors or higher
only, for example:
<precondition class="com.documentum.web.formext.action.RolePrecondition">
<role>contributor</role>
</precondition>
See the section named "Role-based Actions” in Chapter 6, Configuring Roles and
Client Capability , in the Web Development Kit and Client Applications Development Guide
for more information.
•
Role-based filters
You can restrict a container so that it displays some components to specified roles.
For example, you can filter the components in the folder properties container to
display the permissions component only to administrators or higher, while all roles
have access to the remaining components in the container:
<scope type="dm_folder">
<component id="properties" extends="type='*' application='webcomponent'">
<contains>
<filter role="administrator">
<component>permissions</component>
</filter>
<component>discussions</component>
<component>locations</component>
...
For more information, see "Role-based Filters,” in Chapter 6, Configuring Roles and
Client Capability , in the Web Development Kit and Client Applications Development Guide.
For a general description of the use of filters in configuration, see Web Development
Kit and Client Applications Development Guide.
146
•
Role-based component UI
You can present a different UI to different roles. For example, a different properties
page can be displayed to administrators and general users:
<scope type="dm_folder", role="administrator">
<component id="properties" extends="type='*' application='webcomponent'">
<contains>
<component>permissions</component>
<component>discussions</component>
<component>locations</component>
...
For more information, see "Role-based UI,s,” in Chapter 6, Configuring Roles and
Client Capability , in the Web Development Kit and Client Applications Development Guide.
The role service gets the user’s role using either the repository role model plugin (for
details, see the section named "Docbase Role Plugin,,” in Chapter 6, Configuring Roles and
Client Capability , in the Web Development Kit and Client Applications Development Guide). A
role is then used in one the following ways, depending on how it was called:
Role is defined as a scope on an action
The action service limits the action to
users having the specified role or a parent
of the role.
Role is defined as a filter in a container
The configuration service displays the
filtered component to users who have the
specified role or a parent of the role
Role is defined as a scope on a component
The configuration service displays the
component that is defined for the role or
a parent of the role
For detailed information about implementing roles and client capability in your
application, see Chapter 6, Configuring Roles and Client Capability , in the Web Development
Kit and Client Applications Development Guide.
Migrating Search Features
This section describes the new Search capabilities in WDK 5.3, provides some
information about migration best practices if you customized pre-5.3 search components,
and provides mapping information between WDK 5.2.5 search components and WDK
5.3 search components.
147
About Migrating Custom Search Components to WDK 5.3
This release of WDK contains some major new search-related features:
•
You can now display custom types.
•
For simple searches, your users can now dynamically choose which properties to
display when looking at search results.
In previous releases, you had to pre-define which columns to display on the search
results page, using the <column> element in your component configuration file.
•
Searches are now data dictionary-driven.
For example, you no longer need to add the <searchtype> element to the search
component configuration files to include custom types in searches. The default
search type is now dm_sysobject, which means all of its sub-types (including custom
types) are automatically included.
•
The XML configuration file for the advanced search component (advsearchex.xml)
has new configuration options for value assistance. This means that if you have
custom types in your repository, you can specify value assistance to list those types
on the advanced search page.
•
Two search control types are now available:
— Search UI Controls (full-text search)
— Search UI Controls (metadata-only search)
This allows you to search for objects with no content, such as folders.
•
One-box search now supports multi-repository searches, if you have a
multi-repository configuration.
For information on creating federations and managing replication, see the Distributed
Configuration Guide for Content Server.
•
You can now search external sources, such as Google, if you have configured external
search capabilities on your application server with ECI Services.
You can also import search results obtained from external sources into your
repository.
If any of the external sources require authentication, WDK 5.3 will automatically
prompt your users to log in.
For more information on setting up ECI Services, see the ECI Services Installation
Guide.
•
You can now edit saved searches through the Webtop user interface.
This feature works even if you changed the layout of the saved searches page.
•
148
A WDK 5.3-based application now stores search preferences for users.
By using cookies, the application can "remember” a user’s search preferences, such
as which repositories to search in a multi-repository configuration.
•
You can now target searches within a repository.
Formerly, you were restricted to searching an entire repository. With WDK 5.3,
you can specify particular cabinets or folders within a repository as the starting
points for your search.
If you want to migrate existing search component customizations to WDK 5.3, keep the
following in mind:
•
If you customized the Advanced Search (advsearch) page for pre-5.3 versions of
WDK, and want to continue using the older version with WDK 5.3, you must declare
a new component that extends the 5.2.x component.
•
Many of the most common 5.2.x WDK search customizations are no longer needed,
because WDK 5.3 provides a number of controls and configurations that implement
functionality that replaces the need for these customizations. Fro example, you
can now:
•
To continue using your existing 5.2.5 search customizations, extend the
dqlsearchdelegate component to invoke the WDK 5.2.5 search components.
•
Saved searches are now handled differently.
Saved searches were saved as dm_query objects in WDK 5.2.5. You can still run old
saved searches, but the new format is dm_smartlist.
•
Saving search preferences for users is now handled dynamically rather than
programmatically.
By using cookies, a WDK 5.3-based application can "remember” a user’s search
preferences, such as which repositories to search in a multi-repository configuration.
Any customizations you created that perform this function will still work, but they
are no longer needed.
•
If you want to add WDK 5.3 components to an existing application, you must create
new component that extends the desired WDK 5.3 component.
You cannot simply "swap” out WDK 5.2.5 and 5.3 components in existing
customizations. If you have customizations that use WDK 5.2.5 components,
those customized components will still work in WDK 5.3. But if you want to take
advantage of the WDK 5.3 new features, you must create new custom components.
Simple search and advanced full-text search are not case-sensitive. Case-sensitivity
settings for advanced search on attributes depend on the Server version.
If your environment has Content Server 5.2.5 repositories only, you can:
•
Add a checkbox for each attribute to the advanced search JSP page for case-sensitive
search.
•
Give the checkbox controls unique names.
•
Set the casevisible attribute on searchattribute and searchattributegroup tags to true.
149
•
Set the default match case as the value of the defaultmatchcase element to true in
/wdk/advsearchex.xml (default).
Case-sensitive queries will perform faster.
For 5.3 Content Server, attribute search is case-insensitive. The case-sensitive
checkboxes are not generated in the UI because the casevisible attribute is set to false on
searchattribute and searchattributegroup tags.
New and Changed Search Components, Classes, and Layout Files
This section provides a quick reference to new and changed Search feature components
in WDK 5.3. For detailed information about implementing new components, actions or
controls in WDK, see the Web Development Kit and Client Applications Development Guide.
For detailed information about any of the components referenced in Table 7–11, page 150
- Table 7–14, page 157, see the Web Development Kit and Client Applications Reference Guide.
Table 7-11. Search Component Map for Component Conguration Files
150
5.3 Search Component
5.2.x Search Components
Component ID
XML File
Component ID*
XML File
search
(webcomponent
layer)
app/
webcomponent/
config/library/
search/searchex/
search_component.
xml
search
(webcomponent
layer)
app/
webcomponent/
config/library/
search/search_
component.xml
advsearch
(webcomponent
layer)
app/
webcomponent/
config/library/
search/searchex/
advsearch_
component.xml
advsearch
(webcomponent
layer)
app/
webcomponent/
config/library/
search/advsearch_
component.xml
advsearchcontainer
app/webcomponent/config/library/
search/searchex/advsearchcontainer_component.xml
advsearchcontainer
app/webcomponent/config/library/search/advsearchcontainer_component.xml
Component ID
XML File
Component ID*
XML File
savesearch
/webcomponent/config/library/savesearch/
savesearchex/
savesearchcontainer_component.xml
savesearch
/webcomponent/
config/library/
savesearch/
savesearch_
component.xml
Old version invoker
component id: dqlsavesearchdelegate (app/webcomponent/config/library/savesearch/
savesearchex/dqlsavesearchdelegate_component.xml)
savesearchcontainer
/webcomponent/config/library/savesearch/
savesearchex/
savesearchcontainer_component.xml
N/A
N/A
mysavedsearches
/webcomponent/
config/library/
search/searchex/
mysavedsearches_
component.xml
savedsearches
/webcomponent/
config/library/
searche/
savedsearches_
component.xml
allsavedsearches
/webcomponent/config/library/search/
searchexallsavedsearches_component.xml
151
152
Component ID
XML File
Component ID*
XML File
searchstatus
/webcomponent/
config/library/
search/searchex/
searchstatus_
component.xml
N/A
N/A
searchstatuscontainer
/webcomponent/config/library/search/
searchex/searchstatuscontainer_component.xml
N/A
N/A
changesearchsources
/webcomponent/config/library/changesearchsources/
changesearchsources_component.xml
N/A
N/A
attributes (scoped
against external
search results)
/webcomponent/
config/library/
attributes/
attributes_dm_
externalresult_
component.xml
N/A
N/A
properties ((scoped
against external
search results)
/webcomponent/
config/library/
properties/dm_
externalresult_
properties_
component.xml
N/A
N/A
viewexternalresult
/webcomponent/
config/library/
search/searchex/
viewexternalresult_
component.xml
N/A
N/A
search (Webtop
layer)
app/webtop/
config/searchex_
component.xml
search (Webtop
layer)
app/webtop/config/
search_component.
xml
Component ID
XML File
Component ID*
XML File
Advsearch (Webtop
layer)
app/webtop/config/
advsearchex_
component.xml
Advsearch (Webtop
layer)
app/webtop/
config/advsearch_
component.xml
* Unless noted otherwise, all 5.2 components are versioned in 5.3.
Table 7-12. Search Component Map for NLS Properties Files
Component ID
NLS File
Component ID*
NLS File
search
(webcomponent
layer)
com.documentum.
webcomponent.
library.search.
SearchExNlsProp
search
(webcomponent
layer)
com.documentum.
webcomponent.
library.search.
SearchNlsProp
advsearch
(webcomponent
layer)
com.documentum.webcomponent.library.search.AdvSearchExNlsProp
advsearch
(webcomponent
layer)
com.documentum.
webcomponent.
library.search.
SearchNlsProp
advsearchcontainer
com.documentum.webcomponent.library.search.AdvSearchExContainerNlsProp
advsearchcontainer
com.documentum.webcomponent.library.search.AdvSearchContainerNlsProp
savesearch
com.documentum.webcomponent.library.savesearch.
SaveSearchContainerNlsProp
savesearch
com.documentum.
webcomponent.
library.savesearch.
SaveSearchNlsProp
savesearchcontainer
SaveSearchContainerNlsProp
N/A
N/A
153
154
Component ID
NLS File
Component ID*
NLS File
mysavedsearches
com.documentum.webcomponent.library.search.
MySavedSearchesNlsProp
savedsearches
com.documentum.webcomponent.library.savedsearches.SavedSearchesNlsProp
allsavedsearches
com.documentum.webcomponent.library.search.AllSavedSearchesNlsProp
searchstatus
SearchStatusNlsProp
N/A
N/A
SearchStatusContainerNlsProp
N/A
N/A
changesearchsources
changesearchsources.ChangeSearchSourcesNlsProp
N/A
N/A
attributes (scoped
against external
search results)
com.documentum.webcomponent.library.attributes.AttributesExtResultNlsProp
N/A
N/A
properties (external
search results)
com.documentum.
webcomponent.
library.properties.
PropertiesNlsProp
N/A
N/A
Component ID
NLS File
Component ID*
NLS File
viewexternalresult
com.documentum.
webcomponent.
library.search.
SearchExNlsProp
N/A
N/A
search (Webtop
layer)
Inherits from
webcomponent
layer
search (Webtop
layer)
Inherits from
webcomponent
layer
Advsearch (Webtop
layer)
Inherits from
webcomponent
layer
Advsearch (Webtop
layer)
Inherits from
webcomponent
layer
Table 7-13. Search Component Map for Java Classes
Component ID
Java File
Component ID*
Java File
search
(webcomponent
layer)
com.documentum.
webcomponent.
library.search.
SearchEx
search
(webcomponent
layer)
com.documentum.
webcomponent.
library.search.
Search
advsearch
(webcomponent
layer)
com.documentum.
webcomponent.
library.advsearch.
AdvSearchEx
advsearch
(webcomponent
layer)
com.documentum.
webcomponent.
library.advsearch.
AdvSearch
advsearchcontainer
com.documentum.webcomponent.library.advsearch.AdvSearchExContainer
advsearchcontainer
none
savesearch
com.documentum.
webcomponent.
library.savesearch.
SaveSearchEx
savesearch
com.documentum.
webcomponent.
library.savesearch.
SaveSearch
155
156
Component ID
Java File
Component ID*
Java File
savesearchcontainer
SaveSearchContainer
N/A
N/A
mysavedsearches
com.documentum.
webcomponent.
library.
savedsearches.
MySavedSearches
savedsearches
com.documentum.
webcomponent.
library.
savedsearches.
SavedSearches
allsavedsearches
com.documentum.
webcomponent.
library.
savedsearches.
AllSavedSearches
searchstatus
com.documentum.
webcomponent.
library.
searchstatus.
SearchStatus
N/A
N/A
com.documentum.webcomponent.library.searchstatus.SearchStatusContainer
N/A
N/A
changesearchsources
changesearchsources.ChangeSearchSources
N/A
N/A
attributes (external
search results)
com.documentum.
webcomponent.
library.attributes.
AttributesExtResult
N/A
N/A
Component ID
Java File
Component ID*
Java File
search results)
com.documentum.
webcomponent.
library.properties.
PropertiesExtResult
N/A
N/A
viewexternalresult
com.documentum.
webcomponent.
library.search.
ViewExternalResult
N/A
N/A
search (Webtop
layer)
com.documentum.
webcomponent.
library.search.
SearchEx
search (Webtop
layer)
/webtop/classic/
resultlist/resultlist.
jsp;
com.documentum.
webtop.
webcomponent.
advsearch.
AdvSearchEx
Advsearch (Webtop
layer)
Advsearch (Webtop
layer)
/webcomponent/
library/
searchresultslist/
searchresultslist.jsp
com.documentum.
webtop.
webcomponent.
advsearch.
AdvSearch
Table 7-14. Search Component Map for Layout Files
Component ID
JSP File
Component ID*
JSP File
search
(webcomponent
layer)
/webcomponent/
library/
searchresultslist/
searchex/wait.jsp
(5.2.5 equivalent:
wait.jsp)
search
(webcomponent
layer)
webcomponent/
library/
searchresultslist/
wait.jsp;
/webcomponent/
library/
searchresultslist/
searchex/
searchresults_
list.jsp (5.2.5
equivalent:
webcomponent/
library/
searchresultslist/
157
Component ID
Component ID*
JSP File
JSP File
webtop/classic/
jsp)
/webcomponent/
library/
searchresultslist/
searchex/
searchresults_
drilldown.jsp
(5.2.5 equivalent:
searchresultslist.
jsp)
/webcomponent/
library/
searchresultslist/
searchex/
embeddedcontent.
jsp (5.2.5
equivalent: none.
This is specific for
external source)
advsearch
(webcomponent
layer)
/webcomponent/
library/
advancedsearch/
advsearchex.jsp
advsearch
(webcomponent
layer)
/webcomponent/
library/
advancedsearch/
advsearch.jsp
advsearchcontainer
com.documentum.webcomponent.library.search.AdvSearchExContainerNlsProp
advsearchcontainer
/webcomponent/library/advsearchcontainer/advsearchcontainer.jsp
savesearch
/webcomponent/
library/savesearch/
savesearchex.jsp
savesearch
/webcomponent/
library/savesearch/
savesearch.jsp
/webcomponent/
library/savesearch/
savesearchdialog.
jsp
158
Component ID
JSP File
Component ID*
JSP File
savesearchcontainer
/wdk/container/
dialogcontainer.jsp
N/A
N/A
mysavedsearches
/webcomponent/
library/
savedsearches/
mysavedsearches.js
savedsearches
/webcomponent/
library/
savedsearches/
savedsearches.jsp
allsavedsearches
/webcomponent/
library/
savedsearches/
allsavedsearches.
jsp
searchstatus
/webcomponent/
library/
searchstatus/
searchstatus.jsp
N/A
N/A
/webcomponent/library/searchstatus/searchstatuscontainer.jsp
N/A
N/A
changesearchsources
/webcomponent/library/changesearchsources/
changesearchsources.jsp
N/A
N/A
attributes (external
search results)
/webcomponent/
library/attributes/
attributes_dm_
externalresult.jsp
N/A
N/A
search results)
/webcomponent/
library/properties/
properties_dm_
externalresult.jsp
N/A
N/A
viewexternalresult
/webcomponent/
library/
searchresultslist/
searchex/
viewexternalresult.
jsp
N/A
N/A
159
Component ID
JSP File
Component ID*
JSP File
search (Webtop
layer)
Inherits from
webcomponent
layer
search (Webtop
layer)
/webtop/classic/
jsp;
/webcomponent/
library/
searchresultslist/
Advsearch (Webtop
layer)
Inherits from
webcomponent
layer
Advsearch (Webtop
layer)
Inherits from
webcomponent
layer
Migrating Virtual Document Manager Components
This section describes the new Virtual Document Manager (VDM) capabilities in WDK
5.3, provides some information about migration best practices if you customized pre-5.3
VDM components, and provides mapping information between WDK 5.2.5 VDM
components and WDK 5.3 VDM components.
What’s New in Virtual Document Manager for WDK 5.3?
This release of VDM for WDK 5.3 offers significant new features to bring VDM for
WDK-based application to functional parity with VDM for the Documentum Desktop
client.
Many of the WDK 5.2.5 VDM components have been replaced by new components in 5.3
rather than versioned, and for that reason, we strongly recommend that you migrate any
VDM components you customized in WDK 5.2.5 to their WDK 5.3 counterparts. Because
of this, some of the WDK 5.2.5 VDM components you extended have been deprecated.
Your customized components will still work in WDK 5.3, but for future compatibilty, you
should replace these customization with the new 5.3 VDM components.
The major new features in this release of VDM includes the following:
160
•
You can now view the entire virtual document tree through Webtop’s VDM.
•
Drag and drop functionality has been enabled for VDM running on Windows
Internet Explorer. You can now:
— Import items from your desktop by dragging and dropping them into VDM
— Edit the structure of virtual documents by dragging and dropping items between
levels
•
Setting binding rules is now supported
•
Setting version labels for the entire virtual document.
•
Creating, freezing, and unfreezing snapshots (formerly known as assemblies)
•
Creating documents within VDM
•
Dragging and dropping items between multiple Webtop browser windows
•
Multi-repository support allows you to include replica objects in a virtual document.
New and Changed VDM Components, Classes, NLS Properties,
and Layout Files
This section provides a quick reference to new and changed VDM feature components in
Webtop 5.3. For detailed information about implementing new components, actions or
controls in WDK, see the Web Development Kit and Client Applications Development Guide.
For detailed information about any of the components referenced in Table 7–15, page 161
- , see the Web Development Kit and Client Applications Reference Guide.
Table 7-15. VDM 5.2.5 -5.3 Component Mapping
5.3 VDM Components
5.2.x VDM Components
Component ID
XML File
Component ID*
XML File
addvirtualdocumentnodefromclipboard
webcomponent/config/library/vdm/addcomponent/addvirtualdocumentnodefromclipboard_component.xml
addcomponent
webcomponent/
config/library/vdm/
addcomponent/
addcomponent_
component.xml
addvirtualdocumentnodefromfileselector
webcomponent/config/library/vdm/addcomponent/addvirtualdocumentnodefromfileselector_component.xml
addcomponentfileselector
webcomponent/config/library/vdm/addcomponent/addcomponentfileselector_component.xml
161
162
5.3 VDM Components
Component ID
XML File
Component ID*
XML File
addnewvirtualdocumentnode
webcomponent/config/library/vdm/addcomponent/
addnewvirtualdocumentnode_component.xml
N/A
N/A
removevirtualdocumentnode
webcomponent/config/library/vdm/removecomponent/removevirtualdocumentnode_component.xml
removecomponent
webcomponent/config/library/vdm/removecomponent/removecomponent_component.xml
reordervirtualdocu- webcompomentnodes
nent/config/library/vdm/reordercomponents/reordervirtualdocumentnodes_component.xml
reordercomponents
webcomponent/config/library/vdm/reordercomponents/reordercomponents_component.xml
setbindingrule
webcomponent/
setbindingrule/
setbindingrule_
component.xml
N/A
N/A
savechanges
webcomponent/
config/library/
vdm/savechanges/
savechanges_
component.xml
commitchanges
webcomponent/
commitchanges/
commitchanges_
component.xml
modifyversionlabels
webcomponent/config/library/modifyversionlabels/modifyversionlabels_component.xml
N/A
N/A
5.3 VDM Components
Component ID
XML File
Component ID*
XML File
newassembly
webcomponent/
newassembly/
newassembly_
component.xml
N/A
N/A
addvirtualdocumentnode
webcomponent/config/library/vdm/addcomponent/addvirtualdocumentnode_component.xml
N/A
N/A
repositionvirtualdocumentnode
webcomponent/config/library/vdm/repositionnode/repositionvirtualdocumentnode_component.xml
N/A
N/A
vdmclickactionprompt
webcomponent/
config/
navigation/vdm/
vdmclickaction_
prompt_
component.xml
N/A
N/A
163
5.3 VDM Components
Component ID
XML File
Component ID*
XML File
vdmcopyoption
webcomponent/
config/library/
vdm/copyoption/
copyoption_
component.xml
N/A
N/A
viewassemblies
webtop/config/
viewassemblies_
component.xml
N/A
N/A
vdmlist
webtop/config/
vdmlist_
component.xml
webcomponent/
viewassemblies/
viewassemblies_
component.xml
vdmlist
webtop/config/
vdmlist_
component.xml
webcomponent/
config/navigation/
vdm/vdmlist_
component.xml
vdmliststreamline
webtop/config/
vdmliststreamline_
component.xml
webcomponent/
config/navigation/
vdm/vdmlist_
component.xml
vdmliststreamline
webcomponent/
config/
navigation/vdm/
vdmliststreamline_
component.xml
164
5.3 VDM Components
Component ID
XML File
Component ID*
XML File
assemblylist
webtop/config/
vdmliststreamline_
component.xml
N/A
N/A
N/A
N/A
webcomponent/
config/
navigation/vdm/
vdmliststreamline_
component.xml
assemblyliststreamline
webtop/config/
assemblylist_
component.xml,
webcomponent/
config/navigation/
vdm/assemblylist_
component.xml
Table 7-16. VDM 5.2.5 -5.3 NLS Properties Mapping
5.3 VDM Components
Component ID
NLS File
Component ID*
NLS File
com.documentum.webcomponent.library.vdm.addcomponent.AddVirtualDocumentNodeNlsProp
addcomponent
com.documentum.webcomponent.library.vdm.addcomponent.AddComponentNlsProp
com.documentum.webcomponent.library.vdm.addcomponent.AddComponentNlsProp
165
166
5.3 VDM Components
Component ID
NLS File
Component ID*
NLS File
vdm.addcomponent.AddNewVirtualDocumentNodeNlsProp
N/A
N/A
com.documentum.webcomponent.library.vdm.removecomponent.RemoveVirtualDocumentNodeNlsProp
removecomponent
com.documentum.webcomponent.library.vdm.removecomponent.RemoveComponentNlsProp
reordervirtualdocu- com.documentnodes
mentum.webcomponent.library.vdm.reordercomponents.ReorderVirtualDocumentNodesNlsProp
reordercomponents
com.documentum.webcomponent.library.vdm.reordercomponents.ReorderComponentsNlsProp
setbindingrule
com.documentum.webcomponent.library.vdm.setbindingrule.SetBindingRuleNlsProp
N/A
N/A
savechanges
om.documentum.webcomponent.library.
vdm.savechanges.
SaveChangesNlsProp
commitchanges
com.documentum.webcomponent.library.vdm.commitchanges.CommitChangesNlsProp
5.3 VDM Components
Component ID
NLS File
Component ID*
NLS File
modifyversionlabels
com.documentum.webcomponent.library.modifyversionlabels.ModifyVersionLabelsNlsProp
N/A
N/A
newassembly
vdm.newassembly.NewAssemblyNlsProp
N/A
N/A
N/A
N/A
com.documentum.webcomponent.library.vdm.repositionnode.RepositionVirtualDocumentNodeNlsProp
N/A
N/A
com.documentum.webcomponent.library.vdm.clickactionprompt.ClickActionPromptNlsProp
N/A
N/A
vdmcopyoption
com.documentum.webcomponent.library.vdm.copyoption.CopyOptionNlsProp
N/A
N/A
167
5.3 VDM Components
Component ID
NLS File
Component ID*
NLS File
viewassemblies
vdm.viewassemblies.ViewAssembliesNlsProp
N/A
N/A
vdmlist
com.documentum.
webcomponent.
navigation.vdm.
VDMNlsProp
vdmlist
com.documentum.
webcomponent.
navigation.vdm.
VDMNlsProp
vdmliststreamline
com.documentum.webcomponent.navigation.vdm.VDMStreamlineNlsProp
vdmliststreamline
com.documentum.webcomponent.navigation.vdm.VDMStreamlineNlsProp
assemblylist
com.documentum.webcomponent.navigation.vdm.AssemblyListNlsProp
N/A
N/A
com.documentum.webcomponent.navigation.vdm.AssemblyListStreamlineNlsProp
N/A
N/A
Table 7-17. VDM 5.2.5 -5.3 Java Class Mapping
168
5.3 VDM Components
Component ID
Java Class File
Component ID*
Java Class File
com.documentum.webcomponent.library.vdm.addcomponent.AddVirtualDocu-
addcomponent
com.documentum.
webcomponent.
library.vdm.
addcomponent.
AddComponent
5.3 VDM Components
Component ID
Component ID*
Java Class File
Java Class File
mentNodeFromClipboard
com.documentum.webcomponent.library.vdm.addcomponent.AddVirtualDocumentNodeFromFileSelector
com.documentum.
webcomponent.
library.vdm.
addcomponent.
AddComponentFS
vdm.addcomponent.AddNewVirtualDocumentNode
N/A
N/A
"com.documentum.webcomponent.library.vdm.removecomponent.RemoveVirtualDocumentNode
removecomponent
com.documentum.webcomponent.library.vdm.removecomponent.RemoveComponent
reordervirtualdocu- com.documentnodes
mentum.webcomponent.library.vdm.reordercomponents.ReorderVirtualDocumentNodes
reordercomponents
com.documentum.webcomponent.library.vdm.reordercomponents.ReorderComponents
setbindingrule
N/A
N/A
com.documentum.
webcomponent.
library.vdm.
setbindingrule.
SetBindingRule
169
170
5.3 VDM Components
Component ID
Java Class File
Component ID*
Java Class File
savechanges
com.documentum.
webcomponent.
library.vdm.
savechanges.
SaveChanges
commitchanges
com.documentum.
webcomponent.
library.vdm.
commitchanges.
CommitChanges
modifyversionlabels
com.documentum.webcomponent.library.modifyversionlabels.ModifyVersionLabels
N/A
N/A
newassembly
com.documentum.
webcomponent.
library.vdm.
newassembly.
NewAssembly
N/A
N/A
com.documentum.webcomponent.library.vdm.addcomponent.AddVirtualDocumentNode
N/A
N/A
com.documentum.webcomponent.library.vdm.repositionnode.RepositionVirtualDocumentNode
N/A
N/A
com.documentum.
webcomponent.
library.vdm.
clickactionprompt.
ClickActionPrompt
N/A
N/A
5.3 VDM Components
Component ID
Java Class File
Component ID*
Java Class File
vdmcopyoption
com.documentum.
webcomponent.
library.vdm.
copyoption.
CopyOption
N/A
N/A
viewassemblies
com.documentum.
webtop.webcomponent.viewassemblies.ViewAssembliesComponent
N/A
N/A
vdmlist
com.documentum.
webtop.
webcomponent.
vdm.VDMList,
vdm.viewassemblies.ViewAssembliesComponent
vdmlist
com.documentum.
webtop.
webcomponent.
vdm.VDMList
com.documentum.
webcomponent.
navigation.vdm.
VDMList
vdmliststreamline
com.documentum.
webtop.webcomponent.vdm.VDMListStreamline
com.documentum.webcomponent.navigation.vdm.VDMListStreamline
com.documentum.
webcomponent.
navigation.vdm.
VDMList
vdmliststreamline
com.documentum.
webtop.webcomponent.vdm.VDMListStreamline,
com.documentum.webcomponent.navigation.vdm.VDMListStreamline
171
5.3 VDM Components
Component ID
Java Class File
Component ID*
Java Class File
assemblylist
com.documentum.
webcomponent.
navigation.vdm.
AssemblyList
N/A
N/A
com.documentum.
webtop.webcomponent.vdm.AssemblyListStreamline
N/A
N/A
com.documentum.webcomponent.navigation.vdm.AssemblyListStreamline
Adding Failover Support to Existing Applications
This section describes how to implement the new failover support features in
WDK-based applications
Conguring Global Failover Support
Failover support in WDK can be enabled by modifying the context parameter
EnableFailover
in the web.xml file, which is stored in the WEB-INF folder of the virtual root. For
example,
<context-param>
<param-name>EnableFailover</param-name>
<param-value>false</param-value>
</context-param>
By default, the failover support is disabled (set to false). To enable the failover support,
change the parameter value to true.
172
Controlling Session Data Serialization
WDK and various web components place large amounts of data in the session and they
update the session several times during a request. Applications servers such as like BEA
WebLogic replicate the session for every setAttribute/removeAttribute call. To improve
performance, a custom HTTP Session (named ReplicatedSession) is created to control the
serialization of the session data. This custom session object controsl what session data
gets serialized and the frequency of the serialization during a request.
A configuration parameter named SessionReplicationFrequency is available in the
web.xml configuration file to determine when your application replicates the session
data.
<web-app>
. . .
<context-param>
<param-name>SessionReplicationFrequency</param-name>
<!—allowed values: always, end-of-request
always= Session is replicated each time it is updated (setAttribute,
removeAttribute
end-of-request=Session is replicated at the end of the request
Default = end-of-request —>
<param-value>end-of-request</param-value>
</context-param>
. . .
</web-app>
The ReplicatedSession object uses this context parameter to control the serialization
of attributes.
Enabling Failover for Individual Components
You can enable or disable failover support for a component by editing the value of the
failoverenabled tag in the component definition XML file. For example:
<component id="name" >
<failoverenabled>true</failoverenabled>
</component>
If the value of failoverenabled is set to true, the component state will be replicated.
The failoverenabled tag is used by the WDK framework to control the serialization of
the component state and notify the component in case of a failover recovery. It works in
the following way:
•
If a component is marked as failoverenabled, and is extended by another component,
the extended component will also inherit the flag unless otherwise it gets overridden.
•
If the extended component needs to do some additional work to recover/cleanup,
it needs to override the onRecover() method, first call the super method and then
173
should do the additional work. This behavior is similar to over riding the onInit
method.
Enabling Container Component Failover
In WDK 5.3, if the value of failoverenabled is set to true in the container component
definition XML file, then all components contained in that container must also be marked
as "replicable." Otherwise, the WDK framework will not serialize the container and will
log a warning message if the debug flag is enabled.
Common WDK 5.3 container components such as Wizard, Combo, Property Sheet, and
the Property sheet wizard support failover and recovery by default. The following
conditions apply:
•
Out of the box, all container components have the value of failoverenabled set to
true in the container component definition XML file
•
Container component classes will override the onRecover method and will call
onRecover method on all its contained components, which in turn will call
onRecover method on controls.
Adding Drag and Drop Support
This release of WDK integrates drag and drop capabilities similar to those found in
Windows Explorer. By utilizing the new classes and implementing the new interfaces,
you can to integrate drag and drop into your component’s controls. Controls that
integrate drag and drop can flag themselves as a drag source, a drop target, or both.
Drag and drop within and between frames in a WDK application are supported out of
the box by JavaScript that is generated by drag and drop controls. For drag and drop
to and from the desktop, an Active-X control is provided. The user must download
this control the first time a drag or drop action involving the desktop is invoked. The
Active-X DLL can be disabled in the app.xml configuration file.
To implement drag and drop, you must implement the IDragSource interface, the
IDropTarget interface, or both. A new helper class, DragDropSupportBuilder, was
created to help with the drag and drop implementation.
Each IDragSource and IDropTarget will support a set of custom-defined formats (class
objects) along with a set of customer-defined drag/drop actions. When the user drags
using the right mouse button, upon dropping, the set of drag/drop actions will be used
to present the user with a menu from which they can select the action they intend to
perform. If the user drags using the left mouse button, the menu will be presented only
when no default action has been defined.
174
To configure the list of available source actions for each action supported, you must add
an IDragSourceAction instance to the IDragSource implementation.
To configure the list of available target actions: for each action supported, you must add
an IDragTargetAction instance to the IDropTarget implementation. If a source action
exists whose name matches that of a target action, it will be invoked upon successful
invocation of the target action.
Enabling Drag and Drop for Individual Actions
Two new controls, DragDrop and DragDropRegion, have been created to support drag
and drop. To enable drag and drop for individual actions:
•
Controls that you want to use as a drag source should implement the new interface
IDragSource
•
Controls that you want to use as drop target should implement the IDropTarget
interface
Each JSP page that will support drag and drop will need an instance of the DragDrop
control. The control will include the necessary javascript files to support drag and
drop. On a JSP page, the DragDropRegion control should be used to surround desired
draggable or droppable elements. It will provide the HTML markup necessary to enable
the elements to be dragged, dropped, or both.
To support VDM drag and drop, the DragDropRegion will be used to surround object
name links and labels. It is also used by the Tree control to handle drag and drop
rendering for those tree nodes which are designated as supporting drag and drop. The
DragDropRegion control is also used by the Tree control to handle drag and drop
rendering for those tree nodes which are designated as supporting drag and drop.
You can update a class’s XML configuration file by adding the following tags:
<dragdrop>
<sourceactions>
<sourceaction>
com.documentum.web.dragdrop.IDragSourceAction
</sourceaction>
</sourceactions>
<targetactions>
<targetaction>
com.documentum.web.dragdrop.IDropTargetAction
</targetaction>
</targetactions>
<dataproviders>
<dataprovider>
<format>
fully.qualified.path.for.format
</format>
175
<provider>
com.documentum.web.dragdrop.IDragDropDataProvider
</provider>
</dataprovider>
</dataproviders>
</dragdrop>
The XML tags are used as follows:
•
sourceactions represents the set of actions which the drag source will support
•
sourceactionrepresents a specific source action; there may be any number of source
actions
•
targetactions represents the set of actions which the drop target will support
•
targetaction represents a specific target action; there may be any number of target
actions
•
dataproviders describes the set of supported drag and drop data formats and
providers
•
dataprovider defines a single drag and drop data provider for a given format; there
may be any number of data providers format represents a drag and drop data format
provider represents a data provider
Migrating Existing Components for Location and
Navigation
WDK 5.3 contains a number of location and navigation enhancements that address
the following issues present in WDK 5.2.5:
•
Navigation paths (formerly known as breadcrumbs) contained the names of folders
that the user did not have Browse rights on.
•
Paths displayed in listing pages, such as locations, contained the names of folders
that the user did not have Browse rights on.
•
A user could not navigate to a folder (from a DRL, search results, or subscriptions) if
the user did not have rights to all the folders in the folder’s first folder-path entry
•
Navigating from Subscriptions displayed the folder with the navigation path
showing the folder’s first folder-path entry, which was unlikely to be the same path
shown when the folder was subscribed too. Ideally, the path displayed should be
the path displayed when the object was subscribed to.
The following list outlines the changes you need to make to components and
customizations to ensure compliance with the 5.3 navigation and location enhancements.
•
Use olderUtil.getPrimaryFolderPath(…) to determine an object’s primary path.
Change all existing calls to FolderUtil.getFolderPath(<id>, 0) or IDfFolder.
getFolderPath(0) to use this method.
176
•
Add the encrypt=’true’ property on any hidden controls in JSPs that contain
folder paths.
•
Initialize all navigation path controls that contain repository folder paths using
FolderUtil.initBreadcrumb(…).
•
Use FolderUtil.formatFolderPath(…) to format any folder paths that a custom
component or custom control directly renders. The method can also be
used to determine whether a folder path is partial or not. For example, if
(formatFolderPath(xxx).startswith("…/”))
•
Ensure that all listing components that display (or can display) r_folder_path
have a cell template defined in the component’s JSP that uses either the
FolderUtil.formatFolderPath(…) method, or the PrimaryFolderPathLink control to
format the r_folder_path’s value.
177
178
Chapter 8
Migrating DFC or BOF-based Custom
Applications
This chapter provides information about migrating custom applications created using Documentum
Foundation Classes (DFC) or Business Object Framework (BOF). The following topics are discussed:
•
What’s New in DFC?, page 179
•
What’s New in BOF?, page 187
•
The DFC 5.3 Documentation Set, page 187
•
Architecture Changes in DFC, page 187
•
Planning your Migration, page 188
•
Post Migration Tasks, page 191
What’s New in DFC?
This release of DFC contains the following major new features:
•
Several powerful new features added to the programming model, including Aspect
and Document Class
•
Unified Client Facilities (UCF) support
UCF makes client context available to business logic and lower-level services. It
addresses the base client access needs of content library services, such as import,
export, check-in, and checkout, providing the next generation of content transfer
functionality for WDK-based applications, thus reducing the need for DFC on the
client.
•
Business Objects can now be accessed using Web Services.
•
Deeper .NET integration
•
Simplified complex XML and compound document processing in Web environments
•
Support for Content Storage Services features on the Content Server
179
Migrating DFC or BOF-based Custom Applications
New Interfaces and Types
In order to support the new BOF deployment model, Content Server 5.3 introduces
the following repository types:
•
dmc_module
•
dmc_jar
•
dmc_java_library
Refer to the Content Server Object Reference Manual for more information about these types.
Deprecated Features and Interfaces
This section describes features that we no longer support and features for which we plan
to drop support in some subsequent release.
Deprecated Methods
The following methods have been deprecated since DFC 5.2.5:
com.IDfClientX.getOperation (String)
fc.client.DfServiceException (int, String)
fc.client.DfServiceException (Object, String)
fc.client.IDfClient.getDbor ()
fc.client.IDfPersistentObject.apiExec (String, String)
fc.client.IDfPersistentObject.apiGet (String, String)
fc.client.IDfPersistentObject.apiSet (String, String, String)
fc.client.IDfRelation.getPermanentLink ()
fc.client.IDfRelation.setPermanentLink (boolean)
fc.client.IDfSession.apiExec (String, String)
fc.client.IDfSession.apiGet (String, String)
fc.client.IDfSession.apiGetBytes (String, String, String, String, int)
fc.client.IDfSession.apiSet (String, String, String)
fc.client.IDfSession.apiSetBytes (String, String, ByteArrayOutputStream)
fc.client.IDfSession.newObjectWithType (String, String)
180
fc.client.IDfUser.getUserSource ()
fc.client.IDfUser.setUserSource (int)
fc.common.DfException (int)
fc.common.DfException (int, String)
fc.common.DfException (int, String, String, String)
fc.common.DfException (ResourceBundle, int)
fc.common.DfException (ResourceBundle, int, String, String, String)
fc.common.DfException.getErrorCode ()
fc.common.DfException.setErrorCode (int)
fc.common.IDfException.getErrorCode ()
fc.common.IDfException.setErrorCode (int)
BOF Deployment Through DBOR
The pre-5.3 versions of DFC use a deployment model that entails placing a Documentum
business object registry (DBOR) on each client machine. With DFC 5.3, we deprecate the
use of this deployment model. It continues to work, but many features of Documentum
5.3 products use the new deployment model. Refer to for more information.
Overriding Methods in TBOs
Creating a type based object (TBO) sometimes entails overriding methods of DfSysObject.
DFC 5.3 introduces a set of methods designed to make this easier to do.
The process for overriding methods of DfSysObject prior to DFC 5.3 poses the following
problems:
•
Because different client programs sometimes invoke different methods to perform
the same task, you may need to override more than one method with the same
override code.
For example, if you override the save method to customize checkin behavior, you
must also override the savelock method.
•
Subsequent changes to DFC internals may render your customization obsolete.
For example, you may have overridden the getFileEx2 method to customize export
behavior. A subsequent version of DFC may introduce a method called getFileEx3
that behaves the same as getFileEx2 but takes an additional argument. If getFileEx3
181
does not call getFileEx2, then any clients that call getFileEx3 will bypass your
customization.
The override process introduced in DFC 5.3 eliminates these problems. The remainder of
this section explains how it works.
The DFC Development Guide for DFC 5.2.5 SP2 containsTable 8–1, page 182, which tells
you which methods to override for some common tasks you might wish to customize.
Table 8-1. Methods to override when implementing TBOs
Task
Methods
Import
link
setFileEx
save, savelock, checkinEx
Export
getFileEx2
Checkout
checkoutEx
getFileEx2
Checkin
setFileEx
Cancel checkout
cancelCheckoutEx
Delete
destroy, destroyAllVersions
Copy
link
saveAsNew
Move
link
Change properties
setString, setRepeatingString
With DFC 5.3, we deprecate the practice of overriding the methods that appear in the
table. Existing customizations that override those methods will still work, but they may
not continue to work if you upgrade to versions of DFC beyond 5.3.
To replace the deprecated practice, we provide a set of do methods (doCheckin,
doCheckout, and so forth). These are the only methods of DfSysObject for which we
support overrides. Thus, rather than overriding save and savelock, you need only
override doSave.
Table 8–2, page 183 lists the signatures of the do methods. To safely override any of the
do methods, imitate the following pattern:
182
class MyTBO extends DfSysObject {
// . . .
void doSave (boolean saveLock,
String versionLabel,
Object[] extendedArgs)
throws DfException
{
//optional preprocessing
super.doSave (saveLock, versionLabel, extendedArgs);
//optional post-processing
}
}
Methods to override when implementing TBOs
Table 8-2. Methods of DfSysObject
IDfId doAddESignature (String userName, String password, String
signatureJustification, String formatToSign, String hashAlgorithm, String
preSignatureHash, String signatureMethodName, String applicationProperties, String
passThroughArgument1, String passThroughArgument2, Object[] extendedArgs)
throws DfException
IDfId doAddReference (IDfId folderId, String bindingCondition, String bindingLabel,
Object[] extendedArgs) throws DfException
void doAddRendition (String fileName, String formatName, int pageNumber, String
pageModifier, String storageName, boolean atomic, boolean keep, boolean batch,
String otherFileName, Object[] extendedArgs) throws DfException
void doAppendFile (String fileName, String otherFileName, Object[] extendedArgs)
throws DfException
IDfCollection doAssemble (IDfId virtualDocumentId, int interruptFrequency, String
qualification, String nodesortList, Object[] extendedArgs) throws DfException
IDfVirtualDocument doAsVirtualDocument (String lateBindingValue, boolean
followRootAssembly, Object[] extendedArgs) throws DfException
void doAttachPolicy (IDfId policyId, String state, String scope, Object[] extendedArgs)
throws DfException
void doBindFile ( int pageNumber, IDfId srcId, int srcPageNumber, Object[]
extendedArgs) throws DfException
IDfId doBranch (String versionLabel, Object[] extendedArgs) throws DfException
183
void doCancelScheduledDemote (IDfTime scheduleDate, Object[] extendedArgs)
throws DfException
void doCancelScheduledPromote (IDfTime scheduleDate, Object[] extendedArgs)
throws DfException
void doCancelScheduledResume (IDfTime schedule, Object[] extendedArgs) throws
DfException
void doCancelScheduledSuspend (IDfTime scheduleDate, Object[] extendedArgs)
throws DfException
IDfId doCheckin (boolean fRetainLock, String versionLabels, String oldCompoundArchValue, String oldSpecialAppValue, String newCompoundArchValue,
String newSpecialAppValue, Object[] extendedArgs)
IDfId doCheckout (String versionLabel, String compoundArchValue, String
specialAppValue, Object[] extendedArgs)
void doDemote (String state, boolean toBase, Object[] extendedArgs) throws
DfException
void doDestroyAllVersions (Object[] extendedArgs) throws DfException
void doDetachPolicy (Object[] extendedArgs) throws DfException
void doDisassemble (Object[] extendedArgs) throws DfException
boolean doFetch (String currencyCheckValue, boolean usePersistentCache, boolean
useSharedCache, Object[] extendedArgs) throws DfException
void doFreeze (boolean freezeComponents, Object[] extendedArgs) throws
DfException
void doInsertFile (String fileName, int pageNumber, String otherFileName, Object[]
void doLink (String folderSpec, Object[] extendedArgs) throws DfException
void doLock (Object[] extendedArgs) throws DfException
void doMark (String versionLabels, Object[] extendedArgs) throws DfException
void doPromote (String state, boolean override, boolean fTestOnly, Object[]
void doPrune (boolean keepSLabel, Object[] extendedArgs) throws DfException
IDfId doQueue (String queueOwner, String event, int priority, boolean sendMail,
IDfTime dueDate, String message, Object[] extendedArgs) throws DfException
void doRefreshReference (Object[] extendedArgs) throws DfException
void doRegisterEvent (String message, String event, int priority, boolean sendMail,
184
void doRemovePart (IDfId containmentId, double orderNo, boolean orderNoFlag,
void doRemoveRendition (String formatName, int pageNumber, String pageModifier,
boolean atomic, Object[] extendedArgs) throws DfException
String doResolveAlias (String scopeAlias, Object[] extendedArgs) throws DfException
void doResume (String state, boolean toBase, boolean override, boolean fTestOnly,
void doRevert (boolean aclOnly, Object[] extendedArgs) throws DfException
void doSave (boolean saveLock, String versionLabel, Object[] extendedArgs) throws
DfException
IDfId doSaveAsNew (boolean shareContent, boolean copyRelations, Object[]
void doScheduleDemote (String state, IDfTime scheduleDate, Object[] extendedArgs)
throws DfException
void doSchedulePromote (String state, IDfTime scheduleDate, boolean override,
void doScheduleResume (String state, IDfTime scheduleDate, boolean toBase, boolean
override, Object[] extendedArgs) throws DfException
void doScheduleSuspend (String state, IDfTime scheduleDate, boolean override,
void doSetACL (IDfACL acl, Object[] extendedArgs) throws DfException
void doSetFile (String fileName, String formatName, int pageNumber, String otherFile,
void doSetIsVirtualDocument (boolean treatAsVirtual, Object[] extendedArgs) throws
DfException
void doSetPath (String fileName, String formatName, int pageNumber, String
otherFile, Object[] extendedArgs) throws DfException
void doSuspend (String state, boolean override, boolean fTestOnly, Object[]
void doUnfreeze (boolean thawComponents, Object[] extendedArgs) throws
DfException
void doUnlink (String folderSpec, Object[] extendedArgs) throws DfException
void doUnmark (String versionLabels, Object[] extendedArgs) throws DfException
void doUnRegisterEvent (String event, Object[] extendedArgs) throws DfException
185
void doUpdatePart (IDfId containmentId, String versionLabel, double orderNumber,
boolean useNodeVerLabel, boolean followAssembly, int copyChild, String
containType, String containDesc, Object[] extendedArgs) throws DfException
void doUseACL (String aclType, Object[] extendedArgs) throws DfException
void doVerifyESignature (Object[] extendedArgs) throws DfException
Table 8-3. Methods of DfPersistentObject
protected IDfRelation doAddChildRelative (String relationTypeName, IDfId childId,
String childLabel, boolean isPermanent, String description, Object[] extendedArgs)
throws DfException
protected IDfRelation doAddParentRelative (String relationTypeName, IDfId parentId,
String childLabel, boolean isPermanent, String description, Object[] extendedArgs)
throws DfException
protected void doDestroy (boolean force, Object[] extendedArgs) throws DfException
protected boolean doFetch (String currencyCheckValue, boolean usePersistentCache,
boolean useSharedCache, Object[] extendedArgs) throws DfException
protected void doRemoveChildRelative (String relationTypeName, IDfId childId,
String childLabel, Object[] extendedArgs) throws DfException
protected void doRemoveParentRelative (String relationTypeName, IDfId parentId,
String childLabel, Object[] extendedArgs) throws DfException
protected void doRevert (boolean aclOnly, Object[] extendedArgs) throws DfException
Table 8-4. Methods of DfTypedObject
protected void doAppendString (String attrName, String value, Object[] extendedArgs)
throws DfException
protected void doInsertString (String attrName, int valueIndex, String value, Object[]
doSetString (String attrName, int valueIndex, String value, Object[] extendedArgs)
throws DfException
Avoid Casting to Concrete Classes
With DFC 5.1, Documentum deprecated and strongly discouraged the practice of casting
a persistent object to a concrete class. You should cast to the corresponding interface
instead (for example, cast to IDfSysObject rather than DfSysObject).
186
Earlier versions of DFC did not enforce this rule. DFC 5.3 throws ClassCastException if
you cast a persistent object to a concrete class.
What’s New in BOF?
This release of BOF offers the following new features:
•
Service-based business objects (SBOs) can now be installed in one central repository
and deployed dynamically to all clients across your enterprise
This replaces the need to deploy services individually to all clients and servers in
your enterprise, and drastically reduces the number of extra deployment steps, such
as modifying application server classpaths and stopping and starting application
servers, in order to use them, allows you to deploy new versions of the services
at will in "hot deployments”.
•
Type-based business objects (TBOs) are now associated with both a type and a
repository.
In pre-5.3 versions of BOF, you had to have the same TBO implementation for all
repositories since the registration was handled on the client. BOF 5.3 doesn’t rely
on client registration to execute TBO logic, which also eliminates problems that
some applications had in had in pre-5.3 versions of BOF, where a client used a type
but was missing the dbor entry.
•
Business objects can now be accessed using Web Services.
The DFC 5.3 Documentation Set
The DFC documentation set for the 5.3 release consists of the following:
•
Documentum Foundation Classes (DFC) Installation Guide, version 5.3
•
Documentum Foundation Classes (DFC) Release Notes, version 5.3
•
Documentum Foundation Classes Development Guide, version 5.3
Architecture Changes in DFC
Figure 8–1, page 188 represents the DFC 5.3 architectural model.
187
Figure 8-1. DFC 5.3 Architecture
Planning your Migration
This section provides the following information:
•
Who should migrate?
•
Overview of major migration tasks for DFC and BOF
Who Should Migrate?
If you deployed business objects using the original deployment mechanism in pre-5.3
versions of BOF, you can continue to so. You can also use the new and old deployment
mechanisms together (though BOF 5.3 will take precedence).
•
For deployments that use TBOs, to use BOF 5.3 objects you must use Content Server
5.3 with 5.3 content repositories. This is because there were changes to the object
model.
•
For deployments that use SBOs, you must use BOF 5.3 objects you must use Content
Server 5.3 with at least one 5.3 repository specified as the global registry. You can
continue to use your 5.2.x content repositories.
Overview of DFC Migration Tasks
This section describes any tasks required for migrating applications created using
pre-5.2.x versions of DFC.
188
Migrating from pre-5.2.x Versions of DFC
If you created applications or customizations using pre-5.2.x versions of DFC, you
must first migrate to DFC 5.2.5 (with any Service Pack) before you can upgrade to DFC
version 5.3.
For information about migrating from DFC versions 4.2.x and 5.1, see Chapter 6,
Migrating DFC-based Applications, in the Documentum 5 System Migration Guide, Fifth
Edition for version 5.2.5.
Migrating from DFC 5.2.x
There are no required tasks for migrating custom DFC applications created with 5.2.x
versions of DFC.
DFC 5.3 is fully backwards-compatible with DFC 5.2.x.
You may, however, want to keep in mind the following Best Practices recommendations:
•
Content Server 5.3 includes several changes to the Documentum object model,
such as new attributes for dm_relation_type, and you may wish to update your
application or customization for future compatibility.
New, changed, and deprecated types, methods, and API calls for Content Server are
described in Chapter 6, Migrating Content Server.
•
With DFC 5.1, Documentum deprecated and strongly discouraged the practice of
casting a persistent object to a concrete class. You should cast to the corresponding
interface instead.
Earlier versions of DFC did not enforce this rule. DFC 5.3 throws a
ClassCastException if you cast a persistent object to a concrete class.
•
If your application code instantiates BOF objects, such as SBOs, the SBO public
interfaces must be visible to your client application. The jar file can be included in
your web application war file or in your system classpath
This applies to any BOF object that is directly used by an application and has a
custom interface.
Overview of BOF Migration Tasks
This section describe typical migration tasks for custom pre-5.3 BOF objects.
189
Figure 8-2. Migration Tasks for Custom BOF Objects
To migrate customized pre-5.3 BOF objects to BOF 5.3:
1.
Install or upgrade to Content Server 5.3.
BOF version 5.3 is included with Content Server 5.3. You can use version 5.2.x content
repositories with a 5.3 Content Server, however, the following requirements apply:
2.
•
If you have SBOs, you will need at least one 5.3 repository to serve as a global
registry.
•
If you have TBOs, each repository where you use the TBO must be upgraded to
version 5.3 if you want to be able to use BOF version 5.3 TBOs..
Install Documentum Application Builder (DAB) and Documentum Application
Installer (DAI) version 5.3 on a host machine connected to Content Server 5.3.
DAB 5.3 is required to redeploy BOF objects after you finish upgrading your
Documentum system to version 5.3.
3.
190
Upgrade all of your pre-5.3 BOF client applications to DFC version 5.3.
When you install a Documentum 5.3 client application, the installer will prompt
you to specify a repository as your global registry. Your choice will also apply to
subsequent DFC and BOF-based clients that use the same DFC instance, for example,
if you have multiple clients running on the same PC, then they will all use the
repository you specified the first time you ran the installer.
4.
Optionally, update your pre-5.3 BOF TBOs and SBOs to ensure future compatibility.
Existing TBOs and SBOs can be repackaged, unchanged, for this release of
Documentum, but as a best practice, we recommend that you update any
recently-deprecated items.
For more information about changes to TBOs, SBOs, and methods, see the DFC
Development Guide for Version 5.3.
5.
Repackage your pre-5.3 SBOs and TBOs as a DocApp using DAB 5.3, and deploy
them to your content repositories using DAI 5.3.
We recommend that you split each of your business objects into two jar files: one for
implementation, one for interfaces. Deploy the resulting DocApp as follows:
•
If you are deploying SBOs, deploy them to the repository you specified as your
global registry in Step 3.
•
If you are deploying TBOs, deploy them to each repository that uses that
particular type.
For more information about creating DocApps with DAB, see the DAB User Guide
for Version 5.3.
Post Migration Tasks
This release of BOF implements new security features in the BOF layer. However, old
client applications using versions of DFC earlier than 5.3 will not understand these
new security rules.
If you are running a mixed environment of DFC 5.2.x and 5.3, we recommend that you
set two new attributes on the repository configuration object to prevent older versions of
client applications from bypassing new security features.
These new attributes are:
•
check_client_version
The default value of this attribute is F. When this value is set to T, Content Server will
verify the version of a connecting client application against the client version you
specify for the oldest_client_version attribute.
•
oldest_client_version
Sets the lowest client application version allowed to connect to the repository.
191
For example, if check_client_version is set to T, and oldest_client_version is set to
5.2.5, Content Server limits the connecting client application to 5.2.5 or newer
versions, and will refuse to honor connection requests from client applications with
versions earlier than 5.2.5.
By default, Content Server 5.3 and the repository configuration object is set up to accept
connections from all versions of client applications, but if you want to restrict access to
the repository to client applications that are BOF-enabled (using DFC 5.3 and above),
use these attributes.
192
Chapter 9
Migrating to Web Publisher 5.3
This chapter provides information about upgrading from Web Publisher 5.2.x. The following topics
are discussed:
•
What’s New in Web Publisher?, page 193
•
The Web Publisher 5.3 Documentation Set, page 196
•
Web Publisher 5.3 Architecture, page 197
•
•
Migrating Customizations, page 200
•
Post-Migration Tasks, page 203
What’s New in Web Publisher?
This release of Web Publisher contains the following new features for the following areas:
•
Asynchronously publish
You can publish content synchronously or asynchronously using Site Caching
Services whenever content is promoted to the Staging or Active states—depending
on your SCS configuration.
•
Authoring enhancements
— Enhanced Web Publisher Editor
Rich text editing gives the user much more control over the formatting and layout
of the page they are creating. Also includes a Prompt for Comments feature.
— Enhanced versioning of saved content
— Better query capabilities in Web Publisher Editor
— Link management in <content> element. Web Publisher tracks the hyperlinks
and images that are pointing to the repository
— Deep folder import
193
— Intelligent check out (directory knowledge)
•
Contentless object support
Enables you to work with objects in the repository with no content attached.
•
Discussions
•
Drag and drop support for browsers
Internet Explorer users can drag items from their desktop to folders in the system as
well as drag items within the Web Publisher application.
•
Folder level Site Caching Services support
Enables you to publish a Web site from publishing folders in a repository to a Site
Caching Services target directory on a Web server.
•
Folder mapping enhancements
Support of attributes that have no value set, and ability to create multiple folder
maps.
•
Integration with Business Process Services (BPS)
Enables you to include non-repository users in the processing and review of content
using an external workflow.
•
Link management improvements:
— Notification of broken links
— Link management for expired content
— Link management on the content widget
— Location of linked content
•
Multi-repository support for:
— Search
Users can select the repositories included in advanced search.
— Inbox
A single inbox can now contain tasks from multiple repositories.
— Replica object support
Ability to add translation from a replica
— My Files
•
Search improvements:
— Speed
The speed of typical search has increased due to a new search algorithm that
concentrates on returning the first 100 rows quickly
194
— Data dictionary support
Search is now significantly easier to customize and configure.
— Smart List support
— Saved Search enhancements
— Cross Repository Search
Includes ECIS integration for searching external sources and search result
enhancements
•
User experience improvements:
— Interface enhancements such as user-selected columns, visible repositories,
version listing, drag and drop support, subscription notifications, credential
save, preferred rendition support, and layout improvements
— Collaboration features, such as discussion threads
New or Changed Methods
The Web Publisher 5.3 DocApp installs the following new or changed methods into
your repository.
The following existing methods were modified to run as Java methods:
•
wcmObjectBagMethod
•
wcmCreateTransformation
•
wcmLifecycleMonitor
The following methods are new in this release of Web Publisher:
•
wcmAddEdition
This is a new method added to support the Add_Edition_Job
•
wcmVersionInfo
For more information about these methods, see the Web Publisher Administration Guide.
New Jobs
The Web Publisher 5.3 DocApp installs the following new jobs into your repository:
•
Add_Edition_Job
195
New or Changed Relation Types
The Web Publisher 5.3 DocApp installs the following new relation types into your
repository:
•
wcm_category_link
•
wcm_taxonomy_link
•
wcm_native_edit
For detailed information about types and attributes in the Web Publisher object model,
see the Web Publisher Administration Guide.
Changes to Existing Features
This section describes any changes to the behavior of existing Web Publisher features
in version 5.3:
Advanced Content Widget
In Web Publisher 5.2.5 SP3, a user had the option of using either the advanced content
widget or the older content widget. In Web Publisher version 5.3, the advanced content
widget will always be used.
The Web Publisher 5.3 Documentation Set
The Web Publisher documentation set for the 5.3 release consists of the following:
196
•
•
Web Publisher Release Notes, version 5.3
•
Web Publisher User Guide, version 5.3
•
Web Publisher Administration Guide, version 5.3
•
Web Publisher Development Guide, version 5.3
•
FTP Services Release Notes, version 5.3
•
FTP Services Installation Guide, version 5.3
•
FTP Services Administration Guide, version 5.3
•
Site Caching Services™ Installation Guide, version 5.3
•
Site Caching Services Release Notes, version 5.3
•
Site Caching Services™ User Guide, version 5.3
Web Publisher 5.3 Architecture
Figure 9–1, page 197 shows a typical Web Publisher system, with application server, a
Content Server, and Web-based clients:
Figure 9-1. Typical 5.3 Web Publisher System Conguration
This section contains the following information:
•
Supported migration paths
•
Overview of major migration tasks with task flowchart
197
Supported Migration Paths
If you are currently using pre-5.2.5 versions of Web Publisher, you must first upgrade to
Web Publisher 5.2.5 (with any Service Pack) before upgrading to Web Publisher 5.3.
For detailed information about migrating from Web Publisher 4.x to 5.2.5, see Chapter
11,Migrating to Web Publisher 5, in the Documentum 5 System Migration Guide for version
5.2.5.
Overview of Migration Tasks for Web Publisher
This section describe typical migration tasks for Web Publisher.
Figure 9-2. Migration Tasks for Web Publisher
To migrate from Web Publisher 5.2.x to 5.3:
1.
198
Before beginning to upgrade, back up your data and any customizations you created.
2.
Optionally, upgrade to Content Server 5.3.
Though not required for this release of Web Publisher, we recommend upgrading
to the latest version of Content Server for future compatibility, and for access to
new Content Server 5.3 features.
For information about versions of Content Server are supported for this release of
Web Publisher, see the Requirements chapter in the Web Publisher Release Notes. For
step-by-step instructions on how to upgrade from a previous release of Content
Server, see the Content Server Installation Guide.
3.
Optionally, upgrade to Documentum Administrator 5.3.
to the latest version of Documentum Administrator for future compatibility, and
for access to new features in version 5.3.
For information about supported versions for this release of Web Publisher, see the
Requirements chapter in the Web Publisher Release Notes. For step-by-step instructions
on how to upgrade from a previous release of Documentum Administrator, see the
Web Development Kit and Applications Installation Guide.
4.
Optionally, upgrade to Site Caching Services 5.3.
to the latest version of Site Caching Services for future compatibility, and for access
to new features in version 5.3.
For step-by-step instructions for installing or upgrading Site Caching Services, see
the Site Caching Services Installation Guide.
5.
On your Content Server host machine, install the Web Publisher server components.
For detailed, step-by-step instructions, see the Web Development Kit and Applications
Installation Guide.
6.
For each Web Publisher repository, install the Web Publisher DocApp, and,
optionally, the Accelera DocApp.
The Web Publisher server files and Web Publisher DocApps are installed using
a separate installer called Documentum Web Publisher Server Files Installer. You
need to run this installer on the Content Server host machine and install the Web
Publisher DocApp in each of your Web Publisher repositories. If you have more than
one Web Publisher repostory, you must upgrade them all.
The Accelera DocApp contains a sample Web Publisher application. This sample
application has changed for the 5.3 release. If you already have the Accelera 5.2
DocApp installed, installing the 5.3 DocApp will replace some of the existing files
with updated files.
For detailed, step-by-step installation instructions, see the Web Development Kit and
Applications Installation Guide.
7.
Uninstall Web Publisher 5.2.x Web server components from the Web sever host
machine.
199
8.
If required, upgrade to a supported application server on your Web server host
machine.
Before you install Web Publisher 5.3 Web server components, you must install
a supported version of a J2EE application server. Application servers use Java
technology to extend a Web server’s capabilities to handle Web application requests.
The application server makes it possible for a Web server to generate a dynamic,
customized response to a client request. Documentum 5 Web products, such as
Web Publisher and Webtop, use application servers for increased performance and
flexibility.
For information about which J2EE application servers are supported with this release
of Web Publisher, see the Web Publisher Release Notes.
9.
Install Web Publisher 5 Web server components on your Web server host machine.
Web Publisher 5.3 can be installed on the same application server host machine
as WDK and Webtop, as long as you configure different port numbers for each
application.
For detailed instructions, see the Web Development Kit and Applications Installation
Guide.
10. Optionally, install and configure a Document Transformation Services station to
create on-demand PDF renditions of documents in your Docbase.
For detailed instructions, see the Document Transformation Services Installation Guide.
Migrating Customizations
The tasks described in this section are performed after you finish installing Web
Publisher 5.3.
To migrate Web Publisher customizations:
1.
Copy the folders containing your customizations from your 5.2.x Web Publisher
custom folders.
200
•
/custom/xml
•
/custom/string
Contains customized properties
•
/WEB-INF
— /WEB-INF/tld
— /WEB-INF/lib
Contains custom JAR files, if any.
2.
Test your customized Web Publisher application in its new Web Publisher 5.3
environment.
Most existing customizations to 5.2.5 features will still work. For example, the
following types of customizations are not affected by migration:
•
Web Publisher Editor customizations
•
Rules Editor customizations
•
eWebEditPro XML integrations
201
•
Web site administration customizations
•
Content editing customizations (for editors other than eWebEditPro)
•
In-context editing customizations
•
Any customizations to lifecycles
•
Any customizations to publishing
Because of significant changes to the WDK architecture that underlies Web Publisher,
we strongly recommend that you verify customizations made to any of the following
areas:
•
Any Web Publisher or WDK 4.x customized components are no longer
supported. If your Web Publisher 5.2.5 application uses these components, you
must migrate them to 5.3.
•
- Content Transfer applet customizations
The 5.2.5 content transfer model has changed in WDK-based applications for
version 5.3. We strongly recommend you migrate any existing content transfer
applets to use the new UCF (Unified Client Facilities) content transfer. For more
information about UCF content transfer, see Chapter 7, Migrating WDK-based
Applications.
•
Search customizations
If you customized the 5.2.5 search components (either search results or
advanced search) and want to use the new search features added in 5.3 (for
example, multi-Docbase search and increased performance), you will need to
re-implement on the new 5.3 search components.
•
Customized properties pages and other UI customizations
WDK 5.3 -based applications now have a completely redesigned user interface,
and existing customizations to the user interface may now appear less appealing.
You may want to adjust your UI customizations to make them appear consistent
with the new screen layouts and menus..
•
3.
Locators
If you want to replace customized features in your application with new 5.3 features,
create new Web Publisher customizations or extend WDK 5.3 components.
For detailed information about adding new features for WDK-based applications,
and deprecating 5.2.5 WDK custom components, see Chapter 7, Migrating
WDK-based Applications.
202
Post-Migration Tasks
This section describes any required or recommended tasks to perform after you complete
the installation or upgrade steps described in Overview of Migration Tasks for Web
Publisher, page 198.
Verify Custom Jobs
After completing the upgrade to Web Publisher 5.3, verify that any custom jobs, such as
workflow tasks that call custom methods, still work properly.
If you have a distributed environment, ensure that your methods and workflows are still
working properly.
203
204
Appendix A
Product and Terminology Name
Changes
This appendix provides a list of terms and product name changes.
Table A-1. Product and Terminology Name Changes
5.2.5 Name
New 5.3 Name
assemblies
snapshots; virtual document snapshots
breadcrumb
navigation path
Content Rendition Services
Now split into two products:
• Document Transformation Services
(DTS)
• Advanced Document Transformation
Services (ADTS)
Docbase
repository
DocBroker
Connection Broker
Media Services
Media Transformation Services (MTS)
205
Product and Terminology Name Changes
206
Appendix B
Documentum Clients Feature
Comparison
This appendix provides a side-by-side comparison of features in WorkSpace DocManager version
3.2.10, Intranet Client version 4.3, Documentum Desktop version 5.2.5, and Webtop version 5.3.
The information in this appendix is intended to help you make decisions about migrating to
Documentum 5 clients if you are currently using older versions of our client products.
Key:
5.3: New feature in Documentum 5.3
X: Supported feature
Table B-1. Documentum Client Functionality Matrix
Feature
Work- InSpace tranet
3.2.10 Client
4.3
Desk- Desk- Webtop 5.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Core Content Management Functions
Login/Logout
X
Connect to Multiple
repositories
Change Password
Choose Language (locale)
X
X
X
X
X
X
X
X
X
X
Save
Credentials
Save
X
X
X
X
X
Credentials
207
Feature
3.2.10 Client
4.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Create New File, Folder,
Cabinet
X
X
X
X
X
X
Import
X
X
X
X
X
X
Multi-File Import
X
X
X
X
X
X
X
X
Drag- DragandandDrop Drop
208
Multi-File
X
(Folder Selector on Import)
DragandDrop
Export
X
Multi-File Export
X
Check In / Check Out
X
Multi-File Check In / Check
Out
X
Check In from File
X
Cancel Check Out
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
View File
X
X
X
X
X
X
Multi-File View
X
X
X
Edit File
X
X
X
Multi-File Edit
X
X
X
View Checked-Out Files
X
X
X
X
Work
Area
CheckedCheckedLocal My
Out
Out
Files/ Files
Folder Folder Checked
Out
Folder
X
X
X
X
X
X
X
My Files
Feature
3.2.10 Client
4.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Move / Copy / Link
X
X
X
X
X
Multi-File Move / Copy / Link
X
X
X
X
X
Create/Check In/Check Out
of content-less objects
X
X
X
X
X
5.3
5.3
X
X
Create a Reference Object
(cross-repository link)
Check In/Check Out/View a
Reference Object
X
X
5.3
5.3
Check In/Check Out/View a
Replica
X
X
5.3
5.3
X
X
X
X
Delete
X
X
Multi-File Delete
X
X
X
X
View Locations
X
X
X
X
X
X
X
X
X
X
(Where Used)
Subscriptions
(Subscribe, Unsubscribe)
Category Browsing
View Document Summary
X
View Relationships
X
X
X
X
X
X
View
Relationships
View
(dm_relation)
Annotation Support
X
X
(List annotations associated
to a document)
Relationships
Version History
X
X
X
X
X
Inbox
X
X
X
X
X
209
Feature
3.2.10 Client
4.3
Unified Inbox
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
X
5.3
5.3
Send to Folder As Document
X
X
Send to Folder As Locator
X
X
Send to Email Recipient As
Document
X
X
Send to Email Recipient As
Locator
X
X
X
X
Access Control List (Permissions Set) Management
Creating a Document
Resource Locator (DRL)
X
X
X
X
Create ACLs
X
X
X
X
List ACLs
X
X
X
X
Delete ACLs
X
X
X
X
Assign ACLs
X
X
X
X
Modify ACLs
X
X
X
X
X
X
X
X
Where Used
Lifecycle Management
Apply
X
X
X
X
Detach
X
X
X
X
Suspend
X
X
X
X
Resume
X
X
X
X
Promote
X
X
X
X
Demote
X
X
X
X
Virtual Document Management
210
Convert to Virtual Document
X
X
X
X
X
Convert to Simple Document
X
X
X
X
X
Add Child
X
X
X
X
X
Feature
3.2.10 Client
4.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Remove Child
X
X
X
X
X
Reorder Children
X
X
X
X
X
Tree View
X
X
5.3
5.3
Set Binding Rules
X
X
X
5.3
5.3
Create Assembly
X
X
X
5.3
5.3
Freeze Assembly
X
X
X
5.3
5.3
Unfreeze Assembly
X
X
X
5.3
5.3
Publish
X
X
X
X
Property/
FullText
Property/
FullText
Property/FullText
X
X
X
X
5.3
5.3
X
5.3
5.3
X
Search
One-Box Search
Advanced Search
X
X
PowerPoint Search
Data Dictionary-Driven
Searches
Cross-Repository Search
X
Execute DQL Command
X
X
X
X
Save Searches As dm_query
Object
X
X
X
X
Save Searches As
dm_smartlist Object
X
X
5.3
5.3
X
X
Access to Saved
Searches—dm_query Object
Saved Saves
Searches
Searches Tab
Tab
211
Feature
3.2.10 Client
4.3
Access to Saved
Searches—dm_smartlist
Object
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
X
5.3
5.3
Smartlists
Link
on
Search
Dialog
"Show”
Pulldown
or
Tools
Menu
X
X
X
Execute Saved Searches Using
dm_query Object
X
Execute Saved Searches Using
dm_smartlist Object
X
X
X
5.3
5.3
X
X
X
X
X
X
X
X
X
Workflow Management
Start Workflow
Router
Object
Stop Workflow
X
Router
Object
Pause Workflow
X
My
My
Work- Workflows
flows
X
X
Router
Object
Resume Workflow
X
Router
Object
212
X
X
My
My
Work- Workflows
flows
X
X
X
X
My
My
Work- Workflows
flows
Feature
3.2.10 Client
4.3
Workflow Status
X
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
Router
Object
Workflow Template Creation
X
X
X
My
My
Work- Workflows
flows
X
X
X
X
X
X
X
X
X
X
X
5.3
5.3
X
X
X
Router WebTem- Workplate flow
Manager
Initiate Workflow Template
X
X
Router
Template
Workflow Availability
(Out-of-Office)
View Workflows using a
document version
Send to Distribution List
X
X
Quick- Quickflow
flow
Sequential Workflows
X
X
X
X
X
Serial Serial
QuickQuickflow
flow
Forward/Reject
X
X
X
X
X
Router Task
213
Feature
3.2.10 Client
4.3
Forward/Reject/Repeat/
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
X
X
X
Remove Attachment
X
X
X
X
Workflow Task Information
X
X
X
X
Workflow Task
Comments/Notes
X
X
X
X
Workflow History
X
X
X
X
Workflow Reporting:
Workflow Summary
X
X
X
Workflow Reporting:
Workflow Audit trails
X
X
Workflow Reporting: Save
Reports
X
X
Delegate Workflow Task
Workflow Reporting: Change
Performers
View Graphical Workflow
X
X
X
XML Management
Check In/Check Out
X
X
X
X
X
X
X
X
X
X
X
(Parent and/or Children)
Import
(Apply XML Category List)
Export
(Parent and/or Children)
Assign XML Stylesheet
X
Validate
X
Properties
Data Dictionary Support
214
X
X
Feature
3.2.10 Client
4.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Repository Attribute List
driven by data dictionary,
including categories
Primary Attribute Viewing
X
Secondary Attribute Viewing
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Mandatory Field Flag
Multi-Item Property Updates
X
Multi-Item Property Select
X
X
X
History (Audit Trails)
Register Event Notifications
X
X
Properties on Renditions
Renditions
View
X
Delete
X
X
X
X
Import
X
X
X
X
Export
X
X
X
X
Request to Render PDF
X
X
X
X
X
X
Default Rendition
X
X
Preferred Rendition
5.3
5.3
Multiple renditions of same
format Support
X
X
Request to Render HTML
X
X
Request to Render Media
Formats
Integrations
215
Feature
3.2.10 Client
4.3
Microsoft Office Integration
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
5.3
5.3
COM Word, Word, Excel,
add-in ExPowerpoint
cel,
Only / IE Only
Powerpoint
Only
/ IE
Only
Microsoft Outlook Integration
X
X
COM
add-in
Microsoft Outlook
Enhancements (save mail
/ attachments, find, workflow
features)
X
COM Add-In Customization
Support
X
Adobe Acrobat Exchange:
Annotations
216
X
X
X
X
X
Annodoc
Annodoc
Annodoc
Annodoc
or
or
or
DCTM
PDF
Annotation
Services
DCTM
PDF
Annotation
Services
or
DCTM PDF
DCTM Annotation
PDF
Services
Annotation
Services
Feature
3.2.10 Client
4.3
Adobe Acrobat Exchange:
Term-Hit Highlighting
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
Informative Graphics Brava!
Support
Offline Client
X
X
X
X
X
X
X
X
X
(Offline and Synchronization)
Views
Home Cabinet
X
X
Local Files
X
Checked Out Files
X
Thumbnail Viewing
X
X
MyFiles
X
(Checked out, recently
imported, recently updated
documents)
Recent
Documents
/
Checked
Out
Files
UI Features / Preferences
Section 508 Compliance
X
X
X
Unicode Support
X
X
X
X
X
Themes (Color Schemes)
Format Preferences
X
X
5.3
5.3
Column Sorting
X
X
X
X
217
Feature
3.2.10 Client
4.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Number of Items Listed
(Preference Setting)
X
X
X
Content Pane Filters
X
X
X
X
5.3
5.3
X
X
X
X
X
X
X
X
X
X
Subscriptions
Subscriptions
X
X
Column Display Settings
X
Display Order of New Tabs
Display Order of Custom
Properties
X
X
UI Tab to Start In (Inbox,
Myfiles, etc)
Add to Microsoft Favorites
X
Warning on Duplicate Names
X
Warning on opening
non-CURRENT document
X
Remove local copy on Check
In
X
View Options
X
X
X
X
(Check Out automatically on
viewing)
Virtual Document View
Options
Windows Explorer-like
Navigation Bar
Virtual Link Support
X
X
X
X
X
X
X
X
(URL to a document or folder)
Yahoo!- Like Navigation
218
X
Feature
3.2.10 Client
4.3
Mac Look-and-Feel
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
Clipboard
X
X
X
5.3
5.3
Cut /
Copy
/
Paste
/
Drag
&
Drop
Drag-and-Drop to & from
Desktop
X
Print and Save Window Text
X
X
X
X
Print File
X
Select All
X
X
(for
all
items
listed
on a
page)
Link Icon
X
Reference Icon
X
X
5.3
5.3
X
X
X
Developer/Administrator Features
API Message Tester
X
219
Feature
3.2.10 Client
4.3
DQL Query Editor
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Custom
Query
Screen
Show All Attributes
X
Role Support
Lightweight Administration
X
X
(User, Group, Security)
High Latency Configuration
Options
X
Desktop Component
Versioning (4.x vs. 5.2)
X
Desktop Dynamic
Component Delivery (all
users)
X
Support for Local Specific text
for Functionality Class
X
Support for Multi-Lingual
DocApps
X
Mutual compatibility of the
5.x and 4.x MenuSystem.ini
files in the same Repository.
X
Asynchronous Workflow Job
Support
Digital Asset Management
Powerpoint Assembly
220
Thumbnail Creation
X
Thumbnail Viewing
X
X
Feature
3.2.10 Client
4.3
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
Thumbnail Proxy View
Storyboards
Video Play from Frame
Media Transformation:
Automatic on Import
X
X
X
X
X
X
X
X
X
5.3
5.3
Cross-Repository Replica
Object Support
X
5.3
5.3
Cross-Repository MyFiles
X
Cross-Repository
Subscriptions
X
5.3
5.3
X
5.3
5.3
5.3
5.3
Media Transformation: On
Demand
Media Transformation:
Related Media
Video Streaming Support
Rendition Properties
Media Attributes: Automatic
Extraction
Media Attributes: Viewing
Default Rendition
Multiple Renditions of Same
Format
Multi-Repository Support
Cross-Repository Reference
Object Support
X
Unified Inbox
User Selectable Checkout
Directory
X
X
Search
221
Feature
3.2.10 Client
4.3
Cross-Repository Searches
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
5.3
5.3
Cross-Repository Search
Results Indicator (source
repository)
5.3
5.3
Optimized Query for Search
5.3
5.3
Data Dictionary based Search
5.3
5.3
"Or” option for Property
Search
5.3
5.3
X
5.3
5.3
(i.e. limit the return results)
User Defined Display
Columns
X
Execute Smartlists
X
X
X
5.3
5.3
Edit Saved Searches
X
X
X
5.3
5.3
Shared Saved Searches
X
X
X
5.3
5.3
Cancel Search Option
X
X
X
5.3
5.3
Create & Modify Binding
Rules
X
X
X
5.3
5.3
Hierarchical Display of
Virtual Documents
X
X
5.3
5.3
Create, View, Unfreeze
Assemblies
X
X
X
5.3
5.3
Virtual Document Copy
X
X
X
5.3
5.3
Virtual Document Manager
Renditions
222
Feature
3.2.10 Client
4.3
Preferred Rendition Support
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
5.3
5.3
5.3
5.3
5.3
5.3
5.3
5.3
5.3
5.3
(View / Edit Application)
Streaming Support
(User Preference)
Forms Data Format (FDF)
Support for Create/View
UI Enhancement
User Selected Columns
(Search, Folders, MyFiles,
Subscriptions, Inbox)
X
X
Docbase Visibility
User Preference
(preferred repositories)
Show All Versions
X
X
5.3
5.3
Add Version Label & Number
to Display Listing
X
X
5.3
5.3
5.3
5.3
5.3
5.3
Edit Version Label on
Properties Screen
Display Icons (Replicas,
Reference Objects, Links,
Subscriptions)
Collapse / Expand Navigation
Tree (Classic View)
X
5.3
223
Feature
3.2.10 Client
4.3
Drag-and-Drop
X
top
top
Clas- Streamline
for
5.2.5
sic
View
MacView
intosh
5.1
X
5.3
5.3
(external and internal to
Webtop)
(In(Internet
terExplorer only)
net
Explorer
only)
MyFiles Enhancement
(Expiration Preference)
5.3
5.3
MyFiles Enhancement
5.3
5.3
(Keep files on list modified by
another user)
Subscription Notification on
Check-in
X
5.3
5.3
Subscription Notification
Toggle (on a per-item basis)
X
5.3
5.3
X
5.3
5.3
Silent Login Across
Repositories
224
X
Index
A
C
ACL entries
described, 43
ACLs
described, 43
kinds of, 44
template, 45
actions
version, 123
Apache Tomcat
index agent, 70
app.xml, 126
Application Builder, 16
Application Installer
described, 16
application servers
described, 200
AutoRender Pro
renamed to Document Transformation
Services, 200
cabinets
permissions, 41
capability
consumer, 23
contributor, 23
coordinator, 23
check in
editing documents, 34 to 35
check_client_version attribute, 191
checkout
defined, 33
location, 25
child documents, 31
Chinese grammatical normalization, 72
ClassCastException, 189
client application roles
domain group, 22
supporting groups, 22
client/server, 19
COM (Microsoft component object
model), 18
components
of virtual documents, 30
version, 123
connecting, 33
connection brokers
defined, 23
See also brokers
consumer, 23
content
in repository, 23
Content Rendition Services
renamed to Document Transformation
Services, 200
content repositories
security, 41
Content Server, 33
and RDBMS, 14
backward compatibility, 52
B
backward compatibility
client applications, 52
Content Server, 52
for WDK 4.2 custom applications, 60
for WDK 5.2.x custom applications, 60
if RPS is enabled, 57
RPS, 52
BOF
relationship to WDK, 18
SBO new features, 187
TBO new features, 187
brokers, 23
Business Object Framework, see BOF
business object framework global
repository, 58
225
Index
described, 14
repository, 14
role in full-text indexing, 69
content transfer
applets, 123
described, 124
specified in the WDK application
configuration file, 126
UCF, 124
zero-footprint, 124
contributor, 23
coordinator, 23
copying
documents, 35
objects, 41
permissions required, 41
Create Cabinet privileges, 39
Create Group privileges, 39
Create Type privileges, 39
creating
cabinets, 39
documents, 34
folders, 36
groups, 39
objects, 41
types, 39
customization analysis worksheet, 66
D
deleting
assemblies, 36
documents, 35
links, 36
objects, 41 to 42
unused versions, 36
descendants, 31
DFC
casting persistent objects to concrete
classes, 189
relationship to WDK, 18
disk space requirements, index server, 73
dm_acl object type, 43
DocApps
packaging for deployment, 16
Docbases
creating documents, 34
document lifecycles
226
overview, 26
See also lifecycles
document repository, 19
Document Transformation Services
described, 200
documents
check in, 34 to 35
checkout, 33
copying, 35
creating, 34 to 35
deleting, 35
editing, 35
formats, 34
importing, 41
in Documentum system, 34
local, 25
locations, 35
locking, 33
moving, 35
organizing, 36
saving, 34 to 35
templates, 34
versions
described, 28
virtual, 30
Documentum 5, 33
described, 15
Documentum Desktop
accessing Docbases, 20
capabilities, 19
document management, 19
feature comparison, 207
Integrations, 19 to 20
networks, 19
personal computers, 19
repositories, 19
servers, 19
Documentum Foundation Classes, see
DFC
domain groups, 22
domains, 33
E
ECIS
described, 15
editing
documents, 35
Index
Enterprise Content Integration Services,
see ECIS
external ACLs, 44
external applications
client application roles, 22
F
federated repositories, 24
files
local, 25
folder security, 41
folders
creating, 36
primary, 41
security, 41
foreign object, 143
full-text indexing
best practices, 83
Content Server, role in, 69
grammatical normalization, 72
hardware decisions, 73
index agent, 81
index agent, role in, 70
index server, 82
index server, role in, 71
installation order for a new
repository, 74
installation order for a post-upgrade
migration, 78
installation order for pre-upgrade
migration, 76
Microsoft cluster services, 70
migration, 74
new repository, 73
planning, 69, 75
post-upgrade migration, 75
pre-upgrade migration, 75
recommended installation
configuration, 81
required ports for index agent, 72
required ports for index server, 72
supported configurations, 71
Verity, 74
G
global registry
described, 58
when required, 59
global repository, business object
framework, 58
grammatical normalization, 72
groups
described, 22
role, 22
standard, 22
H
home cabinets, 24
HTTP-based content transfer, 124
I
importing documents;, 41
index agent, 81
described, 70
file mode, 70
installation options, 70
migration mode, 70
modes, 70
normal mode, 70
required ports, 72
index server, 82
configuration options, 71
described, 71
disk space requirements, 73
required ports, 72
installation order
new repositories, 74
upgraded repositories, 76
installing Content Server
full-text indexing, 69
Integration
accessing Docbases, 20
application, 19
Integrations
functions available, 20
internal ACLs, 44
Intranet Client
migrating, 51
J
Japanese grammatical normalization, 72
Java language, 17
227
Index
L
lifecycles
overview, 26
See also document lifecycles
linking
objects, 41
primary folder, 41
local files, 25
location objects
fulltext indexes, 107
locking documents, 34
logging in, 33
M
metadata, see properties
Microsoft cluster services
migration
defined, 47
mirror object, 143
moving
documents, 35
objects, 41
ports
index agent, 72
index server, 72
post-upgrade migration
described, 75
pre-upgrade migration
described, 75
preinstallation requirements
index agent, 72
index server, 72 to 73
primary folder, 41
private ACLs, 44
private groups, 22
properties
described, 36
in repository, 23
public ACLs, 44
public groups, 22
Q
queues
tasks, 27
See also work queues
R
O
object permissions, 40
objects, 23 to 24
basic tasks for, 34
described, 34
properties, 36
type, 24
oldest_client_version attribute, 191
organizing documents, 36
P
padlock icon, 34
parent documents, 31
permissions, 27
cabinets, 41
deleting objects, 42
folder, 41
object, 40
object owner, 40
sets, 40
personal computer, 19
228
RDBMS, 14
reference object, 143
replica object, 143
repositories
business object framework global
repository, 58
defined, 24
federated, 24
full-text indexing installation
order, 78
full-text indexing installation order in
new, 74
full-text indexing installation order in
upgrades, 76
indexing in new, 73
large, 75
logging in, 33
overview, 23
small, 75
upgrading large, 75
upgrading small, 75
repository
Index
connecting to, 20
described, 14
Documentum Desktop, 19
objects, 34
repository configuration object
check_client_version attribute, 191
oldest_client_version attribute, 191
repostories
creating documents, 34
Retention Policy Services, see RPS
role groups, 22
root document
in virtual documents, 31
RPS
backward compatibility, 52, 57
S
saving
documents, 34 to 35
SBO
described, 58
migration requirement, 190
where deployed, 191
security
folder, 41
server, 19
Service-based business objects, see SBO
service-based object (SBO), see SBO
SmartSpace, 19
standard groups, 22
Superuser privileges, 39 to 40
system ACLs, 44
System Administrator privileges, 39
system administrators, 41
T
TBO
described, 58
migration requirement, 190
where deployed, 191
template ACLs, 45
timeouts
index update operations, 108
Trusted Content Services
ACLs and, 44
type libraries, 18
Type-based business objects, see TBO
type-based object (TBO), see TBO
U
upgrading
all-or-nothing, 61
upgrading Content Server
installation order, post-upgrade
migration, 78
installation order, pre-upgrade
migration, 76
large repositories, 75
post-upgrade index migration, 75, 77
pre-upgrade index migration, 75
repository copies, 75
small repositories, 75
Verity customizations, 74
users
described, 21
V
Verity
customizations, 74
version
components and actions, 123
version labels, 24
versions, 24
deleting, 42
documents, 28
Virtual Document Manager, 30
virtual documents, 30
children, 31
descendants, 31
parents, 31
root document, 31
uses for, 31
W
WDK
application, 20
backward compatibility, 60
described, 18
WDK application configuration file
app.xml, 126
contentxfer elements, 126
Web Publisher
application servers, 200
Webtop
229
Index
Windows Explorer
file management, 19
Work Queue Management, 27
work queues
Doc Profiles, 27
management node, 27
overview, 27
workflow templates, 26
workflows, 26
WorkSpace
230
customization analysis worksheet, 66
WorkSpace DocManager, 49
migrating, 51
WSServer.dll, 49
X
XML documents
as virtual documents, 31
© 2011 - 2013 EMC Corporation. All Rights Reserved.
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.
EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United State and other
countries.
All other trademarks used herein are the property of their respective owners.

Documentum 5.3 System Migration Guide

Transcription

Similar documents

On this date in history: Aug. 13 MEET THE TEAM

April 20, 1995 - The Repository

Reveille™ RealTime for EMC® Documentum

Notes on shippo

PDF (Author`s version) - OATAO (Open Archive Toulouse Archive

Correspondence to Roger J. Traynor and Daniel Paul Regarding

Migrating SafeConsole from 4.7 to 5.0