MyDocumentum for SharePoint Part II

We (TSG) just finished an evaluation for one of our clients of MyDocumentum for SharePoint. Initially, the client wanted to leverage the MyDocumentum for SharePoint product as part of their effort to have SharePoint users contribute content to Documentum. The client had unused licenses to the product as part of their enterprise purchase agreement.

As we mentioned in our MyDocumentum for SharePoint review, currently MyDocumentum for SharePoint does not have a software development kit (SDK) for extending the Web Part. For the client, this turned out to be a critical missing component. This post will discuss the client’s need for others considering evaluating MyDocumentum for SharePoint.

Ingesting SharePoint Content

Initially, the client had considered leveraging MyDocumentum for SharePoint as a way to ingest SharePoint content into Documentum through extension of the SharePoint interface. A couple of years ago we, TSG, developed a similar example for another client – screencam is still available in our Learning Zone. In reviewing the product, MyDocumentum for SharePoint treats SharePoint as a portal or entry way into Documentum within the SharePoint framework. All content must be initially indexed into Documentum and would never exist in SharePoint. The team saw this as a concern since the current user base is used to storing the content in SharePoint and might get confused by the multiple methods to store content. The team looked as possibly leveraging Repository Services for SharePoint but determined early on that it didn’t meet indexing needs. (look for an upcoming post for more detail)

Storing Documentum Content

The scenario required by the client focused on the ability to easily add content to the repository. For Documentum users familiar with Webtop or previous tools, the ability to navigate to a cabinet/folder, see content and then add content was easily supported with MyDocumentum for SharePoint product. As mentioned in the previous post, where the client struggled was the inability to tweak the product to provide for unique indexing needs. These included:

  • Document Type – based on the user and folder, the client wanted the ability, within the interface, to restrict which Document Types that could be added to a folder. This is a common customization in Webtop and the client wanted to extend this functionality to SharePoint. Without an SDK, our team could not support anything but the default dropdown that allowed the user to create any document type they had access to including non-recommended types like dm_document.
  • Attribute Logic – Another common customization is the use of some type of logic to restrict or suggest attribute values based upon other values. For example, if a certain location is picked for the location attribute, it makes sense that the department would be a department that exists for that location. Without an SDK, we could not add this type of referential integrity check.
  • Workflow Interface – as presented in a previous screencam, we typically see clients wanting to index content and kick off a workflow. (review or approval). Since the interface is so tightly controlled, we could not launch other functions/interfaces without an SDK.

Conclusion

After a review, the client determined that they would either have to develop their own WebPart or push the users to an existing Webtop installation. For clients considering building their own WebPart, some important points include:

  • Development Framework – As a Microsoft development effort, your developers should be familiar with Microsoft SharePoint development. If you are thinking of using Documentum DFS or DFC, you need to be cautious in regards to mixing Java and .Net development. As part of our efforts, TSG developed our SharePoint Web Parts with OpenContent, our own Webservices, for either SOAP or REST as Open Source with an SDK.
  • Licensing – Unless you have users on foundation seats (purchase prior to 2003), typical Documentum licensing would define a home grown SharePoint connector as a “Custom Client” and might require another license. Foundation seats provided for Webtop and “Documentum API (for end user access only)” so a custom client would be supported. Clients should work with their sales rep to determine the appropriate approach.

You can find examples of SharePoint integration in the SharePoint section of the TSG web site and here in our SharePoint section of the blog.

3 thoughts on “MyDocumentum for SharePoint Part II

  1. Apart from not having an SDK – MyDocumentum for Sharepoint (currently) does not provide any Webpart(s) to interact with Workflows – which would be an important limitation

    – Paras

Comments are closed.