Corey Roth [MVP]

I have to admit, the Document Id Service is really only exciting to a small handful of us.  I show it to customers and people in my ECM talks and the response I get is, “meh”.  However, the hardcore ECM people I know really like it and they are always looking for ways to utilize it in their solutions using code or search.  Today, I thought I would show a quick tip on how you can use it in search results.  Now you can always pass the Document Id to DocIdRedir.aspx, but you may want to display it on a search results screen.  If you have defined your own document id prefix, you may even have power users that work with these ids regularly and may want to see them when they search.

To begin working with Document Ids in Enterprise Search, you first need to know which managed property to work with.  The property DocId is the one you need to know.  If you have read my article on naming conventions,  you know I think it should have probably been named DocumentId, but oh well. :)  If you are familiar with the keyword query syntax or my handy keywords blog post, you know that we can query this pretty easily.  Here is the syntax.

DocId:"DocumentIdNumber"

As a reminder, you can view a Document Id on an existing document on the View Properties page of a document.

Taking that Id, I can now use it in search with the following query.

DocId:"YY7PPZHWQVY7-5-3"

Which will give you search results that look something like this.

Again, I know that might not be that exciting because you can use DocIdRedir.aspx.  However, when you start thinking about custom applications and issuing custom queries using the Search web services, you might find it useful.

Let’s take it a step further and add the Document Id to the search results page.  We’re going to do this in pretty much the same way, I added social ratings to the search results a while back.  However, this time I am just going to edit the columns and XSLT in the CoreResultsWebPart instead of editing the federated location.  Go to the results.aspx page of your search center and edit it.  You then want to go down to the CoreResultsWebPart and edit it as well.  Open Display Properties and uncheck the Use Location Visualization checkbox.

We first need to add the DocId managed property to the result set.  We do this by editing Fetched Properties which contains a Column XML element for each property returned.  There used to be an “editor” for this field in 2007, but they removed it.  You may want to cut and paste it into Notepad to edit the XML first.  Go to the end before the </Columns> line and add the following.

<Column Name="DocId" />

Word of warning.  If you mess up the syntax of this XML or reference a managed property that does not exist, you will break search and get an error that says something like the following:

Property doesn't exist or is used in a manner inconsistent with schema settings.

You might want to keep a backup copy of the XML somewhere while you are working with it in case you have an issue.  A lot of times I create another Search Center to try out my changes first instead of breaking the one everyone else is using.  You can also uncheck the Use Location Visualization checkbox to revert back to the default XML.  Once you do make your changes, I usually click OK and save the changes to my page to verify that I have not broken the Search results page.  You won’t see any visual difference on the page yet, but if you get search results you know everything is working right.

Assuming that change was successful, we can now edit the XSL using the XSL Editor button to actually add the Document Id to the search results page.  Finding the right spot can be somewhat tricky, but it’s not too difficult.  A good spot for the Document Id is in the srch-Metadata2 div.  This is where it already displays things like author, file size, and tags.  Simply add the following right before the blank.gif reference and after the DisplaySize call-template.

Once the change is complete, click Save and then save the page as well.  Perform your query again and you should now see the Document Id display along with your search results.

Of course, not every item has a Document Id assigned to it (i.e.: pages, folders, list items, etc).  You may want to add a conditional to your XSLT to only display the Document Id when one exists.  Just update your XSL with the following.

<xsl:if test="string-length(docid) &gt; 0">
Document Id: <xsl:value-of select="docid"/>
</xsl:if>

This will only display the Document Id when one exists.  If you haven’t checked out my post on handy keywords in search, go take a look.  It has a lot of useful keywords that are out-of-the-box that you can build interesting queries with.  I’ve also updated it to include information on DocId as well.