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

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

What not to do with your login/register page

This post is strictly my personal opinions, it does not represent my employer’s views in any way.

Login/register page is essential to any site, especially any Commerce site. You should always follow the proven, established practices, but yet many sites still have issues with their login and register page. Make sure that you do not do anything mentioned below:

Use HTTP for login/register page.

You might say “What?”. It’s 2016 already and certificate is cheap as hell (even free, if you count Letsencrypt). Still, there are Commerce sites use HTTP for login/register. This, sadly, happens to one of my favorite sites, itsajten: NonHttps (1)

In case of itsajten, there is not much of sensitive information an attacker can get if he sniffs the network and gets my password. I’m in Sweden and almost everything is transparent, even my income. But still, it does mean that I’m subject to social engineering attack. I notified itsajten about this but never heard from them since – which is a pity. They are otherwise very nice and they offer some of the best prices on the item I interested.

Continue reading “What not to do with your login/register page” →

Diagnose your Episerver site: find and fix the issues

It’s quite often to see some questions related to issues posted in Episerver World forums. While I (and most of people there) are willing to help, it still takes time for you to write the question and wait for an answer. Sometimes, the answer can be incomplete or even incorrect, because the people answering your question do not have the full context as you do. The truth is, you’re the person who know the most about your site, and you can do something to diagnose it. Those steps below are in the order you should take to diagnose your site:

Browser console is your friend. It’s the thing which seemingly ignored the most. When something does not work in Edit UI (CMS) or Catalog UI (Commerce), make sure to open your Browser console and switch to Console tab. If their was a network issue, such as a 500 “Server error” response, make sure to open it. (Right click and choose “Open in a new tab” in Chrome). More often than you might think, it can reveal the underlying problem. If it’s a JavaScript error, how does it look like?
Logging is your (another) friend. When something seems to be wrong, check your log file, or turn down your logging level to see if you can see any trace there. In some case, no log found can also be a trace to solve the problem.
Does iisreset solve your problem? No I’m not suggesting you to run iisreset every minute on your production site, but it might isolate the problem – if it does, then the problem might relate to cache, or initialization modules. If it does not, well, it can be anything else. But at least it’s not caused by certain things – the key is to narrow down the causes of problem. You can also try to call

ISynchronizedObjectInstanceCache.Clear();

Continue reading “Diagnose your Episerver site: find and fix the issues” →

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

Episerver Commerce routing internals, part 2

This post is a second post after http://vimvq1987.com/2016/03/episerver-commerce-routing-internals-part-1/ . The third part in the series can be found here: http://vimvq1987.com/2016/03/redirecting-your-product-urls-in-episerver-commerce/. (I know, I should have published the post in the right order.) They are all excerpts from my book – Pro Episerver Commerce.

The hierarchical approach:

This “new” approach (today it’s not new anymore, perhaps we can call it newer?) was introduced in Commerce 7.5 to make the routing of Catalog contents inline with CMS content. The core concept of this approach is to reflect the structure of contents to the structure of the Uri, for the discoverability. With SEO Uri approach, customers will never know how to get to the parent node, to see the other items in same category. With the partial routing, they can. To allow that, every catalog content has a piece of information – RouteSegment. This is saved in CatalogItemSeo as UriSegment, but is hidden for editing in Commerce Manager

Continue reading “Episerver Commerce routing internals, part 2” →

Use HTTP for login/register page.