Jonas Bergqvist
Jan 14, 2014
  9432
(3 votes)

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(); }
    }
}
Jan 14, 2014

Comments

Marcus Granström
Marcus Granström Jan 15, 2014 09:24 AM

Nice post Jonas!

K Khan
K Khan Jan 15, 2014 05:34 PM

Straight to favourites

Jonathan Roberts
Jonathan Roberts Jan 17, 2014 10:03 AM

This is amazing - many thanks for this - it saved our bacon :)

Feb 5, 2014 04:14 PM

Hi Jonas, I see this is for Commerce 7.5, would you know if this will work with Commerce 1 R3?

Mar 4, 2014 05:33 PM

This will not work for Commerce 1 R3, because there is no such thing as strongly typed catalog content in that version.

Arve Systad
Arve Systad Jul 8, 2014 04:34 PM

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? :-)

K Khan
K Khan Jul 9, 2014 09:21 AM

Hi Jonas,

http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=88260&epslanguage=en
Any Idea?

Regards
/K

Aug 18, 2014 08:16 AM

Arve: Thanks for the input.

Johannes Mols
Johannes Mols Apr 16, 2021 12:48 PM

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.

Please login to comment.
Latest blogs
Translating Optimizely CMS 12 UI components

Optimizely CMS 12 have been out for a while now, but still some elements haven't been properly translated resulting in a GUI defaulting to english....

Eric Herlitz | Jan 26, 2023 | Syndicated blog

Image preview in Optimizely CMS12 all properties view

With these simple steps, you can now see an Image and its Metadata, including size and dimensions, when editing an Image property in Optimizely...

Tomas Hensrud Gulla | Jan 26, 2023 | Syndicated blog

Setting up the ImageEditor in Optimizely CMS 12

Setting up certain configurations on Opimizely CMS 12 differs quite a bit from prior versions of (Episerver CMS 11 and older). Here's a small guide...

Eric Herlitz | Jan 25, 2023 | Syndicated blog

Happy Hour Returning in February

Hi everyone! It's been a while and we're excited to resume our Happy Hour in February for more learning, sharing, connecting, relaxing, and just to...

Patrick Lam | Jan 24, 2023

Planned breaking change for Locale parameter in Content Graph

Content Graph, a new service which makes it possible to query content using GraphQL, will have a breaking change soon. The service is currently in...

Jonas Bergqvist | Jan 23, 2023

Optimizely Advanced ContentArea Render is Back!

If you have used EPiBootstrapArea package - then back in those days we had an opportunity to render Episerver ContentArea items with different...

valdis | Jan 23, 2023 | Syndicated blog