SCC FeedbackWe value your input! Tell us what you think about our Sana Commerce Cloud roadmap initiatives and the direction we're taking. If there's something specific you'd like to see, don't hesitate to share it with us below. Vote for ideas on the page to let us know what you find important. You can vote by clicking on an idea and then click thumbs up, down or neutral.
Improvement to PIM indexing in Multishop situation
During an analysis of product index problems for a customer, I had a brainstorm with the team with some ideas that I had which I felt would be useful for the improvements list on PIM. Following is an extract from that (customer had InRiver but this applies to PIM in general IMO).
A single product indexing draws data from: 
ERP – Will be different per shop even for the same product. 
Main product infoAnonymous PriceSpecificationsVisibility rulesRelated itemsUoMsOther controlling data flags (e.g.: custom fields like made to order etc.)
InRiver PIM – Will be the same for all shops for the same product ID (check this).
NameTranslationsImagesAttachmentsSpecifications
Each product indexing task calls InRiver every time for all shops even if the product information is the same on all responses. Does the product image indexing task also run individually for all shops even if it is the same product: 
Is there any reason why a get product image response would return different values for different web shops for the same product?
If not can we cache the response in Sana on the scheduled run on the first shop and then use it in the subsequent shop index runs? In theory the opportunities that I see are as below:
Cache the InRiver data separately prior to Enriching:
Currently what happens is if a product info is modified (either in InRiver or ERP), we get ERP data from GetProduct call, get inRiver data from an InRiver product call, enrich the GetProduct response from this combined data. But if the InRiver response is the same for the same product regardless of which web shop is calling it, then it is not necessary to again fetch that InRiver data. 
On the task runs from the framework (from any shop), we can cache the fetched InRiver data against the product ID and store it in a temp table. When the Index of another shop is trying to fetch that same product ID data, the task can first check this cache table and if there is already cached product InRiver response, use the data from the Sana DB rather than fetch from InRiverFrom what I remember each InRiver call takes around at least 3 seconds per product).
If the fetch from DB is waaaay faster than fetch from InRiver (assume 1 second) then this should give us roughly 3-5 times performance gain. If product images are also fetched again and again, then the same theory can be applied to that. The customer can then do some checks and evaluation of the shops that get the most amount of daily modifications on products and set the schedules in descending order. This way most of the data from InRiver is cached already, and the shops further down in the indexing schedule in the same framework can benefit from the cached data resulting in faster processing.
Product Groups - Additional Settings
Product Groups - Additional Settings

To disallow product groupings in search in favor of individual items.Looking to utilize Product Groups to integrate variants in our webshop, and add a setting to keep search functions showing individual items (and/or disallow product groupings in search).

1
0
0