01. Dezember 2020
Do you have an Optimizely implementation which has a lot of products/variations and your Optimizely Find Indexing Job takes a lot of time to complete? Let’s review how to improve the performance by disabling pricing and inventory calls when Find runs.
A situation on Optimizely Commerce
I’d like to cover a situation that we see happening quite often on Optimizely Commerce implementations. One of the most used features in Commerce is search, and to have your search working smoothly you need to have your Optimizely Find index updated.
When we are dealing with catalogs that do not contain a lot of SKUs (let’s say fewer than 30,000), and we do not have a lot of variations of prices, it is common to rely on discontinuous or periodical synchronization of prices and inventory information against internal systems.
On the other hand, when we move into more complex implementations with big catalogs, we know it is common that the Inventory APIs from Optimizely are overwritten to call internal systems, like an ERP, to understand if a specific product is available or not. The same approach is also common for pricing.
Overriding the Optimizely APIs
While overriding the Optimizely APIs for Inventory (IInventoryService) and Pricing (IPriceService), we can call any external system to retrieve the inventory and the price for our products, each time it’s needed. This approach makes Optimizely really flexible, but there are some considerations that we need to keep in mind if we decide on taking this path:
- Some of these methods are heavily called on all the implementations, usually on PDP, PLP, Search pages and any other component in which we would like to show price or inventory information.
- Every time we run the workflows for the cart, these APIs are called. Therefore, we have to expect a heavy dependency on the Cart and Checkout processes.
- By overriding those APIs and doing calls to external systems in real time, we are adding an external dependency (in time and availability) around essential information (price and inventory) for a commerce platform.
Assuming we already went through those considerations and decided to move forward, there is one more thing to keep in mind. Every time we run the Find Indexing Job and every time a product/variation is updated in the Commerce Catalog UI, these methods are also called.
This is a good approach from Optimizely since it means that we can have Pricing and Inventory information always available on our Find Index. But this also will lead to some other considerations:
- We will be calling our external systems to retrieve Pricing and Inventory for all our products. Or at least for all the products that will be indexed into the Find Index.
- If the calls to the external systems are expensive (in time and resources), we are putting our Pricing and Inventory internal platforms under a lot of pressure, considering that our Find Indexing Job is something that should be running frequently.
- If the calls to the external systems take some time to complete, we are adding a lot of time to our Find Indexing Job.
Avoid six extra hours of processing time
Let’s focus on the time perspective only. Assuming a catalog with 100,000 SKUs and assuming an external pricing service that takes 100ms for each product/variation, we are talking about almost three hours just for those calls. Add the same amount of calls for inventory and you will end up with almost six extra hours of processing time.
Luckily, there is a way to disable those calls when Optimizely Find is running. Of course, this will prevent having Pricing and Inventory information on the Find Index, but with the advantage of having a quicker Find Indexing Job execution, and releasing the pressure of our Pricing and Inventory systems outside Optimizely, which is really good news when we are dealing with big or complex catalogs.
- First, we need to implement two interfaces in our variant/product: IPricing and IStockPlacement.
-
Then, we need to implement two new properties on the variant/product itself.
-
Lastly, we need to tell Find to avoid those two properties, which will avoid calling our overridden APIs IInventoryService and IPriceService. We can do this overriding two methods on the CatalogContentClientConventions class.
And that’s all!
When Find is running and scanning your whole catalog, the conventions will be applied and the calls to Pricing and Inventory API will not be made, which can save you some good amount of time.
Improve and release
As you can see, Optimizely is really flexible when it comes to overriding OOTB functionality, and with this simple approach, you can improve the performance of the Optimizely Find Indexing Job, while releasing the stress from your internal services.
