Documentum, So Close and Still So Far Away with SharePoint


Apologies to Andrew on this post, but I’ve got to get everything out of my system before I learn anything new NDA items about the two products working together. I think EMC is moving in right direction on these products, but they aren’t there yet. That being said, their current approach is easily the best that I’ve seen, and I’ve seen a lot.

Before you read this post, read my EMC World notes on SharePoint Repository Services and Content Services for SharePoint. That should help with the background.

Why SharePoint Repository Services Rocks

This is the product that Andrew has been hinting at for a long time on his blog. It uses External Blob Storage (EBS) to intercept content being stored in the SQL Server database and places it in the Documentum Content Server.  The most important details of this product are that it has ZERO impact on the user interface and is completely independent of any customizations that may be made to SharePoint by the organization.

It is only a point-forward solution, but if your SharePoint system is still functional and not bogging down, it can keep it that way. A backup-and-restore of your SharePoint site can get things moved into Documentum, but that should only be done by experienced people. I’ve yet to meet anyone who considers such a procedure routine, so it should only be done if necessary to take a SharePoint site that is suffering from too much content and get it all into Documentum.

Now there are a couple of flaws, like SharePoint versions being stored as separate documents in the Content Server, but is just one way that things aren’t as simple as they seem. This flaw is going to be addressed in a future release and only exists due to some fun complexities in how SharePoint manages versions. It does lead to some other issues.

Where the Solution Falls Down

So here is the basic problem, or problems. All of that content can’t really be interacted with through many normal Content Server based interactions.  Oh, there are some basic things you can do, but you can’t change the security and I suspect the ability to create new versions within Documentum and having them appear in SharePoint may be tricky.

Don’t forget that a versioned document in SharePoint spawns multiple objects in the Documentum Repository. That makes some actions difficult.

Of more importance is the fact that you can’t start declaring records directly from the SharePoint Document Library or see documents within SharePoint that originate from within Documentum. You can do those things using Content Services, but that is a Web Part and IS something different for the users to use.

And don’t get Chris Campbell or I started on the lack of any workflow interfaces in the solution as a whole, but that is another post.

What Can Be Done?

Um…Nothing? I’m not sure what can be done. This is a very complicated problem. To make things work in a way that will be seamless to the user while enabling all the requisite functionality is going to require a much more intrusive SharePoint customization process.  To complicate things, SharePoint 2010 is on the horizon with its 64-bit architecture and CMIS support. What that will mean to users is unknown at this point.  What it means to developers of SharePoint solutions is that they should be careful to not invest too heavily in items that won’t carry forward into SP 2010 readily.  Web parts are probably good, and probably EBS, but everything else is risky.

These are still two different systems and nothing in the near term is going to change that for anyone.  Content Services for SharePoint may be a decent client into Documentum, but it ignores existing SharePoint Document Libraries and is not the perfectly seamless answer.  Repository Services is a great way to add some advanced ECM services behind the scenes of SharePoint, but it has several limits.

The problem is we need both, and in a way that inter-operates well. After a few years of watching many different vendors attempt this, I’m not sure if it is even technically possible given the constraints of integrating into SharePoint. EMC is moving in the right direction, but I’m not sure the desired state is possible.

Any bets on whether or not SharePoint 2010 will make this all easier? I know which way I’d bet.

11 thoughts on “Documentum, So Close and Still So Far Away with SharePoint

  1. If you take out the SharePoint from your post and insert the word eRoom – it sounds all to familiar. EMC never seemed to get that interaction right either, even after all this time.

    Like

    • True, it does feel that way at first glance, but I think that EMC understands the goals they are trying to reach. This offering is already in many ways better than the eRoom integration with Documentum. They are also planning improvements and queried the audience as to where they should invest their resources. It wasn’t a courtesy question either as they sincerely wanted the input.

      This isn’t a case of them not getting it or not caring. With eRoom, EMC owned both sides, but stopped. With SharePoint, EMC has no control over SharePoint but EMC is pushing forward regardless. Time will tell, but they appear to be pushing as hard as they can to reach the finish line. It is just a long way off for everyone.

      Like

  2. I hope it will be possible to find a solution for the integration of Documentum in Sharepoint 2010. But this should be based on the cost-effective approach certainly.

    Like

  3. Jure says:

    Do you know maybe the max size of content that can be uploaded to SharePoint through Repository services and on to Documentum?

    We have a client that wants to use repository services and store content to documentum – but has huge files 2GB size max.

    Thx for answer

    Like

  4. I don’t know of any theoretical maximum limitation but I’d be pretty confident that it would be much larger than SharePoint or IIS would allow. We did performance and scale testing with multi-GB files but I don’t think that we took it to any crazy sizes because whatever we put away has to get through the SharePoint stack first.

    FYI – Repository Services takes the file from the underlying file system and uses DFS to load it into Documentum. If DFS has a limitation then that would be it I guess.

    Like

  5. Kristoffer says:

    Repository Services is a great product for what it was designed to do. It supports MOSS2007 and SP2010, but what about the next version of SharePoint?

    With the release of SP2010 Microsoft announced they would deprecate EBS in favour of Remote Blob Storage (RBS) which sits at the SQL Server level. It has an extension into SP2010 and will be the only way to externalize BLOBS in future releases of SP.

    EMC already have an RBS connector to Centera, available since 2008, for free download on the EMC Community Network. Would be good to hear if IIG will port the EBS features of Repository Services to support RBS?

    Kristoffer

    [Combined your comments into one]

    Like

    • Aside from the fact that this post is 2 years old, thanks for commenting…

      That said, your observation is still relevant. I have been told on multiple locations that they are looking at the possibility of moving to RBS or other methods of maintaining the functionality in future editions. I first heard of the deprecation of EBS from EMC at least a year ago, so they are aware and making plans. EMC is also working with Microsoft on this issue.

      Not indicating that all will be well as some of it is still in the hands of Microsoft, but EMC is aware and working on a solution.

      Like

Comments are closed.