Our monthly Virtual Happy Hour is happening this week, Fri Feb 23!
So first off, let me just say I'm new to Episerver Commerce. I'm in the planning stages of the implimentation and I have a question reguarding meta classes that are created inside of Commerce Manager, as opposed to in code.
First off, let me just say that during the demo, I really liked the ability to create meta classes in the tool, and since we currently have tens of thousands of products, many with very different requirements for specifications, our plan is to create many meta classes and to manage these easily, we'd like them to be fully managed inside of the admin, not in code.
Looking into this however, it seems that when I create a meta class, assign it fields ect, that in Episerver Commerce I am able to create products/categories ect just fine. But when I pull up those categories/products in the Episerver Commerce Catalog, they're listed as being a different meta class type. Have any of you ever heard of this before? It's almost like there's a big disconect between Episerver Catalog, and Episerver Commerce Manager.
The current version of Episerver CMS is 9.8. The current version of Commerce is 9.111. We're currently using an MVC implimentation.
Any ideas, or advice on why this is happening?
I'm not sure I understand what you mean as "they're listed as being a different meta class type" - do you have a screenshot or so?
I don't fully understand your description of the problem but I've experienced caching issues if you create your meta classes and catalog entries in Commerce Manager.
Does an app pool recycle solve your problem? If not, please extend your problem description and include a couple of screenshots as Quan mentioned.
If the site is fully functioning - (the events are fired and catched correctly) - then there should be no caching problem between metaclasses in Commerce Manager and content types in Catalog UI. We fixed that issue in Commerce 7.5.
1. Go to the quanta demo.2. Go to Commerce Manager --> Administration --> Meta Classes --> Create New Class. 3. The New Class appears here. 4. Now that the class has been added, go to Commerce Manager’s Catalog Management tool. 5. Create product using the new class that we just created. In Commerce Manager, this works well. The Meta Class appears in the list as it should, and the product was created just fine. 6. My issue is this… Now that this Meta Class has been created, in Commerce Manager it’s fine. But in Episerver Commerce Catalog tool this class doesn’t appear at all.7. The product for some reason doesn’t appear when browsing to the category, but that’s a different issue.8. I found the product by searching for it. 9. When I view this item in Episerver Commerce Catalog tool, it shows the Type as being Variant/SKU. This is incorrect, this should be Test.Class.4.29.2016. 10. Another issue. This Meta Class was created in Commerce Manager however, doesn’t appear in Episerver Catalog when creating a new part number.
Also worth noting, I'm seeing this exact behavior in on my site. I used the quanta demo so you could repeat my actions literally on the same site as I did mine. A 1 for 1 test if you will. My site is using Episerver CMS 9.8 ant the current version of Commerce is 9.111.
That is by design - Catalog UI requires the content types to work. It can edit the content without content type, but it does not allow to create new without one.
There is no other way than creating the content types for your new metaclasses.
I'd like to confirm what you're saying. So from what it sounds like, Commerce Manager allows you to create meta classes, but they can't actually be used in Catalog UI until you code a ContentType for the meta class? We currently have a content team that manages hundreds of what Episerver calls metaclasses in our old system. If these are all brought into code, we will require a recompile everytime we want to add a new product type. This doesn't seem scalable to me.
I do agree that it will not be easy for your case - but usually new metaclasses/new content types mean redeploy and in most of the cases it would be no issues - the catalog update is only for the data, not the content types.
You can of course develop some smart solutions to ease the work - such as a tool to get all the metaclasses and generate the content type files. Or contact our Expert Services for assistant.
ok. Thanks for your help on this one.
Just to followup, I know some cases similar to yours use more generic meta classes like electronics for example and then map all of the fields to one meta class. This way you can add new fields to the content model when you need to. Also the model just needs to exist, you dont need the strongly typed properties to edit, since it will use the property bag.
Using more generic meta classes isn't an option for us since we have so many different types of specifications. To give you an idea of what we have, we've got about 30k part numbers, with about 1,300 types of product specifications. We've narrowed this down to about 69 meta classes/content types we'll have to create. These are based off of the products we sell, which do change however, so as I'm sure you can imagine we need the ability for these to be dynamic and have the ability for our content team to edit these as they do change.