Helpful tool
One of Documentum’s strengths is its strong object orientation and the possibility to define custom object types (the so-called doctypes) which inherit both attributes and behaviors from their ancestor type.
There are many cases when exporting a portion or the complete types’ hierarchy of a given repository in a readable format is really useful:
- inserting a description of a subset of a doctypes in a documentation
- quickly visualizing the hierarchy of doctypes while discussing design decisions
- …
Although it has not always been officially publicly published, the “Documentum Object Relational Diagram” has always been one of the most useful technical documentation of the platform. This diagram presents the different “system” object types of the platform and their relations.
Extract from the Documentum Object Relational Diagram for 6.0
But what if you want to easily visualize your custom doctypes (and ideally link those to the existing out-of-the-box/system doctypes)?…
View original post 970 more words
I am willing to wager you are already familiar with the iAPI32* and iDQL32 command line clients for Documentum. (If not, these clients allow you to run API commands and DQL queries from the operating system command line. They can be found on the Content Server at %DM_HOME%bin.) But did you know there are a few not-so-obvious commands that these clients posses that make them easier to use?
iAPI32
?
You can run DQL queries and retrieve query results directly from the iAPI32 interface by using the ‘?’ command. The ? command allows you to enter a DQL SELECT statement in iAPI32 and returns the results immediately, just like iDQL32. This is a very handy if you are working in iAPI32 and need to run a quick query.
API>?,c,select r_object_id, object_name from dm_document where folder('/Temp');
---------------- -------------------------------------
090000018000151b Room Upgrade Fri Oct 16 14:28:27 PDT
0900000180001d05 TargetSetup.Result
0900000180007941 VD…
View original post 442 more words
One of my Documentum system administrators continued to get messages like the one below:
Job “dm_StateOfDocbase” failed to execute successfully. The message was:
“[ERROR] [AGENTEXEC 3836] Detected while processing dead job
dm_StateOfDocbase: The job object indicated the job was in progress, but the job was not actually running. It is likely that the dm_agent_exec utility was stopped while the job was in progress.”——————————
COMPUTER-READABLE DATA
——————————
>>>begin_data_block
>>>data_block_type=docbase_event
>>>data_block_name=none
>>>docbase_name=globalregistry
>>>event_name=Job_Failure
>>>sender_name=dmadmin
>>>recipient_name=dmadmin@mail.com
>>>recipient_login_name=dmadmin
>>>object_name=dm_StateOfDocbase
>>>message_text=[ERROR] [AGENTEXEC 3836] Detected while processing dead
>>>job dm_StateOfDocbase: The job object indicated the job was in progress, but the job was not actually running. It is likely that the dm_agent_exec utility was stopped while the job was in progress.
>>>queue_item_id=1b0000000000d919
>>>end_data_block
Though not serious, it is troubling and if it doesn’t self-correct, it needs to be investigated. Robin East wrote about this problem in depth in his post http://robineast.wordpress.com/2008/01/. I will give…
View original post 197 more words
Check if your java method server is up and running. Try accessing the following url
http://<hostname> : 9080/DmMethods/servlet/DoMethod
It should show “Documentum Java Method Server”.
1) Docbroker – Independent of any other application
2) Repository – Dependent on Docbroker
3) Java Method Server – Dependent on Docbroker and Repository
4) Index server – Independent of any other application
5) Index agent – Dependent on Index server
For startup follow the steps from 1 to 5 and for shutdown follow the reverse steps.
[UPDATE] In version 5.3 SP6 and later, the semantics of “first file” mentioned below is the file at page 0 of the attached content object (no matter how many times the content object has been replaced via “check in as same version”). I don’t have access to an environment where I could try to reproduce the behavior related to check in as same version discussed below. See the discussion in comments for more information on the current behavior.
Of course, I could retrieve the document using one of the available mechanisms (Webtop, DFC, API, etc.) and save it locally and then inspect the file size on the filesystem.
However, if all I wanted to know was the size of the document in the repository one would think it should be easy to tell from the metadata. Well, it is in most cases but if you really wanted to be sure…
View original post 467 more words
Query to get the all list of events registered for auditing
select r.registered_id, r.event,r.user_name
from dmi_registry r
where r.is_audittrail = 1
Query to get list of events corresponding to the object types registered for auditing
select t.name,r.event,r.user_name,t.name
from dmi_registry r, dm_type t
where r.is_audittrail = 1
and t.r_object_id = r.registered_id
Query to get list of events corresponding to the user types registered for auditing
select t.user_name,r.event,r.user_name
from dmi_registry r, dm_user t
where r.is_audittrail = 1
and t.r_object_id = r.registered_id
SET “object_name” = ‘location_name’,
SET “file_system_path” = ‘file_system_path’,
SET “path_type” = ‘directory’;
target_store=’filestore_name’,
max_migrate_count=10000,
remove_original=True,
sysobject_query=True,
log_file=’log_path’,
query=’r_object_id in (select r_object_id from dm_document)’
After creating new types in documentum or updating existing type, we may come across situation that it is not getting reflected so we have to clean and publish the data dictionary.
Use the below API to publish Datadictionary after updating attributes using
publish_dd,session[,locale][,type][,attribute][,force_publish]
To flush any cache, use this
flush,session,cache_keyword,[object_type][,reset_change_bit][,include_subtypes]
cache_keyword can be one of the below:
querycache, to flush the user’s persistent query cache
aclcache, to flush the ACLs in the session cache
groupcache, to flush the groups in the session cache
ddcache, to flush the data dictionary objects cached on the client host
registrycache, to flush registry objects in the session’s registry cache
persistentcache, to flush the objects and query results in the user’s persistent client cache
persistentobjcache, to flush the objects in the user’s persistent client cache
Finding an Object’s Content File
Everyone knows that Documentum (in its default state) stores content on the file system and retains a pointer to the content in its database. Likely, you have navigated the file store on the Content Server and discovered directories like ..datadocbasecontent_storage_0100000180 0023. How in the world does this directory structure relate back to a particular object?
Documentum uses several objects to hold persistence information about content; we will use five of them to determine where the content for an object with r_object_id = '0900000180023d07' resides: dmr_content, dm_format, dm_filestore, dm_docbase_config, and dm_location. The following query will get us all the information we need to assemble the path to the object’s content.
select data_ticket, dos_extension, file_system_path, r_docbase_id from dmr_content c, dm_format f, dm_filestore fs, dm_location l, dm_docbase_config dc where any c.parent_id = ‘0900000180023d07’ and f.r_object_id = c.format and fs.r_object_id = c.storage_id and l.object_name = fs.root
Result
data_ticket = -2147474649
dos_extension = txt
View original post 268 more words
dump dm_documentum 