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

Never send me my password

I’m not a security expert myself, not even close, but for more than once, I’ve been greatly concerned about the risks for having accounts in several websites. I wonder myself why did the developers there go with the decisions that bad.

It’s already bad enough to use HTTP on your register/login page . It’s even worse when you send me my password in plain text. Either the one I chose or the one you randomly generated for me.

And this has happened more than once. Each time, it raises my eyebrows higher and higher. I don’t want to rant here – but it takes great deal of ignorance or laziness, or both, do do such as bad practice about securities.
Continue reading “Never send me my password” →

What not to do with your newsletters

Newsletter is a powerful communication channel – it keeps your customer informed, and even more, keep then engaged . Truth is, most of your customers won’t visit your website often, and newsletter is a very good way to keep they coming back. I myself – am an example of those customers – most of my purchases were made from newsletters. A good deal shows up and I just buy it – even thought I don’t really need it. Yes it’s not the best habit in the world, but it’s the way marketing works. You get a good sale, I get a product that I might need some day. Everyone is happy, well, might be except my wife.

However, like other channels of marketing, mistakes can be made with newsletter and drive your customers away. Make sure to avoid these:

Sending too many newsletters:

Unless your customers explicitly say that they want to get your newsletter everyday, it’s best to avoid to do so. Even if your site is full of interesting content, keep in mind that if customers received too much emails from you, their interests might wear out. It’s bad when customers start getting a habit of “Oh another mail from <blah blah>, just ignore it”. It’s even worse if they don’t open your newsletter at all, or simply create a rule to delete it.

Continue reading “What not to do with your newsletters” →

The quirks of coupons

If you have been using the promotion system in Episerver Commerce (or should I call it “old promotion system” – the “new promotion system” is almost out of BETA and it will soon be the promotion system), you should know about the coupon – which is an option setting for a promotion. When it is set, the customers will be required to input that special code in order to get the reward, even if their carts fulfilled all other requirements (the subtotal, the lineitems, the shipping method etc.)

The coupon in old promotion system is quite basic – you can set only one per promotion, or nothing at all. Advanced scenarios like customer-specific coupons (there are multiple coupons and each of them is valid for only one customer) are not supported. (This is one of reasons why you should consider to move to new promotion system ASAP). You can use redemption limits in combination to specify how many times a coupon can be used. But in this post we will talk about the quirks of storing it.

Continue reading “The quirks of coupons” →

Upgrade your website to Commerce 9

You know what – Commerce 9 is released. OK, I’m just kidding, it was released 6 months ago, in October 2015. Last week, Commerce 9.12 was released, and at this time of writing, Commerce 9.13 is ~~on the oven~~ just released. So it’s not so new – but with 6 months on the field, I think Commerce 9 has proven it’s stable and production-ready to be your next version. If you are looking for an upgrade to your website, Commerce 9 is the obvious choice. Many customers have successfully upgraded their sites to Commerce 9 – and the results have been very encouraging.

But it does not mean that upgrading is easy. Commerce 9 is undoubtedly a big upgrade, and getting there is not just an easy walk. So how to ensure a successful upgrade?

Plan ahead:

The catalog subsystem was rewritten almost entirely in Commerce 9, resulting in some very big migration steps. Depends on the size of your catalog, it can take from a couple of minutes, to hours (I would not be too surprised if it takes a day). So plan for the possible down time (even though in most cases you will be upgrading your site in staging first).

Commerce 9 is also a major release, so there were breaking changes – you will have to fix some of your code, to make it compiled. The amount of code that actually broken should be small, but it’s better if you check this list http://world.episerver.com/documentation/Items/Upgrading/EPiserver-Commerce/9/breaking-changes/ to see how much works you’ll need (tips: the less you use “internal stuffs”, the code you’ll have to change. The internal stuffs are, by convention, marked with special doc tag.).

Continue reading “Upgrade your website to Commerce 9” →

Understand the retry policies in Episerver

This is pretty internal stuffs – you will almost never use it yourself (you technically can, but there is no guarantee of backward compatibility whatsoever). I learned the stuff recently and found it interesting enough to share.

No matter how powerful your server(s) are, and how reliable SQL Server is, there are chances that a query can result in error. Hell, there are bunches of error codes that can be returned (and I never remember one, Google made a pretty bad habit of forgetting everything). But they can be divided into two categories:

The un-retry-able errors, such as a grammar error in your stored procedure, or a parameter is missing, or mismatch. These errors need human-interaction to correct them before continuing.
The retry-able errors, which means if you re-run the query, there is a chance that it would eventually succeed. Compared to the un-retry-able errors, these are in smaller number. A deadlock can be considered as retry-able (with the hope that the deadlock conditions are no longer present, the other threads finished their works and released the locks). A timeout error can be considered as retry-able (with the hope that the server can run the query faster, this time). In the end, your query can succeed, after some tries.

You might ask, why retry? The question is, why not? Retrying the query can make it works, and as it’s transparent from end-users perspective, it might provide a smoother experience for them. Say, they are trying to place an order. Because of your highly successful campaign, there are a lot of customers trying to do the same thing at the same time, resulting in some occasionally deadlocks. You’ll be much happy to silently retry and have another order in place, than showing “Something went wrong” to the customers. Of course, the previous errors will still be logged for further analytic, but you’re good for now.

Continue reading “Understand the retry policies in Episerver” →

Episerver Commerce SearchProvider – demystifying

This post is an excerpt from my book, but it’s the short one. It looks like there is a confusion of where the searchprovider is used in Commerce

Many important features in Commerce Manager use index-based search provider to search for entries – it’s simply faster and more flexible to work with. They might not be truly “real-time”, but they’re close (with the right configuration). The only drawbacks are they require extra processing (for indexing entries), external files/configurations, but the advantages easily overweight any of those drawbacks.

There are three search providers provided by Episerver Commerce: LuceneSearchProvider, Solr35SearchProvider, and FindSearchProvider (four if you count SolrSearchProvider as well). LuceneSearchProvider comes as the default option with EPiServer.Commerce.Core, and it’s the only one does not require extra configurations.

Continue reading “Episerver Commerce SearchProvider – demystifying” →

UX design lessons – from a metro perspective

When I come to a new city, I usually pay close attentions to its metro system. Of course, it rarely shows up in TripAdvisor as an attraction of the city, but for me, it’s not only a necessity (based on a quite tight budget, public transportation is almost always our first choice), but also can tell a lot more about the history of the city, the people and the daily life here.

rsz_112909433_10154138750224038_5364040389823582540_o — New York metro system . Make sure you don’t look at the rails.

I’m not a traveler myself, I have visited only Rome, Paris, Venice, Florence London, San Francisco and New York, and of course Stockholm – where I am living. Venice and Florence have no metro I’d know of, and I only tried BART (Bay area rapid transport) in San Francisco, so only metro systems in remaining cities count. In those five, I know Stockholm metro system (tunelbanna) the best, and like it the most, so this post can be highly biased opinion. If I did misunderstand a metro system, kindly point it own.

Continue reading “UX design lessons – from a metro perspective” →

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