Renditions & Annotations

Jun 14, 2018 | by Mark Deckert

Blogpost | Header | Renditions & Annotations

Overview

One of the main benefits of our migration-center is the rich support of nearly all features of the OpenText Documentum content server. In this post, I will discuss migration-center’s ability to handle document renditions and annotations when migrating between Documentum environments. This is a technical article and I assume that you are already familiar with Documentum as well as migration-center.

Terms

Before I dive into the technical details, let me first explain some terms. A rendition is a format variant of a document’s content. In Documentum systems, it is a common use case to generate and save a PDF format variant (rendition) of an Office document (e.g. MS Word, MS Excel etc.). However, the Documentum content server can manage an arbitrary number of renditions of any format for each version of a document.

Blogpost | Renditions & Annotations | 01

An annotation is a comment that a user attaches to a document. Usually reviewers create annotations in order to record editorial suggestions or corrections in an approval workflow. In Documentum, an annotation is a separate object that is related to the original content. A document can have multiple annotations and each annotation can be related to multiple documents. In addition, a single annotation can be attached to several versions of the same document. The relations between these objects are managed by Documentum.

Blogpost | Renditions & Annotations | 02

How migration-center handles renditions

Let us see how migration-center extracts and stores renditions when scanning a source Documentum repository.

First you have to enable rendition handling by setting the Documentum scanner parameter “exportRenditions” to true. migration-center will then export the content of any existing rendition to the folder specified by the parameter “exportLocation” and create several source attributes that you can use in the transformation rules later in order to process the renditions.

migration-center uses the following naming schema for the rendition files:

<r_object_id>[<counter>].<file_format_extension>

This schema ensures that each rendition has a unique file name. The <counter> is needed in case more than one rendition with the same format exists, for example if you add several JPEG thumbnail images with different resolutions as renditions to an object. If there is only one file with the same format, the counter is omitted in the file name.

For each exported rendition file, migration-center will set the following source attributes of the corresponding Documentum object:

Blogpost | Renditions & Annotations | 03

These entire rendition related source attributes are repeating, i.e. can contain several values, in order to support multiple renditions for a single document version.

The attributes along with the exported content of the renditions allow you to migrate the renditions of the source objects to the target system.

Let us now see how the Documentum importer supports renditions when importing into a target repository. You can control the renditions of an object through a set of migration-center system attributes that are named like the rendition source attributes presented above, i.e. “dctm_obj_rendition”, “dctm_obj_rendition_format”, “dctm_obj_rendition_modifier”, “dctm_obj_rendition_page” and “dctm_obj_rendition_storage”.

To keep the renditions for an object and migrate them as they are, the system attribute “dctm_obj_rendition” must be set to contain one single transformation function:

GetValue(dctm_obj_rendition[all])

This transformation function will simply copy all paths in the source attribute “dctm_obj_rendition” to the target system attribute “dctm_obj_rendition”. The importer will pick up the content from the locations specified in this attribute and add them as renditions to the corresponding object version in the target system.

Of course it is possible to add /remove individual renditions to/from objects by using migration-center’s transformation functions. This can prove useful if renditions generated by third party software need to be appended during migration. These renditions can be saved to files in any location, which is accessible to the migration-center job server that runs the import job. Just add the paths to these files to the target system attribute “dctm_obj_rendition” and the importer will do the rest.

The following table shows all rendition related system attributes of the Documentum importer:

Blogpost | Renditions & Annotations | 04

Currently, the OpenText Documentum (including D2) and OpenText Content Server connectors support renditions.

How migration-center handles annotations

Migrating renditions is easy with migration-center’s powerful rendition features. However, migrating annotations is even easier: You just have to enable annotation handling in the Documentum scanner by setting the parameter “exportAnnotations” to true and the scanner will then look for relations of type “DM_ANNOTATE” for each scanned document. For each existing “DM_ANNOTATE” relation, the scanner will do two things: First it will treat the related “dm_note” source object as a regular document and add it to the list of scanned documents. Second it will create a relation of type “DctmAnnotationRelation” between the scanned document and the scanned “dm_note” object.

If you want to import the scanned documents with all their annotations into a target repository, you just have to ensure that:

  1. You import the scanned “dm_note” objects along with the regular documents.
  2. You enable the import of relations by setting the Documentum importer parameter “importRelations” to true.

Conclusion

I think these two examples have impressively demonstrated to what extent migration-center supports the many features of OpenText Documentum. We will continue to present more migration-center features on this blog, so stay tuned.

REQUEST YOUR FREE COPY OF MIGRATION-CENTER      SUBSCRIBE TO OUR NEWSLETTER