Often times I have found a need to only want to index CMS content or Commerce catalog content, but not both. Unfortunately, the default Episerver Find Indexing Job does everything all at once. We have many sites where there is much more CMS content than Commerce catalog content, and having to wait for the CMS content to index before Commerce catalog content indexes can be a pain-point especially when you’re trying to test certain features against the indexed catalog content.
There were two challenges I had to solve to accomplish my desired Episerver Find indexing strategy:
- Prevent the Episerver Find Indexing Job from indexing catalog content so that it only works against CMS content.
- Create a new scheduled job that only indexes catalog content.
This blog post will only cover preventing the default indexing job from indexing catalog content. My next post will show how to create a new scheduled job solely for indexing catalog content.
After doing a bit of research I learned three very important things to how the indexing job works. First, there are a number of services inheriting from an interface called IReindexInformation that is used to determine what target items should be indexed in the Episerver application. The Episerver Find Indexing Job retrieves all the services that inherit this interface and runs through them one by one to get the items for indexing. Second, on all services inheriting this interface there is a method for returning these target items called ReindexTargets(). This method is what the scheduled job is using to get the collections of items for indexing.
Lastly, when you install Episerver Find for Commerce, a service called CommerceReIndexInformation (this service is one of those inherits from the interface IReindexInformation) is added to the solution to allow Episerver Find to locate catalog content. This is the key to making the scheduled job ignore catalog content. We do not want the job to be able to utilize this service.
After discovering these findings, I had my game plan. I needed to intercept all services inheriting from IReindexInformation with my own custom service, and when ReindexTargets() is called, determine if the original service that called it was the CommerceReindexInformation service. If the original service is indeed CommerceReindexInformation, then the call to ReindexTargets() needs to simply return nothing for indexing.
In order to intercept all services inheriting from IReindexInformation you need to do this in an InitiailizationModule with StructureMap. Read more on how to intercept services here.
Below is an example of how I intercepted services inherited from IReindexInformation:
<p> CODE: https://gist.github.com/thec2group-blog/ccdfeeacc674a88c57999f337f344faa.js</p>
This is fairly straightforward. Every time an instance of IReindexInformation is used, we get in front of it and return our CustomReindexInformation service instead. It is very important to note, above,that in our custom service we pass the originally called service in the constructor. We want to do this so we have access to what that service is, and we have the ability to access all public properties or methods on that service still.
All that is needed to prevent the Episerver Find Indexing Job from indexing catalog content is for the CustomReindexInformation service to do its magic.
<p> CODE: https://gist.github.com/thec2group-blog/bf5873b756c7b13785fd74d99a3a28a7.js</p>
I mentioned previously that it was important to pass the original service into the constructor for the custom service. Once completed, you’ll want to assign that original service to a property (I prefer read-only properties where possible) so that you can access it in the other two required properties for the interface IReindexInformation.
IReindexInformation requires two properties: ReindexTargets and Root. ReindexTargets returns the content links to be indexed, and Root returns the root to index. In our custom service we have no use for the Root property and can simply return the original service’s Root property instead.
The only thing that matters in preventing the Episerver Find Scheduling Job from indexing catalog content is the property ReindexTargets, and it’s pretty easy to do. When this property’s getter is called, check if the original service is of type CommerceReIndexInformation. If it is, return an empty collection of ReindexTarget objects, otherwise return the original service’s value for ReindexTargets.
That’s all you need for part one of accomplishing a new Episerver Find strategy for separating out indexing jobs for CMS content and Commerce catalog content. My next blog post will cover creating a new scheduled job solely for indexing your catalog content from Episerver Commerce.