LANGUAGES: C#
ASP.NET VERSIONS: 2.0
Imagine this scenario: A new employee to a company sits down at the company s SharePoint Server intranet portal and is told to figure it out. Right there on the portal home page is an inviting little Web part that says, I d like to find out more about: with a dropdown list full of information about such topics as 401(k), employee stock purchase plans, the latest technical buzzwords, and the company performance reports. By clicking through to these destinations, the employee learns a significant amount about the company all without having to ask any questions. Six months later, the same employee is still frequently using this same Web part because the contents of the dropdown list change often, and always reflect the things that his co-workers are talking about all without any administrators keeping the content fresh.
How is this happening? The contents of this simple dropdown list are really driven by the search terms entered into the SharePoint portal s search center. As the frequency of the search terms change, the different list items bubble up and down in the dropdown list. (This functionality can be seen in action on some prominent Microsoft SharePoint intranets.)
This two-part series will walk you through the process of creating a SharePoint Web part with such a dropdown list, beginning with the out-of-the-box configurations required to ensure that search is successful inside your Microsoft Office SharePoint Server portals, through the discovery of where the search result and click-through data is kept, and, finally, the creation of the Web part itself in Part II.
Configuring SharePoint Search
Because you are interested in providing your users with the best possible results whenever they use the SharePoint search technologies, you need to configure SharePoint Search, along with some best bets for certain keywords or search terms. At the most basic level, SharePoint Search is comprised of a crawler service that builds an index of terms that can be searched for maximum performance. The crawler service reads from identified content sources and tags the discovered material as belonging to one or more search scopes, or categories. Examples include searching file shares for Microsoft Word documents or searching SharePoint sites for Excel spreadsheets. The following walkthrough will show you what is required to correctly configure SharePoint Search and create a search scope for targeted results.
Start by visiting your site s Central Administration site. SharePoint s Central Administration is the single central location where you can administer your farm s Web applications, site collections, backups, security, policies, and more. On the Operations tab of Central Administration, you can check the status of the server s Search service.
Central Administration also surfaces a middle level of configuration known as Shared Services. The Shared Services Provider is the host for application services on a portal such as Search and MySites, and, as such, is the destination for search configuration. Follow these instructions to turn on Search in your MOSS portal:
- Click Start, point to All Programs, point to Administrative Tools, then click SharePoint Central Administration.
- Use the quick launch navigation on the Central Administration page to click Shared Services Administration, then click the default Shared Services Provider.
Under Search on the Shared Services Provider home page, click Search Settings (see Figure 1). If you need to create additional content sources, such as external WSS team sites or network file shares, click the Content sources and crawl schedules link. By default, the Search service is already configured with the Local Office SharePoint Server sites. Clicking the content source link will allow you to modify a variety of settings, such as the URL or file path of the content to crawl, the schedule for full and incremental crawls, and more. Figure 2 shows the settings available for the content source of the default Local Office SharePoint Server sites. This default content source is more than sufficient to demonstrate the concepts of this article, so adding additional content sources is not necessary at this time.
Figure 1: Configure search settings.
Figure 2: Edit content source.
Among the other options available on the Search Settings page are the Scopes settings. A search scope is a way to classify data across content sources and return narrower sets of results to search users. Examples of search scopes might be Word documents or images. To create a new search scope, click the View scopes link from the Configure Search Settings page, then click the New scope button.
The next step is to identify a search scope that searches only for Word documents to assist users in finding the content they want. Title your new scope Documents and click OK. You ll be brought back to the View Scopes page, where your new scope has been defined but is currently empty and awaiting the addition of some content rules. Click Add rules next to currently Empty status of your new Search scope.
You ll be presented with a screen where you are given several options to define your search scope s rules. Your Search scope is able to restrict search results by URL, by content source, or by matching properties. It is this property query option that allows you to restrict the search scope to certain file types. By default, there is a property named FileExtension that can be used to restrict searches to specified file types. However, by default, this property is not available for search scopes and must be enabled. Without making any changes to your scope s rules, return to the Configure Search Settings page and click the Metadata property mappings link, which will take you to the page shown in Figure 3.
Figure 3: Metadata property mappings.
Click the FileExtension managed property and check the box at the bottom of the page to make the property available for search scopes. With the FileExtension property now available for use in scopes, return to the rules for your search scope by clicking Search settings in the breadcrumb navigation at the top of the page, then click View scopes, then click the Add rules link. Select the Property Query rule and select the FileExtension property as the property restriction. Type doc into the = box and leave the behavior set to Include. Your screen will look like Figure 4. Click OK to exit.
Figure 4: Add scope rules.
Add a second FileExtension restriction rule to this scope to include docx extensions (so Word 2007 documents are also returned). Click on the Documents scope and select New rule in the Rules section of the page. Once you re finished, your Scope Properties for search are set up on your Rules page.
The server is now configured for search, but the crawler service must be started and the scopes updated before your users can actually see any search results. Follow these steps to run the full crawl and update the search scopes:
1) In Central Administration, click the Shared Services link on the Quick Launch menu to return to the top of the site.
2) Click Search settings, then click the Content sources and crawl schedules link.
3) Click Local Office SharePoint Server sites, check the box at the bottom of the screen to run a full crawl, and click OK to confirm this action.
4) Repeat step 2 on all other content sources to ensure that search scopes that span across content sources are fully updated.
5) Return to the Search settings page. Once the crawler is idle, update the scopes by clicking Start update now (in the Scopes section).
Now search has been fully configured at the Shared Services level, including defining the search scopes that help your users find exactly what they are seeking. Next it s time to configure the site to use the search scope you just created. Log in to the top-level site of your site collection as an administrator; click the Site Actions menu and select Site Settings. From the Site Collection Administration menu, select the Search scopes link. Notice that your new scope is at the bottom of the page, in the unused scopes section. To activate the new search scope in the Search Dropdown and Advanced Search groups, click the names of each group to get to the Edit Scope Display Group page, where you can activate the new scope by checking the box next to its name, as shown in Figure 5.
Figure 5: The Edit Scope Display Group page.
Now your site is ready to be searched. Basic search capabilities are automatically built in to every page, but to grant your users a truly advanced search experience, create a site using the Search Center with Tabs template. Click the Site Actions menu and select the Create option. In the Web Pages group, select the Sites and workspaces option. Give your new search center a title, description, and URL. The Search Center with Tabs template is located in the Enterprise group. Select the template and click the Create button at the bottom of the page. Your new site will be created and you ll automatically be taken to the tabbed search center. The first thing to observe is that the search scopes seen in the Shared Services admin pages are represented as individual tabs, allowing users to easily restrict search results to the subcategories defined by the scopes.
Keywords and Best Bets
Search has been configured, but how, as an administrator or content owner, do you direct people to a specific document or page as the best possible resource for specific information. For example, when an employee searches on the phrase company benefits , you might want to provide the company s HR benefits guide as the first place they should go. This is referred to as a best bet; the following walkthrough will guide you through configuring a keyword and the associated best bet.
Log in to the top-level site of your site collection as an administrator; click the Site Actions menu and select Site Settings. In the Site Collection Administration menu, select the Search keywords option. Click the Add Keyword button. Fill in the form with the word or phrase for which you expect your users to search. Be sure to add any pertinent synonyms. Notice that you can assign an expiration date for this keyword. Click the Add Best Bet link to enter the URL of the best bet, as well as a short description. Your page should now look like the sample screenshot shown in Figure 6. Notice that you can have multiple best bets for a keyword. Return to the site and search for your keyword. The results page will have a new section on the right side with the best-bets results.
Figure 6: Adding a keyword.
Search is now up and running with some administrator-specified best bets. Employees are using the portal to store and work with their content. Insightful navigation options direct users through the portal, and search is filling in the gaps, helping users quickly find relevant information. As an administrator or content owner looking to improve the portal navigation and surface the most requested documents, you are interested in the top-searched terms and the results of those searches. Fortunately, SharePoint has Search reporting built in. To discover what users have been requesting, the following walkthrough will guide you to the various reports at the Shared Services level.
Open Central Administration and click the default Shared Services provider. Click the Search usage reports link; notice that the search reports that come up have no data you must enable usage reporting on the server before the search usage reports work.
To enable usage reporting, go back to Central Administration; from the Operations tab click Usage Analysis Processing. Enable both logging and usage analysis processing. Be sure to set your processing window to a time close at hand, as the search usage reports will empty until the usage analysis processing has been run.
When the usage analysis processing has been given ample time to run for the first time, return to the Shared Services search usage reports; there is now data available (see Figure 7).
Figure 7: Usage reports.
Behind the User Interface
At this point, we begin to enter the territory outlined in the scenario presented in the first paragraph. The goal is to build a Web part that uses the search results data that SharePoint is displaying in the reports to build a custom Web part that can act as a navigation aid. The first step along that path is to figure out how SharePoint itself is able to report on search data. This voyage of discovery will require the use of Lutz Roeder s Reflector for .NET (http://www.aisto.com/roeder/DotNet/), SQL Server Management Studio, and a tool to view code, such as Visual Studio or Notepad.
To find which Web parts, namespaces, and database objects are used in the search usage reporting, begin by navigating to one of the SharePoint Search reporting pages. Take note of the URL (for example, http://demoserver/ssp/admin/_layouts/SpUsageSspSearchResults.aspx). Locate the file on disk at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\ SpUsageSspSearchResults.aspx and open the file with Visual Studio or Notepad. At the top of the aspx page you ll find the <%@ Page %> directive with the Inherits attribute (Inherits= Microsoft.SharePoint.Portal.Analytics.UI.SspQueryLoggingReportPage,Microsoft.SharePoint.Portal,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c ). This directive states that the source code for the page is stored in the Microsoft.SharePoint.Portal.dll and the namespace, the aspx page s class, is in is Microsoft.SharePoint.Portal.Analytics.UI. Further down in the source code you ll see that the Web parts used on the page include Analytics:TopBestBetsReportControl and Analytics:TopDestinationsReportControl.
Using Reflector, open the Microsoft.SharePoint.Portal.dll, located at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI. Expand the following nodes of the tree: Microsoft.SharePoint.Portal | Microsoft.SharePoint.Portal.dll | Microsoft.SharePoint.Portal.Analytics.UI to reveal SspQueryLoggingReportPage, as well as TopBestBetsReportControl and TopDestinationsReportControl, among other choices (see Figure 8).
Figure 8: Reflector viewing the Microsoft.SharePoint.Portal.Analytics.UI namespace.
To view the class source code, right-click TopBestBetsReportControl and select Disassemble from the menu. In the right pane, select the Expand Methods link at the bottom of the code listing to see the code shown in Figure 9.
[SharePointPermission(SecurityAction.Demand, ObjectModel=true),
AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
public sealed class TopBestBetsReportControl :
QueryLargeListReportControl
{
// Properties
protected override string RdlFileName
{
get
{
return "ResultsTopBestBets.rdlc";
}
}
protected override string StoredProcedureName
{
get
{
return "proc_MSS_QLog_TopBestBets";
}
}
protected override string TitleText
{
get
{
return StringResourceManager.GetString(
LocStringId.SearchAnalytics_TopBestBetsTitle);
}
}
}
Figure 9: Reflector view of TopBestBetsReportControl.
From this glimpse at the source code, you can see that SharePoint is using an embedded form of Reporting Services to generate the reports, and you can see the name of the stored procedure feeding data to the report. Searching the SharePoint server s hard drive reveals that the .rdlc file ResultsTopBestBets.rdlc is located at C:\Program Files\Microsoft Office Servers\12.0\Bin\Analytics, along with 24 other rdlc files. An rdlc file is a compact Reporting Services report definition file. The major difference is that connection information is not stored inside the file in the case of rdlc report definitions. To learn more about adding reporting services to your application, visit http://msdn2.microsoft.com/en-us/library/aa964126.aspx.
The next logical step in this investigation is to find the stored procedure and see what kinds of data it (and similar reporting stored procedures) makes available. Open the SQL Server Management Studio and expand the Programmability section of the SharedServices_DB database (not the SharedServices_Search_DB) to find the stored procedure proc_MSS_QLog_TopBestBets. Here you can see the data returned, as well as the source tables where the raw data is stored.
Conclusion
At this point, you ve learned how SharePoint ships with some Web parts that execute SQL Statements and presents the results using customized SQL Server Reporting Services display logic. Now the challenge is to use this knowledge to build our own custom Web part which is what we ll do in Part II.
The source code accompanying this series is available for download.
Matthew S. Ranlett, a senior consultant with Intellinet s Information Worker team, is based out of Atlanta. A Microsoft SQL Server MVP, Matt is co-author of Professional SharePoint 2007 Development, and co-founder of the Atlanta .NET Regular Guys, hosted at DevCow (http://www.devcow.com).
Brendon Schwartz is a principal consultant with Slalom Consulting in Atlanta specializing in SharePoint 2007. Brendon is a Microsoft MVP, co-author of Professional SharePoint 2007 Development, and co-founder of the Atlanta .NET Regular Guys, hosted at DevCow (http://www.devcow.com).
