Documentum is an enterprise content management platform providing services to manage all types of content such as document, audio, video, etc. Email notifications play a major role in any application. Documentum provides in-built features to send email notifications. Below are some of the key points to configure email notifications for your applications.
1) Documentum Events
Most Documentum email notifications are triggered by events in the repository and correspond to tasks and messages that get queued to a user’s Documentum Inbox. All out-of-the-box Documentum email notifications originate from one of the three sources:
- Jobs (Events like Job_Failure, Agent_Exec_Failure)
- Registered Events (Events listed in dmi_registry table)
- Workflow Tasks (All workflow and router events)
Following events can be considered for notifications:
|//General repository events:|
|dm_checkin||Document checked in|
|dm_checkout||Document checked out|
|dm_fetch||Document fetched/retrieved by particular user session|
|dm_branch||Added new branch to the version tree of the document|
|dm_prune||Removed a branch from the version tree|
|dm_mark||Mark the object|
|dm_save||Save the object|
|dm_status||Change the status of document|
|dm_link||Link the document to new folder location|
|dm_unlink||Unlink the document from folder location|
|dm_archive||Document archive operation requested|
|dm_archive_done||Document archive operation performed|
|dm_restore||Restoration requested for object|
|dm_restore_done||Restoration done for object|
|dm_getfile||Document read operation|
|Job_Failure||Job failed to execute|
|Agent_Exec_Failure||agent_exe_method failed to execute|
|DM_SYSADMIN||Posted event in docbase|
|dm_end||Terminated the operation|
|dm_halt||Halted the operation|
|//Workflow and router events:|
|dm_acquire||Acquired the object in workflow task|
|dm_force||Forced task to READY state|
|dm_forward||Forwarded object in a workflow task|
|dm_reassign||Reassigned workflow task to new performer|
|dm_route||Routed the object|
|dm_reverse||Rejected the object|
|dm_startedworkitem||New workitem started for a workflow instance|
|dm_selectedworkitem||User selected/acquired particular workitem for processing|
|dm_completedworkitem||User completed workitem|
|dm_pseudocompletedworkitem||Server completed workitem|
|dm_reassignedworkitem||User reassigned workitem|
|dm_delegatedworkitem||User delegated workitem|
|dm_createworkflow||Created workflow instance|
|dm_startworkflow||Started workflow instance|
|dm_terminateworkflow||Terminated workflow instance|
|dm_abortworkflow||Aborted workflow instance|
|dm_changestateworkflow||Changed workflow state|
|dm_changeworkflowsupervisor||Changed workflow supervisor|
|dm_abortactivity||Aborted workflow activity|
|dm_autotransactivity||Selected route case for workflow autoactivity|
|dm_changestateactivity||Change activity state|
|dm_changestateprocess||Changed process state|
2) SMTP Account for Sending Emails
By default, Documentum uses SMTP to send email notifications. For email notifications to work properly, the Content Server’s installation owner (dmadmin) should have a user account with the SMTP server. This is the account specified in the user_address attribute of the dm_user object that has the same user_name as the OS account that installed the Documentum server software.
The installation owner’s account will appear in the “From” field of emails sent from the Content Server. In other words, Documentum email notifications will appear to have been sent from the installation owner.If you have configured SMTP server while installing Content Server, the value appears in attribute dm_server_config.smtp_server.
Note: This value can be used only in Windows-based systems.
3) UNIX Platform
Below flow chart explains how email notification works on UNIX based systems and where to look for email related methods.
|File Name||Path on Content Server||Type|
For UNIX env a shell script command “dm_mailwrapper.sh”(Documentum/product/6.7/bin) will be executed for sending mails.
By default, notifications will be sent to owners/superusers, or in case of workflows, group of performers.
Now, if you don’t want to send notifications to workflow performers but to specific mail group, you can customize the dm_mailwrapper.sh
/bin/mail -s "$subject" "address" < $content_file
Here in place of address you can put your common group id
/bin/mail -s "$subject" "firstname.lastname@example.org" < $content_file
4) Disable Email Notifications
Turn off all email notifications
If you want to turn off notifications globally for all events, you need to update your content serverserver.ini file at path "$DOCUMENTUM\dba\config\documentum\server.ini" with valuemail_notification = F
Turn off notifications for some users only
Update dm_user object and remove the attribute value set for user_address for a user you don't want to send email notification to.
Update dm_user OBJECT set user_address = '' where user_name='$user_name$';
Turn off notifications for some events only
Update the dm_event_sender.ebs script and do “exit sub” for the events you don't want to send email notifications.
e.g. Stop mail alerts for dm_startedworkitem event
object_info_flag = "false"
task_event_flag = "false"
router_event_flag = "false"
subject_line = "Started workitem: " & CleanQuote(package_id) & " in docbase " & CleanQuote(docbase_name)
5) Useful Queries
Changing SMTP server configuration
Select smtp_server from dm_server_config;
Update dm_server_config OBJECT set smtp_server = '
To get the method name used for email notifications
Select method_verb from dm_method where object_name='mail'
To get email address set for any user
Select user_address from dm_user where user_name='$user_name$';
To change event sender method
Update dm_method OBJECTS SET method_verb = ".dmbasic.exe -f.dm_html_sender.ebs -eMail" WHERE object_name = 'dm_event_sender'
EMC release notes for: Email_Notification_Troubleshooting_Guide.pdf