How to: Use the SharePoint 2013 Search KeywordQuery Class
Posted
Thursday, January 3, 2013 11:42 AM
by
CoreyRoth
Over the past few versions of SharePoint, I have provided a number of blog posts on how to query search. Of those, my posts on how to use the KeywordQuery class using KQL are some of the most popular (2010 and 2007). In continuing that tradition, I am proud to present the “How to” post on using the KeywordQuery class in SharePoint 2013. The good news: your old KeywordQuery code should still work. The bad news: the way you did it is marked completely obsolete. I actually had to dig through quite a bit of documentation to find the right API that wasn’t obsolete. One thing that always provided confusion was that there were similar classes named KeywordQuery in both Microsoft.Search.Query and Microsoft.Office.Server.Search.Query. To reduce some of that confusion, the KeywordQuery class in Microsoft.Search.Query is now marked as obsolete. The new updated class is in Microsoft.Office.Search.Query. Microsoft may have killed the word Office from the name of the product in 2010, but it’s alive and well in the API.
Now let’s talk about what we need to execute some queries with our code. The code here today will work well from farm solutions in SharePoint as well as other .NET applications hosted on the same SharePoint server. We’ll be building a console application today. If you want to query remotely using the object model, then you will need to use the Search Client Object Model which I covered previously. Create a new console application, and then you will need to add a few references. These can be found in the 15 hive in the ISAPI folder. Add the following:
- Microsoft.Office.Server
- Microsoft.Office.Server.Search
- Microsoft.SharePoint
- Microsoft.SharePoint.Security
The classes we need are in the search assembly but you’ll get lots of errors about dependencies missing if you don’t include the others. We then need the following references. This gives us what we need for search, SharePoint, and for the underlying datatable object that is available after we query.
using System.Data;
using Microsoft.SharePoint;
using Microsoft.Office.Server.Search.Query;
Once we have this, we’re ready to get started. There are many ways to instantiate a KeywordQuery object. For simplicity, I am just going to pass a SPSite object for one of my site collections. You can also pass a SPWeb or you can use the proxy technique like I used in my SharePoint 2010 post. We’ll first, get our SPSite object.
using (SPSite siteCollection = new SPSite("http://server/sitecollection"))
We then create a KeywordQuery object using that site collection.
KeywordQuery keywordQuery = new KeywordQuery(siteCollection);
Now, we specify our query using the QueryText field. This is where you can use your custom KQL queries. The documentation team updated the post on this so there are a lot of good tips here. I am just going to search for the word SharePoint.
keywordQuery.QueryText = "SharePoint";
In the past, we would then set the ResultsProvider and ResultTypes that we want, but now we don’t have to. In fact, this whole process takes considerably less code. Instead we use the new SearchExecutor class that I first mentioned in my Client OM post.
SearchExecutor searchExecutor = new SearchExecutor();
We then use it’s ExecuteQuery method passing it our KeywordQuery class.
ResultTableCollection resultTableCollection = searchExecutor.ExecuteQuery(keywordQuery);
Assuming it executes correctly, we can then get our search results. Before, we used to use an indexer using ResultTypes.ReleventResults to get the table of results we need. The indexer has been made obsolete, so now we must use the new Filter method. I figured out what it required from the obsolete descriptor of the indexer. For the first value, it needs a string with a value of TableType and since the previous enum is also obsolete, we now use KnownTableTypes.RelevantResults.
var resultTables = resultTableCollection.Filter("TableType", KnownTableTypes.RelevantResults);
It returns an IEnumerable<ResultType>, so we need to filter it. I just FirstOrDefault() to get the table we need.
var resultTable = resultTables.FirstOrDefault();
Previously, we then had to load the data into a DataTable which took a few more lines of code. However, now that is not required due to the new Table property.
DataTable dataTable = resultTable.Table;
Now that you have a DataTable, you can bind it or query it as you see. You can also look at the results using the visualizer in Visual Studio.
Here is the entire code snippet.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data;
using Microsoft.SharePoint;
using Microsoft.Office.Server.Search.Query;
namespace SearchConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (SPSite siteCollection = new SPSite("http://server/sitecollection"))
{
KeywordQuery keywordQuery = new KeywordQuery(siteCollection);
keywordQuery.QueryText = "SharePoint";
SearchExecutor searchExecutor = new SearchExecutor();
ResultTableCollection resultTableCollection = searchExecutor.ExecuteQuery(keywordQuery);
var resultTables = resultTableCollection.Filter("TableType", KnownTableTypes.RelevantResults);
var resultTable = resultTables.FirstOrDefault();
DataTable dataTable = resultTable.Table;
}
}
}
}
So if you have a lot of search based code, you may need to do some updates at some point. However, I think these are good changes and simplify the process a little bit. In an upcoming post, I’ll cover some of the new things you can do with the KeywordQuery class.