Query Pipelines
A Query Pipeline transforms a set of inputs into a Solr query request and it can execute requests and manipulate the Solr response as well, via a set of modularized operations called Query Stages. The objects sent from stage to stage are Request objects and Response objects.
Fusion stores pipeline names and definitions, allowing a pipeline to be reused across applications. Pipeline definitions can be modified, so that as an application evolves, the pipelines used by that application can evolve accordingly. During application development, the Fusion UI can be used to develop and debug a Query Pipeline.
The available stage types allow setting specific parameters for the query, such as the number of results to return or the query parser to use. You can also define facets and recommendations to be returned with the results. If Access Control Lists (ACLs) are in use, you can apply a security-trimming stage to apply user access restrictions to the results.
For details about the available REST APIs, see Query Pipelines API and Query Stages API.
Search mode
When creating a query pipeline, you can select a search mode for the pipeline to use.
-
dsl(Domain Specific Language) uses expressive search queries and responses via a structured, modern JSON format. -
legacyprimarily uses Solr parameters. See the Solr Query Language cheat sheet. -
alluses both DSL and legacy search modes. This is the default value.
The default value of all works well for most use cases.
|
Default query pipelines
Fusion creates a default query pipeline when you create an app. The query pipeline has the same name as the app.
The default query pipeline has the following pre-configured stages:
-
This stage uses the SolrTextTagger handler to identify known entities in the query by searching the
COLLECTION_NAME_query_rewritecollection. See Manage Collections in the Fusion UI for more information.
For Fusion 5.x.x organizations that do not have a Predictive Merchandiser license, the Solr Text Tagger handler also searches the COLLECTION_NAME_query_rewrite_staging collection in the case of the Fusion query rewriting Simulator).
|
-
The Boost with Signals query pipeline stage uses aggregated signals to selectively boost items in the set of search results.
-
The Query Fields query pipeline stage defines common Solr query parameters for the edismax query parser. If using a less-than sign (<) with DisMax, it must be escaped using a backslash. An alternative to this stage is the Additional Query Parameters stage.
-
The Field Facet query pipeline stage is used to add a Solr Field Facet query to the search query pipeline.
-
This stage looks up rules that have been deployed to the
COLLECTION_NAME_query_rewritecollection and matches them against the query. Matching rules that perform query rewriting are applied at this stage, while matching rules that perform response rewriting are applied by the Modify Response with Rules stage later in the pipeline.
| To trigger a rule that contains a tag, specify the tagname in the request URL of the user search app. See Easily define triggers in tags for more information. |
-
The Solr Query stage transforms the Fusion query pipeline Request object into a Solr query and sends it to Solr.
-
Most rules operate on the request, but some rule types, such as banner rules or redirect rules, do their work when the response comes back. The Modify Response with Rules stage applies those rules to the response. For example, a banner rule can add a banner URL to the response before returning it to the client.
Custom query pipelines
Using the Query Workbench or the REST API, you can develop custom pipelines to suit any search application. Start with any of Fusion’s built-in query pipelines, then add, remove, and re-order the pipeline stages as needed to produce the appropriate query results.
Asynchronous query pipeline processing
Query pipeline processing performance can be improved by enabling asynchronous processing for certain stages that make requests to secondary collections, external databases, and so on. The following stages support asynchronous processing:
This feature uses the fork-and-join model, where any of the stages above can create a fork on the pipeline. The parallel processes are joined again using the Merge Async Results stage at a later point in the pipeline.