Thursday, June 2, 2011

DateTime resolution on your SharePoint Search Center hits

If you use the search center in SharePoint you will notice document dates are listed with year, month and day. What if you want to show hours, minutes and seconds as well for the last modified date?
image

Turns out this is harder than you would imagine as the underlying xml is missing the data we need, so changing the xslt will not help.

image

If I use the FAST Search for SharePoint Query Logger on my FAST server, I see that hours, minutes and seconds are returned, so the question is, where do they disappear?

image

Firing up one of my favorite tools, Reflector, I found the answer in the SharePoint result XML builder, an internal class used to build search result xml - Microsoft.Office.Server.Search.Query.Gateway.XMLBuilder. In the method GetPropertyValue there is a section handling the managed property called write.

image

and if we take a closer look at GetDateTimeValue we find the answer.

image

In the last line it formats the date with the d modifier. This stands for short date, and will render a date without hours, seconds and minutes -http://msdn.microsoft.com/en-us/library/az4se3k1.aspx. The siteCulture parameter comes from the search runtime (either the SharePointSearchRuntime or the FASTSearchRuntime, depending on if you are using the built-in search or FAST Search for SharePoint).

My first instinct was to override the formatting of the d modifier for the culture of the running thread. But this will not help as it’s the SSA runtime which executes the query and it is running on a different thread.

Seems your only solution when using the Core Results Web Part is to create a new managed property, and map to it the same crawled properties as is mapped to write. Then use your new managed property instead in the xslt rendering.

If you are using any of the API’s for search, you will get the full date resolution, as the result is not run thru the result XML Builder.

5 comments:

  1. Thanks for the explanation Mikael, very good!

    ReplyDelete
  2. Hi Mikael, I'm trying to implement your suggested workaround now, and I've created a new managed property in SP that maps to the crawled property "write" (at least I think it's "write", although the crawled property is called "LastModifiedTime"..). But how do I query against this mapped property from code? I am using the QueryManager class in my code to submit queries to FAST and specify a RequestedProperties collection of properties that I want to retrieve, but these are all properties directly in the FAST index if I am not mistaken. So if I try adding my newly mapped property, it won't work, as this is not a crawled property, but a mapped property.. any help or pointers would be appreciated!
    cheers

    ReplyDelete
  3. Make sure the new managed property is Queryable, and you could add something like:

    "MyWrite>="2011-07-07 12:00:00"

    to the query string.

    Also, check out all mappings to the "write" managed property, and include them in your new one as SP items, web pages and file shares all have different crawled properties for the last modified date. Do this either via the FAST Search Admin UI or PowerShell.

    $m = Get-FASTSearchMetadataManagedProperty write
    $m.GetCrawledPropertyMappings()

    ReplyDelete
  4. Hi Mikael, thanks for all of your help (and digging) so far, I've been able to get it to work perfectly! I've got another question though, which is probably off-topic, but you seem to be an expert, so I might as well ask: How can I get separators to work in the FAST index for managed multi-valued properties, like for instance "author"? The problem I'm facing at the moment is that multiple authors for a document are written into the FAST index without separators, like "Roel Adams Mikael Svenson", which is difficult to parse. Could you point me in the right direction on this one as well? I'd be really thankful!!

    cheers
    Roel

    ReplyDelete
  5. Roel,
    The default authors field is already using separators. If you have your own managed property make sure MergeCrawledProperties=true (this enables multiple values).

    Also read http://social.technet.microsoft.com/wiki/contents/articles/multi-value-property-support-in-fast-search-server-for-sharepoint.aspx, and in particular the last paragraph which says to use U+2029 as the separator character in the crawled properties data.

    Also read: http://social.technet.microsoft.com/Forums/en-US/fastsharepoint/thread/a4285ae0-c899-4c6c-ab24-032e70d4525d

    I would also mention that posting questions at http://social.technet.microsoft.com/Forums/en-US/fastsharepoint is a good way to get answers :)

    ReplyDelete