Debugging and Troubleshooting the Search UI

Use Managed Properties to Improve the search results experience

Agnes Molnar

by Agnes Molnar on 3/31/2014

Share this:

Article Details

Date Revised:

[IF condition="s1.Length > 0" strings="Microsoft SharePoint SearchSharePoint 2010spx"]

Applies to:
Microsoft SharePoint , Search, SharePoint 2010, spx


Recently, I have done a lot of work on Search in SharePoint 2010, and some of that work focused on Crawled and Managed Properties. Now, I'd like to focus on the user experience part of this story, particularly on debugging and troubleshooting.

SharePoint content can include one or more unstructured part and some structured metadata properties. When you crawl the content, you extract these properties. We refer to these as Crawled Properties. Based on these Crawled Properties, you can create Managed Properties.

Managed Properties in a nutshell

The Search Administrator controls and manages Managed Properties. You can create a Managed Property and map it to one or more Crawled Properties.

For example, let’s say your company has various pieces of content coming from different source systems, such as Office documents, emails, database entries, and others. These document types are stored in SharePoint, File System, Exchange or Lotus Notes mailboxes, Documentum repositories, etc.

For each piece content, someone who created it, right? But the name of this property may be different for each different system and/or document type. For Office documents, the name of the property may be the Author, Created By, Owner, etc. For emails, the property name is usually From.

At this point, you have several different Crawled Properties with the same purpose: to tag the creator of the content. Why not display this in a common way for the end user? For example, you can create a Managed Property called ContentAuthor and map each of the above-mentioned Crawled Properties (Author, Created By, Owner, From, etc.) to it. By doing this, you will be able to use these properties in a common way on the UI: to display on the Core Results Web Part, to use as Refiner, or as a Sorting value in case of FAST.

(NOTE: Of course, you can use each Crawled Property for more than one Managed Property.)

On the Search UI

If you check a typical SharePoint Search UI, you can find the Managed Properties in several ways, which are shown in Figure 1.


 Figure 1: Managed Properties in the Search UI

1. Refiners – Refiners can be created by the Managed Properties. You can define several refiner types (text, numeric range, date range, etc.) by customizing this Web Part’s Filter Category Definition property. Several articles and blog posts describe how to do this. One of my favorites is the one by John Ross.

2. Search Result Properties -- The out-of-the-box Search Result Set is something like what you see in Figure 2.


Figure 2: Out-of-the-box Search results

This UI contains some basic information about your content, but I’ve never seen any environment where it should have not been customized. As with Figure 1 above, you can include the Managed Properties you want, and also customize the way of displaying them. For this, you’ll have to edit some XMLs and XSLTs. I'll cover that below.

3. Property-based Actions

– Since you can customize the UI of properties on the Core Result Web Part, why not assign some actions to them? For example, you can assign a link to a related item, a link to more details, or a link to the customer dashboard; anything that has a (parameterized) URL and has business value to your Search users.

4. Scopes and Tabs – You can use Search Properties to create Scopes, and each Scope can have its own tab on the Search UI.

Core Result Web Part - Fetched Properties

If you want to add Managed Properties to the Search UI, the first step is to add this property to the Fetched Properties. However, as Figure 3 shows, this field is a bit tricky.


Figure 3: Fetched Properties field

Edit the Page, open the Core Result Web Part’s properties, and expand the Display Properties. Here, you’ll see the field for Fetched Properties. Take a deep breath, and try to edit it. Yes, it’s a single-line, crazy long XML. No, don’t try to copy and paste this using your favorite XML editor. If you do and break it to lines, tabs, etc., and try to copy back here, you’ll have another surprise!

This is really a single-line text editor control. If you paste multi-line XML, you will only get the first line. Instead, copy the content of this to the clipboard and paste to Notepad++ (This is a free text editor tool, and really--it is a Notepad plus! plus!). It looks like what you see in Figure 4.


Figure 4: Notepad++


Open the Language menu, and select XML. Your XML will still be a single line, but at least it will be formatted.

Open the Plugins / XML Tools / Pretty Print (XML only – with line breaks) menu, and here you go! Figure 5 is your well-formatted, nice Fetched Properties XML:


Figure 5: Fetched Properties XML

Now you can enter your Managed Properties by using the Column tag:


OK, you’re finished editing, but remember: It’s not a good idea to copy this multi-line XML and paste to the Fetched Properties field of the Core Results Web Part. Instead, use the Linarize XML menu of the XML Tools in Notepad++, and your XML will be one loooooooooong line immediately. From this point on, it’s really an easy copy-paste again. Do you like it? :)

NOTES about the Fetched Properties:

* If you enter a property name that doesn’t exist, the error message in Figure 5 will be displayed:


Figure 6: Error message


* You’ll get the same (!) error if you enter the same property name more than once.

* Also, you’ll get the same error if you enter some invalid property names to the Refinement Panel Web Part!

Debugging the Property Values

Once you’ve entered the proper Managed Property names to the Fetched Property field, technically, you’re ready to use them. But first, you need to be able to check their values without too much effort. Matthew McDermott has published a very nice way to do this: Use an empty XSL on the Core Results Web Part, so that you’ll get the plain XML results. You can find the full description here. Figure 7 shows how it looks.


Figure 7: XML results

All set

To summarize: If you create a Managed Property AND add it to the Fetched Properties, you’re ready to display (and use) it on the Result Set. For debugging the property values, I always create a test page with Matthew’s empty XSL first; then, begin working with the UI customization afterwards.


Topic: Search

Sign in with

Or register