Momentum 2010 – MyDocumentum for SharePoint

As pointed out in yesterday’s post, we are reviewing the various SharePoint connectivity solutions from Momentum 2010 in Lisbon.    The best presentation was “Documentum and SharePoint Interoperability: Optimize SharePoint and Leverage Your Documentum Infrastructure” – by Andrew Chapman.

MyDocumentum for SharePoint

To start the post – quick review of the different SharePoint solutions and acronyms.

• Repository Services for SharePoint – works behind the scenes to move content from SharePoint Libraries to Documentum.
• MyDocumentum for SharePoint – MyDSP – Reviewed in this post – out of the box/configurable SharePoint WebParts.
• SharePoint Documentum Framework – SDF – Currently an EMC professional services offering of open web parts (not a product).

Andrew began the MyDocumentum for SharePoint presentation with a good definition of when to use MyDocumentum for SharePoint.  Repository Services for SharePoint is really focused on having SharePoint users “allows content to flow from SharePoint in one direction down to Documentum.”

Andrew posed the question “What if you have content and processes in Documentum and you don’t really want to roll out one of our clients to your users but they all have SharePoint?”

MyDocumentum for SharePoint is focused on:

• Provide access to DCTM content and interaction with ECM processes
• Native end-user experience….less training, less confustion
• Expand the reach of content management: ECM for the masses

Product has been designed from the beginning to work well with SharePoint.  While there are some differences (icons) – the goal is to have SharePoint users familiar with SharePoint to be able to work with minimal training.

What is coming in MyDocumentum for SharePoint 6.6?

• Subscription/Favorites Web Part – Documentum Subscriptions
  • Registered in the Content Server and are Site and Client Independent
• Single Sign-on Solutions – added Kerberos and MOSS SSO Plug-in
  • Kerberos allows the user to never have to log into Documentum
  • MOSS SSO supports different LDAP and requires log-in everytime password changes
• New Configuration Scope – Farm and Site
• New Configuration Tools – including Menu Item Configuration, Object Type Filtering, Search Properties Configuration
  • Object Type Filtering – provides the types to display for view and search, types to create.  TSG note – This is a great add as nothing is worse than users creating dm_documents.
• Search – Synchronized with Display, MOSS defaults or allows for custom
• Add Custom Item Level Menus – probably the most interesting – ties into SharePoint Documentum Framework (not a product) although Andrew mentioned ability to “add your own menus”
  • Launch Custom Web Parts/Application Pages
  • Menu and Sub-Menu
  • Can pass object-id and user-id
  • New Upload Import Control

Last point from one of the other presentations, for future releases

• MyDSP 6.7: “Runs in” SharePoint 2010
• MyDSP 7.0: “Designed for” SharePoint 2010

Not sure what that means but futures are always difficult to interpret.

TSG Thoughts

• We (TSG) are encouraged by the direction for MDSP 6.6.  Clearly Documentum is listening to clients in regards to additional functionality.  Since this will be the replacement for some clients Webtop clients, the ability to do common customizations via configuration (what documents can I create, required attributes, attribute logic) are all things that should be addressed.  All the above being said, until we try it, we need to withhold judgment – look for a deeper discussion in a future post.
• It is a Documentum Portal in SharePoint – Andrew does a nice job of pointing that out, while it looks like SharePoint, the interface is a Documentum Web Part running in SharePoint.  Things like Word connectivity, a key differentiator of SharePoint, do not work with the web part but work with the SharePoint Library Services.
• Other ECM vendors have emulated the SharePoint Protocol to have their ECM tool behave like SharePoint.  If I remember correctly, it was something the European union forced on Microsoft to publish the protocol.  It would be interesting to see if Documentum looks to this ability in the future.
• It is not a development framework – although the ability to add custom item level menus has us (TSG) very intrigued.  Will have to evaluate for common enhancements clients are asking for.
• Pricing – For most clients, the price issue is as big as any discussion in regards to functionality.  With the pricing model changing, it will be interesting to see if EMC prices MDSP to get over clients pricing issues.

Client Scenario

In discussing SharePoint with one of our clients, he thought it would be a good idea to post his scenario for feedback/input from our readers in regards to his “hybrid” scenario for  SharePoint.

• SharePoint users have already started using SharePoint for building sites wherever and SharePoint Libraries with documents.  This is consistent with Rick’s earlier keynote in that users want to use SharePoint for collaboration.
• At some point the document becomes a “record” and needs to be indexed and routed for approval and then managed within Documentum consistent with other records.

It is important to understand that:

• The document was initially created with SharePoint and not MyDocumentum for SharePoint.
• The client is requesting that the site and links they have created stay the same

We had looked into using Repository Services for SharePoint but that didn’t address the need of the client to have an interface for the user to add the required property indexing and kick off workflows in the Documentum repository.  The scenario we ended up building for it is outlined below (with small updates for maintaining the SharePoint site and document):

1. Document is created in SharePoint or other collaborative tools.  We are hoping that a standard template is used for consistency.
2. When the document is ready to be approved, the user initiates an action in SharePoint to copy the document to Documentum.  The security for the SharePoint document should be switched to “read only” in the SharePoint site.  The user could also initiate a simple import or bulk load for multiple documents (LAN drive example) from any Documentum interface.  Once in Documentum, the document is a compliance record and managed according to defined lifecycles, business processes and security.
3. Documentum Index and Workflow screen is launched from SharePoint to capture structured components (index values) as well as collect workflow approval values.
4. SharePoint users have access to Documentum approval from either SharePoint inbox or other interfaces.  Documents receive consistent electronic signatures via Documentum Trusted Content Services.
5. Once Document is approved, a PDF version is published into a consistent Compliance/Regulatory Vault.  As we have discussed in other posts, the vault might be outside of Documentum for business continuity, performance and licensing reasons.   The thought was to have the SharePoint site document replaced with an HTML document that points to the Vault.
6. Users can search the Vault from a variety of tools including SharePoint.
7. Documents include PDF Headers and footers, signature pages and real-time Watermarks (ex: use only on mm/dd/yyyy) for compliance, security and printed document control.
8. The ongoing check-in and check-out of the document is from Documentum only.  The HTML document stored in SharePoint would give an easy pointer back to launch Webtop or other interfaces to check-in or check-out.

Let us know your thoughts – we are working through a scenario involving some of our products.