Overview
A global pharmaceutical company and Sitrof client uses FirstDoc R&D for managing their FDA submission content. After acquiring another life sciences company that were left with submission content in three disparate content repositories; one in FirstDoc and the other two lightly customized versions of Documentum. The company tasked Sitrof with defining the migration mapping requirements, evaluating configurations and customizations in the source system and implementing a technical solution in order to migrate this mission critical content and metadata.
Key points to consider when performing such a migration include:
- FirstDoc Object Model
- Migration of FirstDoc Configurations
- FirstDoc API
- FirstDoc Migration
FirstDoc Object Model
When performing a migration from one FirstDoc system to another, it is important to remember that FirstDoc interfaces rely on the FirstDoc object model to function correctly. The FirstDoc object model for the FDRD module is reproduced below:
All objects that extend from the fdk_document type are recognized by the FirstDoc interface to be FirstDoc documents. If types are to be mapped from one FirstDoc system to another, this is important since mapping to a type that does not extend from fdk_document will cause the document to become a normal non-FirstDoc document.
Properties of the fdk_document in all FirstDoc:
FirstDoc extends the Documentum Type architecture to Subtype, Unit, and Subunit. Thus, a mapping of the Types, Subtypes, Units and Subunits is required from one system to the other. This is usually achieved in the requirements gathering phase, after mapping has been decided upon. Furthermore, each FirstDoc module has other special mapping requirements which are unique to each module. For example, in the FDRD module, all FirstDoc documents extend from the r_and_d_document type which has the required attribute ‘product’. Each unique product is associated with a Product Dictionary in the FDRD system.
When migrating from one repository which has a different set of products to another, all product dictionaries must be created from the source system in the target one. Products may also be mapped from the source system to the target one in which case a new product dictionary does not need to be created. This is illustrated below:
For a successful migration of all documents, all products must be completely mapped or created in the target system since the FDRD module will not allow documents to have products which do not have a Product Dictionary.
Migration of FirstDoc Configurations
FirstDoc is a client-driven enforcement of server-side configurations, meaning that all FirstDoc rules and security are enforced at the Web layer. The rules are implemented and stored in the Content Server. Every FirstDoc configuration is associated with at the minimum a Type and a Subtype and at maximum the Unit and Subunit.
During migration, this presents us with two scenarios:
- All Types and Subtypes are mapped completely from the Source System to the Target System. In this case, migration of FirstDoc configurations might not be necessary--unless the configurations from the Source System to the Target system are in conflict with each other. In this case, the business owners of the source system and the target system must decide which configurations to keep.
- Some Types and Subtypes from the Source system are created as new Types and Subtypes in the Target System. In this case, the configurations associated with these type-subtypes might have to be migrated to the Target System. These new type-subtypes must also be added to the FirstDoc Dictionary of the Target System. To assist in the migration of the configurations, the FirstDoc CMU Tool could be employed.
FirstDoc API
FirstDoc provides developers with an extensive set of JAVA API to perform many of the server-side functions that are executed upon user-interaction. For the purposes of migration, only the API related to the following two functions are important:
- Refoldering API: Documents in FirstDoc are foldered according to their Type and Subtype. This is stored in a FirstDoc configuration. During import of the documents, one must run the Refoldering API so that the documents are foldered at the right place.
- Security API: Documents in FirstDoc inherit their ACL according to their Type and Subtype. This is also stored in a FirstDoc configuration and during import of the documents, one must run the Security API so that documents attain the correct ACL according to the FirstDoc rules.
The flow of the Import program is thus illustrated as below:
FirstDoc Migration
This section summarizes all the above points and provides a visual for the overall FirstDoc Migration:
