During our upgrade and migration work, we typically get asked the question “can OpenMigrate preserve the r_object_id during the upgrade process?” Clients typically look for this because they are using the r_object_id as the “link” between Documentum and another system (PeopleSoft, SAP, Custom….).
For this post, we will discuss why leveraging r_object_id for system connectivity is not a best practice.
Background
r_object_id is the unique attribute given to each sysobject in Documentum. The r_object_id is generated as a unique index per object/docbase and provides a quick method for retrieving content. Typically, in Documentum Webtop or any of TSG’s custom applications, we will use r_object_id as the link to retrieve the content or other attribute data. For example, the query to retrieve objects would look like
SELECT r_object_id, object_name from ……
The query results would be built with the object_name imbedded in the link
<a href=…?id=(r_object_id)>Object_Name</a>
It is important to understand that the r_object_id is only used in the context of the query and not saved anywhere in the system. For some organizations, it can be tempting to imbed the link above in any system that can store links (ex: SAP). It is important to understand that, if stored in another system, the r_object_id is not generated dynamically but is static. If the r_object_id changes as the result of a change of object type/migration, this link will be broken.
Open Migrate
OpenMigrate provides the ability to map any attributes during the migration from one object to a new object in the same or different docbase with the exception of r_object_id. This includes r_create_date and r_modify_date (via underlying tables or the super-user-id). OpenMigrate does not allow the updating of r_object_id for the following reasons:
- We have not discovered a reliable way of updating Documentum with the old r_object_id without going to the underlying database tables. We recommend mapping r_object_id to another custom field (ex: old_r_object_id) if necessary.
- r_object_id is a unique value assigned by Documentum. Assigning r_object_id within the application can cause unsupported and unexpected results from Documentum including the potential of duplicates and lost data.
- While r_object_id is the most efficient way to retrieve content, other indexed attributes perform almost comparably as the bulk of performance is typically content delivery – not content access.
Best Practice
- TSG recommends clients assign their own internal id for inter-system connectivity rather than leverage r_object_id as it limits the migration and upgrade options.
- Database Trigger is a great way to develop an independent unique identifier that can persist across migrations. (rather than custom development).
Pawan Kumar says
It is pertinent to mention that r_object_id encodes (contains) the numerical ID of the repository and that r_object_id is auto-generated by the Content Server. If you have multiple Documentum repositories in one installation, they should be using different repository IDs to avoid conflicts in accessing them from one client. In this recommended setup, it will be impossible to preserve the r_object_id attribute if you migrate objects from one repository to the other. You could use its value in another custom attribute as mentioned in the post.
Paras Jethwani says
If another custom attribute is used instead of r_object_id – then won’t that also require some customisation to the DRL or Weblinks components in WDK clients like Webtop or TaskSpace to use the custom identifying attribute to locate the document instead of the r_ojbect_id?
– Paras Jethwani