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.
Stock Alerts - Enhancements
Stock Alerts - Enhancements

The Stock Alert feature is lacking in the area of communication to the business. As it stands, the customer makes a stock alert request but the company has no idea that the request has been made. Therefore, there is no sense of urgency for purchasing to bring in the needed items. If the requests are made on normally stocked items, it's not a problem. However, if they are wanting items that are typically not stocked, the stock request won't be fulfilled unless that customer places an order or requests a quote. (They wouldn't likely do this since they think the stock alert is all they need to do to trigger more stock.)



Here are some ideas to improve the feature:

1) In the Sana Admin, have a listing of all active stock alert requests. Include details like item, variant, quantity, email address of requestor, logged in account (if available) and date of request. This will allow businesses to track what items are needed in the market and will assist us in purchasing correctly to bring in products that customers want. This will also allow the business to analyze market trends and expand business.



2) Create the option for an internal email alert when a customer makes a stock alert request. This will immediately alert the business purchasing of the need for a specific product and can help influence purchasing so that items can be brought in to fulfill the request as quickly as possible to increase the odds of capturing the sale.

0
0
0