External Catalog – Chapter 3 – Relations, Pricing and Inventory

This is Chapter 3 of our series about implementing a "Real time catalogue" in Episerver commerce. In this post we dive deeper into the RelationRepository, CatalogContentStructureProvider, IInventoryService and IPriceService. If you like start reading from the start, start reading the series here and go to the previous chapter here.

Implementing RelationRepository

The RelationRepository is responsible for returning the relation types between nodes and entries. This one is needed to show your categories / products / variants in the tree structure how you want them to be rendered. We have intercepted the implementation of IRelationRepository to be backwards compatible with the original implementation. The reason why we have intercepted the implementation is that we cannot inherit from the DefaultRelationRepository because it’s an internal class. By intercepting the implementation we have access to the ‘previous’ implementation and thus have the ability to call the base implementation when needed. For more information about the IRelationRepository see World. For more details on how to intercept in your IOC container see the section: Putting it all together.

The two functions you need to override are:

public IEnumerable GetChildren(ContentReference parentLink) where T : Relation
public IEnumerable GetParents(ContentReference childLink) where T : Relation

The GetChildren and GetParents function return an IEnumberable of entries in the namespace EPiServer.Commerce.Catalog.Linking. These entities define the ‘link’ between the different nodes and / or the entries below them.


The CatalogContentStructureProvider is used for the episerver backend (‘/EPiServer’) to determine the number of nodes / entries to render in the catalog tree (‘/EPiServer/Commerce/Catalog’). The implementation is pretty straight forward but when this is not implemented and returns an incorrect number the catalog tree does not function correcty.


We have overwritten the implementation of the IInventoryService to let it retrieve inventory from a web API. The IInventoryService is different from the implementation of the other services because the IInventoryService accepts the Code property values of variants as identifier where it retrieves inventory for. All other services use a ContentReference for this. We use the IdentityService to map the relation between the Code and a content reference. More on the IdentityService read Chapter 2 of this series.

See World for more information about the IInventoryService.


The IPriceService is implemented in the same way as the IInventoryService see World for more information about the IPriceService.


Tomorrow we are going to put everything together in our final chapter.

%d bloggers like this: