Search
Describes the extensive, system-wide search engine that comes with Optimizely Customized Commerce.
You can make any information available to the search engine, even if that information is not in the Optimizely Customized Commerce database. Some systems, such as Catalog and Orders, have additional search features.
Customized Commerce has its own pluggable API for search providers. The search engine is based on provider model, meaning you can create your own providers to search servers. Customized Commerce comes with providers for Lucene (built-in).
The search provider can be used to build user-facing features in the site implementation. An even more powerful approach is to integrate Customized Commerce with Optimizely Search & Navigation to create more advanced search-based navigation and filtering for websites.
Classes in this topic are available in the following namespaces:
- EPiServer.DataAnnotations
- Mediachase.Search
- Mediachase.Search.Extensions
- Mediachase.Search.Extensions.Indexers
Architecture
Customized Commerce has a layer built on top of Lucene for easy integration. A MediachaseSearch layer provides a base layer to simplify the interface. This base creates an index for any data source, while you still have access to the Lucene classes. Searchable data is written to a file index.
SearchExtensions provide catalog indexing and a searching implementation using the MediachaseSearch layer built into Customized Commerce and include several controls for this implementation. You can create you own search implementation on top of MediachaseSearch.
Index
To make data available, you must first index it by calling the Mediachase.Search.SearchManager.BuildIndex(bool rebuild) method. Click the Build or Rebuild buttons in the Customized Commerce Admin UI to call the method.
The individual indexer implementations are defined using SearchOptions class. The default catalog indexer included, Mediachase.Search.Extensions.Indexers.CatalogIndexBuilder, Mediachase.Search.Extensions, reads the catalog data and calls the SearchProvider.Index(string applicationName, string scope, ISearchDocument document) method.
Implement the method by the provider that is currently configured. The provider is passed an ISearchDocument, containing properties that need to be indexed. You can replace the indexer completely or extend the existing indexer by inheriting CatalogIndexBuilder class and overriding OnCatalogEntryIndex method. You also can add new indexers.
By default, the indexer only populates
- fields marked searchable in the metafield configuration
- fields decorated with the [Searchable] attribute on catalog content models
- some system fields like price, name, and code.
Depending on the provider, additional configuration changes need to be made to index those fields.
Calling BuildIndex with rebuild = *falseonly adds indexes that changed since the last index was created. The system tracks when the last index was performed using the .build file. Location of the .build* file is configured inside IndexerBasePath property of SearchOptions class for each indexer defined.
Example:Â Build index command.
SearchManager searchManager = new SearchManager(applicationName);
searchManager.BuildIndex(false);
The Catalog Service provides catalog metadata fields, which let you specify:
- Whether a field is added to the index. This alone does not make the field searchable.
- Whether a field value is stored. Stored = stored in an uncompressed format. Not stored = add the value to the index in a compressed format. Only store a value if you will use it as part of search result text.
- Whether a field is tokenized, that is, broken into individual, searchable words, and common words are omitted. Only tokenized fields are searchable.
Search
When the data is indexed, this index is searched. Search is done by calling the ISearchResults Mediachase.Search.Search(ISearchCriteria criteria) method. The method call is handled by the configured search provider and returns the ISearchResults interface.
CatalogEntrySearchCriteria criteria = new CatalogEntrySearchCriteria();
criteria.SearchPhrase = "canon";
SearchManager manager = new SearchManager(AppContext.Current.ApplicationName);
SearchResults results = manager.Search(criteria);
The search phrase can contain complex search syntax that is specific to a provider.
Facets and filters
Facets are organized into facet groups. A facet group is referred to as a Filter in the configuration file. For instance, a Color facet group can have a Red facet. In the configuration, Color_is the filter and _Red is a SimpleValue. A facet group is linked to a particular field or meta-field. You can specify facets as part of the ISearchCriteria interface.
See Facets foundation on how to implement facets.
Updated 9 months ago