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.

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

    • In my organization we use a product called Oasys Mail Manager, it’s easy to file emails and includes the most powerful search UI that I’ve ever come across.

      • Alan – I think you’re referring to email management on your desktop. This article is about how to store and manage emails in an ECM repository, not on an individual’s desktop PC.

  1. We are a non-DCO customer and we looked into converting from email stored as dm_document subtype, .MSG format in 6.5 SP2. To even attempt to test the migration utility we had to get special access and permission to use the docapps for DCO since the client-based utility required a bunch of the doc types, etc. from DCO. Once we got all the pieces working, and bugs in the utility fixed, plus a 3rd party app to get to dm_email_message, we eventually decided it wasn’t worth the effort.
    And if EMC ever goes away from the EMCMF format, I’d hate to have to move it all back!
    We’ve now upgraded to 6.6 and would have to start the whole investigation from scratch – not planned.
    Biggest drawback to our existing setup is that we cannot search on email-specific attributes (to, from, subject, received date, sent date, etc.).

  2. This just in from EMC:

    The current product strategy for 2012 plans to address this issue as follows:

    MyDocumentum for Microsoft Outlook will shift from using a proprietary email message format (EMCMF) to storing email message in their native format, .msg. The MS Outlook integration will manage its specific email properties (To, From, Date, etc.) via an aspect attached to the email object. Other Documentum clients, such as Webtop which do not handle aspects, will simply not show these email properties.

    Leaves me with more questions than answers.

  3. On the 4i Days with desktop client. Outlook integration was native to that client. And the function was basically performed by the “import” component. I actually did an Import customization that was able to take the relevant email attributes and also import the attachments separately forming a virtual document. The email message was a custom doctype with the basic email attributes and the attachments could be any doctype.
    I really miss this functionallity on recent versions. We sold DCO to one of our customers (Oil and Gas company) and have nothing but trouble with DCO even on 6.7 version (tested v. 6.5 SP3, 6.6, 6.7, 6.7 SP1) and different things failed on each of this versions:

    1. Used a propietary lightweight object not a standard dm_document so didn’t match the designed doctype infraestructure wich derived from dm_document

    2. Properties functionallity didn’t worked with value assistance

    3. TBO’s weren’t working either as validations where not transmitted to the UI by the product.

    We still think that DCO could be a good solution if EMC had built it with good enough quality process that could match Documentum’s basic functionality. But as today it’s unusable other than to store it’s OOTB attributes an standard functions

Comments are closed.