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.
Variant images duplication
Variant images duplication

Sana expects variant images to be stored as productID_VariantID_1.jpg. This means that each variant has to have a separate image. But consider the following situation:

- The product is a t-shirt, it has 3 variants - Medium RED, Small RED, Large RED. In terms of image, the customer will ONLY have a red t-shirt as the only thing that changes is size.



Now according to Sana this requires 3 separate images to be stored. In the thumbnail section of product images the same red t-shirt image will show 3 times (which is weird).



Solution ideas:

1. Short team win: allow settings in the product detail page Image element to set "Show thumbnails for selected variant only", or "Show thumbnails for selected variant images and the common images only".

2. Long term : Allow some logic in Sana + ERP to map 1 image to multiple variants (This also comes up in PIM discussions for mapping the same image to multiple products - the concept is called Product masters).

1
0
0