The Coveo Search Provider settings are located in the
Coveo.SearchProvider.config file, which is located under
App_Config\Include\Coveo. This page describes its various sections and settings.
To avoid modifying the original file, you should configure the Coveo Search Provider by modifying the
Coveo.SearchProvider.Custom.config file, which is located in the same folder.
Basic Configuration Settings
Those are the basic settings that may be configured initially. They can be found under the
|The Admin Service URI.||http://localhost/AdminService|
Whether to allow search queries to be sent in the context of a Coveo quick view. The element is under the
Setting the value to
The default value is
|The name of the collection in CES.|
Allows the specification of settings to apply on facets when performing a LINQ query (
|The default injection depth value to apply on facets when performing a LINQ query (|
|The default number of facet values that are returned when performing a LINQ query (|
|The default number of results that are returned when performing a LINQ query (see Retrieving Large Sets of Items Using LINQ). The element is under |
|Whether Sitecore boosting is supported in queries or not.|
|Whether to encrypt data sent to the indexing queue.|
The name of the Sitecore farm. Specifying a value in this setting will affect the names of the sources, fieldsets, security provider, and user identity.
For example, setting the farm name to
When this setting is not specified, the farm name corresponds to the instance name which is, by default, composed of the machine name and the IIS website name (e.g. MyMachine - SiteName).
|The number of fields to send in a single batch to the Admin Service.||250|
Whether to force a delete on excluded items.
|Whether to index all Sitecore fields. If set to |
|Whether to index fields needed for Analytics, such as the |
|The factory used to instantiate objects required to communicate with the index.|
|Whether to index Coveo fields on documents. These fields are system fields that are not starting with an underscore (_), such as |
|Whether referrer items are re-indexed on an item update.|
|Defines the delay that query results are cached before being refreshed by a new query on the index. This element is under the ||00:15:00|
The separator used for fields that contain multiple values. For example, a field could contain a series of GUIDs.
The Admin Service password.
|Whether to send the Sitecore users and roles to Coveo Cloud on each index rebuild.|
The RabbitMQ password.
The RabbitMQ URI.
|The RabbitMQ username.|
|The message size threshold beyond which binary data is compressed in RabbitMQ queues. Useful when indexing large files in the media library.||10 (MB).|
The delay, in seconds, before the index requirements are invalidated. Setting the value to zero means that the index requirements is checked before any indexing operation. The index requirements include the sources, fieldsets, security provider, and user identity.
Useful when there are frequent indexing operations that are batched by the Sitecore search provider. In other words, the index configuration is verified each time an item is indexed. This behavior might occur in these situations:
The name of the security provider in the Coveo platform. Used when many Sitecore instances are targetting the same Coveo platform.
This setting supersedes the value set in the
|The Sitecore server URL. Used by the Coveo security provider.||http://jetstreamsitecore7/|
Whether the clickable URI should be shortened. This will be taken into account in the
The Sitecore password. Used for the Coveo security provider.
|The Sitecore username. Used for the Coveo security provider.|
|The URI of the Sitecore Web Service. Used to retrieve the binary data of Sitecore items.||http://sitecoreInstance/sitecore%20modules/Web/Coveo/WebService/SitecoreWebService.asmx|
|The site name to extract Sitecore content from.|
|Whether to skip the First time setup check on Coveo Enterprise Search when initializing. Can be used on Content Delivery only servers.|
The name of the user identity in the Coveo platform. Used when many Sitecore instances are targeting the same Coveo platform.
This setting supersedes the value set in the
|The Admin Service username.|
Index-Related Configuration Settings
Those are the settings that are specific to the Coveo index. They can be found under the
|param desc="p_Name"||The name (id) of the index.|
|BinaryDataPropertiesWriter||The instance of IBinaryDataPropertiesWriter used to write binary data properties on documents sent to the Coveo platform .|
locations > crawler > database
|The database name associated with the crawler.|
locations > crawler > root
|The starting point of this crawler when indexing.|
|strategies||List all indexing strategies to apply to this index.|
|strategies > strategy > type||The Sitecore strategy to use.|
You need to add all the required parameters after this tag so the strategy can run correctly.
The source name to be used in the Coveo platform . This should only be set if you explicitly want to override the default source name created by Coveo for Sitecore.
Security-Related Configuration Settings
These are settings that are specific to the security configuration of the Search Provider. They can be added under the
|A semicolon-separated list of usernames that are considered as anonymous Sitecore users.|
|Whether to index the Sitecore permissions on items. Disabling this indexes all the items as Anonymous.|
|Skips the Sitecore credentials update in Coveo for the Security Provider. To be used on Content Delivery servers to simplify the setup.|
|Skips the login validation in Sitecore. To be used on Content Delivery only servers to simplify the setup.|
Miscellaneous Configuration Settings
Those are miscellaneous settings that are used to configure various modules of the Sitecore Search Provider. They can be found under the
The CES master information defines the different settings used to connect to CES. Here is an example:
The CES Communication factory is the factory responsible for enabling communication between CES 7 and Sitecore. A typical configuration of this node looks like this:
The Coveo Cloud platform communication factory is the factory responsible for enabling communication between the Coveo Cloud platform and Sitecore. A typical configuration of this node looks like this:
Computed fields are fields that are created from a combination of other fields.
A typical computed fields section looks like this:
The field map defines how a field is mapped between Coveo and Sitecore. Here is an example:
The field map also defines how fields are handled in the Coveo platform. For example, to include a field in a facet or to make it sortable, it must be defined in the
fieldMap node. Please note that changes to this section will be taken into account in the Coveo platform only after the affected items are re-indexed. Some of the most common options that can be defined on the
fieldType are explained in the following table.
|Parameter name||Description||Example value||Default value|
|Defines the field name.|
|Defines whether full-text search operations can be performed on this field.|
|Defines whether facets can be bound to this field. This is also required for wildcard search.|
|Defines whether this field contains multiple values. This is required for the "OR" and "AND" filtering in the facets.|
|Defines whether search results can be sorted by this field.|
|Defines whether the translation (addition of the "f" prefix and the source name hash suffix) should be avoided on this field.|
| ||Defines whether the field should be displayed in search results.|| || |
| ||Defines whether values used in a filter on this field are used for ranking calculation.|| |
|Defines whether to stem the query in a filter specific on this field.|| |
|Defines whether to load data in memory for index computed fields.|
|Defines whether to load data required to perform nested queries in memory.|
|Defines whether to load data of numeric queries in memory, which allows quicker numeric operations, including operations on dates.|
|Defines whether to load the sort data in memory.|
|Defines the type of field as seen by the index. For instance, in the case of an |
|Defines the type of class to be used for the configuration of this field. This should not be changed by a user.|
|Defines the input type of the field. For example, for an |
|Defines the converter to be used for this specific field. It must work with the |
|Parameter name||Description||Example value||Default value|
|fieldName||Defines the field name.||syssize|
|fieldTypeName||Defines the type of the field seen by the Coveo components (Facet, Facet Range, Slider).||Number / Integer / Date / Datetime||String|
The FieldReaders node defines which .NET class should handle a specific Sitecore field type. You can easily customize how a field is read by specifying its type name. In the
Sitecore.ContentSearch assembly, Sitecore already provides a few field readers for various types, such as Checkbox, Date, RichText, Image, Lookup, etc. You can also create your own field readers in .NET by inheriting the
Sitecore.ContentSearch.FieldReaders.FieldReader class and overriding the
GetIndexFieldName methods. For more details on how to achieve this, you can visit Sitecore's technical blog or Sitecore's official documentation portal.
The index field storage value formatter is used to convert some field into a format recognized by the Coveo index. Here is an example:
The common options of the conversion types are explained in the following table.
|Defines the type to which the conversion will be applied. It means that all fields with this type will be converted with the specified converter.|
|Defines the type of the converter to be used for this conversion type.|
Some fields can be created outside of the Sitecore context and have a meaning only in the search context. Those are not real fields on Sitecore items, but fields created on-the-fly by the corresponding processor.
Using Logging for Debugging Purposes
The Sitecore Search Provider uses the log4net logging library bundled with Sitecore. To enable logging, add the following node into the
web.config file of your Sitecore instance. To enable logging in whatever portion of the code, modify the logger's name.
You can add Sitecore pipeline processors using the Coveo Search Provider configuration file (see Using the Coveo Pipelines).