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.
Replace Product Codes in Favourites
Replace Product Codes in Favourites

We occasionally need to close one of our products and replace them with a new code. When this happens, if a customer has the old product in their favourites list, it appears as "Product does not exist".

Would it be possible to create functionality that would enable us to match old codes with new ones when a replacement is made, so that favourites can be updated automatically? I'm envisioning a list that we could update to add old and new codes to, like the below, is this something that could be done do you think?

Closed Code Replacement Code

PR111 PR222

PR112 PR223

PR113 PR444

0
0
0