Documentum or Alfresco – Linking to a Document using OpenContentURL

One of the common requests from clients is the ability to create direct URL links to a document in a content management platform from a variety of other tools.  A recent client was maintaining links in SharePoint to Documentum via a proprietary Documentum tool based on Webtop.  This post will discuss our eventual solution and how this led to the creation of our OpenContentURL Open Source product for Documentum, Alfresco or a variety of other content management repositories.


Our client’s requirements were to imbed approved documents in SharePoint.  Upon entering SharePoint, the user would see a standard URL link that would launch Documentum Webtop (in all its glory) for viewing the document.  This approach leveraged the DRL (Documentum Resource Link) typically used for notifying users of documents in Webtop.  The client had a couple of issues with this approach including:

  1. For most users, the desire was just to view/print the document, not necessarily all of the other functions of Webtop.
  2. It limited document access to employees authorized to access Documentum.
  3. The DRL link by itself would retrieve the “current” version of the document.  The user really wanted to specify the approved or released version.
  4. If the document is replaced by another in Documentum, the DRL needed to be changed, and it had to be changed manually by a SharePoint user.
  5. The client was implementing an approved document “cache” and did not want to have to change document links in SharePoint to reflect where the document would finally “live”.

In keeping with the client’s goal to focus on the document instead of the document management system, we developed OpenContentURL; creating a system neutral URL link to a document.

OpenContentURL Design

Thinking beyond the simple one to one relationship of a URL to a target, we designed OpenContentURL with the ability to route the user’s browser to a document based on criteria contained within the URL. This means an OpenContentURL link is conditional and not hard wired to a specific system. For example, when an OpenContentURL link is clicked, it directs users to a content management neutral resolver program, the Resolver web service. The service parses criteria in the link and compares it to target system mapping criteria configured for the service. When a match is found it indicates the target system. Using the mapping, a new link is created and the browser redirected to that link. OpenContentURL’s Resolver service acts as a link interpreter and redirector.

Interpreting and redirecting a URL link is only one piece of the solution.

  1. Users needed a way to easily create an OpenContentURL link
  2. Systems need a way to accept an incoming link, find the document and display it.

For our integration with Documentum Webtop, we wrote a simple WDK component in Webtop that creates the link and copies it to the clipboard for easy pasting into SharePoint or any other application that supports URL’s.

While the OpenContentURL link appears in the menu similarly to the option to create a DRL link, the difference is that the OpenContentURL link contains identifying attribute criteria for the document, not the internal r_object_id.


Note that the OpenContentURL link may not necessarily be short; however, it could be shortened through aliasing and assuming criteria labels and even values instead of explicitly including them. Adding in a capability similar to TinyURL the document links could simply be http://docs/SOP12345.

Target Mapping configuration is accomplished through an XML file that describes the criteria that will force a redirection to the target. It also describes how to use the criteria to create a link for the target.

To handle OpenContentURL links that redirected to Documentum we wrote a small target handler for Webtop. When a link hits the target in Webtop, it initiates a search for the r_object_id in Documentum using the criterion that was passed in. Once the r_object_id is found, the target code creates a Documentum DRL link and redirects the browser to it. From the Documentum user’s perspective, the OpenContentURL link behaves just like a DRL.

Closing Thoughts

We see many possibilities where OpenContentURL can help solve legacy document linking issues. With the capability to build intelligent interpretation of links OpenContentURL can:

  • help give companies ease the transition from an old document management system to a new one,
  • provide new opportunities to share documents through portals and extranets, and
  • avoid hardcoded links that must be updated every time a document moves to a new location.

We’d love to hear other thoughts and ideas where OpenContentURL might be valuable. This product is not available for download yet, but is planned to be released during Q2. A demo is available of OpenContentURL on the Learning Zone.

3 thoughts on “Documentum or Alfresco – Linking to a Document using OpenContentURL

  1. […] OpenContentURL makes it easy for end-users to generate dynamic permanent links to documents that are stored in a content management system or portal. It reduces or eliminates the problem with out of date links to documents in web site, training material, and references throughout an organization. You can read more about how one of our client’s is using it here. […]

  2. Interesting utility and I really think this covers a common need, as it seems that this type of functionality is built a lot in custom development. What are your thoughts in directly accessing the content server or a interface layer like cmis or dfs (in Documentum’s case) and bypassing webtop at all. Possible cases are that you manage content in clients apps like taskspace or D2, while access for consumers only requires a document (not even metadata) based on a logical link. Even further, combining this with OpenOverlay for eg stamping of the current date and support of proxy logins would make this even more generic.

  3. Hi Mark.

    You are absolutely correct that Webtop is not necessary. We did brainstorm with our client about using OpenContentURL to find and return content to a calling program instead of redirecting to a browser as well as accessing documents through different interfaces such as our OpenContent web services, CMIS, etc. Regardless, the target system where the document lives needs to have some type of interface that can handle the incoming URL, parse the attributes, find the document, and present it to the user.

    Our other blog post on OpenContentURL explores this in some more detail.

    Thank you very much for the comment and I’d like to hear back if you give OpenContentURL a try!

Comments are closed.