In any well-defined software lifecycle, you develop the application on a development environment and get it QA'ed (or system tested) on an altogether separate test environment. By environment we mean a complete hardware and software setup consisting of a suite of servers and programs in place, necessary for the developed application to function properly. Subsequently, the system-tested application is released on staging and then eventually on production servers. While the environments keep on changing from development to system testing to production, what remains constant is a common deployment strategy. This strategy should be well planned, consisting of steps that involve minimal human intervention to ensure they can be performed repetitively for migrating our application across various environments.
In Documentum, a typical application would have the following components or entities that need to be migrated across the various environments:
- Docbase objects such as object types, lifecycles, workflows, alias sets, templates, presentation files, and such other objects that lay the foundation of the application
- Content existing in the Docbase created from templates or imported files, images, etc. in the Docbase
- Web Publisher code and customized files
- Any post-deployment scripts that need to be executed on the target environment (such as scripts for creating Site Publishing Configurations)
Figure 25.1: Deployment from source to target environment
There are numerous deployment methodologies available that assist us in migrating objects and content from one environment to another. Each of these has its own share of advantages and disadvantages and should be chosen after a proper evaluation of your specific needs.
Figure 25.2 will give you a quick idea about which methodology should be adopted when and under what circumstances. Also, you will understand some of the advantages and disadvantages of each of these methodologies so that you can take a better decision for your custom applications.
Note that this table should not be treated as a comprehensive list. For a detailed evaluation of the multitude of deployment approaches, kindly go through the Documentum manuals and white papers.
|
Entity to be migrated |
Methodology |
Advantages |
Disadvantages |
|---|---|---|---|
|
Docbase objects |
DocApp migration |
Useful in selectively migrating objects in a Docbase. |
Requires setting up installation options meticulously to avoid target Docbase from being corrupted/damaged. |
|
|
Dump & Load scripts |
Useful in migrating an entire Docbase. |
Time-consuming process if the Docbase size is huge. |
|
|
Custom-written scripts |
Useful if the applications cannot be migrated by the available methodologies. |
Requires strong scripting knowledge and understanding of Documentum architecture/objects. |
|
Docbase content |
DocApp migration |
Useful in selectively migrating contents in a Docbase. |
Workflow states/tasks for contents are migrated incorrectly on target Docbase. Also the creation and modification dates of objects in source Docbase are lost on the target Docbase. |
|
|
Dump & Load scripts |
Useful in migrating an entire Docbase. |
Time-consuming process if the Docbase size is huge. |
|
|
Custom-written scripts |
Useful if the applications cannot be migrated by the available methodologies. |
Requires a strong scripting knowledge and understanding of Documentum architecture/objects. |
|
|
Documentum FTP Services |
Useful for migrating bulk content into a Docbase. |
Requires manual drag and drop to import files into Docbase. |
|
Web Publisher code and customizations/ processing scripts |
Manual deployment |
None. |
Error-prone since requires manual intervention and time-consuming as well. |
|
|
Automated build scripts using ANT |
Systematic means to compile and package code. |
Requires good knowledge of ANT scripting. |
In this chapter we will discuss DocApp migration as a methodology to selectively migrate Docbase objects and content, and ANT scripts to migrate Web Publisher code and custom scripts.
Using Documentum Application Builder you can create and package all your objects within a DocApp (refer to Chapter 2). In our case, we created a DocApp with the name TestDocApp to include our custom Documentum objects. Once all the objects have been packaged within a DocApp, you can create a DocApp archive using Documentum Application Builder. A DocApp archive is nothing but a ZIP of the included objects and their related objects in a proprietary format that can read by Documentum Application Installer and released on a target Docbase. However, migration using Application Builder and Application Installer is not as easy as it sounds. There are a couple of things you need to keep in mind to ensure smooth migration. The prerequisites mentioned below list some basic points that you need to take care of if you are using DocApps for migrating Docbase objects and content across environments.
The installation options need to be set correctly for all objects that need to be archived and installed on the target Docbase. We will be covering this in detail later in this chapter.
Be sure to include all objects in your DocApp that need to be migrated onto the target Docbase. Documentum does not automatically include related objects. For example, if you include a Web Publisher Template file in the DocApp, Documentum does not automatically include its associated Rules and Presentation files in the DocApp.
Remove any references to objects that have been deleted in the source Docbase while selecting a DocApp archive. For example, if an Alias Set references a particular group name and this group no longer exists in the source Docbase, then remove its reference from the Alias Set before creating a DocApp archive.
If you have some of the objects already available on the target Docbase and you need to incrementally update them, make sure you do not change their names (object_name property) on the source Docbase while creating a DocApp archive. This is because DocApp archiving and installation looks at the object_name property to locate and identify any existing objects in the target Docbase.
Let us now go through some simple steps to include objects in a DocApp and to set their installation options in the source Docbase. We will then take an archive of this DocApp and install the archive on a target Docbase using Documentum Application Installer.