Some hints on testing custom managed properties and queries
When you customize your FAST Search Server deployment, there are certainly things that may go wrong. Sometimes it is convenient to reduce the number of potential error sources and test that the custom managed property mapping works properly.
It is possible to submit test documents directly to the FAST Search Server deployment (in case the issue is in the crawling). You can submit test items using 'docpush', and you can also set up the item processing pipeline so that you can submit test documents as XML. By using XML test documents, you can make your own crawled properties and map to managed properties the way you want. This is explained in the following TechNet Wiki article: How to create a FAST Search for SharePoint test document using XMLMapper. Note that 'docpush' is only supported for testing, you should not use it in a production environment.
There are some useful query test tools provided by the community that you can use to test your customizations. One good example is https://blogs.technet.com/b/speschka/archive/2010/08/15/free-developer-search-tool-for-sharepoint-2010-search-and-fast-search-for-sharepoint.aspx
Another simple way to test queries, is to use a PowerShell script that access the Query OM. In this way, you can verify what's returned from the OM, and hence figure out if the problem is in the back-end or in the Web Part (or your custom query app). The attached PowerShell script runs a query via the KeywordQuery interface, and returns the selected custom managed property.
usage: propertytest.ps1 <URL> <Hits> <Property> <Query>
- <URL> - Specifies the URL for the query front-end web server of the SharePoint farm.
- <Hits> - Number of hits to return.
- <Property> - Specifies the name of a managed property. Prints the content of the property and associated query refiner data. Use lowercase only, even if the property name contains uppercase letters.
- <Query> - The query string in FQL syntax. Use single quotes if it contains spaces or double quotes.
If there are no refiners defined for the property, all OOB refiners are printed.
The script is also useful for other test purposes:
- If you have specified a query refiner for the property, it will also provide the refinement data. This is useful for testing custom property extractors and refiners.
- The script will also return the rank value, in case you are testing relevancy features.
- The script accepts queries according to the FAST Query Language (FQL) syntax. This enables you to easily test advanced FQL query features. If you are not familiar to FQL: For basic property filters and single term queries, the syntax issimilar to the standard SharePoint Keyword Syntax you type in any SharePoint query box.
- It is easy to test other OM features via PowerShell.
There is also another way to test queries. FAST Search Server provides an internal test query interface on the query processing server. This is explained in Test feeding and searching on FAST Search Server 2010 for SharePoint. This works fine if you index items with no access right restrictions, which is the case when you use 'docpush'. But for SharePoint data it will not work without some security tweaks, as this interface does not enable any authentication. Hence, it may be more convenient to test using the PowerShell script described in this blog.