I am confused by product variants in Hybris.
For example, why would you choose to use a variant for size or color?
Wouldn't expanding the product item to include both style and size as attributes simplify the resulting data model?
Any insight would be greatly appreciated.
Variants are a common concept in eCommerce systems. Hybris supports this as do others:
http://docs.shopify.com/api/product_variant
http://msdn.microsoft.com/en-us/library/ms962267%28v=cs.70%29.aspx
http://guides.spreecommerce.com/developer/products.html
So why do we do this? Mainly this is for ease of management.
If we take an Apparel example, perhaps we have Products with no size or colour (maybe sunglasses) variations, we have products with only Colour variations (hats?) and we have Products with Size and Colour variations (t-shirts perhaps).
Here is our setup:
Product
Product Blue
Product Blue/S
Product Red
Product Red/M
Product Green
Product Green/S
Product Green/XL
In this example we need configure only one Price, on 'Product'. We need only configure 3 images, on 'Product Blue', 'Product Red' and 'Product Green'. We can then configure Stock Levels on the "leaf" variants.
So different products will have different numbers of variations and different ways to vary. As a result we don't want to fill up the Product table with lots of Null columns representing all these possible variations for every product. A more extensible approach is taken via the VariantType MetaType.
Via this approach you can create 'concrete' Variants (as I call them) via your items.xml, or 'dynamic' Variants via run time definition using impex. Only concrete Variants can be used in code directly (i.e. using instanceof) but cannot be added with a deployment and an updatesystem. Dynamic variants require more clever coding to determine the VariantAttributes on the item but this is in general a much better approach and more extensible.
There is of course an argument that multi level variant structures are a bit redundant and slightly false. There is no "direction" to variants. You do not naturally navigate Product > Blue > Small, you simply select the Blue Small Product. So it could be argued that all variant structures should only be 1 level deep.
You will need a variant product to manage the price for example. For some colors it could be possible that the product will cost more than for another color. You can't manage this in one product. Also it is possible that you will define another description / productname for your variant product. It is way easier to do this with a variant product than using the custom product.
Related
I'm wondering if there is a way (specific package, process, etc.) of grouping items based on an overall category? For example, I'm looking at empty search results and want to see what category customers are most interested in.
Let's say I have a list of searched terms: skittles, laundry, snickers and detergent. I would want to group these items based on a broader category (i.e., skittles and snickers are "candy" and laundry and detergent would be "cleaners").
I've done some research on this and have seen similar (but not exact) ways of doing this (e.g., common keyword grouping using NLP) but not sure if something like this exists in the world when there isn't necessarily any commonality. Any help or direction would be greatly appreciated.
Update here: The best way to handle this scenario is to use pretrained word embeddings using something like Google's BERT algorithm as the first pass and then layer on another ML model that is specific to the use case.
I am building a product catalog for an e-comm website. I am having a requirement to build a azure search/solr/elastic search based index. The problem is saving the market specific attributes. The website is supporting 109 markets and there is each market specific data like ratings, price, views, wish-listed, etc. that I need to save in the index eg: Product1 will have 109 ratings(rating is different in each market)/109 prices(price might be different in each market) corresponding to 109 markets. Also I will have to use this attributes to add a boosting function so that when people are searching for this, products with higher view/ratings surfaces up. How do I design the index definition to support this? Can I achieve this by 1 index doc per product or do I have to create 1 index doc per market? Some pointers will be very helpful. I have spent couple of days on this and could not reach to a conclusion that is optimized for this use case. Thank you!
My proposed index definition:
-id
-mktUSA
--mktId
--rating
--views
--price
...
-mktCanada
--mktId
--rating
--views
--price
...
-locales
--En
--Fr
--Zh
...
...other properties
The problem with this approach is configuring a magnitude scoring functions inside scoring profile, to boost products based on the market
Say eg: If user is from Canada, only the Canada based rating/views should be considered and not the other market ratings while Cognitive search is calculating the search relevance score.
Is there any possible work around this? Elastic search has a neat solution of Function score query that can be used to configure the scoring function dynamically
From what I understand, your problem is that you want to have a single index with products that support 109 different markets. Many different properties for your Product model can then be market-specific. Your concern is that the model gets to big, or if it's a scalable design. It is. You can have 1000+ properties without a problem.
I have built a similar search solution for e-commerce for multiple markets.
For price, I specify one price per market. I have about 80 or so markets, so that's 80 prices. There is no way around it. I would probably do the same for ratings and views too. One per market.
In our application we use separate dimensions for market, language and country. A market can be Scandinavia, BeNeLux or Asia-Pacific. You need to clearly define what a market is in your case, and agree with the business which markets you have and how you handle changes. Countries can map directly to markets, but it may also differ. Finally, language is usually shared across markets/countries and you usually only have to support 20-25 languages.
Suggested data model
Id
TitleEnGb
TitleDeDe
TitleFrFr
...
PriceGb
PriceUs
PriceNo
PriceDe
...
RatingsGb
RatingsUs
RatingsNo
RatingsDe
...
DescriptionEnGb
DescriptionDeDe
DescriptionFrFr
...
I try to illustrate that the Title and Description are language-specific. The price and ratings are market-specific.
For the 20-25 language-specific properties, you have to think about what analyzers to use. You want to use language-specific analyzers, and preferably the Microsoft analyzers since they have much better linguistics support with full lemmatization and so on.
When you develop your frontend application you have to keep track of which market, country and language you then refer to the specific properties. This is the easiest way to support boosting and so on.
Per-market index is not recommended
You could create one index per market. I have gone down this route before. I would not recommend this. This means you have to update 109 indexes every time you add, change or delete an item. And Azure Search supports 50 indexes per service at the most anyways.
What is the difference between a Variant and a Classification System?
I don't really understand why is there an ApparelSizeVariantProduct in the *-items.xml file only for a size variation. Isn't it easier to create a classification for a category that holds a "size" feature instead of creating a new type ? What is the purpose of these "variants" ?
It depends on what you are sell and price strategy. For example in fashion, you need to manage stocks by size, but price managed by base product model. Some companies also manage price by color variant. So you need another variant for color.
Example: BaseProduct > ColorVariant > SizeVariant
You cannot manage price or stock with classification. Also there is another concept exists: attributes.
These functionalities are power of hybris, other solutions maybe solve same challenge different way.
I am an experienced full-stack web dev, but new to PimCore. I’m organising a large catalogue of many types of items in PimCore and have looked through the documentation many times, but I still don’t know how to tackle two basic issues I have organising my product data into classes. I hope some more experienced PimCore users or devs can shine some light on this.
Issue 1: how to model general product attributes that apply to all products in the catalogue.
All of the products in my catalogue will have a name and a description, so I thought it made sense to make a Product class that has these fields and make all of my specific product classes subclasses of that Product class so I wouldn’t have to add name and description fields to each subclass individually.
I tried to set this up, but in the object editor of the specific subclass the layout fields that I added to the generic Product superclass don’t show up. Am I missing something here? Should my approach actually work? If not, what would be the PimCore approach to modelling this?
Issue 2: how best to model products with multiple options, ie. variants over more than one dimension.
For example, T-shirts with both color and size options (let’s say, 3 colors and 3 sizes for a total of 9 variants). I would want to create one single T-shirt product in the object tree and then add 3 color options and 3 size options for an (automatic) total of 9 variants. I want the T-shirt to appear as a single product in the e-commerce frontend and let the end customer determine the value of both options.
I am wondering if it is at all possible to do this in a way that allows me to specify the 3 color options and the 3 sizes independently of each other. The examples I find in the documentation all show me a fully expanded object tree covering all options (eg., 1 T-shirt object, with 3 subobjects for each size, each with 3 subobjects for each color in that size). Although data inheritance helps with the management of this info, a change in the available colors would still have to be made once for every size option. I can’t imagine there is not a better way to set up object variants in multiple dimensions in PimCore, but days of searching have led me nowhere. Am I missing something here? Or does PimCore actually force you to create objects/variants for every combination of product options? If not, what would be the PimCore approach to modelling this?
I hope someone with a little experience in this field is willing to shed some light on these two issues. Thank you so much!!
Received very helpful answers on the PimCore forums, by user fash:
Issue 1: Pimcore DataObject classes cannot inherit from each other. The way to go would be to create one product class (that
contains all common product attributes) and then use object bricks or
classification store groups to model category specific attributes.
Then on object level, the corresponding object brick or classification
store group can be added to the product object (depending on its
category or other criteria).
Issue 2: As you already noticed, the default way of dealing with different variants of a product is to create an object instance for
each variant and utilize data inheritance to reduce data maintenance
effort (like in the demo). Also as Andrew already pointed out, adding
some helper functionality like a generate variants button is easily
possible.
The reason why we create a unique data object for each variant most of
the time is, that normally each SKU has a unique product number and
also in terms of e-commerce it needs to be possible to reference the
exact variant that was ordered. As an alternative you of course could
use data structures like field definitions or block to follow your
approach and have to attributes (like color, size, etc.) and add
multiple values to them and then deal on the output channel with the
variant generation. It is really up to your use case and your system
what fits better.
An hybrid solution would be to define possible variants with variant
attributes, and then generate the actual object variants on the fly
when one is ordered.
Preface: I'm a self-taught coder, so a lot of my knowledge is limited to my research. I'm hoping to have other opinions as I want to build things right the first time. I need help with determining an appropriate solution and how to implement the solution.
I'm looking to build a least cost alternative model (essentially a shortest path) for delivering between locations (nodes), based on different modes of transportation (vehicles) and the different roads taken (paths). Another consideration is the product price (value) to determine the least cost path.
Here are my important data items:
nodes: cities where the product will travel to and from.
paths: roads have different costs, depending on the road.
vehicles: varying vehicles have differing rental costs when transporting (motorbike, car, truck). Note that the cost of a vehicle is not constant, it is highly dependent on the to/from nodes. For example, using a car to go from city A to city B will have a different cost than using a car to go from city B to A or city A to city C.
value: Product value. Again, a product's value is highly dependent on its destination node. The same product can have a different value at City A, B or C.
Problem Statement
How to setup data structure to best determine where the least cost path would be to get a product from one location to every other location.
Possible Solutions
From my research, I believe a weighted graph data structure would be most suitable for my situation in combination with dijkstra's algorithm. I believe breaking the problem down simpler would be essential, to first create a simple weighted graph of only nodes and paths.
From there, adding the vehicle cost and the product value considerations afterwards. Perhaps just adding the two values as a cost to "visit" a node? (aka incorporate it into the path cost?)
Thoughts on my current solution? Other considerations I overlooked? Perhaps a better solution?
Implementation
I'd love to be able to build this within Excel VBA (as that is how I learned how to code) and Excel is what I use for my tools. Would VBA be too limited in this task? How else can I incorporate my analysis with Excel with another language?
Try the book Practical Management Science by Winston & Albright and check out the chapter on Operations Management - lots of models explained in there from the simple onwards. Available online as a pdf : http://ingenieria-industrial.net/downloads/practicalmanagementscience.pdf
VBA is more a scripting language than a full-fledged one, though one may contend that the underlying framework is .NET. Why don't you give a shot at C++ or Java? If you intuitively understand the data structure and the algorithm, then it'll be a breeze coding in these. Chapter 4 of Algorithms by Sedgewick and Wayne has a beautiful explanation of Shortest Paths. You may also consider studying Bellman-Ford algorithm if you foresee any negative weight cycles on a vertex.