Tuesday, February 21, 2012

The "No Code" way to Customize FAST Search - Part 1 - Search Results

SharePoint Search can be a great way to elevate the findability of content to a whole new level; even better, it's easily customizable.  I used to think about FAST Search customization in the sense that they can only be achieved via code or PowerShell, and to some degree, that's correct.  However, there's a lot that can be implemented to enhance the search experience: results, best bets, user targeting, and even document/site promotion and demotion...without writing a drop of code.  This is the first of a series, today we will be covering customizing the search results set.

First - a good resources on how to customize (and troubleshoot) SharePoint search using XSLT.  A lot of the results customization is very similar to traditional search, with a few exceptions...as such, we won't cover XSLT updates here, short of a few tips.

Let's take a practical scenario - perhaps we want to display different things based on the content types within the FAST Search results - how would we do that?

  1. Create the managed property
  2. Update our search results web part to consume the column and update the XSLT to display the results

Step 1 - Create the Managed Property
Creating a managed property in FAST is a little different than in traditional SharePoint search, and it can be a bit confusing.

  • Log into Central Admin
  • Navigate to the FAST Query Service
  • In the left nav, select "FAST Search Administration" (yes, FAST Search Administration...don't go straight to the Metadata Properties area of the FAST Query Service)
  • Under Property Management, select "Managed Properties"
  • On the Managed Properties page, select "Add Managed Property"
  • In this scenario - we want to add a property called "ContentTypeQuery"; on the add property page:
    • TIP - there is already a Content Type managed property, however, you are not able to use this in your search results, so you must create a new one
    • Give the property a name, such as ContentTypeQuery
    • Set the type to "Text"
    • Add mapping and point to "ows_ContentType"
    • Set additional properties where applicable (in our case, we just want to display the field in our search results, there is no need to activate the other properties):
      • Sort - if this is a parameter that the search results can be sorted by
      • Query - if you are performing property queries from Advanced Search (or other scenarios)
      • Refinement - if you want this to display in the refinement panel
    •  Click OK
  • Conduct a full crawl

 

Step 2 - Update our search results web part to consume the column and update the XSLT to display the results
Now that our managed property has been created, we need to inform the search results web part that it exists, and pass it on to the search results.  Generally speaking, I prefer to use a customized federated location to house search result columns and xslt as it's a better way to disseminate these settings, especially if there are multiple search result pages, or multiple site collections  within a farm.  For the purpose of this example, I will not be using a federated location, but rather editing the search results web part directly (which, is a great way to test!).

  • Navigate to your FAST search results page
  • Edit the page, then edit the "Search Core Results" web part
  • Expand the "Display Properties" section
    • Uncheck the "Use Location Visualization" box (which allows overrides of the federated location)
    • Add the column to Fetched Properties
      • Click into the "Fetched Properties" text box and copy all contents to your clipboard, paste it into Notepad (for easier editing)
        • At the end of the XML, before the </Columns> tag, add: <Column Name="ContentTypeQuery"/> 
          • Copy from Notepad, and paste it back into the Fetched Properties text box
    • Customize the XSLT Search results
      • Click on the XSL Editor
      • Copy/Paste into Notepad or SharePoint Designer - somewhere to make the formatting easier
      • Make the XSLT Updates as needed (there's a whole slew of ways to do this)
        • TIP - the reference to columns in the XSLT is case sensitive...but not in the way one would think.  Any references to columns within the Search Results XSLT must be all lowercase, regardless of the way the property is configured.
        • TIP - you do not need to add the property to the top of the XSL file in order to use it within
        • In my case, I was performing some if logic around my content types, which ended up looking like this in the XSLT
      • Copy/Paste back into the XSL editor of the web part
      • Click OK
  • Save and Publish the page

With the above information, especially the tips, you can add almost anything to your search results, change up the view, and styling, etc.  Some common elements to update:

  • Ratings
  • Description or other pertinent metadata
  • Cusotmized xslt in the event we see a task or calendar item (based on content type)
  • Remove fields that are no longer needed

Happy (no code) customizing!  In the next series we will review additional no code customizations around keywords and best bets for FAST.