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.
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
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.
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.
- 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).