New version of EPiServer.Find.Commerce
A new version of EPiServer.Find.Commerce (9.3.0) was recently released. This version makes it easier to use Find together with Commerce. We now listen to ecf events, price updates, and inventory updates. We also index markets and relations. More features will be released soon, as the nested querying is being developed by the Find team.
Listening of ECF events
We listen to ECF events. We add your typed content to the indexing queue when a change is made in the ECF layer.
Service API
Your typed content is now indexed/reindexed/removed from the index after a request is made to the service API.
Commerce manager
We listen on remote events from commerce manager, and index your typed content when something changes in commerce manager.
It's not 100% sure that the front end site will receive the event from commerce manager. If the front-end site is down when an event is triggered, the typed content is not added to the indexing queue. A safer approach will be developed later.
Indexing prices
We index both the default price and the whole price collection for variation content. Performance will be a lot better when receiving prices from the index, instead of using the price provider. It will be possible to make price filters for a specific user when nested query support is released in EPiServer.Find.
Reindex content on price updates
If your document indexes a property of type Price, or IEnumerable<Price>, the document is reindexed when prices are changed, if the price provider raises the price update event. The default provider raises the price update event. More information how to raise the event from a custom price provider can be found here: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Search/find-integration/raise-price-and-inventory-event-updates/
Remove prices from index
It's easy to remove the indexing of prices for variation content. Documentation how to remove the extension can be found here: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Search/find-integration/overriding-default-conventions/
Indexing inventory
We index the inventory collection for the variation content. Performance will be a lot better when receiving the inventory from the index, instead of using the inventory provider. There can be a problem indexing inventories if the inventory is changed too often. In that case, the inventory should be removed from the index.
Reindex content on inventory updates
If your document indexes a property of type Inventory, or IEnumerable<Inventory>, the document is re-indexed when the inventory is changed, if the inventory provider raises the inventory update event. The default provider raises the inventory update event. More information how to raise the event from a custom inventory provider can be found here: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Search/find-integration/raise-price-and-inventory-event-updates/
Remove inventories from index
It's easy to remove the indexing of inventory for variation content. Documentation how to remove the extension can be found here: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Search/find-integration/overriding-default-conventions/
Relations
We now index relations between different catalog content.
- Products: Variation references for a product
- Variations: Product(s) the variation are related to.
- Packages: Package entries for a package, and the related package(s) for the entries.
- Bundles: Bundle entries for a bundle, and the related bundle(s) for the entries.
- Nodes: Both parent node relations, and child node relations.
- Associations
Markets
Markets are indexed for EntryContentBase, which makes it easy to filter content based on a market. The filter "FilterOnCurrentMarket" only receives entries that are available on the current market.
New version of Brilliant cut
There is an updated version available of Brilliant cut, which uses the new EPiServer.Find.Commerce package.
Github: https://github.com/jonasbergqvist/BrilliantCut
Site: http://www.brilliantcut.se/
Documentation
Documentation about the find integration can be found here: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Search/find-integration/find-integration/
Nice, I am very keen to start trying this out :)
Excelent, In absense of Pricing Provider, How the Pricing and Discounts will work togather? Will Discount ENgine also be picking pricing from index?
Khan: Pricing and discounts are intresting when it comes to the index. We havn't looked at this so much yet, but I promise you I will do it when the core of the discount system is done.
The promotions we now are creating will pick the prices using the price provider or calculators (http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Orders/calculating-orders-beta/) to get the prices. But I will make sure that we design them so it will be very easy to instead get the prices from the index by overriding some method. We will create several promotions shortly, and make sure we get a good design, where it's easy to reuse the logic, and override the logic.
I changed an internal template to get the prices from the index instead of the price provider, and the page got 10 times faster. 10 times!
Thanks Jonas, With current improvements, Can we write a Custom Price Provider based On Indexed Pricing Data on Find?
Regards
/K
Khan: Yes, I have thought about that too, but there is some problems that needs to be fixed.
When indexing the prices, we will go through the price provider, so we need to go to the real source at this point. I'm not sure how to fix that.
It might be a good idea to override the load methods for the default implementation. The saving of prices could be the same, so we have all the prices in the database, and then use Find for the loading. But as I wrote earlier, we need the real source when indexing the prices.
I will probably use a hack day for this soon.
Thanks Jonas, That make sense. Any way, EPiServer Commerce have moved one step further with this implementation. Great work indeed.
/K