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.

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

• Front end: Catalog UI uses SearchProvider in the quick search box:

And Global search uses SearchProvider as well:

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.