Andrew Chapman is presenting and is displaying his sense of humor.  The Slide title is “COM Based DCML API Implementation Models for Visual Basic Development Environments”. I suspect that is a an actual title from an old Developer Conference presentation.

• I guessed wrong, that title is from 1998 Momentum
• SharePoint Repository Services (Documentum as a back-end to SharePoint)
  • Not being covered in this session- SharePoint Content Services uses SharePoint as a client, aka Web Parts
• Zero impact on end-users
• Bring SharePoint into ECM infrastructure
• Increasing SharePoint operational efficiency
• Applying enterprise compliance controls to SharePoint content
  • Number 1 asked feature (I asked for it myself)
• Not for access content already in Documentum
• No Documentum functionality exposed with this product within SharePoint, but
• Shortcut solutions have issues
  • Can’t be full-text indexed
  • Breaks links as the shortcut doesn’t have the same name as the original document
  • They tend to ruin the MS Office integration, which is the awesome part of SharePoint usability
• Doesn’t “move” the content out of SQL Server, uses External Blob Storage (EBS) to store blobs/content in Documentum instead of SQL Server.
  • EMC EBS Handler intercepts the content on the way to the database.
  • Copy of the metadata is stored in Documentum, but still resides in SharePoint.
  • Invisible to SharePoint and the end-users
• Microsoft likes the solution and helped develop the product as it extends SharePoint, doesn’t replace it
• Benefits:
  • Operational: SQL Server Manageability (bakcups), HSM, De-duplification, Object-level restore (delete in SP, not in Documentum right away)
  • Compliance: Repository of record, Common Policy Management, Long-term archiving
  • Interoperability: Intelligent Archive, Repurpose/reuse
• Don’t delete it or change the ACL, but you can do some basic things behind the scenes if you are careful
• Word properties can go from Word > SharePoint > Documentum
• No versioning of the stored documents in the Content Server in the first release.
• The documents in Content Server knows which SharePoint objects to which they belong
• Two delete options:
  • 1: Delete will Delete from Documentum if it doesn’t have Retention blocking or otherwise protected. User sees it deleted though, regardless of what happens in Content Server
  • 2: Can just flag it as deleted in Documentum so you can run “purge” jobs to perform a delayed delete.
• Folder Structure can mirrors the SharePoint structure, which is deep, but easy to figure out (missed the 2nd option, but Andrew was kind enough to add it to the comments below.)
• Three meta-data mapping
  • 1: Basic reuses Documentum basic attributes: Name, Keywords, and Authors
  • 2: Advanced Mapping has a bunch of custom “MOSS” attributes that comes directly from SharePoint
  • 3: Can create custom Aspect that will look at the meta-data XML file (stored as rendition of document) to map items and perform actions. Sample code for now and may not be productized (Maybe a partner can write it)
• Configuration options
  • Mapping options
    • Mapping where it will be stored in Documentum
    • Minimum content size to redirect (Sweet!)
    • Delete from Performance Cache after write (Y/N)
      • Not so much a cache as a staging area to handle asynchronous operations in-case/when Documentum hiccups
      • Improves performance with on and liberates content in Documentum for full usage in Documentum
      • Accessible to SharePoint Web Front-End
      • If deleted from cache manually, system will retrieve Documentum again
    • Hard delete vs. Flag
  • Object Creation Options (Document Library granularity)
    • Default base folder in Docbase
    • User to own the content in Documentum
    • Object type to create in Documentum
    • ACL to apply in Documentum
    • Metadata mapping: Basic v Advanced
    • Folder creation: Full v Relative
• Information Rights Management on the Documentum level doesn’t work, needs to be on SharePoint level
• This solution is day-forward approach. A backup/restore of your site will kick EBS off, but it isn’t a recommendation, some customers are going to do it that way
• SharePoint full-text search is completely un-effected
  • Suppress the specific object type for indexing within Documentum if you do Federated Search so you don’t get multiple hits
  • Can index things faster as SharePoint may request it for indexing when it is still in the Performance Cache
• Solution does not deal with wikis, blogs, or comments, just documents in Document Libraries
• Priced on a per-SharePoint user basis
• EBS is enabled on a SharePoint Farm level

Off to the CenterStage Product Advisory Forum. No notes for that as it is NDA, but I’ll share what they let me, if anything, in a week or two.

Disclaimer

All information in this post was gathered from the presenters and presentation. It does not reflect my opinion unless clearly indicated (Italics in parenthesis). Any errors are most likely from my misunderstanding a statement or imperfectly recording the information. Updates to correct information are reflected in red, but will not be otherwise indicated.

All statements about the future of EMC products and strategy are subject to change at any time due to a large variety of factors.