DCM Importer

Introduction

The DCM Importer takes the objects processed in migration-center and imports them to a DCM repository. It currently supports DCM version 6.7. For accessing the DCM repository DFC 6.7 or later is required.

Importer is the term used for an output adapter which is most likely used at the last step of the migration process. An Importer (such as the DCM Importer) takes care of importing the objects processed in migration-center into the target system (such as a DCM repository).

An importer works as a job that can be run at any time, and can even be executed repeatedly. For every run a detailed history and log file are created.

An importer is defined by a unique name, a set of configuration parameters and an optional description.

DCM Importers can be created, configured, started and monitored through migration-center Client, but the corresponding processes are executed by migration-center Job Server.

DFC (Documentum Foundation Classes) configuration

Starting from version 3.9 of migration-center additional configurations need to be made for the Documentum adapter to be able to locate Documentum Foundation Classes. This is done by modifying the dfc.conf file, located in the Job Server installation folder.

There are two settings inside the file that by default match the paths of a standard DFC install. One needs to have the path for the config folder of DFC and the other needs the path to the dctm.jar.

See below example:

wrapper.java.classpath.dfcConfig=C:/Documentum/config wrapper.java.classpath.dfcDctmJar=C:/Program Files/Documentum/dctm.jar

The dfcConfig parameter must point to the configuration folder. The dfcDctmJar parameter must point to the dctm.jar file!

Information on folder migration

When importing DCM documents, their folder paths are also scanned and the folder structure can be automatically re-created by migration-center in the target repository. This procedure will not keep any of the metadata attached to the folder objects, such as owners, permissions, specific object types, or any custom attributes. Depending on project requirements, it may be required to do a “folder-only migration” first, e.g. for migrating a complete folder structure including custom folder object types, permissions and other attributes first, and then populate this folder structure with documents afterwards. In order to execute a folder-only migration the following steps should be performed to configure the migration process accordingly:

1. Scanner: Scan the source data using a scanner which can generate folder metadata to be used later for import to a DCM repository. See the appropriate scanner’s documentation.

2. Migration set: When creating a new migration set choose the <source type>ToDCM(folder) type – this will create migration set containing folders targeted at DCM. Now only the scanner runs containing folder objects will be displayed on the |Filescan Selection| tab. Note that the number of objects contained in the displayed scanner runs now indicates folders and not documents, which is why the number on display (folders) can be different from the total number of objects processed by the scan (if it contains other types of objects besides folders).

3. Transformation rules: When creating transformation rules for the migration set, keep in mind that folder-only migration sets have folder-specific attributes to work with, in this case attributes specifically targeted at the DCM folder objects.

“object_name” and “r_folder_path” are key attributes for folders in Documentum/DCM. If these attributes are transformed without taking into consideration how these objects build into a tree structure, it may no longer be possible to reconstruct the folder tree. This is not due to migration-center, but rather because of the nature of folders being arranged in a tree structure which does create dependencies between the individual objects.

In Documentum/DCM the “r_folder_path” attribute contains the path(s) to the current folder, as well as the folder itself at the end of the path (e.g. /cabinet/folder_one/folder_two/current_folder), while “object_name” contains only the folder name (e.g. current_folder). To make it easier for the user to change a folder name, migration-center prioritizes the “object_name” attribute over the “r_folder_path” attribute; therefore changing “object_name” from current_folder to folder_three for example will propagate this change to the objects’ “r_folder_path” attribute and create the folder /cabinet/folder_one/folder_two/folder_three without the user having to change the “r_folder_path” attribute to match. This only applies to the last part of the path, which represents the current folder, and not to other parts of the path. Those can also be modified using the provided transformation functions, but migration-center does not provide any automations to make sure the information generated in that case is correct.

For more information about these attributes and folders in Documentum/DCM see the appropriate documentation about the EMC Documentum Object Model and Content Server.

Note that the “importObjects” and “autoCreateFolders” options on the DCM Importer’s |Parameters| tab are not used for the folder-only migration. Note that these parameters will still be in effect if other migration set(s) containing DctmToDctm(document) objects will be imported together with the folder migration set.

Folder migration is important. It is necessary to take the approach described above when migrating folder structures with complex folder objects containing custom object types, permissions, attributes, relations, etc. This information will be lost if “exportFolderStructure” is not switched on during scan.

Working with features specific to DCM

Document classes and controlled documents

The key concept around which DCM revolves is that of document classes and controlled documents. These concepts are also represented in migration-center when working with a migration set targeted at DCM. A valid document class and type must be specified through specific system rules provided for migration sets targeted at DCM in order for the importer to create a proper controlled document upon import to DCM. It is not mandatory to import documents as controlled documents to DCM, as omitting the document class is possible, thus creating a regular document in the DCM target repository.

Other attributes and can be set by defining transformation rules for them in the same way as if these were imported to a regular Documentum repository.

The document class to be set is controlled via the predefined system rule controlled_document_class. This one is created automatically for migsets targeted at DCM and appears alongside the other system rules in the bottom left corner of the Transformation Rules window.

A valid DCM document class existing on the target DCM system must be specified for the importer to be able create controlled documents.

Specifying an invalid or inexistent document class will cause the import to fail with the appropriate error message.

Omitting setting a value for the “controlled_document_class” rule will result in the documents being imported as regular documents as opposed to controlled documents.

Currently the importer supports importing controlled documents and change notices. Change notices can be imported by associating the “r_object_type” rule with the type “dmc_change_notice”. The following sections in this chapter refers to both controlled documents and change notices.

When setting a document class through the controlled_document_class rule, the object type set through the r_object_type rule must be a valid object type defined for the document class.

Autonaming

DCM autonaming rules can be applied to the imported documents simply by omitting the object_name rule, or at least not associating the object_name rule with the object_name attribute. This will result in the documents being named according to the autonaming rules applicable to the specified document class.

Defining and associating a rule for object_name will override DCM autonaming rules. Due to DCM behavior the object name has to be set in the importer parameter “preserveMCAttributes” in order to set the value of object_name from MC for the first version.

Setting the object_name through transformation rules is recommended if no autonaming rules are available or intended to be used for the specified document class.

Lifecycles

Another key feature of DCM are the lifecycles attached to controlled documents. Lifecycle states can be set for DCM objects through migration-center by creating rules and associating them with the attributes handling lifecycle status and associations, such as a_aplication_type, a_status, r_current_state, r_resume_state.

If Documentum scanner is used to obtain source objects, delete “a_application_type” from “ignoredAtrributesList” scanner parameters.

For more information about these attributes in Documentum/DCM see the appropriate documentation about the EMC Documentum Object Model and Content Server.

Permissions

If any of the attribute acl_name, acl_domain, group_permit, world_permit and owner_permit is not set in the transformation rules, the imported documents will be assigned with the permissions according with the DCM configurations.

The default DCM permissions on imported objects can be overwritten by creating transformation rules for acl_name and acl_domain or group+permi, world_permit and owner_permit. The attributes group_permit, world_permit and owner_permit can be used to set granulated permissions. For setting ACLs the attributes acl_domain and acl_name must be used. The user must set either *_permit attributes or acl_* attributes. If both*_permit attributes or acl_* attributes are configured to be migrated together the *_permit attributes will override the permissions set by the acl_* attributes. Because Documentum will not throw an error in such a case migration-center will not be able to tell that the acl_* attributes have been overridden and as such it will not report an error either considering that all attributes have been set correctly.

If the group_permit, world_permit, owner_permit AND acl_domain, acl_name attributes are configured to be migrated together the *_permit attributes will override the permissions set by the acl_* attributes. This is due to Documentum’s inner workings and not migration-center. Also, Documentum will not throw an error in such a case, which makes it impossible for migrationcenter to tell that the acl_* attributes have been overridden and as such it will not report an error either, considering that all attributes have been set correctly. It is advised to use either the *_permit attributes OR the acl_* attributes in the same rule set in order to set permissions.

Working with features specific to Documentum

Standard Documentum features such as versions, renditions, relations, virtual documents and audit trails are also supported by the DCM Importer, which, just like DCM, is based on Documentum.

Versions

Versions (including branches) are supported by the DCM Importer, including custom version labels. Version information is generated during scan, be it a Documentum Scanner or other scanners supporting systems where version information can be extracted from. This version information (essentially the Documentum r_version_label) can be changed using the transformation rules prior to import. The version structure (i.e. the ordering of the objects relative to their antecedents) cannot be changed using migration-center.

If objects have been scanned with with version information, all versions must be imported as well since each object references its antecedent, going back to the very first version. Therefore it is advised not to drop the versions of an object between the scan and the import processes since this will most likely generate inconsistencies and errors. If an object is intended to be migrated without versions (i.e. only the current version of the object needs to be migrated), than the affected objects should be scanned without enabling the respective scanner’s versioning option.

Renditions

Renditions are supported by the DCM Importer. Rendition information is typically generated during scan, be it by the Documentum Scanner or other scanners supporting systems where rendition information or other similar features can be extracted. Should rendition information not be obtainable using a particular scanner, or if the respective source system doesn’t have renditions at all, it is still possible to add files as renditions to objects during the transformation process. The renditions of an object can be controlled through the migration-center system attribute called dctm_obj_rendition. The dctm_obj_rendition attribute appears in the “System attributes” area of the Transformation Rules window. If the object contains at least one rendition in addition to the main content, the source attribute dctm_obj_rendition will be available for use in transformation rules. 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 will reference the path of the files where the corresponding renditions have been exported to; the Importer will pick up the content from this location and add them as renditions to the respective documents.

It is possible to add/remove individual renditions to/from objects by using the provided 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 Job Server where the import will be run from. The paths to these files can be specified as values for the dctm_obj_rendition attribute. A good practice for being able to assign such third party renditions to the respective objects is to name the files with the objects’ id and use the format name as the extension. This way the dctm_obj_rendition attributes’ values can be built easily to match external rendition files to respective DCM documents.

Other properties of renditions are also available to be set by the user through a series of rendition-related system attribute which are available automatically in any migset targeting a Documentum based system:

Rendition system attribute	Description
dctm_obj_rendition	Specify a file on disk (full path) to be used as the content of that particular rendition
dctm_obj_rendition_format	Specify a valid Documentum format to be set for the rendition Leave empty to let Documentum decide the format automatically based on the extension of the file specified in dctm_obj_rendition (if the extension is not known to Documentum the rendition’s format will be unknown) Will be ignored if dctm_obj_rendition is not set
dctm_obj_rendition_modifier	Specify a page modifier to be set for the rendition. Any string can be set (must conform to Documentum’s page_modifier attribute, as that’s where the value would end up) Leave empty if you don’t want to set any page modifiers for renditions. Will be ignored if dctm_obj_rendition is not set
dctm_obj_rendition_storage	Specify a valid Documentum filestore where the rendition’s content file will be stored. Leave empty to store the rendition file in Documentum’s default filestore. Will be ignored if dctm_obj_rendition is not set

All dctm_obj_rendition* system attributes are repeating attributes and as such accept multiple values, allowing multiple renditions to be added to the same object. Normally the number of values for all dctm_obj_rendition* attributes should be the same and equal the maximum number of renditions one would like to set for an object. E.g. if three renditions should be set, then each of the dctm_obj_rendition* attributes should have three values for each of the three renditions. More values will be ignored, missing values will be filled in with whatever Documentum would use as default in place of that missing value.

Relations

Relations are supported by DCM Importer. Relations for import to DCM can currently be generated only by the Documentum Scanner, but technically it is possible to customize any scanner to generate relation information that can be processed by the DCM Importer if information similar or close to Documentum relations needs to be extracted from non-Documentum system. The option named exportRelations in the Documentum scanner’s configuration determines if relations are scanned and exported to migration-center.

Important: relations cannot be altered using transformation rules; migration-center will manage relations automatically if the appropriate options in the scanner and importer have been selected. Relations will always be connected to the parent object of the relation and can be viewed in migration-center by right-clicking on an object in any view of a migration set and selecting <View Relations> from the context menu. All relations with the selected object as the parent object are listed with their associated metadata, such as relation name, child object, etc.

An option corresponding to the scanners’ must be selected in the importer as well to restore the relations between objects on import; the option is labeled importRelations. The importer can be configured to import objects and relations together or independently of one another. This can be used to migrate only the objects first and attach relations to the imported objects later.

Relations will always be connected to the parent object of the relation, which is why importing a relation will always be attempted when importing its parent object and the importRelations option mentioned above is selected as well. Importing a relation will fail if its child object is not present at the import location. This is not to be considered a fatal error. Since the relation is connected to the parent object, the parent object itself will be imported successfully and marked as “Partially Imported”, indicating it has one or more relations which could not be imported (because the respective child object could not be found). After the child object gets imported, the import for the parent object can be repeated. The already imported parent object will not be touched, but its missing relation(s) will now be created and connected to the child object. Once all relations have been successfully created, the parent object’s status will change from “Partially imported” to “Imported”, indicating a fully migrated object, including all its relations. Should some objects remain in a “Partially imported” state because the child objects the relation depends on are not migrated for a reason, then the objects can remain in this state and this state can be considered a final state equivalent to “imported” in such a case. The “Partially imported” state does not have any adverse effects on the current or future migrations even if these depend on the respective objects.

migration-center’s Documentum based adapters support relations between folders and/or documents only (i.e. dm_folder and dm_document objects, as well as their respective subtypes) dm_subscription type objects for example, although relations from a technical point of view, will be ignored by the scanner because they are relations involving a dm_user object. Custom relation objects (i.e. relation-type objects which are subtypes of dm_relation are also supported, including any custom attributes they may have. The restriction mentioned above regarding the types of objects connected by such a relation also apply to custom relation objects.

Virtual Documents

Documentum Virtual Documents are supported by migration-center. The option named exportVirtualDocs in the configuration of the scanner determines if virtual documents are scanned and exported to migration-center.

Another option related to virtual documents, named maintainVirtualDocsIntegrity is recommended when scanning VDs. This option will allow the scanner to include children of VDs which may be outside the scope of the scanner (paths to scan or dqlString) in order to maintain the integrity of the VD. If this option is not turned on, the children in the VD that are out of scope (they are not linked under the scanned path or they are not returned by dqlString) will not be scanned and the VD may be incomplete. This option can be enabled/disabled based on whichever setting makes sense for the migration project.

The VD binding information (dmr_containment objects) are always scanned and attached to the root object of a VD regardless of the maintainVirtualDocsIntegrity option. This way it is possible to scan any missing child objects later on and still be able to restore the correct VD structure based on the information stored with the root object.

The ExportVersions option needs to be checked for scanning Virtual Documents (i.e. if the ExportVirtualDocuments option is checked) even if the virtual documents themselves do not have multiple versions, otherwise the virtual documents export might produce unexpected results. This is because the VD parents may still reference child objects which are not current versions of those respective objects. This is not an actual product limitation, but rather an issue caused by this particular combination of Scanner options and Documentum’s VD features, which rely on information related to versioning.

The Snapshot feature of virtual documents is not supported by migration-center.

Audit Trails

The DCM Importer also supports migrating audit trails of documents and folders. Audit Trails can be scanned using the Documentum Scanner (see the Documentum Scanner use guide for more information about scanning audit trails), added to a DCM Audit Trail migset and imported using the DCM Importer.

Audit Trail migsets are subject to the exact same migration procedure as documents and folders. Audit Trail migsets can be imported together with the document and folder migsets they are related to, or on their own at any time after the required document and folder objects have been migrated. It is of course not possible to import any audit trails if the actual object the audit trails belong to hasn’t been migrated.

Importing audit trails is controlled in the DCM Importer via the importAuditTrails parameter (disabled by default).

A typical workflow for migrating audit trails consists of the following main steps:

1. Scan folders/documents with Documentum Scanner by having “exportAuditTrail” flag activated. The scanning process will create tree kind of distinct objects in migration-center: Documentum(folder), Documentum(document) and Documentum(audittrail).

2. Assign the. Documentum(audittrail) objects to a DctmToDCM(audittrail) migset(s) and follow the regular migration-center workflow to promote the objects through transformation rules to a “Validated” state required for the objects to be imported.

3. Import audit trails objects by assigning the respective migset(s) to a DCM Importer job with the importAuditTrails parameter enabled (checked)

Preparing a Migration Set Containing Audit Trails

In order to prepare audit trail for import, first create a migset containing audit trail objects (more than one migset containing audit trails can be created, just like for documents or folders). For a migset to work with audit trails, the type of object must be set “DctmToDCM(audittrail)” accordingly. After setting the migset type to “DctmToDCM(audittrail)” the | Filescan | tab will display only scans which contain Documentum audit trail objects. Any of these can be added/removed to/from the migration set as usual.

Transformation Rules for a Migration Set Containing Audit Trails

Transformation rules allow setting values for the attributes audit trail entries on import to the target system. Values can be simply carried over unchanged from the source attributes, or they can be transformed using the available transformation functions. All attributes that can be set and associated are defined in the target type “dm_audittrail”.

As with other migration-center objects, audit trail objects have some predefined system attributes:

• audited_object_id this should be filled with the corresponding value that comes from source system. No transformation or mapping is necessary because the importer will translate that id into the corresponding id in target repository.

• r_object_type must be set to a valid Documentum audit trail object type. This is normally “dm_audittrail” but custom audit trails object types are supported as well.

The following audit trail attributes don’t need to be set through the transformation rules because they are automatically taken from the corresponding audited object in target system: chronicle_id, version_label, object_type.

All other “dm_audittrail” attributes that refer to the audited object (acl_domain, acl_name, audited_obj_vstamp, controlling_app, time_stamp, etc) can be set either to the values that come from the source repository or not set at all, case in which the importer will set the corresponding values by taking them from the audited object located in the target repository.

The source attributes “attribute_list” and “attribute_list_old” may appear as multi-value in migration-center. This is because their values may exceed the maximum size of a value allowed in migration-center (4000 bytes), case in which migration-center handles such an attribute as a multi-value attribute internally. The user doesn’t need to take any action to handle such attributes; the importer knows how to process and set these values correctly in Documentum.

Not setting an attribute means not defining a rule for it or not associating an existing rule with any object type definition or attribute.

Working with rules and associations is core product functionality and is described in detail in the Client User Guide.

Migrating Updates (“Update” or “Delta” Migration)

Objects that have changed in the source system since the last scan are scanned as update objects. Whether an object in a migration set is an update or not can be seen by checking the value of the Is_update column – if it’s 1, the current object is an update to a previously scanned object (the base object). There are some things to consider when working with the update migration feature:

An update object cannot be imported unless its base object has been imported previously.

Updated objects are detected based on the r_modify_date and i_vstamp attributes. If one of these attributes has changed, the object is considered to have been updated and will be registered accordingly. By default actions performed in Documentum change at least one if not both of these attributes, offering a reliable way to detect whether an object has changed since the last scan; on the other hand, objects changed by third party code/applications which do not touch these attributes might not be detected by migration-center as having changed.

Objects deleted from the source after having been migrated are not detected and will not be deleted in the target system. This is by design (due to the added overhead, complexity and risk involved in deleting customer data).

Updates/changes to primary content, renditions, metadata, VD structures, and relations of objects will be detected and updated accordingly.

Extracting an object type from Documentum and preparing it for migration-center 3.x

migration-center Client, which is used to set up transformation and validation rules does not connect directly to any source or target system to extract this information. Object type definitions can be exported from the respective systems to a csv file which in turn can be imported to migration-center.

One tool to easily accomplish this for Documentum object types is dqMan, which is used in the following steps to illustrate the process. dqMan is an administration Tool for EMC Documentum supporting DQL queries and API commands and much more. dqMan is free and can be downloaded at http://www.fme.de. Other comparable administration tools can also be used, provided they can output a compatible CSV file or generate some similar output which can be processed to match the required format using other tools.

1. Start dqMan and connect to the target DCM repository. dqMan normally starts with the interface for working with DQL selected by default. Press the [DQL] button in the toolbar if not already selected.

2. In the “DQL Query” -box paste the following command and replace dm_document with the targeted object type: select distinct t.attr_name, t.attr_type, '0' as min_length, t.attr_length, t.attr_repeating, a.not_null as mandatory from dm_type t, dmi_dd_attr_info a where t.name=a.type_name and t.attr_name=a.attr_name and t.name='dm_document' enable(row_based); Press the [Run] button.

3. Click somewhere in the “Results” box. Use {CTRL+A} to select all. Right-click to open the context menu and choose <Export to> <CSV>.

4. The extracted object type template is now ready to be imported to migration-center 3.x as described in the chapter Object Types (or object type template definitions) in the migration-center Client User Guide

Content Validation

The Content Validation functionality is based on checksums (an MD5 hash) computed for the document’s contents during scan (by the Scanner itself) and after import (by the Importer). The two checksums are then compared - for any given piece of content its checksums from before and after the migration should be identical.

If the two checksums differ in any way, this is an indication that the content has been corrupted/modified during/after migration. Modifications can happen on purpose or simply by user error and can usually be traced back based on the r_modifier and r_modify_date attributes of the affected object. Actual data corruption rarely happens and is usually due to software and/or hardware errors on the systems involved during content transfer or storage.

Validating content is always performed after the content has been imported to the target repository, thus adding another step to the migration process. Accordingly, using this feature may significantly increase import time due to having to read back every piece of content for every document and compute its checksum in order to compare it against the initial checksum computer during scan.

This feature is controlled through the checkContentIntegrity parameter in the DCM Importer (disabled by default).

Currently only documents scanned by Documentum Scanner or Filesystem Scanner can be used in a migration workflow involving Documentum Content Validation.

Renditions

The Documentum Content Validation also supports renditions in addition to a document’s main content. Renditions are processed automatically if found and do not require further configuration by the user.

There is one limitation that applies to renditions though: since the Content Validation functionality is based on a checksum computed initially during scan (before the migration), renditions are supported only if scanned from a Documentum repository using the Documentum Scanner. Currently this is the only scanner aware of calculating the required checksums for renditions; other scanners, even though they may provide metadata pointing to other content files which may become renditions during import, do not handle the content directly and therefore do not compute the checksum during scan time needed by the Content Validation to compare the imported content’s checksum against.

DCM Importer Properties

To create a new DCM Importer job specify the respective adapter type in the importer’s Properties window – from the list of available adapters “DCM” must be selected. Once the adapter type has been selected, the Parameters list will be populated with the parameters specific to the selected adapter type, in this case the DCM adapter’s.

The Properties window of an importer can be accessed by double-clicking an importer in the list, or selecting the Properties button or entry from the toolbar or context menu.

Common importer parameters

Configuration parameters	Values
Name	Enter a unique name for this scanner Mandatory
Adapter type	Select the “DCM” adapter from the list of available adapters Mandatory
Location	Select the Job Server location where this job should be run. Job Servers are defined in the Jobserver window. If no Job Server migration-center will prompt the user to define a Job Server Location when saving the Scanner. Mandatory
Description	Enter a description for this job (optional)

DCM importer parameters

Configuration parameters	Values
username*	User name for connecting to the target repository. A user account with superuser privileges must be used to support the full Documentum/DCM functionality offered by migration-center. Mandatory
password*	The user’s password. Mandatory
repository*	Name of the target repository. The target repository must be accessible from the machine where the selected Job Server is running. Mandatory
importObjects	Boolean. Selected by default; if NOT checked, documents and folders will NOT be imported. The reason for NOT importing folders and documents is to allow importing only relations between already imported folders/documents.
importRelations	Boolean. Determines whether to import relations between objects. In this case a relation means both dm_relations and dmr_containment objects. Hint: Depending on project requirements and possibilities, it can make sense to import folders and documents first, and add relations between these objects in a second migration step. For such a two-step approach the importer can be configured accordingly using the importObjects and importRelations parameters. It is possible to select both options at the same time as well and import everything in a single step is the migration data is organized suitably. It doesn’t make sense, however, to deselect both options.
importAuditTrails	Boolean. Determines whether Documentum(audit trail) migsets are imported or not. If the setting is false, any Documentum(audit trail) migsets added to the Importer will be ignored (but can be imported later, after enabling this option)
importLocation	The path inside the target repository where objects are to be imported. It must be a valid Documentum path. This path will be appended in front of each dctm_obj_link (for documents) and r_folder_path (for folders) before linking objects if both the importLocation parameter and the dctm_obj_link/r_folder_path attribute values are set. If the attributes mentioned previously already contain a full path, the importLocation parameter does not need to be filled.
autoCreateFolders	Boolean. This option will be used for letting the importer automatically create any missing folders that are part of “dctm_obj_link” or “r_folder_path”. Use this option to have migration-center re-create a folder structure at the target repository during import. If the target repository already has a fixed/predefined folder structure and creating new folders is not desired, deselect this option
checkContentIntegrity	Boolean. If enabled will check compare the checksums of imported objects with the checksum computed during scan time. Objects with a different checksum will be treated as errors. May significantly increase import time due to having to read back every document and compute its checksum after import.
ignoreRenditionErrors	Determines whether errors affecting individual renditions will also trigger an error for the object the rendition belongs to or not Checked - renditions with errors will be reported as warnings; the objects and other renditions will be imported normally Unchecked - renditions with errors will cause the entire object, including other renditions, to fail on import. The object will be transitioned to the "Import error" status and will not be imported.
defaultFolderType	The Documentum folder type name used when automatically creating the missing object links. If left empty, dm_folder will be used as default type.
preserveMCAttributes	Specifies a list of attributes that should be preserved upon import as set in migration-center, rather than set to the values DCM’s rules and lifecycle may set. The default selection of attributes listed here is a good choice for allowing controlled documents to be imported into any lifecycle state; the list can of course be edited depending on requirements.
loggingLevel*	Sets the verbosity of the log file. Values: 1 - logs only errors during scan 2 - is the default value reporting all warnings and errors 3 - logs all successfully performed operations in addition to any warnings or errors 4 - logs all events (for debugging only, use only if instructed by fme product support since it generates a very large amount of output. Do not use in production) Mandatory

On the | Migsets | tab, the user can select the migration sets to be imported with this importer. Depending on the chosen Adapter Type only the migration sets compatible with this type of importer will be displayed and can be selected for import. Also, only migration sets containing at least one object in a validated state will be displayed (since objects which haven’t been validated cannot be imported).

Available migration sets can be moved between the two columns by double clicking or using the arrows buttons.

Log files

A complete history is available for any DCM Scanner or Importer job from the respective items’ History window. It is accessible through the History button/menu entry on the toolbar/context menu. The History window displays a list of all runs for the selected job together with additional information, such as the number of processed objects, the start and ending time and the status.

Double clicking an entry or clicking the Open button on the toolbar opens the log file created by that run. The log file contains more information about the run of the selected job:

• Version information of the migration-center Server Components the job was run with

• The parameters the job was run with

• Execution Summary that contains the total number of objects processed, the number of documents and folders scanned or imported, the count of warnings and errors that occurred during runtime.

Log files generated by the DCM Adapter can be found in the Server Components installation folder of the machine where the job was run, e.g. …\fme AG\migration-center Server Components <Version>\logs

The amount of information written to the log files depends on the setting specified in the ‘loggingLevel’ start parameter for the respective job.