Mari Jørgensen
Feb 21, 2013
(1 votes)

Hidden Gems of EPiServer Find

EPiServer Find is not just for EPiServer CMS pages– in fact the client API supports indexing of any .NET object.

When working with indexing of data in EPiServer Find there are some hidden gems that are nice to know about.

The Id attribute: Avoid duplicates when updating

According to the documentation, If a document of the same type with the same ID already exists it will be overwritten (or updated if you like). In other words, controlling the ID is the key.

Let me illustrate this with a code sample. For demonstration purposes I have created a class Product:

public class Product
    public Guid Id { get; set; }
    public string DisplayName { get; set; }
    public string Description { get; set; }
    public string Brand { get; set; }
    public string Model { get; set; }
    public string Type { get; set; }

Using the Product model I can now add some simple test data to the EPiServer Find index.

Product p1 = new Product()
    Id = guidproduct1,
    DisplayName = "Cannondale CAAD 10",
    Model = "CAAD 10 Shimano 105",
    Description = "With its lightest-in-class frame and unmistakable Cannondale ride-feel," 
        + "the CAAD10 is designed to turn people into cyclists.",
    Brand = "Cannondale",
    Type = "Elite Racing Bikes"
Product p2 = new Product()
    Id = guidproduct2,
    DisplayName = "Cannondale Synapse Carbon 3",
    Model = "Carbon 3 Ultegra",
    Description = "Elite-race performance meets all-day comfort.",
    Brand = "Cannondale",
    Type = "Elite Racing Bikes"
var client = Client.CreateFromConfig();

If I navigate to the Find Explorer (from the main menu in EPiServer CMS) I can now see the following:


Notice the “Index ID” – this is the id that Find is using for identifying each document in the index. Lets see what happens if I now try to update product number two:

private static void UpdateItem()
    var client = Client.CreateFromConfig();
    // get product 2
    var searchResult = client.Search<Product>().
        Filter(p => p.Id.Match(guidproduct2))
    if (searchResult != null)
        searchResult.Type = "Performance Road";


As you can see from the screenshot above, the update resulted in duplicate documents in the index. Off course, I could solve this by deleting the document before re-indexing, but that far from an ideal solution. The trick is to use the Id attribute on the property that uniquely identifies your model:

public Guid Id { get; set; }

Re-indexing, we can see that the Find is now using my Id property as Index ID:


This way updating existing documents no longer result in duplicates.

“Making it look pretty” - using IDocumentInterpreter

By default, Find will use Namespace_Class as title in the index explorer. To easier distinguish between the different documents, we can tell the explorer to use a property on our model instead. In order to do this, we create a new class where we implement interface IDocumentInterpreter and override the ExtendDocumentInformation method.

public class MyIndexInterpreter : IDocumentInterpreter
    public void ExtendDocumentInformation(IndexDocument indexDocument)
        Expression<Func<Product, string>> headerExpression = 
            x => x.DisplayName;
        var headerField = SearchClient.Instance.Conventions.
        JToken headerToken;
        if (indexDocument.Hit.Document.TryGetValue(headerField, out headerToken))
            indexDocument.Headline = headerToken.ToString();

Notice that you pass in your model type and specify the property you want to use as title – here I’m using DisplayName.

Navigating to the explorer view, it is a lot easier to distinguish between the documents in the index.


The IDocumentInterpreter interface is part of the EPiServer.Find.Framework.UI namespace.

Feb 21, 2013


Feb 21, 2013 10:20 PM

Good blog post for future reference.

Also very much like the road cycling reference! ;-)

Joel Abrahamsson
Joel Abrahamsson Feb 21, 2013 10:52 PM

Yay! You found IDocumentInterpreter! I owe you a beer next time I'm in Oslo!

Mari Jørgensen
Mari Jørgensen Feb 22, 2013 08:28 AM

@Joel: Actually the tip about IDocumentInterpreter came from my friends in EPiServer Norway :)

Henrik Lindström
Henrik Lindström Feb 25, 2013 09:13 AM

Great post! I'm just missing the "Canyon Ultimate CF" :-)

Per Magne Skuseth
Per Magne Skuseth Mar 1, 2013 09:54 AM

Nice post!
Note that after the [Id] attribute has been set, you can do a simple SearchClient.Instance.Get(id), instead of filtering.

@Joel: I think the tip about IDocumentInterpreter originated from you, so I guess you should buy yourself a beer :-)

Please login to comment.
Latest blogs
Vulnerability in EPiServer.GoogleAnalytics v3 and v4

Introduction A potential security vulnerability was detected for Optimizely Google Analytics addon (including EPiServer.GoogleAnalytics and...

Bien Nguyen | Sep 20, 2023

Overriding Optimizely’s Content Recommendations Block to Implement Custom Recommendations

Introduction The Content Recommendations add-on for Optimizely CMS dynamically recommends content from your site tailored to the interests of each...

abritt | Sep 13, 2023 | Syndicated blog

Developer contest! Install the AI Assistant and Win Bose QC45 Headphones!

We are thrilled to announce a developer contest where you have the chance to win a pair of Bose Headphones. The goal is to be the first developer t...

Luc Gosso (MVP) | Sep 7, 2023 | Syndicated blog

Send Optimizely notifications with SendGrid API, not SMTP

If your Optimizely site already sends transaction emails through an email platform API, why not do the same with Optimizely notification emails?

Stefan Holm Olsen | Sep 6, 2023 | Syndicated blog