Indexing catalog content using EPiServer Find Content Indexing Job
When developing a commerce site, a good search product might be the key to success. Working search driven can make the site fast, easy to understand, and simple to use. For me, EPiServer Find is the obvious choice when working with EPiServer Commerce.
Find search provider
When using EPiServer Find in a commerce site, you might end up using the “Find seach provider” on the site, which isn’t that good. Instead you should work with the strongly typed “catalog content”, that are being indexed when adding or updating content in the new catalog UI. The problem with the typed catalog content, is that there’s no indexing job for it.
So, why should we use catalog content (the content types you create in code) instead of the content stored by the find search provider? The Find search provider index the data untyped in different dictionaries. The provider system can be used for free text search and maybe an simple facet, but is not useful for more complex operations. Indexing the content types you have created, makes it possible to make strongly typed search queries, facets, and listings. All the properties you create in code, and all the properties in the base classes can be used in the search queries. The code will also be pretty and easy to understand when working against typed data. You will also get help from the compiler to write correct code when working with typed data.
Indexing catalog content using the find indexing job
We can make the “EPiServer Find Content Indexing Job” index catalog content for us using the code below.
[ServiceConfiguration(typeof(IReindexInformation))]
public class DescendetLinksOfCatalogRoot : IReindexInformation
{
private readonly IContentLoader _contentLoader;
private readonly ReferenceConverter _referenceConverter;
private readonly ILanguageBranchRepository _languageBranchRepository;
public DescendetLinksOfCatalogRoot(ReferenceConverter referenceConverter,
IContentLoader contentLoader,
ILanguageBranchRepository languageBranchRepository)
{
_contentLoader = contentLoader;
_referenceConverter = referenceConverter;
_languageBranchRepository = languageBranchRepository;
}
/// <summary>
/// Returns all descendents of the <see cref="Root"/>.
/// </summary>
public IEnumerable<ReindexTarget> ReindexTargets
{
get
{
var catalogs = _contentLoader.GetChildren<CatalogContent>(Root);
foreach (var catalogContent in catalogs)
{
var reindexTarget = new ReindexTarget()
{
ContentLinks = _contentLoader.GetDescendents(catalogContent.ContentLink)
};
var languages = catalogContent.ExistingLanguages.ToList();
if (!languages.Select(x => x.Name).Contains(catalogContent.DefaultLanguage))
{
languages.Add(CultureInfo.GetCultureInfo(catalogContent.DefaultLanguage));
}
reindexTarget.Languages = languages;
yield return reindexTarget;
}
}
}
/// <summary>
/// Gets the reference of the catalog root.
/// </summary>
public ContentReference Root
{
get { return _referenceConverter.GetRootLink(); }
}
}
Nice post Jonas!
Straight to favourites
This is amazing - many thanks for this - it saved our bacon :)
Hi Jonas, I see this is for Commerce 7.5, would you know if this will work with Commerce 1 R3?
This will not work for Commerce 1 R3, because there is no such thing as strongly typed catalog content in that version.
While this will indeed index your strongly typed product/variant classes, I'm guessing it won't really affect the search provider itself? As in, when searching from within the catalog gadget inside commerce, it will still look in my FindDocuments , I guess? Aka, the index will basically be twice the size (in number of documents). Which is, obviously, not very practical.
And, in some cases, it might even burst the entire license model (If I have 4000 products, I need 8000 documents in the index, which tips me from the (current) Standard Small package to the Standard medium - more than doubling the price because of a weak implementation. This is currently an issue for me with a developer index...
Is this something that will be fixed in the (near?) future?
IMO, the default indexing should be:
1. Moved out from the commerce manager, and into the normal CMS Admin interface.
2. Index my real IContent based types, and not as FindDocuments
3. Use these documents as the basis for the gadget search. If need be (temporarily or not), make remapping from proper to oldschool objects in the commerce manager, not the other way around like it seems to be today.
Any useful input? :-)
Hi Jonas,
http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=88260&epslanguage=en
Any Idea?
Regards
/K
Arve: Thanks for the input.
Has there ever been a solution to this? I'm facing the same issue as Arve where our Find Index is twice the size because of FindDocument types.