Query Language
One of the most important and often ignored
options is the query language. All modern browsers allow the user to
define a browser language. This is not the language of the browser
interface, but the language preference submitted to web sites. The
result set returned by SharePoint or most federated locations is
affected by the language preference. A common confusion for end users is
why certain results are not returned or why they
get different results returned when performing the same search on
different computers. Setting a default language forces the search to be
executed using a specific language, word breaker, noiseword table, and
stemming (if enabled).
Fixed Searches
The Fixed Keyword Query setting is an easy way
to define specific searches that do not require user input. The Search
Core Results Web Part can be placed on any page. If a fixed keyword
query is defined, the results view will automatically be populated with
the corresponding results when the user enters that page.
The main reason this is such a powerful option
is that it also accepts complex queries. It is possible to set the fixed
keyword query to always search and display news from a specific
department in a given time frame using a department managed property and
one of the date property values.
Appended Searches
It is also possible to append text to the
existing query (similar to the Search Box Web Part). This allows all
queries redirected to the given page containing this Search Core Results
Web Part to be augmented by this appended text. The relevancy is, for
example, if the search center is targeting specific content. Thus the
appended text acts as a result set filter.
Metadata and Sorting
The Custom columns setting, which is configured by editing the Fetched Properties text box (Figure 14),
is used to specify the metadata to output to the search result XML.
This allows custom properties or metadata to be displayed by modifying
the XSLT template.
Figure 14. Configuring search output
The Location property, which specifies the
location to fetch properties from, affects which metadata properties
will be available. For the selected location, only properties relevant
to this location are available. The relevant properties are defined at
Search service application level if it is a SharePoint location. For
other locations outside SharePoint, they are not.
If Use Location Visualization is selected, the
fetched properties are automatically populated and the section is grayed
out. If it is required to edit which columns to fetch and output,
deselect Use Location Visualization. This makes the fetched properties
text box editable. If the Fetched Properties are configured to include a
property that is not available from the location, that property will
not be included in the XML output from the Web Part, which means that it
has no effect when used in an XSLT template.
To edit the location visualization, go to the
Search service application and open Local Search Results Federated
Location. Here a new section for the Core Search Results metadata is
added.
The benefit is that it allows a consistent look
and feel to be defined for search results on all search centers on the
farm. As mentioned this can be overridden locally by un checking the Use
Location Visualization check box and defining which columns to output.
To add a custom column and display it in the Search Core Results Web Part, do the following:
- Check for crawled property: Make sure the custom property is
crawled. This can be done by searching for it in the crawled properties
collection on the relevant Search application.
- Create managed property: Create a new managed property, and map this managed property's custom column crawled property.
- Add property to Web Part output: On the
Display Properties group of the Search Core Results Web Part, add the
new property to the Columns section by typing the new column name as
<Column Name=”custom_property” />. - Add property to XSL: Add the column for the custom property
to the XSL template such that it gets rendered. This is done by clicking
the XSL Editor button, which opens the browser-based XSL text editor.
Locate and apply the appropriate rendering logic inside:
<xsl:template match=”Result”>.
Another important option is the Default Results
Sorting setting. In standard SharePoint 2010 Search, it is not possible
to configure sorting for properties other than Ranking and Modified
Date. This is possible in FAST search, where sorting can be configured
for all metadata properties, including custom properties.
Note Crawled properties are prefixed by an acronym for its typename. If the custom property is of type string and the name is “custom_property”, the crawled property will be “ows_custom_property”.
Top Federated Results
The Top Federated Results Web Part settings (Figure 15)
are used to execute and display search results from federated
locations. They contain the same search settings as the Search Core
Results Web Part with the exception of the Location properties. A
notable advantage of this Web Part is the option to aggregate results
from several locations. In this section, we will look at the following
search-related settings of the Top Federated Results: choosing a
federated location and using the asynchronous Ajax options.
Figure 15. Top Federated Results settings
Choosing a Federated Location
To use any new federated location, choose it
from the Location drop-down. Alternatively the pre-defined Internet
Search Results location can be selected. This searches http://bing.com using the Open Search 1.1 standard and RSS. To complete the configuration, follow these steps. The results are shown in Figure 16.
- After selecting a location, click Apply, and then OK.
- Click Stop Editing on the ribbon, and test the new settings with a query.
Figure 16. Example of top federated results
Using the Asynchronous Ajax Options
One of the important but often overlooked features is the option to use asynchronous loading of federated search results (Figure 17). Some federated sources may respond slowly, causing the user interface in SP2010 to seem unresponsive.
Figure 17. Asynchronous loading of external content
Per default, the user
interface will not render until the entire page is ready, which includes
fetching all federated search results. To avoid this, it is recommended
to use the Enable Asynchronous Load option for federated locations
outside your company's control.
