Change the entity id structure

There are several ids in Dynamics. We get, and use, something called a record id. It’s considered an “internal” id and it’s represented as a long. Record ids are unique per entity type. This model is not compatible with Episerver since it uses globally unique strings as ids. We get around this by converting back and forth depending on which system we want to interface with. We use something called code resolvers. We have one for each entity type. ProductCodeResolver, VariationCodeResolver etc.

The default pattern in the starter site is type_record id. We use type to guarantee that we don’t get id collisions between different entity types. If you want to change this pattern you will need to:

Create your own implementations of the code resolver interfaces
Register your implementations

Let’s start with the implementation! Consider this interface:

public interface IProductCodeResolver
{
    string ResolveCode(string id);
    string ResolveRecordId(string code);
}

One method to convert from record id to code, ResolveCode, and one method to convert from code to record id, ResolveRecordId. Note that the data type is string in both directions. The reason is that we convert the record id from long to string before we stage it. Our dto contracts use string ids for compatibility reasons.

The starter sites IProductCodeResolver implementation currently looks like this:

public class ProductCodeResolver : IProductCodeResolver
{
    private const string Prefix = "P_";

    public string ResolveCode(string id)
    {
        if (string.IsNullOrEmpty(id))
        {
            return string.Empty;
        }

        return Prefix + id;
    }

    public string ResolveRecordId(string code)
    {
        return !string.IsNullOrEmpty(code) && code.StartsWith(Prefix)
            ? code.Substring(Prefix.Length)
            : code;
    }
}

Let’s assume that we want to change this, and that we have implemented our own code resolver ExampleProductCodeResolver : IProductCodeResolver from scratch. If we want to use it, we need to register it. We will use it in two different ways: in the integration when we write entities to Episerver and on the site when we call Retail Server. This means that we have to register it in two different ways, one for the integration and one for the rest of the site. Integration dependencies need to be registered in ShopDependencyRegistration.cs > RegisterDependenciesInModuleContainer. We need to remove the current registration:

context.ConfigurationExpression.For<IProductCodeResolver>().Use<CodeResolvers.ProductCodeResolver>();

And replace it with our own:

context.ConfigurationExpression.For<IProductCodeResolver>().Use<ExampleProductCodeResolver>();

Site dependencies need to be registered in InitializationModule.cs > ConfigureContainer. We’ll find a similar registration there:

services.AddSingleton<IProductCodeResolver, CodeResolvers.ProductCodeResolver>();

Replace it with our own:

services.AddSingleton<IProductCodeResolver, ExampleProductCodeResolver>();

That’s it. Your custom code resolver will be used.

It’s important to note that it’s easiest to change a code resolver when you have an empty catalog. If you want to change a code resolver when you already have entities with a certain id pattern, you will need to make sure that your code resolver can handle both the new and the old pattern.