Share via

SharePoint 2010: Integrating FAST Search

  • Article

Introduction

FAST Search Server 2010 for SharePoint (FAST Search for SharePoint) is an alternative to the out-of-box SharePoint Server search (the built-in enterprise search solution in SharePoint Server 2010). It utilizes the same Search Service Application framework as SharePoint Server search, including most integration points. The back-end architecture, however, is rather different.

You can find more information about the functional differences between the two enterprise search solutions in the following white paper: Getting started with enterprise search in SharePoint 2010 Products.

FAST Search Server in the SharePoint farm architecture

A SharePoint Server farm is one SharePoint deployment sharing one Central Administration. In a standard SharePoint deployment, the search capabilities (SharePoint Server search) are part of the SharePoint farm out-of-box.

The FAST Search for SharePoint back-end is not part of the SharePoint farm itself but is deployed and configured as a separate farm – the FAST Search for SharePoint farm (FAST farm).

The FAST farm can be seen as an extension to the parent SharePoint farm. The FAST farm cannot exist without the parent SharePoint farm. When deployed, FAST Search for SharePoint replaces the out-of-box SharePoint Server search as the search provider in the SharePoint farm. The SharePoint farm and the FAST Search for SharePoint farm are connected via the concept of Search Service Applications (SSAs).
**
**More information: Plan search topology.

Search Service Applications

A good reference to the Search Service Application framework is SharePoint Service Application Framework Object Model. 

In a SharePoint Server deployment, when using the standard SharePoint Server search, there is one SSA (often denoted “the SSA”), which represents the grouping of the search components of the farm. This SSA consists of one or more crawl components and one or more query components.

Note: In SharePoint Server search terminology the crawl component also includes the indexer. This is not the case in FAST Search for SharePoint.

In a FAST Search for SharePoint deployment, the users interact with the SharePoint farm via two SSAs, the FAST Search Query SSA and the FAST Search Content SSA. 
 
Note: In a FAST Search for SharePoint deployment, you may still see an SSA named “Search Service Application” from SharePoint Central Admin. This is actually the SharePoint Server search SSA that was created when the SharePoint farm was deployed in the first place, and will not be used after you have deployed FAST Search for SharePoint. This may be confusing for commands that are associated with service applications.

More information: Plan search service applications (TechNet).

Single and multiple farm architecture

The following figure shows how FAST Search for SharePoint fits into a SharePoint Server farm:


The Content SSA provides the crawl/connector interface for FAST Search for SharePoint. The Query SSA provides the query side integration between FAST Search for SharePoint and the query interfaces as exposed in SharePoint.

The following figure shows the multiple farm architecture when using FAST Search for SharePoint:


In this deployment, there is one centralized search farm that index content from multiple SharePoint farms, and also serves queries for these farms.

Note: The SSAs are located in the parent SharePoint farm, not the child farms. You should not configure more than one SSA of each type associated with the FAST Search for SharePoint farm.

The FAST Search Query SSA

The query SSA provides the query side integration between FAST Search for SharePoint and the query interfaces as exposed in SharePoint (Web parts, Query Web Service, Query OM, and Federation OM).

The key differences from the SharePoint Server search SSA are:

  • All queries except People Search queries are sent to the FAST Search for SharePoint farm. This means that most of the query load is in the FAST farm, and in most cases, you only need to scale out the Query SSA for fault tolerance.
  • All crawling, except user profiles for People Search, are handled in the Content SSA, not the Query SSA.
  • People Search queries are executed by the query component within the FAST Query SSA.
  • Note that the FAST Query SSA also includes a crawl component that crawls and indexes user profile data for people search Remember that this is a different crawl component than the one you find in the FAST Content SSA!

The Query SSA contains an instance of SharePoint Server search that handles People Search. This one operates rather independently of the FAST Search Server back-end, and the front-end federates people search results with other results in the web parts. This instance of SharePoint Server search includes a crawl component that crawls user profile data from SharePoint, and a query component that responds to people search queries.
 
If you need to change the People Search configuration (scopes, customizing ranking, etc.) it is important to understand that this must be done using the SharePoint Server search admin interfaces, not the FAST Search admin interfaces!

People Search has its own scaling model. Normally you do not need to scale out People Search for performance, but you may want to have an end-to-end fault-tolerance. To achieve that, you need to configure two query components, and two crawl components in the Query SSA (the crawl components will only crawl user profile data).

Note: You scale out the Query SSA by adding query components, not by adding multiple SSAs!

There is an important difference in how you configure features for people to search and non-people search. Example: If you want to change managed properties configuration for people search, you do that from Queries and Results --> Metadata Properties: 

For non-people search content, you change the configuration from FAST Search Administration --> Managed Properties:

The FAST Search Content SSA

The Content SSA behaves in the same way as the SharePoint Server search crawler from a content retrieval point of view (content sources, crawl rules, etc.). The crawl DB is used for content retrieval (crawling) housekeeping in the same way. 

Definition and handling of content sources are handled in mainly the same way as for SharePoint Server search. 

The key difference from how SharePoint Server search performs crawling is:

  • The main part of the item processing (parsing documents, etc.) and the indexing happens in the FAST Search farm. SharePoint Server search performs all processing and indexing inside the crawl component of the SSA. This means that you will experience less crawl load on the crawl component, but the load is still significant in a larger deployment.
  • The Content SSA represents the default indexing connector for crawling content with FAST Search for SharePoint. If you have special crawling needs, there exist some FAST specific connectors that can only be used with FAST Search for SharePoint. They are managed as stand-alone connectors which interface directly with the FAST Search for SharePoint farm (not using the Content SSA). For more information, see Plan to deploy FAST Search specific connectors.

Integration points (SDK)

The main integration points are the same for SharePoint Server search and FAST Search for SharePoint:

  • Query integration: You use the same Query Web Service and Query/Federation Object Model for integration. There are some important differences, and they are explained in FAST Search query integration overview (MSDN). One key difference is that with FAST Search for SharePoint you can also use the FAST Query Language (FQL). This is a supplement to the default SharePoint Keyword Query Syntax and provides a more efficient query language for programmatic integration.
  • Creating custom connectors: You use the same framework, and this is further explained on MSDN: SharePoint Server Search Connector Framework.

Some integration points and customization options are specific to FAST Search for SharePoint:

  • Custom item processing. FAST Search for SharePoint provides a unique framework that enables you to impact how items are being indexed. It is possible to modify the content or create new metadata for the content that is indexed. For more information, see Customizing item processing (MSDN).
    • The following article provides an example on how to use the custom item processing framework to submit test XML documents for indexing: [[How to create a FAST Search for SharePoint test document using XMLMapper]].
  • Custom administration. There is a dedicated FAST Search administration object model that you can use. This OM includes management of the index schema, as well as how to manage the contextual search experience. For more information, see Programmatically administering FAST Search Server 2010 for SharePoint.

Also see this useful blog post that explains the query integration points: The Search Developer Story in SharePoint 2010 - Query Interfaces

See Also