WCM Deployment Guide

Deploying Documentum Web
Content Management
Copyright © 1994-2004 Documentum, a division of EMC. All Rights Reserved.
DOCUMENTUM, NOW YOU KNOW, UNITING THE WORLD THROUGH CONTENT and the Corporate Logo are trademarks or registered
trademarks of Documentum, a division of EMC, in the United States and throughout the world. All other company and product names are used
for identification purposes only and may be trademarks of their respective owners.
Table of Contents
Preface .......................................................................................................................... 7
Chapter 1 Overview ............................................................................................... 11

What to Deploy .......................................................................................... 11
Methods of Deployment ............................................................................. 12
DocApp ................................................................................................. 12
Dump and Load ..................................................................................... 13
Choice of Tools ........................................................................................... 13
Using FTP Services ................................................................................. 13
Using DocApps ...................................................................................... 14
Contacting Documentum ............................................................................ 15
Chapter 2 Deploying WCM Repository Components Using DocApp ..................... 17

Preparing to Archive the DocApp ................................................................ 19
ACLs ..................................................................................................... 23
Archiving the DocApp ................................................................................ 24
Checking the DocApp Archive .................................................................... 25
Preparing the Target repository for Install .................................................... 26
Installing the DocApp Archive .................................................................... 26
Server Scripts ......................................................................................... 26
Users ..................................................................................................... 26
Custom Region Configurations................................................................ 26
Check the Install Log .............................................................................. 27
Checking the DocApp Archive Installation ................................................... 28
Enable Workflows .................................................................................. 29
Publishing Configurations....................................................................... 29
Web Publisher Configurations ................................................................. 30
User Interface Customizations ................................................................. 30
Testing ................................................................................................... 30
Chapter 3 Deploying WCM repository Components Using Dump and

Load ...................................................................................................... 31
Creating a Dump File .................................................................................. 31
Creating a Load File.................................................................................... 36
Rolling Back Your Target repository ............................................................. 38
Chapter 4 Troubleshooting .................................................................................... 39

Check the Documentum Application Installer Install Log .............................. 39
Deploying Documentum Web Content Management 3

Table of Contents
List of Figures
Figure 3–1. Sample Dump Script ....................................................................................... 32

Figure 3–2. Sample Load Script ......................................................................................... 37
4 Deploying Documentum Web Content Management

Table of Contents
List of Tables
Table 2–1. DocApp Installation Options ........................................................................... 18

Table of Contents

Preface
Purpose of this Guide

This guide describes how to move your Web Content Management (WCM) repository
components from one repository, usually testing, to another repository, usually
production. It describes what you should do before, during and after a deployment.
Intended Audience
This guide is primarily intended for system integrators and Documentum administrators
who customize and deploy Web Publisher.
Revision History
Development Guide Revision History
Revision Date Description

October, 2002 Initial Document Release
November, 2004 Updated product names, directory paths,
and dump and load scripts.
Application Knowledge
This guide assumes you have experience working with the following Documentum
applications version 5.2.5 or later:
• Web Publisher
• Documentum Application Installer (DAI)
• Site Caching Services
• Documentum Application Builder (DAB)
• Documentum Administrator

Preface
Organization
This guide contains six chapters and one appendix. The table below lists the information
that you can expect to find in each.
Chapter Contents
Chapter 1, Overview Discusses pre-planning tasks to
complete before you deploy from one
repository to another repository.
Chapter 2, Deploying WCM Repository Discusses preparing your target and
Components Using DocApp source repository, and provides steps to
deploy content using DocApps.
Chapter 3, Deploying WCM repository Discusses creating a dump file and a
Components Using Dump and Load load file and running both dump and
load scripts to deploy content.
Chapter 4, Troubleshooting Discusses problems you may have
encountered during your DocApp
installation or dump and load, and
provides solutions or workarounds.
Conventions
This manual uses the following conventions:
Convention Description
→ Represents a flow from one user interface (pop-up or
pull-down menu) item to another.
italic Represents a variable name for which you must provide
a value, or a defined term.
typewriter Represents code samples, user input, and computer output.
bold Represents all user interface (pop-up or pull-down menu)
items.
Related Documentation
The following lists other Documentum documentation you should be familiar with
before attempting to deploy Web Content Management (WCM) repository components.
• The Web Publisher documentation set; Web Publisher User Guide, Web Publisher
Administration Guide, Web Publisher Development Guide, and the Web Development Kit
Applications Installation Guide.

Preface
• Documentum Application Builder User Guide describes the concepts and general
strategies for packaging some customizations into a DocApp, deploying the DocApp
to a repository, and using Application Builder.
• Documentum Administrator User Guide describes how to use Documentum
Administrator.
• Docbasic Reference Manual helps application developers create Docbasic procedures.
• Content Server Administrator’s Guide provides information, instructions, and
procedures for the normal system administration tasks of a Documentum
installation. It also describes connection brokers, full-text indexing administration,
managing content storage areas, and repository security.
• FTP Services Administration Guide provides information on configuring FTP Services,
configuring third-party clients, such as Dreamweaver, and transferring files and Web
sites through FTP Services using clients.

Preface

Chapter 1
Overview
This document describes the process of deploying Web Publisher content from one repository
to another repository using a DocApp or dump and load. The deployment information in this
guide is based on successful deployments performed by Documentum Professional Services and
Documentum’s internal documentum.com team.
There are different reasons to deploy. Deployments can be carried out with upgrades to take
advantage of new functionality or with site growth to deal with scalability issues. As your site grows,
your hardware and infrastructure need to grow in support so you might need to move your WCM
application to different hardware. You may also need to deploy because you are moving a test area
to a production area.
To smooth your deployment from one repository to another repository Documentum has created a
list of pointers.
• Consider what to deploy
Deploying concerns everything from custom types in DocApps to the systems on which you
run your deployment.
• Determine your method of deployment
Are you going to use a DocApp or dump and load? Using a DocApp to deploy your content
enables you to selectively move content based on location, and ensures the movement of
necessary and related files. Using dump and load to deploy your content enables you to move
the entire repository.
• Choose the correct tool
Depending on the type of deployment your are planning you may need to use FTP Services, a
DocApp with Documentum Application Installer and Application Builder.
• Consult Documentum experts
As with any move, it is easier to work from experience. Documentum Professional Services, a
Documentum SI or someone familiar with deployments can help to ease the transition.
What to Deploy
Before you deploy you should be aware of all the items to be deployed including custom
items. Some items may need a special deployment path while other items may deploy
directly through dump and load or a DocApp. Following is a list of items that need to
be deployed:

Overview
• Object Types (Both Web Publisher object types and custom object types)
• Workflow templates
• Permission Set templates
• Alias sets
• Lifecycles
• Jobs
• Groups
• Site Cabinets (Web Publisher Configuration)
— content templates
— supporting templates and files
— locales (if working with global deployments)
• Web cabinets (Web site content)
• Change Sets
• Server methods
• Custom procedures and scripts
• Customizations to the user interface
• Site Caching Services pre- and post-synchronization scripts
Methods of Deployment
This document describes a deployment using DocApp or dump and load. Deploying
repository content is rarely a cut and dried process. Often, deployments of enterprise
systems require a combination of approaches.
DocApp
Using a DocApp to deploy your content enables you to selectively move content based on
location, and ensures the movement of necessary and related files. DocApp is preferred
when you are deploying WCM applications because often only a portion of the repository
needs to be deployed. DocApps are used to deploy objects within a repository from one
repository to another, and by definition, do not handle items outside a repository.
Common types of items outside a repository include:
• WDK application customization files for example; definition files, JSP pages, and
externalized strings
• Site Caching Services target pre- and post-synchronized scripts
Note: Publishing configurations should not be deployed, but should be manually
recreated in the target repository through Documentum Administrator to match the
source repository.

Overview
Dump and Load

Dump and load is one of the most basic methods of deploying content from one
repository to another. It is used when you want to deploy an entire repository.
Documentum recommends you only perform the dump and load procedure once on
a clean repository.
The dump and load modifies the target repository and may include the following:
• Content templates with the correct WCM relationship types maintained between the
Editor rules file, presentation file, thumbnail file, and content
• Web cabinet content with correct lifecycle states
• Web Publisher application for example, default DocApp (type dm_application) or
custom DocApp
• Custom applications for example, custom lifecycles, workflows, object types
• Object type instances for example, change set in correct lifecycle state
Choice of Tools
Whether you are upgrading an existing deployment or creating a new deployment,
once you set up your infrastructure you can deploy your Web site content from a test
repository to a production repository. Your choice of deployment tool will depend on
the type of information you are deploying.
For the initial bulk deployment of Web site content from a file system into a repository
this example uses FTP Services. For deployment of repository objects and content this
example uses a DocApp which uses more robust tools such as Application Builder and
Documentum Application Installer.
Using FTP Services

For Web sites existing outside a Documentum repository you must first create your
Web Publisher Web cabinet in a clean repository then use FTP Services to perform
a bulk import.
When working with certain client applications, FTP Services lets you import an entire
Web site into a repository all at once, in one drag-and-drop action. For example, when
working with Macromedia Dreamweaver, you can import an entire directory structure
(folders and files) with one drag-and-drop action, instead of having to do so file-by-file.
FTP Services configuration files are used to set up rules to govern your import.
Configuration files are found in the folder containing the FTP Services installation. They
include the following:
• ftpConfig.xml. Assigns dm_document subtypes and other properties to files being
copied into repository.
• WebPublisherDocType.conf. Assigns a default dm_document subtype to files that do
not fit the criteria in ftpConfig.xml and that therefore do not get assigned a subtype.

Overview
If you do not configure this file, FTP Services assigns files to the dm_document
object type.
• FTPServer.conf. Sets session parameters and other parameters.
• FileFormatType.conf. Maps file extensions to Documentum Content Server format
types.
Configuration file rules can determine that files copied from a certain directory be given
a certain custom object type upon import into a repository. For example, a custom type
called webdoc, could be assigned to most of your content (html, asp, jsp). A subtype
of webdoc, webdoc_image could be assigned to all of your image files with attributes
customized for the image.
Please refer to FTP Services Administration Guide for information on configuring FTP
Services, configuring third-party clients, such as Dreamweaver, and transferring files
and Web sites through FTP Services using clients.
Once you import a Web site into FTP Services authors can use Dreamweaver or Homesite
to edit existing content. Authors can also use Web Publisher supported in-context
editing to locate content files on a published Web site by navigating the live, staging, or
in-progress version of the site. When authors navigate to the page by browsing the site,
they can then edit the page from a button on the interface. Web Publisher 5.x extends
content editing using an eWebEditPro integration which enables web-based WYSIWYG
editing of HTML-based Web pages.
Depending on your content language you may want to migrate your content to work
with XML/XSL templates or HTML/XML templates to take advantage of Web Publisher
Editor. If your Web site contains a lot of content, you may want to create scripts to
associate the existing content with XML/XSL template files. If you ultimately want to
edit your existing content in the Web Publisher Editor, you must first create XML/XSL
templates for your content and slowly introduce them to your user community.
Eventually, existing content that is edited using an HTML editor will be replaced with
content that is edited using Web Publisher Editor.
Your content must be well formed XML to work with Web Publisher so you may want
to run your content through an XML data validation tool like XML TIDY. XML TIDY
can be accessed from the Web.
Using DocApps
Upgrading existing environments or moving test environments to production
environments involves more than moving content. If you already have a
Documentum-based WCM environment in place you probably have objects, workflows,
lifecycles, groups, users, ACLs, cabinets and folders all of which must be deployed.
Documentum Application Builder and Documentum Application Installer can package
your content, maintain the relationships, and do the deployment for you.
You create a custom DocApp using Documentum Application Builder which acts as a
container for your source WCM content. You then copy the your custom DocApp using
Documentum Application Installer to your target repository.

Overview
Contacting Documentum
Customers with a software support agreement can access the support area of
www.documentum.com.
Customers without a software support agreement can access the support area by
following the links to request a user name and password. Documentum responds to
access requests within two business days. Once you have a user name and password,
you can access the support area without delay.

Overview

Chapter 2
Deploying WCM Repository
Components Using DocApp
This chapter explains how to deploy WCM repository components using DocApps.
If you want to easily deploy selective content from one location to the next you can create a DocApp
archive and install that DocApp archive to a repository.
Caution: The DocApp that you are preparing to deploy should be your own custom DocApp. You
should never modify the default Web Publisher DocApp. Your custom DocApp should include the
Web Publisher DocApp objects and any custom object types, workflows or lifecycles.
Before you deploy your WCM content using DocApps you should be aware of any critical deployment
issues. Following is a list of issues that you should consider.
• Configuration
Each object’s configurations must be set properly in the source repository before archiving. To
set these configurations, checkout your custom DocApp in Application Builder, and select
DocApp→Set Installation Options. The proper settings are crucial for a successful deployment.
See Documentum Application Builder User Guide for detailed instructions on configuring your
installation options.
• Creation and Modify Dates
The creation and modify dates of objects included in the DocApp archive will not retain the
original dates from the source repository. The dates will be reset to the date of the DocApp
Archive installation to the target repository.
• Object Names
Objects deployed through a DocApp do not remember where they came from (as replicated
objects do), and therefore rely on criteria when installing. Documentum Application Installer
uses two main pieces of criteria to determine if an object already exists in the target repository
and whether to overwrite, version or do nothing to any object. These two pieces of main criteria
for dm_document or its subtypes are object name and locale.
When an archive object is to be installed, Documentum Application Installer uses different criteria
to determine if the object already exists in the target repository and whether to overwrite, version,
or do nothing. Depending on the object type, different criteria might be considered.
Following are two examples of criteria used to determine of any object exists in a target repository.

Deploying WCM Repository Components Using DocApp
Example 2–1. object type criteria

You include a lifecycle (dm_policy) object named Test_Lifecycle in the DocApp. You set a
location alias to the repository path /Test/MyLifecycle. The Documentum Application Installer
checks to see if the target repository has a dm_policy object named Test_Lifecycle in the folder
/Test/MyLifecycle. If the same dm_policy object is found, then Documentum Application Installer
checks the Installation Options settings in the DocApp to see if version, overwrite, or ignore
is checked, and acts appropriately.
Example 2–2. other criteria

You have a document named index.htm (version 1.0) whose locale is set to French (fr_FR) in the
target repository. index.htm is located under the cabinet MySite.com. You have included the
index.htm document in your DocApp archive. Following are the configuration settings in the
DocApp that you should set on index.htm:
Table 2-1. DocApp Installation Options
DocApp Installation Options Target Repository State After DocApp

Install
version Version to next minor version.
overwrite Overwrite with the new content from the
source, version remains same.
do not overwrite (do nothing) If the object already exists in the target
repository then the object will not be
modified. If the object does not already
exist in the target repository at the same
location then a new object will be created
in the target repository.
If you are re-deploying objects to a repository and you change the source object’s name but not
the target object’s name Documentum Application Installer creates a new, duplicate object in
the target repository. If you are upgrading from a previous deployment you would want any
existing objects to be versioned not renamed so you need to ensure that object names are identical
from deployment to deployment.
Object name changes are less of an issue if you are deploying to a clean target repository because
there are no existing objects, and more of an issue for incremental deployments because you may
have existing objects with the same names as objects you are newly deploying.
Exercise caution when changing object names that are, or will be, included in a DocApp.
• Deleted Objects
Archiving may fail if there is a reference to an object that no longer exists in the source repository.
For example, if a server method referenced by a workflow template is deleted, the DocApp
archive operation will fail when it processes that workflow template and the operation will be
unable to resolve the method reference. Likewise, if a group referenced by a workflow task
is deleted, then archiving errors will occur.
Documentum strongly discourages you from deleting groups or users from a repository, because
of the possibility of dangling references.
• Groups, Permission Set Templates and ACLs

While group objects and Permission Set Templates (ACL templates) can be included in a DocApp
and deployed to a target repository, ACLs such as the Web Publisher User Default ACL cannot.
If you want to deploy ACLs from the source repository to the target repository the source
ACLs must exist when you install to the target repository. Be sure you create ACLs or have the
pre-installation procedure create them before you install to the target repository.
Caution: The pre-installation procedure will only create valid ACLs if referenced user and group
entries already exist in the repository. Therefore, it may be unnecessary to include custom groups
in the DocApp, since they must already exist at the time of installation.
Please refer to Developing DocApps for more information on ACLs and the pre-installation
procedure.
• WCM Dependencies
Application Builder is a general use, application-independent Documentum product. DAB
handles objects the same way for all Documentum applications. For example, if workflow
templates are included in a DocApp, then they will be deployed into the target repository even
though they are unusable until an administrator performs the Web Publisher-specific task of
making them accessible to Web Publisher.
Similarly, DAB would have no way of knowing that content objects may require Web Publisher
content templates, Editor rules file or Editor presentation files. If you do not include those
supporting templates (or their folders) explicitly in the DocApp, then DAB will not automatically
include them in the DocApp archive.
• Testing
Incorrect DocApp configurations can cause serious and irreparable damage to a target repository.
Documentum strongly recommends you test your DocApp installation on a clean test repository
before installing on a production (target) repository.
Once you have evaluated your deployment issues you can begin your deployment.
Refer to Documentum Application Installer Installation and Release Notes, and Documentum Application
Builder User Guide for more information on the steps discussed in the following sections.
Preparing to Archive the DocApp

Before archiving your DocApp, you must configure your source and target repositories
to correctly archive and import WCM repository components. You use Documentum
Application Builder (DAB) to configure installation options on your source repository,
and perform pre-installation tasks, set correct lifecycle states and install correct server
scripts in the target repository.
The installation options on your source repository must,
• control whether duplicate objects are versioned, overwritten, or ignored
• control whether data objects (cabinets, folders, documents) within cabinets and
folders are installed
• assign specific permission sets, locations, or owner aliases to sysobjects or use the
defaults

• run pre- and post-installation procedures

You can use pre- and post-installation procedures to create repository users,
groups, cabinets, and folders if required, or you can create them manually using
Documentum Administrator before you install the DocApp
The installation tasks on your target repository must at least create the operating system
users that correspond to the source repository users (or user aliases in your DocApp)
that manipulate the documents in your DocApp.
For more information about repository administration and using Documentum
Administrator, see Content Server Administrator’s Guide and Documentum Administrator
Installation and Release Notes.
To prepare your target repository:
1. Check the target repository to ensure that the Web Publisher DocApp has been
installed.
2. Using DAB, open the Web Publisher DocApp and set all of the states to Allow
attachment directly to this state for all existing lifecycles in the target repository.
3. Ensure that all lifecycles in the target repository are validated and installed before
your DocApp installation.
4. Ensure that all server scripts are copied to the server bin directory before your
DocApp installation.
Note: When the instructions do not ask you to specify a value for a field or whether to
select an option, accept the default.
To prepare your source repository:
1. Using Documentum Application Builder (DAB), open your custom DocApp and set
all default WCM objects to do not overwrite.
You will include all default Web Publisher object types, lifecycles, workflow
templates, procedures, jobs, alias sets, server methods, and permission set templates
into your new DocApp.
a. Open DAB, and log in using your username and password.
b. Click Open existing DocApp from repository.
c. Browse for your custom DocApp and click Open.
Your custom DocApp opens in DAB.
d. Select each default WCM object individually.
e. Choose DocApp→Set Installation Options.
f. In the Upgrade options section, check Do not overwrite; leave target object[s]
alone.
g. In the Location Alias section type,
/System/Applications/WebPublisher
You do not need to set a location alias for every default object. You can leave this
field blank for server methods and alias sets.

Setting upgrade options ensures that the archive process succeeds and prevents
the DocApp installation from making duplicates of existing objects in the target
repository. However, if you have customized any WCM objects, you should set these
items to, ’overwrite’ so you do not lose your customizations.
2. Using DAB, set the following objects to overwrite.
a. Select Web Publisher standard object.
b. Select Web Publisher content files and templates, including custom document
types.
If Web Publisher content objects are included in a DocApp the dm_relation
objects between objects are deployed only if both parent and child objects are
included in a DocApp. Web Publisher content objects include content templates,
Editor Rules files, Editor presentation files, thumbnail files and those objects that
have been created through the template process.
c. Select XML applications used to extract attributes from Web Publisher Editor
or for XML files included in the XML applications.
d. Select custom region configuration (locales).
e. Choose DocApp→Set Installation Options.
f. In the Upgrade options section, check Overwrite in the target repository for
each selected item.
If your WCM deployment is a global one, and you are migrating custom locale
settings, you will only have custom region configurations.
Note: You must manually copy any custom region configurations (XML files)
from the source repository to the target repository in the same location prior to
installation of the DocApp to the target.
3. Include any pre- or post-processing procedures defined in the installation options
for example, localization workflow assignments, and user creation scripts. Include
all standard procedures and set all standard procedures to overwrite or do not
overwrite depending on whether or not you have custom procedures you want to
keep or default procedures you want to overwrite.
a. Include all standard procedures from the DocApp /System/Application/
WebPublisher folder.
b. If you have customized any procedures choose DocApp→Set Installation
Options.
c. In the Upgrade options section, check Overwrite in the target repository.
d. If the procedures are called by any lifecycle state for example, promote, or
custom, in the Upgrade options section check, Do not overwrite; leave target
object(s) alone.
e. If an activity in a workflow calls Inter–Enterprise Workflow Server, in the
Upgrade options section check, Do not overwrite; leave target object(s) alone.
4. Choose DocApp→Set Installation Options and set all lifecycle states to Allow
attachment directly to this state for all lifecycles included in the DocApp.

This setting associates included content with the appropriate lifecycles and lifecycle
states when content is installed to the target repository.
5. Install all lifecycles included in the DocApp.
Be sure to check the installation options for each lifecycle being deployed for the
following:
• Use an alias for Web Publisher User Default ACL
• Create or reuse an existing location alias,
• If desired, define a specific Owner Alias for the lifecycle
6. Include all object types and associated lifecycles for all Data Objects included in
the DocApp.
Object types include any sub-types added to the Acceptable SubTypes list in DAB.
If you do not include all object types, the archive process may fail to properly archive
the objects, and the install process may not properly associate content to correct
lifecycles.
7. Include all action and post-change procedures of all lifecycles included in the
DocApp.
You should also include the standard Web Publisher procedures such as
WCMLifecycleScript, which is referenced by the standard Web Publisher lifecycles.
8. If using alias sets, include the following parts when creating your DocApp.
• standard wpgroups alias set
• all alias sets referenced by lifecycles, set to overwrite
• TranslatorEmailAddress alias set if configuring for engagement services
translations, set to overwrite (applies to Globalization deployments with
Engagement Services only)
• Identify any group dependencies from alias sets
9. Include any custom Web Publisher jobs and methods in your DocApp.
If a job references a method, which they generally do, then the method must also
be deployed. If the method is not deployed the job will run in the target repository
without a method causing the job to error out.
10. Ensure that all workflow templates that have been included in the DocApp are
installed.
Uninstalled workflow templates will be deployed to the target repository but will
be in the uninstalled state. Uninstalled workflows will not display in the list of
available workflows in the user interface. You must manually install uninstalled
workflows to make them usable.
11. Complete all ongoing workflows in the source repository.
Objects that are in an ongoing workflow are flagged and cannot be archived into a
DocApp. Using Web Publisher check to see which objects are in a workflow and be
sure to complete the workflow.
12. For each included custom workflow template, configure a different location alias to
map where the workflow template will be stored in the target repository.
The easiest technique would be to map each one to a specific folder in
the DocApp folder itself. For example, if a custom workflow template is

named ’custom_wf’, create a location alias named custom_wf that maps to

/System/Applications/<DocApp>/custom_wf. Otherwise, by default, all of the
workflow templates and their activities will be stored in the same DocApp folder.
Creating separate location aliases will prevent confusion that would arise with
multiple activity objects with the same name in the same folder.
13. Ensure that all groups defined as recipients and all groups referenced by alias sets
in included workflow templates are themselves either included in the DocApp,
pre-exist in the target repository, or will be created in the target repository by the
pre-installation procedure.
This applies as well to the ACLs defined in the Permission Set Template aliases for
the DocApp Installation Options.
14. Check in all checked-out documents that are included in the DocApp (either directly
as a Data Object, or indirectly through a folder Data Object.)
15. You do not need to include the following items in your DocApp because they are
created or referenced automatically.
• Web Publisher DocApp methods called by automatic tasks in workflow
templates.
The DocApp archiving process will automatically include referenced Web
Publisher DocApp methods.
• Publishing configuration objects
The DocApp archiving process will not know how to set up the appropriate
relationships between publishing configuration objects (dm_webc_config)
and Site Caching Services target objects (dm_webc_target) if these objects are
included in the DocApp archive.
Documentum recommends that you don’t include publishing configuration
objects in your custom DocApp. You should manually re-create the publishing
configuration objects in your target repository using DA.
16. You may have some content or folders that lifecycles or other objects depend upon
to correctly archive but are not needed in the target repository. Include any folders
and documents to exclude, and set to do not overwrite.
17. Regarding the pre-installation procedure, Documentum recommends you include
the CURRENT version of the procedure object before archiving.
It’s a good idea to include print statements in your procedure. These print statements
will show up in the install log file and can be very useful.
18. Check your file path in which the DocApp archive will be stored to ensure there
are no spaces in folder names.
ACLs
If you have specific ACLs on specific folders, ensure those folders are individually added
to the DocApp and the ACLs are individually specified.
In addition, each Category folder may have a unique ACL associated with it. For
example, engineering_category_acl and marketing_category_acl. These ACLs restrict

author access to authorized users (an Engineering author cannot see the Marketing
Category, and thus cannot create Marketing content), and you want to maintain this
security in the target repository. In the DocApp, you cannot simply include the folder
’Departments’ because this would force you to apply a single Permission Set Template
to the entire folder, which would automatically be applied to its sub-folders and all
objects within. Rather than including ’Departments’, you include both ’Engineering’
and ’Marketing’ explicitly in the DocApp. You assign a separate Permission Set
Template for each folder and assign a location alias which points to /WebPublisher
Configuration/Content Templates/Departments. When this DocApp is archived and
installed in the target repository, Documentum Application Installer recognizes which
part of the location path does not exist in the target repository (namely Departments),
and creates the path for you.
Documentum Application Installer’s automatic path creates DocApp folders within the
Site Cabinet, but not the Site Cabinet itself. Documentum Application Installer will
create the missing pieces of the path but it will not create anything other than dm_folder
objects. The outcome of this is that when viewed in Web Publisher, it will look as if the
content templates were not deployed, but when viewed in another client (Documentum
Administrator, Desktop Client), the content templates are viewable.
Archiving the DocApp

Once you have read and completed the tasks in Preparing to Archive the DocApp, page
19 you can archive your DocApp.
You package a DocApp into an archive to deploy content to other repositories. When
you install a DocApp archive into a repository, you can provide the desired values (user
names, groups, cabinets, folders, or permission set templates) in the target repository
for the aliases in your DocApp.
Archiving the DocApp may take a long time depending on your network bandwidth,
complexity of your DocApp, and server and client speed. It may take several hours
to archive a repository for deployment. Testing has shown that approximately 1000
objects can take up to five hours to archive and over one hour to install. The time of your
deployment activity will depend on various factors at your site.
During these archiving operations, it may appear as if Documentum Application Builder
has frozen. However, the application may have completed the I/O operations and begun
repository operations like creating dm_relation objects and making lifecycle associations
without any user indication. Therefore, be sure not to terminate the process until the
application has signaled completion.
Using UNIX utilities on Windows you can issue a
tail -f <logfile path>
on the custom Documentum Application Installer log file and retrieve the end of file
status of the log file, providing you with real time status on the operation.
To archive your DocApp:
1. In Documentum Application Builder, ensure you have included all the appropriate
objects in your custom DocApp.

2. Set the options (upgrading objects, cabinets/folders hierarchies and content,

permission set aliases, location aliases, user aliases, pre- and post-installation
procedures) for installing to a target repository.
3. Choose DocApp→Create DocApp Archive.
The Choose Directory dialog box opens.
4. Navigate to and select a folder on the file system.
Application Builder creates a subfolder (with the same name as the DocApp) of the
specified folder and creates the DocApp archive files in the subfolder. Documentum
recommends that you do not change the name of the DocApp archive folder because
Application Installer uses it to install the DocApp archive and the DocApp archive
folder might be specified in paths (such as in the XML application configuration
file or location aliases).
You do not need to create a custom DocApp directory, Documentum Application
Builder automatically creates a directory with the same name as your DocApp and
saves the archive files in it.
In addition to archiving all the objects that have been included in a DocApp, these
objects are also archived and will be installed by Application Installer:
• ACX forms (components) associated with an included type’s functional classes.
This action ensures that the type functions properly in the target repositories.
For example, if you inserted the dm_document type-but not any of the ACX
forms associated with its functional classes-into a DocApp, several ACX forms,
including DcView, DcEdit, and DcOpen, would still be archived.
• dm_activity objects and their content (if any) that are part of an included
workflow template.
• Email templates (which are of the dm_sysobject type or one of its subtypes)
associated with an included workflow template or on of its dm_activiry objects.
Checking the DocApp Archive

After the DocApp archive operation succeeds, check the log file for any ’unable’
warnings. Check if the pre- and post-installation procedures were executed by checking
the “print” statement log messages.
If you encounter errors during the pre-installation script DocApp will exit. If you
encounter errors during the post-installation script, then you need to manually run
Documentum Application Installer on the target repository.
See, Documentum Application Builder User Guide, and Content Server Administrator’s Guide
for more guidance on DocApp Archive errors.

Preparing the Target repository for Install

Before you install the DocApp archive to the target repository you should create
operating system users that correspond to the repository users (or user aliases in your
DocApp) that manipulate the documents in your DocApp.
You can use pre- and post-installation procedures to create repository users, groups,
cabinets, and folders if required, or you can create them manually using Documentum
Administrator.
For more information about using Documentum Administrator, refer to Documentum
Administrator User Guide, and Content Server Administrator’s Guide.
Installing the DocApp Archive

Before installing your DocApp archive you should also check the server scripts, OS users,
repository users, and install log to ensure that all objects were correctly archived.
If you encounter errors, refer to Content Server Administrator’s Guide, and Documentum
Application Builder User Guide.
Server Scripts
Ensure that the WCM server scripts are in the /bin directory prior to installing the
DocApp. The DocApp, and in particular the wcmLifecycleScript relies on these
scripts being present before installing the DocApp. This should not be an issue if the
deployment is using the same Content Server instance as they will already be present in
the /bin directory.
Users
This is one of the manual steps to be performed. Create users in the target repository,
and add users to the appropriate groups. Users are not deployed, and therefore neither
are group memberships.
If you encounter errors, refer to Content Server Administrator’s Guide and Documentum
Administrator User Guide.
Custom Region Congurations

If your are migrating custom locale settings, you must manually copy any
custom region configurations (XML files) from the source repository located in
webapps\wp\wp\config\library\locale\add_locale_component.xml to the target

repository located in config\library\locale\add_locale_component.xml prior to

installing the DocApp.
A locale is defined by a region and a language and a default list of regions and languages
are provided but additional regions and languages may be needed for your global
deployment. An example of a custom region would be South East Asia or Central
America instead of a specific country. These entries are added to an XML file on the
application server--not an object in the repository.
Check the Install Log

During the install, the process may seem to be hung as the application user interface may
freeze. Do not terminate the process until it has gracefully completed.
The installation log stores most of the installation information. You should look in the
install log for installation success or failure messages.
In the installation log, you may see a line like:
Warning: '<file_name>' will be attached to the base state of document lifecycle <lifecycl
The current state '<lifecycle_state>' is not attachable”
This warning means that in the source repository, the state of this lifecycle was not set to
Allow attachment directly to this state.
The following lines will probably show up repeatedly towards the end of the log file:
Installing dm_relation
Installing dm_relation_type: wcm_categoryWARNING: Relation type wcm_category
already exists. It will be overwritten.
Status: No errors detected, object 'wcm_category' should be installable.
Status: No errors detected, object 'Relation' was installed.
These messages are normal responses to the deployment of dm_relation objects, and do
not indicate any errors (they can also be seen in the upgrade process when installing a
DocApp into a Web Publisher repository.
A line that indicates if the pre-installation procedure failed to run would look like:
dmadmindmbasic: <file_path>: No such file or directory
Note: If your first DocApp installation fails, the existing target lifecycles may have
been uninstalled. Double-check the lifecycles and ensure they are all installed before
re-running the DocApp installation.
Before installing your DocApp archive to a repository, make sure that you have super
user privileges in the target repository.
To install the custom DocApp archive to a target repository:
1. Choose Start→Programs→Documentum→Application Installer.

2. Connect to the repository as a user with Superuser privileges by typing the
repository user name, password, and domain when prompted and clicking OK.
The domain is the operating system domain against which your user account is
authenticated. You might not be required to enter the domain.
Note: Your repository user account must have the Superuser privilege.

Superuser privilege is the highest level of user privilege in a repository. Users with
the Superuser privilege have a minimum access level of Read of all sysobjects. They
also have the ability to change the object-level permissions of any object.
For more details about Superuser abilities and to learn how to grant Superuser
privilege to a user, see Content Server Administrator’s Guide.
3. In the Select DocApp Archive dialog box, click Browse to find the DocApp archive
folder (which is the same name as the DocApp archive).
4. Select the DocApp archive folder and click OK.
By default, the installer log file is named archive_installerLog.html and is saved
in c:\TEMP.
archive is the name of the DocApp archive folder.
a. To select a different location for the installer log, click Browse (next to the Path
name field) and select a directory.
b. To specify a different filename, type a new name in the File name field.
For more information about the installation log file, see Documentum Application
Builder User Guide.
5. Click OK in the Select DocApp Archive dialog box.
You are returned to the main window.
6. Click Start Installation.
If a message box displays stating that there are connected users, click Yes to continue.
If you specified aliases for objects in your DocApp, then the Resolve Alias dialog
box displays.
7. In the Resolve Alias dialog box displays, select the alias or folder in the repository
under Value:
a. To find the appropriate folder, click browse and select the folder–do not
double-click the folder to open it—then click Select.
b. Select the corresponding user or group from the drop-down list.
8. Click OK.
Application Installer installs the DocApp archive, and executes any post-installation
procedures (if the installation succeeds). Any errors that occur display in the
Installation Status window.
If errors do occur and the text Abort transaction is displayed in the Installation
Status window, do not exit the Application Installer. Refer to the troubleshooting
chapter of the Documentum Application Builder User Guide.
Checking the DocApp Archive Installation

Once you have installed the DocApp archive to the target repository you should check
a few things to ensure that the installation did not encounter any errors. You can also
begin to configure some objects.

Enable Workows
Administrators must install and add workflows to a pick list so users with fewer
permissions can use workflows. If workflows are created using Documentum
Application Builder but not installed users will not be able to use them. For example, if
ten workflows are available and installed the administrator can add six of them to the
pick list so users such as content authors and content managers can only pick a workflow
from the six displayed. Administrators can also decide to force content authors or
content managers to use a specific workflow by associating a workflow with a template.
If a user chooses that template then they automatically use the workflow associated
with that template.
To make a workow template available, and start a workow:
1. Log in to Web Publisher.

2. In the Classic view’s left pane, expand the Administration node.
3. Expand the Web Publisher Admin subdirectory.
4. Select Workflow Templates.
5. Check the an uninstalled workflow template’s checkbox.
Any workflows that were created using Documentum Application Builder but not
yet installed will be marked as uninstalled.
6. Select Tools→Workflow Templates→Make Available.
The workflow template is installed.
7. Select Tools→Workflow→Start.
8. In the list of workflow templates, locate the template you want and select its
checkbox.
9. Click the OK button (at the bottom of the page).
10. Fill in Info tab, Performers tab, and Comments tab.
For more information on using these tabs see, Web Publisher User Guide.
11. Click OK and Finish.
Publishing Congurations
Create the required publishing configuration objects through Documentum
Administrator.
Please refer to Site Caching Services User Guide for information on creating publishing
configuration objects.

Web Publisher Congurations

Update the /Common/System Configuration object as appropriate, if it was not deployed.
If you did not deploy the System Configuration object to the target repository you must
manually update the object to ensure that it has the correct values for example, allow
authors to import.
User Interface Customizations

Any customizations that you have made to the Web Publisher user interface through
the web_application_root/custom directory should be deployed to the target repository
using the manual copy and paste operation available on your file system. Once you
have copied and pasted all your customizations you must then restart your application
instance to clear your cache.
Testing
Once everything is ready, you can test the deployment. Begin with simple tasks like
checking in and checking out content from templates. Create content and promote it to
test the lifecycle. Test a full publish. Documentum recommends that you create some
test scripts with criteria to test the entire extent of the install to ensure that the newly
deployed content is working correctly.

Chapter 3
Deploying WCM repository
Components Using Dump and
Load
This chapter explains how to deploy the Web Publisher dump and load application.
If you want to easily copy Web Publisher applications from your test machine to your production
machine you can perform a dump and load procedure. Documentum recommends you only perform
this procedure once on a clean repository.
The dump and load modifies the target repository to include the following:
• Content templates with the correct wcm relationship types maintained between the Editor rules
file, presentation file, and thumbnail file
• Site Cabinet content with correct lifecycle states
• Web Publisher application for example, default Web Publisher application
• Custom applications for example, custom lifecycles, workflows, object types
• Object type instances for example, change set in correct lifecycle state
Creating a Dump File

You must perform a dump operation on the source repository to copy the Web Publisher
objects in the source repository to a specified dump file. Before you create a dump file
you should make sure that your dump script contains all repository specific information.
A sample dump script (dumpscript.api) and is provided with your Web Publisher
application and is installed to <DM_HOME>\bin\webPublisher\install during
installation.
What you should modify in the dump script:
1. If your repository has custom object types be sure to manually add each custom
object type to the dump script.
For example,
append,c,l,type
mytype1
append,c,l,predicate
1=1

Deploying WCM repository Components Using Dump and Load
2. If your repository has a custom DocApp installed, for example the Accelera DocApp,
and you want to move that DocApp to the target repository, be sure to manually add
the application name to the dump script.
For example,
append,c,l,type
dm_application
object_name='Accelera'
3. If you have linked content in multiple cabinets through the folder map you must
manually add all cabinets to the dump file.
For example,
append,c,l,type
dm_sysObject
folder('/accelera.com',descend)
4. The file must contain all Web Publisher object types.

5. Make sure the predicate attribute is 255 characters or less. The predicate attribute
has a limitation of 255 characters. See, Content Server Administrator’s Guide for more
details.
To determine if the dump script contains all Web Publisher object types, open the Web
Publisher DocApp in Application Builder and include all the types found there. This
applies to any custom DocApps as well.
To create a dump le:
1. Open an MS-DOS prompt or a UNIX shell on the machine where the source
repository is installed.
2. At the DOS prompt, type the following command:
iapi32 repository_Name —Urepository_Owner —Ppassword -RDump_File_Name
-Dump Log File Name
For example,
iapi32 DCTMDocbase —Utestuser —Ptestpass -Rdump.api -ldump.log
The command runs the dump script and creates a dump file to the location specified
in the dump script.
Note: If you are using UNIX type iapi, not iapi32.
3. When the command completes you should check the dump log file for errors.
A sample dump file is provided below.
The dump file (dumpscript.api) following is a sample only. This dump
file is provided with your Web Publisher application and is installed to
<DM_HOME>\bin\webPublisher\install during installation. You must include or
exclude types and objects as appropriate for your company. The following script shows
examples that apply only to Documentum’s test environment.
Figure 3-1. Sample Dump Script

####################################################################
# SAMPLE DUMP SCRIPT FOR WP 5.3 REPOSITORY
# AUTHOR: DCTM

# DATE: 8 Nov 2004

# LAST MODIFIED:
####################################################################
# Specify a path to dump file

# The path must be recognizable on the server machine
create,c,dm_Dump_record
set,c,l,file_name
c:\harsh_dump.dmp
set,c,l,include_content
####################################################################
# PART A
# SYSTEM OBJECT TYPES
####################################################################
append,c,l,type
dm_workflow
1=1
append,c,l,type
dmi_workitem
1=1
append,c,l,type
dmi_package
1=1
append,c,l,type
dm_alias_set
1=1
append,c,l,type
dm_acl
1=1
####################################################################
# PART B
# WEB PUBLISHER APPLICATION DOCAPP
####################################################################
append,c,l,type
dm_application
object_name='WebPublisher'
append,c,l,type
dm_sysObject
folder('/System/Applications/WebPublisher',descend)
append,c,l,type
dm_xml_application
object_name='updatexmlcontent'
####################################################################
# PART C

# WEB PUBLISHER CONFIGURATION OBJECT AND CABINET

# cabinet is dumped as dm_sysobject which will make sure to archive
# all instances of dm_sysobject as well as dm_sysobject's subtype
####################################################################
append,c,l,type
dm_sysObject
folder('/WebPublisher Configuration',descend)
#append,c,l,type
#wcm_config
#append,c,l,predicate
#1=1
####################################################################
# PART D
# WEB PUBLISHER OBJECT TYPES
####################################################################
append,c,l,type
wcm_category
1=1
append,c,l,type
wcm_change_set
1=1
append,c,l,type
wcm_supporting_doc
1=1
append,c,l,type
wcm_user_pref
1=1
append,c,l,type
wcm_locale
1=1
append,c,l,type
wcm_auto_naming
1=1
append,c,l,type
wcm_edition
1=1
append,c,l,type
wcm_edition_fld
1=1
####################################################################
# PART E
# Skip the wcm_channel_fld and wcm_channel type because Web
# cabinet is dumped as dm_sysobject which will make sure to archive
# all instances of dm_sysobject as well as dm_sysobject's subtype

####################################################################
#append,c,l,type
#wcm_channel_fld
#1=1
#append,c,l,type
#wcm_channel
#1=1
#append,c,l,type
#ar_prod
#1=1
#append,c,l,type
#ar_press
#1=1
####################################################################
# PART F
# CUSTOM APPLICATION DOCAPP
####################################################################
append,c,l,type
dm_application
object_name='Accelera'
append,c,l,type
dm_sysObject
folder('/System/Applications/Accelera',descend)
####################################################################
# PART G
# WEB PUBLIHSER CONTENT
####################################################################
append,c,l,type
dm_sysObject
folder('/harsh.com',descend)
append,c,l,type
dm_sysObject
folder('/accelera.com',descend)
####################################################################
# PART H
# ERROR MESSAGE
####################################################################
save,c,l
getmessage,c
####################################################################

Creating a Load File

You must then run a load operation on the target repository to bring the Web Publisher
objects from the dump file to the target repository.
A sample load script (loadscript.api) and is provided with your Web Publisher
application and is installed to <DM_HOME>\bin\webPublisher\install during
installation.
Before you perform the load procedure you must:
• Run the wcmConfigure.ebs script.
This script creates groups, roles, and system ACLs in the repository.
• Create all Web Publisher repository users using Documentum Administrator see,
Documentum Administrator User Guide for information on creating users and groups.
To run the wcmCongure.ebs script:
1. Ensure that the dmcl.ini file on your target machine where Web Publisher is installed
has an entry pointing to the host name on which the target repository is running.
The target repository is the repository on which you want to perform the load
operation.
a. Navigate to your dmcl.ini file.
This file is usually located in your Windows directory.
b. Check for a host name where the target repository is running for example,
host=<hostname>
c. If an entry does not exist, add one.

d. Save and close the dmcl.ini file.
2. Open an MS-DOS prompt on the machine where Web Publisher is installed.
3. At the DOS prompt, navigate to the following:
$DM_HOME/bin/DcmDocapp/install (UNIX) or
%DM_HOME%\bin\DcmDocapp\install (Windows)
4. Type the following command:

dmbasic -fwcmConfigure.ebs -ePreInstall -- repository_Name
repository_Owner password
To load the dump le:
1. Open an MS-DOS prompt on the machine where the target repository is installed.
2. At the DOS prompt, type the following command:
iapi32 repository Name —Urepository Owner —Ppassword -RLoad
File Name -lLoad Log File Name
For example,
iapi32 DCTMProductionDocbase —UProduser —PProdpass -Rload.api -lload.log
The command runs the load script and loads the dump file, specified in the load
script, to the target repository.
Note: If you are using UNIX type iapi, not iapi32.

3. When the command completes you should check the target repository for errors.
a. Open Application Builder and check to ensure that the default Web Publisher
application and the custom application were correctly transferred.
b. Check for multiple copies of lifecycles, workflows or dm_procedure objects.
There should only be one copy.
c. Check that the default ACL (Web Publisher User Default ACL) is applied to
lifecycles and workflows.
d. Check that user information is correct for example, domain, email, address. If
this information is not correct then correct it using Documentum Administrator.
e. Login to Web Publisher from the target repository. Check that all Web Publisher
Editor templates were transferred correctly.
f. Check that the Folder Map and system property information are correct.
g. Perform some sanity tests on Web Publisher. A sanity test includes such tests
as logging into Web Publisher as each user (content author, content manager,
administrator, Web developer) and adding new content, importing content,
starting a workflow, creating a change set, promoting a document, demoting a
document, power promoting a document, and expiring a document.
Note: Running the load script will load some objects which were not explicitly
mentioned in the dump script from the source repository to the target repository.
The load file (loadscript.api) following is a sample only. This load
file is provided with your Web Publisher application and is installed to
<DM_HOME>\bin\webPublisher\install during installation.
Figure 3-2. Sample Load Script

####################################################################
# SAMPLE LOAD SCRIPT FOR WP 5.3 REPOSITORY
# AUTHOR: DCTM
# DATE: 8 Nov 2004
# LAST MODIFIED:
####################################################################
trace,c,10
create,c,dm_load_record
set,c,l,file_name
c:\harsh_load.dmp
set,c,l,relocate
T
save,c,l
getmessage,c
####################################################################
If you are working with a repository whose content has been created using a dump and
load procedure you must recreate the site publishing configuration in the repository.
For more information on site publishing configurations, refer to Site Caching Services
User Guide.

Rolling Back Your Target repository

Users can role back to the initial state of the target repository. You may want to do this
if the dump and load procedure fails. Perform the role back procedure to correctly
recapture your initial target repository state.
To role back your target repository:
1. Run a DQL query on the target repository to find the last dmi_load_object_record ID
in the repository.
For example,
select distinct load_object from dmi_load_object_record
DQL can be run interactively from Content Server using IDQL32.exe by typing
IDQL32.exe into the Start→Run dialog box and clicking OK. Refer to Content Server
DQL Reference Manual for more information on running DQL.
2. Make sure that you note the object ID.
3. Fetch the last dmi_load_object_record ID and apply the revert command.
a. Start iapi32.exe
b. Type the following revert command on the target repository,
revert,c,dmi_load_object_record ID
The dmi_load_object_record ID is the ID returned from running the DQL query on

the target repository in step 1.

Chapter 4
Troubleshooting
This chapter provides troubleshooting tips and procedures in case your DocApp deployment or your
dump and load deployment encounters errors.
Check the Documentum Application Installer

Install Log
During the install, the process may seem to be hung as the application user interface may
freeze. Do not terminate the process until it has gracefully completed.
The installation log stores most of the installation information. You should look in the
install log for installation success or failure messages.
In the installation log, you may see a line like:
Warning: '<file_name>' will be attached to the base state of document
lifecycle <lifecycle_name>. The current state '<lifecycle_state>
' is not attachable”
This warning means that in the source repository, the state of this lifecycle did not have
its setting set to Allow attachment directly to this state.
The following lines will probably show up repeatedly towards the end of the log file:
Installing dm_relation
Installing dm_relation_type: wcm_categoryWARNING: Relation type wcm_category
already exists. It will be overwritten.
Status: No errors detected, object 'wcm_category' should be installable.
Status: No errors detected, object 'Relation' was installed.
These messages are normal responses to the deployment of dm_relation objects, and do
not indicate any errors (they can also be seen in the upgrade process when installing a
DocApp into a Web Publisher repository.
A line that indicates if the pre-installation procedure failed to run would look like:
dmadmindmbasic: <file_path>: No such file or directory

Troubleshooting
Note: If your first DocApp installation fails, the existing target lifecycles may have
been uninstalled. Double-check the lifecycles and ensure they are all installed before
re-running the DocApp installation.

Index
D related documentation, 8
deploy
dump and load, 31 T
troubleshooting
R DocApp, 39
references dump and load, 39

WCM Deployment Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

WCM Deployment Guide

Transféré par

Droits d'auteur :

Formats disponibles

Deploying Documentum Web

Chapter 1 Overview ............................................................................................... 11

Chapter 2 Deploying WCM Repository Components Using DocApp ..................... 17

Chapter 3 Deploying WCM repository Components Using Dump and

Chapter 4 Troubleshooting .................................................................................... 39

Deploying Documentum Web Content Management 3

Figure 3–1. Sample Dump Script ....................................................................................... 32

4 Deploying Documentum Web Content Management

Table 2–1. DocApp Installation Options ........................................................................... 18

Deploying Documentum Web Content Management 5

6 Deploying Documentum Web Content Management

Purpose of this Guide

Revision Date Description

Deploying Documentum Web Content Management 7

8 Deploying Documentum Web Content Management

Deploying Documentum Web Content Management 9

10 Deploying Documentum Web Content Management

Deploying Documentum Web Content Management 11

12 Deploying Documentum Web Content Management

Dump and Load

Using FTP Services

Deploying Documentum Web Content Management 13

14 Deploying Documentum Web Content Management

Deploying Documentum Web Content Management 15

16 Deploying Documentum Web Content Management

Deploying Documentum Web Content Management 17

Example 2–1. object type criteria

Example 2–2. other criteria

Table 2-1. DocApp Installation Options

DocApp Installation Options Target Repository State After DocApp

18 Deploying Documentum Web Content Management

Preparing to Archive the DocApp

Deploying Documentum Web Content Management 19

• run pre- and post-installation procedures

To prepare your target repository:

To prepare your source repository:

20 Deploying Documentum Web Content Management

Deploying Documentum Web Content Management 21

22 Deploying Documentum Web Content Management

named ’custom_wf’, create a location alias named custom_wf that maps to

Deploying Documentum Web Content Management 23

Archiving the DocApp

To archive your DocApp:

24 Deploying Documentum Web Content Management

2. Set the options (upgrading objects, cabinets/folders hierarchies and content,

Checking the DocApp Archive

Deploying Documentum Web Content Management 25

Preparing the Target repository for Install

Installing the DocApp Archive

Custom Region Congurations

26 Deploying Documentum Web Content Management

repository located in conﬁg\library\locale\add_locale_component.xml prior to

Check the Install Log

To install the custom DocApp archive to a target repository:

1. Choose Start→Programs→Documentum→Application Installer.

Deploying Documentum Web Content Management 27

Checking the DocApp Archive Installation

28 Deploying Documentum Web Content Management

To make a workow template available, and start a workow:

1. Log in to Web Publisher.

Deploying Documentum Web Content Management 29

Web Publisher Congurations

User Interface Customizations

30 Deploying Documentum Web Content Management