Tuesday, November 25, 2008

Sharepoint - Sorting people search results by name

Hello Dear Reader, for this new post. First some personal news, after working for quite sometime on load testing a java CRM application, I wanted to move on and finally work with the newest Microsoft technologies. And that’s what I did as I managed to land a job at a local Microsoft Gold Partner in Nantes, France. The team I ‘m part of is mainly working integrating the Sharepoint solution for local partner, and I got to say it’s a nice opportunity so far.


For my first Sharepoint post I’ll speak about the limitation of the integrated People Search functionality. With MOSS 2007 comes the Enterprise Search Center that allows you to gives an easy acces to the search engine to your users. This Sharepoint site (because that’s exactly what it is) comewith two search mode OOB:

  • a standard search for searching through documents, lists, pages, ... basically whatever you let the Search Engine crawl and
  • a people search for, you guessed it, searching people based on any properties you want among the profile properties defined in the SSP (Shared Service Provider)

We recently had a problem where a client wanted to:

  • Display the list of employee for each office, sorted by name/firstname
  • Be able to search a client based on its name/firstname

The problem

We first imagined to fulfill these two needs with a single item, a people search page, where results per office would be obtained by adding the office as a searchable property. And that’s when we realized a huge shortcoming of the Search Center:

People search results can’t be sorted on arbitrary fields you will define, such as the name/firstname. Two standard Sorting modes are available and that’s it. Results can be sorted based on the ranking computed by the Search server. Results can also be sorted by social distance, the principle is fine enough, if you are looking for a John, it will first display the John who is your direct colleague instead of the John who is working in another department of another office.

The almost working workaround

Starting from this realization, we figured we might solve this problem by doing a quick sorting in the XSL displaying the results. This way, the sorting could be done on any fields necessary. While this solution is perfect if you have less than 50 results, it is not a full working solution.

The thing is, the search engine first returns the results. These results are then divided (by the Search Core Results web part) in x collections of y elements (people) where y is a webpart parameter capped at 50. Therefore if we have more than 50 matchs, the sorting will be done separately on each page in a discontinued manner.

That is , a hypothetical “Albert Alden” might be on page 2 while “Brittany Bern” is on page 1 if his rating is lower than Brittany’s. But we know for sure that “Cindy Costner” which is on page 2 will be presented after Albert whatever her rating is because the sorting on each page is done lexicographically by our XSL.

The working workaround

Keeping these limitations in mind we had to devise a quick solution. We chose to keep the standard people search for standard people search, considering the size of the company and the fact way it is going to be used. Yet we still needed a way to present the users with a list of all the employees of any given office (at this point, it’s probably needless to remind you that we REALLY want this list to be sorted by name/firstname J). That’s when we stumbled upon this superb article by Dietmar Kurok (http://www.codeproject.com/KB/sharepoint/DepartmentPeopleViewer1.aspx ).

The solution is to use the Web Service exposed by the search engine to get the information we need sorted as we need and then present it with a XSL of our own. In our case we used the same principle as the one used in Dietmar Kuork’s article, however we chose to generate our QueryEx input parameter (the Querypacket) with a very nice tool available on CodePlex. The tool is named SharePoint Search Service Tool and will be found at http://www.codeplex.com/SharePointSearchServ.

The general idea of the process is to:


I hope you enjoyed this first Sharepoint post and I hope to be able to post more often on this nice product in the future.


people search said...

nice post!

Anonymous said...

I think this is good way to solve the limitations of the 'out of the box' search, without having to code a custom web part.

I can get fixed queries working fine (i.e. WHERE Department LIKE 'IT'), but how do I parameterise the 'IT' part so it can be used dynamically for any department passed into the web part via the query string?

I can use the query string as a filter when using a SP list as the data source, but can't figure out this when using the search web service.

Any ideas?

Joe said...


I sure have an idea. First thing to know is that you'll have to edit the web part manually. The SharePoint Designer GUI can't andle the complexity.
First you'll want to replace your fixed value with parameter in the <queryXml> node. The parameter will be enclosed between brackets :
<queryXml>.....WHERE Deplatment LIKE '{MyParam1}'....</queryXml> . Of the whitespaces and ' will be encoded as _x0020_ and such. Just make sure not to encode the {.

Then you will have to specify this parameter by inserting a SelectParameters node and DataFormParameter for every parameter between the SelectCommand end node and SoapDataSource endnode.
<SelectParameters><WebPartPages:DataFormParameter name="MyParam1" ParameterKey="MyParam1" PropertyName="ParameterValues" DefaultValue="*"/></SelectParameters>


Then you will have to plugin this parameter on a source. If the source is a query string add a subnode to the ParameterBindings node
<ParameterBinding Name="MyParam1" Location="QueryString(MyParam1)" DefaultValue="*"/>

Hope it works for you, leave me a message otherwise.
Note that this works for every other web services you might want to invoke.