Tale from inside TransactionScope

One of the last things you want to get from your Commerce site is that the order data is gone. What can be more confused than if your log shows that the cart has been converted into a purchase order, you even got the PO number, but after that, the order disappears? It’s nowhere to be found, even if you look into database. It’s kind of magic, but not the kind of magic you would want to have.

But everything happens for a reason. And actually it’s with a good reason: data consistency.

Episerver Commerce has the concept of TransactionScope. Simply put, it allows two or more database operations to be done as atomic: Either all of them succeed, or all of them will revert back. If a TransactionScope contains 3 operations A, B, C, then even if A, B succeeded, but C is yet to commit, and something goes wrong, then A and B would be reverted.

Continue reading “Tale from inside TransactionScope” →

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 list only loads the contents when you scroll to them is not helping in this matter. Moreover, the grouping introduces an overhead for the UI, and having too many groups can severely affect the performance. Trust me, you won’t like a sluggish UI.

This improvement was introduced way back – 7.11 if I remember correctly – thanks to my colleague Magnus Rahl. To this day it’s still valuable – the performance was improved – but not that much to remove the threshold completely (And the improvement to the catalog versioning in Commerce 9 should have nothing to do with this).

When you see this notification, and if you’re unhappy with it, you have two (primary) options: Either to sub-categorize your category – i.e. introduce sub categories so each will have a smaller number of entries. Or increase the value of threshold.

Each approach has its own disadvantages. Sub-categorizing might break your SEO, while the second approach will undoubtedly effect the UI performance. Your call!

Now – the tricky part – which number to configure in SimplifiedCatalogListingThreshold setting. Obviously, it must be greater than the biggest number of entries in a category. But how to obtain that number? I’ve seen the confusion to raise that value to 3000, 5000, or even 10000 and it’s still not working. No, you can’t guess, you have to know for sure.

One simple option is to look at Commerce Manager Catalog Management. There is a small text in right corner of the list which shows the number of entries in that category (No, it’s not available in the Catalog UI, but I assume it would be helpful?)

The nuke option is to look at the database. Usually we recommend to avoid manipulate the database directly, as it can be dangerous – but here is a little code which only queries data (so practical harmless)

SELECT CatalogNodeId, Count(CatalogEntryId) 

FROM dbo.NodeEntryRelation

GROUP BY CatalogNodeId

ORDER BY Count(CatalogEntryId) DESC

Now you know the biggest number of the entries in a category – just change the threshold in setting. Try it and see if the UI Performance is acceptable to you.

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:

            var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>();
            var referenceConverter = ServiceLocator.Current.GetInstance<ReferenceConverter>();

            var firstCatalog = contentLoader.GetChildren<CatalogContent>(referenceConverter.GetRootLink()).FirstOrDefault();

            var partialRouter = new HierarchicalCatalogPartialRouter(() => SiteDefinition.Current.StartPage, firstCatalog, false);

            routes.RegisterPartialRouter(partialRouter);

Continue reading “Find indexing job + HierarchicalCatalogPartialRouter: A note” →

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 load contents, especially with the new content APIs. Given an universal ContentReference, you can load a content with a simple line of code. By default, the loaded content is cached, so you might think it’s cheap, or even free to load a content. Think again.

Continue reading “Episerver Commerce performance optimization – part 1” →

Episerver Commerce CustomerContact Events

This post was inspired by this question: http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2016/9/commerce-manager-contacts-events/

and is an excerpt from my book: https://leanpub.com/proepiservercommerce

You might notice the lacking of events in some parts of the system. We have events for catalog system, for order system, for prices and inventories changes, but that’s not enough. You might want to have events – or at least – the ability to know when something happens. For example, when a customer contact is changed, or edited, or deleted, it would be very nice to do some extra actions.
Sending emails, updating external systems, etc.

Such events are not available out-of-box, so we have to implement our own. How? We don’t have ICustomerContactService (or something similiar) interface where we can write our implementation to replace the default service (and even if there is, it would be a big task to do so). So there’s no “ordinary”, framework-way to do that. However, CustomerContact is built on Business Foundation system, and BF, at its core, is all above extensible and pluggable. We don’t have ICustomerContactService interface, but we have IPlugin
who can do the same, and even more. As we learned in previous chapter, CustomerContact is just another EntityObject and all operations are still done via BusinessManager.Execute(Request) – even we have some nice wrapper methods to make working with it easier. And when Execute(Request) is called, it also runs all registered IPlugin modules.
Continue reading “Episerver Commerce CustomerContact Events” →

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)” →

How to check if a coupon was successfully applied

When a customer add a coupon to his/her cart, it’s nice and best practice to show to him/her if the coupon has been applied successfully, or if it was an invalid/not applicable code.

How can you do that?

In old promotion system

When old promotion system run, each successfully applied promotion will be presented by an instance of Discount, which has a property named DiscountCode – this is the coupon used for the promotion (it can of course be null if the promotion requires no coupon).

Continue reading “How to check if a coupon was successfully applied” →

The beauty of new promotion system

This is going to be a relatively short post. If you are using Episerver Commerce 9, you probably know that we are working on a new promotion system. It’s still BETA, but some of our customers already use it, and from what I heard they are really happy with it.

One of the reasons we create a new promotion system is the old one is not developer-friendly. Have you ever tried to create a promotion in old system, by code?

This is an “simple” example of how to create a new campaign and a couple of promotions:
Continue reading “The beauty of new promotion system” →

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)

 [BackingType(typeof(PropertyDictionarySingle))]
 public virtual string Color { get; set; }

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” →

Quicksilver – ServiceApi: fixing issues

From what I heard, developers seem to love both QuickSilver – as a template – and ServiceApi – as a REST server – very much. Despite of being relatively new on the field, they are being used quite frequently – QuickSilver is the preferred choice for MVC template while many sites are using ServiceApi to update the catalogs. What’s about the combination of these two? Would it be the best-of-bread for Episerver Commerce. I would say yes, but after you have fixed the issue.

The installation of ServiceApi.Commerce package to Quicksilver site should be easy and painless. Update the database and build the project, you should be expecting to have a working site.

Not quite. You should be seeing this error:

A route named 'MS_attributerouteWebApi' is already in the route collection. Route names must be unique.
Parameter name: name

It’s because

MapHttpAttributeRoutes

is called twice (as it’s called in ServiceApi as well). So naturally, let’s try by commenting that line in SiteInitalization.cs, and build it again.

This can also be solved by adding this into appSettings:
"episerver:serviceapi:maphttpattributeroutes"

Which will signal ServiceAPI to skip calling

MapHttpAttributeRoutes

A new error would show up:

Continue reading “Quicksilver – ServiceApi: fixing issues” →