EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?

It can be pretty confusing for new Commerce developers to understand how to work effectively with entries in Commerce. There are many things which represent the same concepts, however they are different and their APIs are not compatible. So which is which and what should you use?

Which is which

  • CatalogEntryDto is the DataSet to represent one or more entries (CatalogEntryDto can of course be empty). Beside the basic information like Name, Code, or MetaClassId, depends on how did you load it, a CatalogEntryDto can contain information about the assets, the associations or the variations (you can specify what to load by using CatalogEntryResponseGroup parameter. CatalogEntryDto, however, does not contain information of the metadata system of an entry – for example, if you add a metafield named “Description” to your entry metaclass – that is not available in a CatalogEntryDto.
    CatalogEntryDto can be loaded or saved by ICatalogSystem methods.

Continue reading “EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?”

Catalog Search APIs are for editing only!

If you are using Catalog Search APIs for any customer-facing features, you are doing it wrong!

I have seen this problem a couple of times – the search feature on the site is “dead” – it is very slow, and the log file is usually filled with dead lock or timeout error. As it turns out, the search feature was implemented by Catalog Search APIs, which is a big no-no.

To be clear, there are two builtin APIs related to searching in Episerver Commerce: the “fast” one, which can be done via SearchManager, ISearchCriteria and ISearchResults, is the SearchProvider APIs. It’s the indexed search (strictly speaking, you can make it not “indexed”, but that’s beside the point), and the actual search functions will be provided by providers, like LuceneSearchProvider, Solr35SearchProvider, or FindSearchProvider.

Continue reading “Catalog Search APIs are for editing only!”

The hidden danger of dot (Or why should your metafield not contain . in the name)

A dot (.) – it is harmless. What harm can it do, it looks pretty innocent.

And yet it can break your Catalog UI.

Psyduck, from Pokemon Go
A dot can look pretty harmless and innocent, just like a Psyduck. Frankly, its eyes are also two dots.

Catalog UI relies on the Shell UI from CMS to render properties and such. Shell UI, in its hands, needs to know about the metadata of the properties. When you have dot in the metafield names, the MetaDataPropertyMapper will create an Property with that name on site start up. And then when you open All properties mode, Shell UI will request your content type models, and CMS Core will happily return those properties.

Continue reading “The hidden danger of dot (Or why should your metafield not contain . in the name)”

Episerver Commerce MetaDictionary internals

This is an excerpt from my book – Pro Episerver Commerce – which is now already 2/3 complete.

Dictionary types.

Previously we discussed on how properties work with catalog content. However – if you have dictionary types in your MetaClasses, they will work differently. In this section we will examine these special data types – this applies to Order system metaclasses as well.

As we all know – there are three types of dictionary in Episerver Commerce:

  • Single value dictionary: editor can select a value from defined ones.
In Commerce Manager, you can create new metafield with type of Dictionary, but without "Multiline" option
In Commerce Manager, you can create new metafield with type of Dictionary, but without “Multiline” option

Single value dictionary type is supported in the strongly typed content types – you’ll need to define a property of type string, with backing type of typeof(PropertyDictionarySingle)

  • Multi value Dictionary: editor can select multiple values from defined ones. The only different from Single value dictionary is it has the “Multiline” option enabled.

Continue reading “Episerver Commerce MetaDictionary internals”

Import catalog: beware of warning messages

Recently I worked with a support case from a customer. They complained that the catalog import is too slow for them, it took them 6-7 minutes to import 200 entries. Their catalog is about 50k entries, which is not particularly big, but not small neither, and with that rate, it does mean they will have to wait for days for the catalog imported. This is of course not good and I jumped in when I became available. (In the end, I like performance tuning so much that I find it hard to refuse a case like this)

I did try to import their catalog on my development machine – a relatively powerful desktop with Intel Core i7 4790 CPU, 16GB of RAM and 256GB SSD on Windows 10/.NET 4.5.2. Everything went quite well – I achieved a rate of 200 entries per 9-10 seconds, which is, IMO, more than enough. (And this is on Commerce 9, on Commerce 8 then I would suspect it’s 3-4 times slower).

After some conversations with Episerver’s developer support team, it seems that the slowdown only happens with the re-import. I tried it again with re-import. Hmm, something is wrong here. The import is much slower and it eventually stops at some points. The debugger shows that it starts quite well, even faster than a new import (200 entries per 3-4 seconds, a very recent version of Commerce made an improvement of skipping the entries which are not changed to speed up the import), but it slows down by time. Profiling does not show anything obvious, most of the time was spent with loading the MetaObject:s – which is kind of expected.

I was starring at the import tab, and wondering what can be wrong, and suddenly I realized the answer is what I was looking at:

Continue reading “Import catalog: beware of warning messages”

How Episerver Catalog content versions work

This is an excerpt from my book – Pro Episerver Commerce. Use http://leanpub.com/proepiservercommerce/c/Easter2016 to get 20% off the book during Easter holiday (Mar 24th – Mar 28th)

One of the most important features in CatalogContentProvider is it bring versioning to catalog content. It was somewhat limited with Commerce 7.5 (the languages handling was a bit sloppy), but it has been much more mature since Commerce 9. The versioning system in Commerce 9 is now more or less on par with versioning in CMS, and it’s a good thing.

If you’re new to Episerver CMS/Commerce, then it might be useful to know how version and save action work in content system. Of course, you can skip this section if you already know about it. The version status is defined in EPiServer.Core.VersionStatus. When you save a content, you have to pass a EPiServer.DataAccess.SaveAction to IContentRepository.Save method.

Continue reading “How Episerver Catalog content versions work”