Creating product data model on Hybris e-commerce
I'm evaluating different e-commerce platforms. As part of this work I'm evaluating how our present product structure fits the platforms. With vendors such as IBM it's easy since they have all the material publicly on web. I have growing interest on Hybris e-commerce. However they have no material what so ever available. They have a private wiki that I have access to but even there is no material on their data model.
Hybris' reps keep on insisting that their product is so flexible that any data model can be created. Well I believe them but there are still boundaries that should not be crossed, e.g. GUIs and reports display certain pieces of data and OOB order management for sure relies on certain data. To make the full use of OOB features, the data model I create must follow that of Hybris'. However Hybris doesn't allow me to see their data model, so I'm in a chicken and egg-kind of situation.
Now my question is: Do you have experience on modeling product structure on Hybris and how have you approached this? All help appreciated!1!
Cheers!
Answer
Hybris data model or to say the TYPE SYSTEM is very flexible. I have been working on Hybris for last 4 yrs and never came across a situation where it will fail as long as modeling is concerned. Type System is Hybris ORM, where all of the Java Objects are defined in XML format and at the same time mapped to Data base tables and columns. All of the java data types are supported, types collections are supported as well. Type System is independent of choice of DB and all most no change (or very minimal extra configuration) to items.xml even on DB change. Exception will be CLOB which will require DB vendor specific or equivalent DB column data type configuration, again in the same items.xml.
Modeling associations is simple as well in terms of Hybris relations
- 1:1 -> Modeled as Object2 as attribute to Object1
- 1:n or n:1 -> Modeled by Relation item with Source and Target attributes
- n:m -> Modeled by Relation item with Source and Target attributes and under separate DB table
Now coming back to Products, Product has two hierarchy which may dwell into multi level structure. The 2 base hierarchy constructs are Product & Product Variants.
Lets model the products for apparels, there may be 4 kind of products:
- Product itself is SKU: BaseProduct
- Product has Color variant: BaseProduct -> ColorVariant
- Product has Size variant: BaseProduct -> SizeVariant
- Product has Color and Size variants: BaseProduct -> ColorVariant -> SizeVariant
All of the product properties will be held BaseProduct and Variants will hold only the varying attributes like Color, Size and Cost.
Extrapolate the type of variants against the product, the Product-Variant hierarchy path will grow, simple with minimum or no-duplication.
For modeling BaseProduct, the only attribute which is mandatory is product code and rest are there but optional, so convenient. This helps in running the enrichment process via workflows and helps in a very flexible base implementation with scope of additions to specific requirements.
Out of the box support for GUI via Service layer services and accelerator is commendable, even with the additions of loads of custom attributes, same will suffice as it is driven from the ITEM to MODEL then DATA conversion. Implementation has full control on Data and segment of data to be populated from Model to Data.
Reports are driven from Report cockpit based on the Jasper reports. Flexible search query is defined with JOINS and UNIONS and even option to execute small java code for a report attribute value population.
Modeling, Conversion, GUI and Reports, in my opinion is all very well covered by Hybris.