Documentum Client for Outlook (DCO) – A cautionary tale in regards to message formats and object types – comment if you have experience to share.

We have two clients that are struggling with the combination of email formatting as well as the Documentum Client for Outlook (DCO) regarding format and different releases.  TSG doesn’t see a ton of DCO or email implementations so we thought we would share our client’s experiences here.  Please comment if you have any DCO experience to share.

Documentum Client for Outlook and storing emails in Documentum – background

Documentum offers multiple ways to store emails in Documentum.  They include:

• Documentum Client for Outlook – DCO provides for integration for users working in Outlook to drag emails (and attachments) into folders in Documentum.  As a client/server application, DCO has had some technical issues in the past but those will not be the topic of this post.
• Multiple Client Applications – Webtop and other interfaces (ex:  Desktop Client) have enabled users in Outlook to drag and drop emails and attachments into Documentum as well.

Emails are slightly different than other documents in that an email (one document) can contain attachments (additional documents).  Each needs to be stored in the repository as a separate object and the relationship between the email and attachment needs to be maintained.  The email also has additional metadata (To, From, Subject, Sent Date, Received Date) that should be maintained as attributes.   Documentum began with just storing .MSG Outlook format (Microsoft standard) as another object.  As you can read below, the move to store the email as more of a specific email type along with object types and formats has led to issues with long-term users.

Documentum Client for Outlook and email formats

Formats of emails, object types and attached documents are causing the most issues for our clients.   Below is a brief history of email formatting before expanding on the different client issues.

• Pre Documentum 5.3 SP3 – Emails could be stored as any type of object type, just like importing a Word or Excel document.  For applications like Webtop or Desktop Client, emails were stored as whatever default document type was being used or that the user selected during import, usually dm_document or a custom subtype. This approach lacked any storage of email specific metadata.  For both DCO and Webtop, the email format was .MSG (Microsoft standard for Outlook) Attachments were embedded within the MSG content and were not stored as separate objects.
• Pre Documentum 5.3 SP3 – Documentum Client for Outlook  – Emails were stored as dm_mail_message again in the .MSG format.   With this object type, certain meta-data was extracted from the email for subject and other fields but attachments were still stored embedded within the MSG file.
• DCO 5.3 SP3 – With the 5.3 release of DCO SP3, Documentum moved to a new dm_message_archive object type with movement from MSG format to EMCMF (proprietary format from EMC).  The EMCMF format (and DCO client) relies on splitting the attachments out of the MSG file and storing them as separate objects with a relationship between the email and attachments.   The format also requires a hidden folder in the same folder where the email is stored and places the attachment object(s) into that folder.  Given the new format, Documentum gave out a conversion utility to move all the old emails to the new email format.  Since the conversion of the outlook MSG format to EMCMF takes place in the Unified Client Facilities (UCF) – the migration tool was a client based tool.  The migration utility needs to run on a client and is not multi-threaded.  Seems like somewhat of a “hack” particularly if you have a large amount of emails to convert.   Initially, the utility forced de-duplication of messages. If the utility detected the same message id (in the email message header which is then stored in one of the dm_message_archive attributes) already stored in the repository, it would skip any later instances of the same message that were stored in other locations. While this might make sense for a litigation support application, it was completely unacceptable given that more than one user might each store the same message.  The other consideration with the conversion utility is that only dm_email_message can be converted to dm_message_archive.  For Desktop Client or Webtop users who had been importing messages as dm_document or a subtype, a preliminary conversion step had to be done using some other third party tool to get to dm_email_message before the utility could even be used.
• Documentum 6.5 – The conversion EMCMF utility was updated to not do the de-duplication but instead will store both emails as well as attachments in separate hidden folders.
• Webtop 6.5  – provides for a way to view emails but not as a MSG document (only as an HTML view).  The viewer does not have the ability to reply/forward or respond.  The only way to open as an MSG format would be to open from DCO client or export from Webtop at which point the UCF conferts the EMCF format back to MSG.
• DCO 6.7 – in the new release of DCO, the way DCO stores the document attachment relationships has changed.

Email Issues

Here are some the issues two of our clients are struggling with:

•  Client One –  is attempting to upgrade to DCO 6.7 as part of their Documentum 6.6 upgrade.  The client ran the migration utility on their 5.3 docbase.  Unfortunately, the new DCO client cannot read the old emails but can only read new emails.  The client is also disappointed that, in order to get emails in the MSG format, they are required to use the DCO (ironically, Webtop 6.6 can read both formats).  The client thinks something was lost regarding a change in relationships between objects and is working through the issue with EMC while their upgrade is delayed.
• Client Two – is a non-DCO user struggling with conversion.  The client was thinking of running the migration utility on their older documents (still in MSG format) but is very concerned about the utility running on the client side (they have 500,000 emails), being stuck in the proprietary EMC format, as well as having to move their older documents from dm_document to dm_email_message as a first step in the conversion process.

Please comment below if you have similar experiences and would like to share your thoughts and email strategy.