Steven Galton
Jan 2, 2018
visibility 3288
star star star star star
(3 votes)

Indexing extra Episerver Find properties onto a single variant for Episerver Commerce

Recently on a client project that I have been working on at Redweb, I have been working on getting Episerver Find working with Episerver Commerce. This was a simple task as you just needed to do some configuration and run the index job in the Commerce manager (Guide found here). 

The main issue that arose was that the catalogue structure was very complicated, and information was split across difference parents and children. This made it a bit difficult to get all the information needed for a single variant. Rather than doing multiple searches, I found that you could simply index this information into a single variant. 

To get the information to index onto the single variant, I created some properties that are ignored by the CMS. These would be used to store the actual information needed from the different parents of the variant.

[Ignore]
public string LocationName => SearchLocationName();

[Ignore]
public string Title => SearchTitleText();

[Ignore]
public string Description => SearchDescriptionText();

[Ignore]
public bool IsWeekendCourse => CourseRunType.HasFlag(CourseRunType.Weekend);

[Ignore]
public bool IsWeekdayCourse => CourseRunType.HasFlag(CourseRunType.Weekday);

Some more properties were added that would store a reference to the parents of the variant that were also hidden from the CMS. Some methods were created that would then extract the information from these properties and then assign them to the properties created above.

private CourseVenueProduct _parentCourseVenueProduct;
private CourseProduct _parentCourseProduct;
private CourseCategory _parentCourseCategory;
private CourseRunType ? _courseRunType;

[Ignore]
public CourseVenueProduct ParentCourseVenueProduct 
{
    get 
    {
        if (_parentCourseVenueProduct == null) 
        {
            var parentProduct = this.GetParentProducts().FirstOrDefault();
            var loader = ServiceLocator.Current.GetInstance<IContentLoader>();
            _parentCourseVenueProduct = loader.Get<CourseVenueProduct>(parentProduct);
        }
        
        return _parentCourseVenueProduct;
    }
}

[Ignore]
public CourseProduct ParentCourseProduct 
{
    get 
    {
        if (_parentCourseProduct == null) 
        {
            var parentCourseProduct = this.ParentLink;
            var loader = ServiceLocator.Current.GetInstance<IContentLoader>();
            _parentCourseProduct = loader.Get<CourseProduct>(parentCourseProduct);
        }
    
        return _parentCourseProduct;
    }
}

[Ignore]
public CourseCategory ParentCourseCategory 
{
    get 
    {
        if (_parentCourseCategory == null) 
        {
            var parentCourseCategory = ParentCourseProduct.ParentLink;
            var loader = ServiceLocator.Current.GetInstance<ContentLoader>();
            _parentCourseCategory = loader.Get<CourseCategory> (parentCourseCategory);
        }
        
        return _parentCourseCategory;
    }
}

[Ignore]
public CourseRunType CourseRunType 
{
    get 
    {
        if (_courseRunType == null) 
        {
            var workingDaysService = ServiceLocator.Current.GetInstance<IWorkingDays>();
            _courseRunType = workingDaysService.GetCourseRunType(CourseStartDate, CourseEndDate);
        }
    
        return _courseRunType.Value;
    }
}

private string SearchLocationName() 
{
    return ParentCourseVenueProduct.DisplayName;
}

private string SearchTitleText() 
{
    return ParentCourseCategory.DisplayName;
}

private string SearchDescriptionText() 
{
    return ParentCourseProduct.DisplayName;
}

When a new item was created, updated or the indexing job was run, the new properties would be updated and indexed so they could be used to filter against in the search queries. There was also an added benefit as you could also use these properties elsewhere in the solution.

Image Capture.PNG

[Pasting files is not allowed][Pasting files is not allowed]

Jan 02, 2018

Comments

Jeroen Stemerdink
Jeroen Stemerdink Jan 2, 2018 09:57 AM

I am not a big fan of adding properties with a lot of logic to your models, especially when it is only needed for your search index.

Have a ook at this thread, which is IMHO a much cleaner approach., and works just as well.

Steven Galton
Steven Galton Jan 2, 2018 10:11 AM

We used the convention way to add the properties to our search index before but realised that we needed to use the properties in other methods. We will be looking to move the logic into their own helpers in the future as well.

error Please login to comment.
Latest blogs
The Silent Success: When Your Optimizely SaaS CMS Config Push Succeeds with "0" Changes

  Picture this frustratingly common scenario in headless, code-first development with Optimizely SaaS CMS: You’ve defined a brilliant new element,...

Vipin Banka | Jul 13, 2026

Architecting an Enterprise-Grade Development Pipeline in Optimizely SaaS CMS

Most enterprise teams show up to Optimizely SaaS CMS with a clear roadmap for their release pipeline: DEV → QA → Stage → Prod. Four logical...

Vipin Banka | Jul 12, 2026

Bynder DAM Connector for Optimizely SaaS CMS: Improved Metadata Property Synchronization

While working with the Bynder DAM Connector for Optimizely SaaS CMS , one of the key areas I explored was how Bynder asset metadata is synchronized...

Vipin Banka | Jul 11, 2026

Optimizely DXP: Every Supported Culture, One Searchable Page

Quick one for anyone building multi-language sites on Optimizely DXP. I put together a reference tool listing all 806 supported cultures. More...

Adnan Zameer | Jul 10, 2026 |