Developer forum

Nevermind.

I have found it:

I have to admit that it's not exactly intuitive for someone working with DW in the past. I just hope the new users will find it intuitive :)

Adrian

Hello Adrian,

- I don't think, that you should use the Warehouse (if the target is new users of a DW10 solution), but instead should you look into the new data model (which behind the scenes actually is using a warehouse). Only reason why the Warehouse still are available, most be in cases of an migration from DW9 to DW10.

Br. Michael Knudsen

Hi Michael,

I will admit openly that I don't exactly understand the whole "Data Model" concept. i have watched a few videos and I have tried to find real life scenarios that would work as described in the video.

But apart from having some groups with attributes and default values for those attributes, I could not find a way to work with it with catalogues of various product types.

Unless it is the same thing as using groups with product categories. In which case it's just another way of doing the same thing :)

If you have any pointers for me that would help me understand these concepts better, please do so. Right now, I am a bit confused by the interface changes together with the new object names and relations. Pretty hard to accomplish even simple tasks :)

Thank you,
Adrian

Hi Adrian,

Try this:

• Let's assume you have a 3 group level structure
• Create a data model with 3 fields
  • Category
  • Sub Category
  • Sub Sub Category
    (you can also call them Level 1, Level 2 and Level 3 if you prefer)
• Then set the value of each field to what the "Group" name would be
• Create a Dynamic Workspace and call it "By Category"
  • Choose the 3 fields accordingly

This could be your starting point to NOT using groups. It's similar to what you'd get from an ERP (attributes for Category and Subcategory), thus better mimicking that setup.

Best Regards,

Nuno Aguiar

Hi Nuno,

Thank you for the details. It seems logical the way you put it but it's still hard for me to envision applying this model to my needs.

In the meantime, I just realized that not all of our projects will have PIM (in this case, Products). And I am not sure how this setup (e-commerce only) will affect the availability of the different new objects (Dynamic workspace, Data model, Data set etc).

Fun fact, I have just spent almost 2 hours trying to wrap my head around the interface and add 1 product with a couple of variant groups, one product category with a few options, attach the category to a group, try to figure out why my newly created product category fields are not visible, assign another product to data model, de-assign product from data model, assign the product to a Channel category, assign the product category, then figure out how to make the fields visible.

All of this is for 2 products with a few variants and options. And I have spent my last +10 years working with DW :)
Tomorrow I have a demo presentation where I need to convince other people that DW 10 is the solution for 2025 :)

I probably need to re-learn everything :)

Thank you,

Adrian

Hi Adrian,

In DW10, we have implemented the new "Data modeling" concept, there gives users more flexibility to setup their Data-models, compared to DW9 Warehouse

But to make it possible to upgrade DW9-> DW10, we have the Warehouse management in Settings area.

If you have Client's setup, without PIM license, you can still define Category-fields on Groups level in a Shop.

Also take a look in the Manual area Products | Dynamicweb 10 Developer Documentation

I hope it answer your questions, othervise let me know

/Søren

Hi Soren,

I believe that I have to read more about the key concepts and understand the main differecnes between old Warehouses and current Data Models.

Thank you,

Adrian

Hi Adrian,

> it's still hard for me to envision applying this model to my needs.

> I probably need to re-learn everything :)

I'm on that boat as well :) It doesn't yet come 100% naturally to me. Hopefully one day.

Nuno

Hello

I'm jumping on that boat, the concept is hard to understand also in comparison with other PIM. 

The whole area under Settings- Products - Attributes is not an area I want to explain to a customer :)
On the bright side, the latest version is a lot more flexible than it was in version 9

Best regards
Kim

Hi Adrian,

What really helped me in this, was when I started to perceive the Data Models as a flat hierarchy (as opposed to a nested taxanomy with DW9 and Warehouses)

As humans we are used to describe things in a nested taxanomy, for reference we can look at the biological world on how taxanomy is created, for describing living organisms. However, when it comes to describing products, we are not always in agreement and different perspectives usually taint the process of analysis.

Wtih Data Models being a flat structure instead of a nested, it gives us better freedom in organizing the inheritance structure of categories and attributes, and even data. But we are not locked down to a Primary Category > Secondary Category > Tertiary Category > etc ...

It creates a little more work in the initial configuration of PIM, but I feel it gives a LOT of freedom (and slack, in case of mistakes) for analysis and longer maintenance.

Bets part is, you are not locked into thinking, designing or implementing through the nested structure, but you can design from a data perspective. More often than not, customers ERP or Ecom group structure is not thought like this, and that's always an uphill battle doing PIM implementations. Very often we end duplicating the ERP Group structure or the ECOM Group structure into the Warehouse, which is inefficient and produces a not of nuisance down the road.

/Kenneth

Hi guys,

Thank you very much for all the info and suggestions. They are very much appreciated!
I am preparing for a PIM demo for a prospect who's selling foto and video equipment including all kinds of accessories.

They have about 12 top level categories and more than 100 subcategories (different product types) . Should I assume that I should define 100 Data models (one for each product type)?

Also, how should I handle grouping of the attributes inside a data model? Think for example a Foto camera with attributes structures on multiple groups: Sensor, connectivity, lens etc.

How should I use the Data model, Data sets and Field display groups in this situation?

Would it be same to assume that Data Model is specific to a product type (in this case Foto camera), the field display group would be specific to a Group of attributes (Sensor) and Data set will be a Data model with a predefined set of values?

Also, since this Data model thing is supposed to help the admin define easier the data structure, shouldn't I be able to add new data models directly from the Products interface without going to Settings/Products/Attributes/Data model?

Thank you in advance,
Adrian

I am not sure if you've already seen it, but maybe this article on data modeling can help: Data modeling

If there's anything unclear in the article please let me know. Took me a while to grasp the concept too.

Hi Adrian,

I would like to arrange a meeting with you, about this DEMO project you describe above.

Would you please send an email, with details about their products and their categorisation, Subcategories and their relation to Categories

Look forward to hear from you

/Søren

Hi Adrian,

A quick and dirty (off my fantasy) modelling could be done like this:

Also Carstens links is pretty miuch the same. - This structure I outlined is trying to duplicate the Warehouse logic, but without the nested taxonomy, but split out into levels. But organized with Folders to help humans perceive it better, since we still think in nested taxonomies.

I would consider adding some data sets specific for a Chip or a Lense a camera would be using is a 4th data model, in order to have more technical data, but only have to enrich it once.

/Kenneth

Hi Carsten, 

I have read the documentation, but it is a bit confusing:

Here, I have a list of DataModels:

In this example, according to the interface, Camera Foto, ETIM and iTrade should be Data Models. Except they are not. They are actually the old "Warehouse" objects.
Only the next level (CARACTERISTICI CAMERA and Mac) is actually a Data model as documented in the documentation (actually a Group that supports a ProductCategory):

Then, under the top level Data model, I can add Data model folders and Data models (which are Groups supporting ProductCategory).
Under each DataModel (not top-level) I can add Data set (which is also a Group but this time it does not have a Product Category property, but it will inherit the product category from the parent Data Model and I am able to set up default values for those attributes.

This is as far as I got :)
 

@Soren I will drop you an email about the demo.

Thank you guys,

Adrian
 

Hi Adrian,

Well, yes, there might be some interface issues in that the first level is not data models but actually data model nodes - granted. By chance, my test site setup is actually a camera store - is it organized like this:

As you can see, I have three data model nodes:

• Categories - the data models here contain category-like attributes
• Brands - the data model here (Brand) has a lot of preconfigured data sets with brand information, e.g. logos and links to websites, etc. Makes it easier to enrich new products from those brands when they come in.
• Other - a catch all category for other properties, like... does a camera have wifi and bluetooth? Instead of adding those fields to all categories where they might occasionally be needed, I've created a separate data model you can add to producs when necessary.

The "trick" is to think of data models a little bit like advanced 'property fields' which can be added to products on a need-to basis. This is only more pronounced if you have component products where all base products consist of many preconfigured parts, e.g. gaming computers - you can then add the relevant data sets for e.g. a motherboard, a GPU, a CPU, some blocks of RAM, etc.

It's abit of a mind twist, I know, but it makes sense I promise :D

Hi Carsten

Thanks for sharing :)

Thank you, the example makes sense.
You still have to wrap your head around it, but it makes sense.

Have you tried this approach for a large catalogue? +30.000 SKUs, +100 Product Categories?

Thank you,
Adrian

I have not - I am sure that will be challenging. But the whole point of PIM is to break that challenge into smaller parts.

I know our PIM consultants use data models and work with large catalogues, so maybe reach out to them for some knowledge sharing.

I will reach out to Soren.

My worry is that having many ProductCategories with many sub sub models will lead to a very large number of elements in the tree, affecting both usability and performance.
Your suggested approach works very well on a small scale, I will be curious to see it in action for a large catalog with many data models.
 

Thank you,
Adrian

Yes, as always it depends heavily on the product data you have available from the customer, so it's hard (for me) to say which approach works for which projects. So analyzing the product data and how the product attributes are organized etc. is super important. That's where I think the PIM consultants have what I haven't - a lot of experience with actual projects :)