Anyone who likes SharePoint Enterprise Search has to love FAST. As a developer, sooner or later you are going to want to take advantage of the FAST Query Language also known as FQL. This lets you truly leverage the power of FAST and perform very advanced queries. I’ve shown you how to use the KeywordQuery class in the last post. Now we’re going to expand on that to execute FQL queries. It’s actually easier than you might suspect. It all starts with setting the EnableFQL on the KeywordQuery class to true. Of course, you still have to remember how to put the rest of it together first.
In SharePoint 2013 KQL statements are translated to FQL before being executed. If this will hold true forever no one knows, but probably until that part of the search engine is being rewritten at some point – and this is good news as FQL has some tricks up it sleeve compared to the polished KQL counterpart.
SharePoint 2013 includes two query languages which can be used to formulate your search queries. The Keyword Query Language (KQL) and the FAST Query Language (FQL). KQL is the language you will mostly use when writing search queries, and is aimed at end-users.
FQL has some extended capabilities over KQL, but you will usually solve your queries using KQL.
The basis of KQL is a set of operators and special characters you can use to formulate your queries. The KQL version included in SharePoint 2013 also have some enhancements brought over from FQL.
Search in SharePoint 2013 enables users to modify the managed properties of crawled items before they are indexed by calling out to an external content enrichment web service. The ability to modify managed properties for items during content processing is helpful when performing tasks such as data cleansing, entity extraction, classification, and tagging.
The major two drawbacks of this process are:
- Whatever custom processing we need, must be performed within this single WCF service call. There is only one registration of a Content Enrichment Web Service allowed per pipeline (and there is only one pipeline allowed per Search Service Application). This introduced a bottleneck where we have requirements for multiple external processing of documents passing through the pipeline.
- After we register the Content Enrichment Web Service it will be applicable for all “Content Sources” in a specific Search Service Application. In practical scenario if we might have multiple Search Content Sources for a Search Service Application and have different requirements for each of the Content Sources there is no way to achieve this.
Registering a WCF Routing Service as Content Enrichment Web Service(“CEWS”) can resolve this problem which we’ll discuss in the next article.