Episerver Commerce SearchProvider – demystifying

This post is an excerpt from my book, but it’s the short one. It looks like there is a confusion of where the searchprovider is used in Commerce

Many important features in Commerce Manager use index-based search provider to search for entries – it’s simply faster and more flexible to work with. They might not be truly “real-time”, but they’re close (with the right configuration). The only drawbacks are they require extra processing (for indexing entries), external files/configurations, but the advantages easily overweight any of those drawbacks.

There are three search providers provided by Episerver Commerce: LuceneSearchProvider, Solr35SearchProvider, and FindSearchProvider (four if you count SolrSearchProvider as well). LuceneSearchProvider comes as the default option with EPiServer.Commerce.Core, and it’s the only one does not require extra configurations.

LuceneSearchProvider works pretty well to some points, but after that, it’ll struggle when the catalog becomes big enough, or when it has to process high number of queries at the same time. When that happens, it might be the time for you to consider more suitable search providers – Solr35SearchProvider, FindSearchProvider, or even better, Find Commerce.

Strictly speaking, Find Commerce does not fully replace a search provider, because it can not be used in Commerce Manager. However, it’s usually the front end site which has to manage the high load of queries. You can still use LuceneSearchProvider in Commerce Manager.

Where SearchProvider is used.

It can be confusing to understand where the SearchProvider is used or how does it distinct from EPiServer Search? It can be easier to grasp the idea if you remember that SearchProvider concept came from a Commerce (Mediachase eCF) background. Despite of a big effort Episerver have tried to integrate Commerce into CMS, they are still two sub-systems working together at this time of writing (and will be, at least in near future).

  • EPiServer Search uses LuceneSearch internally and works with CMS pages. In case you use EPiServer Find, it uses Find internally.
  • SearchProvider works only with catalog entries.

Then where SearchProvider is used?

  • Commerce Manager: As mentioned above, Commerce Manager uses SearchProvider in almost search-related functionalities, either when you search to edit an entry, or when you add a lineitem to an order, or when you set an entry to be a gift in a promotion.
New line item catalog, powered by SearchProvider
New line item catalog, powered by SearchProvider

There is still one exception: Search by code or id in Catalog Management use SQL search internally.

Search By Code/Id is the only place which *does not* use SearchProvider

Search by code/id uses SQL internally, so you have to input the keyword exactly
Search by code/id uses SQL internally, so you have to input the keyword exactly
  • Front end: Catalog UI uses SearchProvider in the quick search box:

Search box use SearchProvider, but returns all entries including inactive

Catalog UI quick search box uses SearchProvider internally
Catalog UI uses SearchProvider internally

And Global search uses SearchProvider as well:

Global search, search results from SearchProvider are combined with results from other searches

Global Search combines results from SearchProvider and other search sources
Global Search combines results from SearchProvider and other search sources

The search in view-mode, is of course, depends on your choice. Most of the implementations will go with Search API:s (which use SearchProvider internally), sites with FindCommerce usually use the functionalities provided by Find.

What happens if you use Find? SearchProvider still works separately, even if you use FindSearchProvider – FindSearchProvider uses Find internally, but in “its own way”, not the “strongly typed contents” as FindCommerce does. The indices for Find and for FindSearchProvider will still be separated, even if you share the same service from Episerver.


One thought on “Episerver Commerce SearchProvider – demystifying

  1. Hello,

    We have set as default provider LuceneAzureSearchProvider (in both CMS and Commerce websites).
    When we have tried to index the catalog we have received the following exception for every product:

    “Mediachase.Search.Extensions.BaseCatalogIndexBuilder : Failed to index catalog entry 205-6020-8612-55-00000046882906(265851) in Shop. Exception: Mediachase.Search.RetryableIndexingException: Lock obtain timed out: [email protected]. —> Lucene.Net.Store.LockObtainFailedException: Lock obtain timed out: [email protected].
    at Lucene.Net.Store.Lock.Obtain(Int64 lockWaitTimeout) in d:\Lucene.Net\FullRepo\trunk\src\core\Store\Lock.cs:line 97
    at Lucene.Net.Index.IndexWriter.Init(Directory d, Analyzer a, Boolean create, IndexDeletionPolicy deletionPolicy, Int32 maxFieldLength, IndexingChain indexingChain, IndexCommit commit) in d:\Lucene.Net\FullRepo\trunk\src\core\Index\IndexWriter.cs:line 1228
    at Lucene.Net.Index.IndexWriter..ctor(Directory d, Analyzer a, Boolean create, MaxFieldLength mfl) in d:\Lucene.Net\FullRepo\trunk\src\core\Index\IndexWriter.cs:line 1019
    at Mediachase.Search.Providers.Lucene.LuceneIndexWriter.Commit()
    — End of inner exception stack trace —
    at Mediachase.Search.Providers.Lucene.LuceneIndexWriter.Commit()
    at Mediachase.Search.Providers.Lucene.LuceneSearchProvider.Index(String applicationName, String scope, ISearchDocument document)
    at Mediachase.Search.Extensions.BaseCatalogIndexBuilder.IndexCatalogEntryDto(IndexBuilder indexer, CatalogEntryRow entryRow, String defaultCurrency, String[] languages)
    at Mediachase.Search.Extensions.BaseCatalogIndexBuilder.c__DisplayClass17_0.b__0(CatalogEntryDto entryDto)”

    Other details:
    1. Episerver vesion used: Episerver.Commerce 11.4.1 & Episerver.CMS 10.10.4
    2. Project hosted on DXC environment

    Could you please help us with a suggestion on how we can fix the issue?

    Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *