Challenges with quickly looking up document properties using Document ID’s in SharePoint

Just a few running notes on my work with Document ID’s in SharePoint 2010.  The main challenge that I’m seeing in general with Doc Id’s is that they can only be resolved in one of two ways to actual documents:

  1. You can run a search within your SharePoint search center in the form “docid: 6WJUPFHUC735-11-1” (you can use your own ID in this case).  I presume in the event that you are using FAST, you’ll want to search on “spdocid:” but I haven’t verified this yet.
  2. You can send a query to “http://<serverurl>/_layouts/DocIdRedir.aspx?ID=6WJUPFHUC735-11-1&#8221;, which simply issues a 302 (object moved redirect) and sends your browser to the file content.

In both of these cases, however, the challenge is that you are unable to immediately get to document properties or other ways of manipulating the document.  You either need to take the resulting search result (parsing the search result) to track down a reference to the document (solution #1, above), or you need to parse the contents of the 302 redirect and perform an additional query to lookup the document properties.

From a Document Id, there is not a straightforward way (in a single hop) to get a reference to the document object or the document metadata.  Perhaps I’m obsessing here, but it just feels like you shouldn’t need two hops from Document Id before you can view document metadata.

I’ll be posting further on this once I find a solution…

4 thoughts on “Challenges with quickly looking up document properties using Document ID’s in SharePoint

  1. Hey contentczar,

    I’m needing to solve this problem but for different reasons…

    I have an ERP that stores links to SharePoint documents via the SP doc ID using “http:///_layouts/DocIdRedir.aspx?ID=6WJUPFHUC735-11-1″.

    These get attached to emails and, of course the attachments aren’t ‘real’, as they reference a web page that has a link to the actual document.

    Have you found a way around this one yet?


    • Well, I’ve got part of a solution, but you’re not going to like it… I haven’t yet had a chance to write-up my solution.

      The problem is this: SharePoint changes the actual url of version X.0 of a document when version X.1 appears. If you have an approved, X.0 version of a document (published, approved) without any draft versions after it, all users reach the document it the normal path in the doc library. Once a X.1 draft version is released, things change. Users with Edit privileges must access the document at a path under “/_vti_history/” where version number is Major# * 512 + Minor#.

      Thus, the path to the document “changes” for users with edit privileges based upon whether a newer draft version is available.

      Now, in my case, I’ve written two handlers:
      (1) An .ashx handler that returns a JSON object showing all of the draft and published versions of the document and allows the calling application to determine quickly which url to call.
      (2) Another version of the DocIdRedir page that also takes an explicit version, and redirects you to the proper version of the document.

      What I find curious about your case, is that the document id redirection function makes use of an HTTP 302 redirect, which SHOULD be completely transparent to any calling application (javascript even has trouble picking it up, which is appropriate, since it should be transparent to the browser / calling application).

      So, your ECM tool / email application should honor the 302 redirect and simply retrieve and attach the file. When you are creating an email and you attach a file, you aren’t really attaching a link, as the email server / client software should resolve the link and embed the file within the email, correct?

    • I did post a second part to the original post:

      Basically, you need to write your own handler to returning JSON data on the file. I’ve written up the basic methodology, but didn’t include source code as I’m not at liberty to share direct source from this particular project.

      Basically, unless you’re willing to write code, you’re in the cold.

      Actually, this isn’t 100% true, as you might be able to POST data to the doc id page, and you might avoid the 302 redirection automatically, as POST requests are not supposed to follow 302 redirects (it’s a long story, but only GET requests follow 302’s silently). Basically, you can then parse the returned error, find a link to the file, and then send a user to the properties on the file. This could all be done with client-side javascript….

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s