Default Email Notifications

The information provided in this post is tested under the following environment.
Documentum        :6.5 SP2
Database         :Oracle 11g
Operating System  :SUSE Linux Enterprise Server 10

This post is about the default email notifications from a Documentum System.

I would classify these notifications broadly into three categories.

1. Workflow Notifications: The email notification received when a WorkItem is assigned in the user’s documentum inbox
2. Document Notification: A Read/Write notification for a document for which user has registered
3. Jobs Alerts: This includes
• Job/Agent Exec failure alerts
• Alerts regarding Environment’s health from default jobs

The important point to note is that I am not claiming that these are the only email notifications send by Documentum. Further the categories of email notifications are not the actual scope of this post.

So moving ahead; if we wish to take benefit of these email notifications the most important thing is that our documentum environment should be capable of sending email notifications. This is achieved through a SMTP server. So, the first thing one would like to check is whether a SMTP IP address is defined in the Server Config Object.

SELECT object_name, smtp_server FROM dm_server_config;

If one is lucky enough to have a SMTP Server configured, the next interesting thing would be to verify whether the configured SMTP server is capable of doing what it is supposed to do. In addition it should also be reachable from the Content Server Host.

The following instructions can be used to test it. The text in blue is the user input.

Use Putty to connect to the Content Server Host and login using the Installation Owner’s account. Connect to the SMTP Server using Telnet.

mypc:~> telnet <smtp ip> 25
Trying <smtp ip>...
Connected to <smtp ip>.
Escape character is '^]'.
220 <smtp host> ESMTP Thu, 7 Jul 2011 11:53:25 -0400
HELO Me
250 <smtp host> Hello [<content server host ip>], pleased to meet you
MAIL FROM: from@email.com
250 2.1.0 from@email.com... Sender ok
RCPT TO: my@email.com
250 2.1.5 my@email.com... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
This is a sample test email
.
250 2.0.0 p67FrP9G027974 Message accepted for delivery


You should feel quiet happy if you receive the intended email. Your SMTP server seems to be working just fine.

If the SMTP server is working absolutely fine then we may like to verify whether documentum is able to use the SMTP Server as per expectation. Documentum uses dm_mailwrapper.sh to call the mail program. dm_mailwrapper.sh resides in $DM_HOME/bin and by looking at it’s content it can be figured out that it is called in the following way.

mypc:~>/documentum/product/6.5/bin> ./dm_mailwrapper.sh "This is the Subject" "my@email.com" testcontent

testcontent is a text file which contains the content of the email message.

dm_mailwrapper.sh uses the mail program to send the emails. mail program can be tested using the syntax given in dm_mailwrapper.sh.

mypc:~>/documentum/product/6.5/bin> /bin/mail -s "This is the Subject" "my@email.com" < testcontent

By default all the Documentum email notification are in plain text. Documentum uses dm_event_sender method (dm_method) which by default uses dm_event_sender.ebs to generate the email content. The Verb of dm_event_sender method can be modified to use dm_html_sender.ebs and it starts generating the email content in HTML. But generating HTML content is not enough. sendmail program can be used in order to make sure that the email is rendered as HTML. dm_mailwrapper.sh can be updated as follows.

#/bin/mail -s "$subject" "$address" < $content_file
/usr/lib/sendmail -io "Dummy Subject" "$address" < $content_file

Before updating the dm_mailwrapper.sh do make sure that the sendmail program is sending emails. The content of testcontent can also be updated as HTML while doing so.

With the above two changes in place we should start getting the email notifications in HTML format. No, there is no need to restart anything. I indeed got few issues with the content of Workflow and the Jobs notification. Those issues were fixed by commenting few lines in the dm_html_sender.ebs. The content of the email notification can be customized by customizing dm_event_sender.ebs for plain text notifications and dm_html_sender.ebs for HTML notifications.

Content Server High Availability Installation

There are a lot of discussions on various forums/threads regarding the Content Server High Availability Environment. But I have not come across any documentation providing the precise steps to implement it. This is an attempt to list the steps that I have been using for the implementation. It’s basically an integration of bits and pieces from various sources combined along with my experience in order to put a clear picture. These steps may not be exactly as suggested and supported by EMC.
The procedure listed below is specific to the Content Server Linux Oracle 6.5 SP2 version.

Prerequisites:

• As it’s a HA environment, the content files should be present in a File Store that is shared across the Content Servers.
• The Installation Owner and the Installation Path should be same on each Content Server.
• Availability of a Database Server and its connectivity through each Content Server Host using Oracle Client.
• Update the /etc/hosts file of the Content Server Hosts so that they can resolve their IP addresses and hostnames.

Once the above prerequisites are satisfied, the below steps can be used to establish the HA environment.

• Install the Primary Content Server as per the standard procedure mentioned in Installation Guide.
• Install the docbroker on the Secondary CS host.
• Create a Secondary Server Config object using Documentum Administrator.
• Copy server.ini, aek.key, dbpasswd.txt, dm_start_docbase and dm_shutdown_docbase from Primary CS Host to Secondary CS Host.
• Update the server.ini on both the Hosts so that the docbrokers project to each other.
  server.ini on the Primary CS:

  [DOCBROKER_PROJECTION_TARGET]
  host = <primary docbroker>
  port = 1489
  [DOCBROKER_PROJECTION_TARGET_1]
  host = <secondary docbroker>
  port = 1489

  server.ini on the Secondary CS:

  [DOCBROKER_PROJECTION_TARGET]
  host = <secondary docbroker>
  port = 1489
  [DOCBROKER_PROJECTION_TARGET_1]
  host = <primary docbroker>
  port = 1489

• Update the dm_shutdown_docbase as follows: 
  The line preceding to “shutdown,c,T,T” should be updated as follows:
  • Original:

    ./iapi <docbase> -U$DM_DMADMIN_USER -P -e << EOF 

  • Updated:

    ./iapi <docbase>.<secondary server config object name> -U$DM_DMADMIN_USER  -P -e << EOF

• Update the dfc.properties of the Web Application as well as both the Content Server Hosts so that they point to both the docbrokers.
• Create an ACS Config object using the below command:

  dmbasic -f dm_acs_install.ebs -e Install -- <docbase name> <installation owner> <password> <new acs config name> <secondary server config name> <JMS Port> <JMS protocol> <output log location>

• Update the acs.properties accordingly.
• Once the above steps are complete, shutdown the Primary CS and test the Secondary CS for expected functionality. There may be minor issues which may need few basic fixes. Such fixes include creation of sysadmin directory at $DOCUMENTUM/dba/logs/<repository id>/ in order to fix issues relating to jobs running on Secondary CS.

Start the Primary CS and now both the CS should be in HA.