• Catalog,  Commerce,  Episerver

    Watch out for orphan rows in Episerver Commerce database

    One of the most important aspect of data storage is integrity, meaning that the accuracy and consistency is maintained throughout the life cycle. However, there are cases when the integrity can be compromised in certain tables. It is difficult (if not impossible) to enforce a constraint between those columns technically, because of the schema design. The data integrity is enforced by other means (such as triggers, or carefully written stored procedures). If you are using Episerver APIs, it’s guaranteed that no orphan rows are left behind. However, if you are doing data manipulation directly yourself (which we generally advise against), or if you are syncing databases between environments (for example,…

  • Catalog,  Commerce,  Episerver,  Uncategorized

    Price optimizing: to be or not to be

    It can be quite confusing when you first edit prices in Episerver Commerce. To your surprises, some of the prices you imported or edited might disappear, or change, without your consent! What happened? To answer that question, it’s essential to know there are two pricing system in Commerce: IPriceService and IPriceDetailService. They have some different characteristics, and one of them is very important: the default implementation of IPriceDetailService saves prices as-is, while the default implementation of IPriceService does not: it optimizes prices before saving. Prices which are best for customers will be favored over the “less good” ones.

  • Catalog,  Commerce,  Episerver,  Performance,  Tips,  Uncategorized

    Can Episerver Commerce support our catalog size?

    One of the questions customers usually raise during evaluation of Episerver Commerce is : “Can it support our catalog size? We have (a very big number of ) entries. Will it work?” The answer is (of course, as always): It depends! I’ve seen “big” catalogs. Some big enough in number – 1 million entries catalogs are not very uncommon, and some are even (much) bigger. Theoretically, Episerver Commerce can support up to 512 millions 1 billion of entries (!), so you can have pretty much anything in your catalog until you reach a hard technical limit. Just for comparison, Amazon.com, which is arguably the biggest eCommerce site on the world, has…

  • Catalog,  Commerce,  Episerver,  Performance,  Tips,  Uncategorized

    The Catalog UI trade-off: performance or better UI

    I supposed this is a well known feature, but I was asked more than once about it, so it’s better to write something here to clarify the confusions. If you have some very, very big catalogs, you probably have seen this “notification” in Catalog UI By default, the Catalog UI groups a product and its variations in a parent-children view (they are not exactly parent-children, by the way). However, to do that, it needs to know about all the entries in that specific category. If it’s a small category, it should be no problem, but if it’s big one, then it’s inevitable slow. The lazy loading which the catalog content…

  • Catalog,  Commerce,  Episerver,  Find

    Find indexing job + HierarchicalCatalogPartialRouter: A note

    I ran into this problem recently and while in the end it’s quite simple issue (Everything is simple if we understand it, right?), it costed me quite many hairs in the process – as it involved debugging with 3 solutions – Find.Commerce (where the problem appears), Commerce (where the router does the work), CMS Core (where the routers are handled). It was both fun, and confusing. The problem as a customer has this code in an initialization module: [crayon-5d32fddb47d7b113381890/]

  • Catalog,  Commerce,  Episerver,  Performance

    Episerver Commerce performance optimization – part 1

    This is a first part of a long series (which have no planned number of parts) as the lessons I learned during trouble shouting customers’ performance problems. I’m quite of addicted to the support cases reported by customers, especially the ones with performance problems. Every time I jump into such support case, I’ll be with less hairs, but I also learn some new things:  Implementations are different from cases to cases, but there are some common mistakes which will hurt your website performance. This series will try to point out those mistakes so you get your performance gain, for (almost) free: Mistake 1: Loading to much content It’s easy to…

  • Blogging,  Catalog,  Commerce,  Episerver,  SQL Server

    Speed up your catalog entries indexing

    Even with the raising popularity of FindCommerce, I suspect that many Commerce customers are still using the search provider system, as it comes with an undeniable benefit: It can be used within Commerce Manager. And while I suspect a majority of you have the eventual indexing turned on (aka the entry will be indexed as soon as it’s changed), many still index the entries on demand. Aka manually, or periodically via scheduled job. We received a report from a customer recently as the indexing timeout, as he was indexing a large amount of entries (about 250.000 entries on 8 catalogs). When we looked into the problem, we discover a possible…

  • Catalog,  Commerce,  Episerver,  Uncategorized

    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…

  • Blogging,  Catalog,  Commerce,  Episerver,  ranting

    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…

  • Catalog,  Commerce,  Episerver,  SQL Server,  Tips

    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. 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.