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
- 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
- Mapping options
- 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.
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.
4 thoughts on “EMC World 2009: SharePoint Content Interoperability with Documentum”
Nice summary…for the Folder Structure the two options are
1) Relative – uses the site’s friendly name and then the folder structure. Cannot guarantee that it will be unique – for example if you have 5 SharePoint sites all redirecting their ‘Shared Documents/WIP’ in to one folder in Documentum then you will not easily know which content is from which SharePoint site.
2) Absolute – We add SharePoint site/server data to qualify the path so that it is guaranteed to be unique, for example… Ce28980d-e147-4ede-902d-c6fb8e3540c9/qasvr65:80/sitename/Shared Documents/WIP
Rest of it looks good.
Andrew, thanks for the feedback. I appreciate it greatly. Now I know what I can tell people and can stop guessing.
Question about EBS: Above it states that EBS doesn’t “move” content. It’s intercepting it and storing it in Documentum. I take that to mean that EBS isn’t going to move already existing documents stored as blobs in the SharePoint database, but anything new will be “kidnapped” and stored (the way it should be) in Documentum and in it’s place is a “blob pointer” which is stored in SharePoint. Correct?
While there isn’t versioning in the Content Server for the first release, I can see a workaround for this by constructing a simple TBO to handle that. Super easy to do. I wrote one for a batch import processes. All the logic needs to do is:
Does it already exist with the same name in the same folder?
Yes? Then save document as new version.
No? Then create as new document.
Wash, Rinse, Repeat.
Chris, you are correct. Repository Services, and any solutions using EBS, is a point-forward solution. There are a few ways around this, though none are elegant.
As for versioning, you are correct about writing a TBO to do this. It wasn’t simple enough for them to accomplish in the release window as it wasn’t as simple as they assumed. It will be in a future release barring any unforeseen issues. I think it was something weird with the object ids, but I didn’t get into it in much detail as I’ll get to play with it soon enough.
Thanks for your thoughts, all of them.
Comments are closed.