Condividi tramite

Content API for FAST Search Server 2010 for SharePoint

  • Articolo

FAST Search for SharePoint provides multiple options for crawling and retrieving content for indexing:

  • When you use the FAST Content SSA, the feeding/crawling will work in the same way as for SharePoint Server search. This is the recommended approach in most cases.
  • FAST Search for SharePoint also supports additional indexing connectors, to solve more advanced needs. For more information, see  Plan for crawling and federation (TechNet). There is also a table that provides a comparison of the connectors.
  • If you have a custom content source, you can in most cases retrieve data for indexing using the BCS framework.

If you have more specialized needs, there is one more option. The FAST Content API enables you to push content from a client .NET application. This API is mainly provided to enable customers of previous FAST products to migrate their custom content connectors and use them with FAST Search for SharePoint. You may also use this API for other custom applications, but note that there are certain limitations on the support for the API - see the download page for details.

The API provides an asynchronous interface for pushing items to the FAST Search farm from a remote client application. The API communicates with the FAST Search Content Distributor, using WCF. The API is based on .Net Framework 3.5.

If you are familiar with the FAST ESP .NET Content API, you will find it easy to use, but there are some differences:

  • The routing attributes are not supported
  • You can add multiple attachment documents for each item
  • You can add a security descriptor for each item, using a  Security Descriptor Definition Language string that describes the security/allowed access for an item
  • The API works with crawled properties, and in SharePoint the crawled properties must have a name and a GUID. When you add a crawled property to an item, you can set the crawled property GUID for the IDocumentFeeder instance, or for the property instances

By using the Content API, you create your own custom crawled properties. In the FAST Search Server farm, you should create a new crawled property category for the new crawled properties:

    $guid = [guid]::NewGuid()

    $cat = New-FASTSearchMetadataCategory -Name xmlprops -Propset $guid

    Set-FASTSearchMetadataCategory -Category $cat

    $guid

Note the GUID value. This is a unique value that you need to use in the API client.

In most cases it is convenient to use one crawled property category for all crawled properties used in the API, and then map the crawled properties to managed properties within the index schema. In that case, you only need to specify the GUID in IDocumentFeeder (PropertySet). You can also specify crawled property category for individual properties. When you create a 'Document', and wants to specify a unique GUID for the crawled properties, you can do that by adding elements of type Property (e.g. StringProperty), and add the GUID you have created above using PropertySet. 

You must also create a unique content collection for the Content API client. Do not use the default 'sp' collection.

For detailed documentation of the API interfaces, refer to the .chm help file that is part of the download.

Download: Content API for Microsoft FAST Search Server 2010 for Sharepoint

1.

Comments

  • Anonymous
    December 14, 2011
    Hi Knut, We are trying to update an indexed document using the FS4SP Content API. We are facing few problems in setting the security descriptor as it is a mandatory field for an update. Would you be able to provide some sample code for this ? Specifically we are looking for the accessMask value to be set in the AddAccess method of the DiscretionaryACL class. We are not able to figure out any documentation that explains the various options of accessMask & what they mean. The sample code with the ContentAPI isnt really of much help in this regards. We were able to update an the ACL for an indexed doc with using the "0xffffffffL" access mask. however we want to understand this in detail before we ship any such change in production. Any guidance would be greatly appreciated. Thanks, Ashwani