Following PanfilovAB‘s post regarding Documentum email notification system and his customization (read it here: blog.documentum.pro/2014/08/04/e-mail-notifications) I decided to improve my own mail customization by adding the Groovy library in order to get advantage of the customization possibilities.

So, what does Documentum provide by default? Let’s see: Depending on the value stored in the mail_method attribute found in dm_server_config, CS will use:

• dm_event_sender: Notifications will use dm_event_sender method. This method uses dmbasic to run $DM_HOME/bin/dm_event_sender.ebs. This EBS defines a plain-text email template for each of the possible events generated by the CS and sends the email by running the binary mail.exe bundled with the CS.

• dm_html_event_sender: Same behaviour than dm_event_sender, but the email templates are HTML templates. In order to use it, dm_event_sender must be modified to use the $DM_HOME/bin/dm_html_event_sender.ebs script.

• [BPM] dm_template_event_sender: When BPM is intalled in the CS, a new servlet (DO_METHOD) is deployed in JMS. mail_method attribute is updated with this placeholder to use the servlet instead of running a method. When an event generates a notification, a POST is send to the do_method servlet and the notification is processed. If the event is a workflow event, the servlet will process it applying (if has been previously defined) a JSP template and sending the email with Java Mail. Otherwise it will forward the notificacion to the dm_event_sender method.

• mail method: There’s also a method that allows a “direct call” to mail.exe, as long as you provide the necessary parameters.

So, what main problems/limitations do we have?

• If you have BPM installed, you have 3 different entry points to a new mail:
  • event_sender
  • html_event_sender
  • JSP templates

So if you update one template, you have to update every file to keep consistency

• When migrating CS, you have to be careful not to overwrite/remove your customized EBS. And if “something” has changed you’ll have to recheck your existing templates. Meaning you’ll have to enjoy the “power” of dmbasic and its great debugging capabilities (yes, that means writing to an output file)

So, when I read Andrey’s solution using Groovy I realized that if you have to modify your email templates “often”, that’s the way to go. So, what do we need?:

Documentum container with two components and a custom method:

• List templates
• Edit template
• Custom mail method

List template will be a listbox showing the documents returned by a query that fetches our custom templates located in a special folder:

For ease of use, the name of the document indicates the event that uses the template and, if applicable, the r_object_id of the activity that uses the template, allowing further customization.

Edit template will be a component that loads the content of the selected template into an editor (codemirror, check Andrey’s updated post to see a “nice” implementation as WDK control), a sortablelistbox that will allow the user to put temporal values to be replaced in the template for preview, and the preview button that will generate the final email applying the submitted values to the template. This component has a <inputvars> element in its definition that defines default values to be already filled (docbase_name, user_description, server_url, etc).

Now, I only need to improve my mail designing skills

Finally, a custom Java method that will replace dm_template_event_sender and that will run a java class that generates the email body and sends the email.

What do we get with this customization?

1. Get rid of dmbasic email notificacions
2. Unify email notifications (it will only use the defined templates)
3. Simplify email management (my “default” template now has 200 lines, while my “default” dm_event_sender has 1400)
4. Easier upgrade process