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

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 routing internals, part 1

Routing is important for any sites, and it’s even more important for a Commerce site – it can help driven sales. People nowadays search for everything, and ranking higher in the search results yield much better chance of your products being purchased. There are two routing systems in Episerver Commerce (as always!). The old one is based on SEO URI, has been there since Commerce R1, and the new one, HierarchicalCatalogPartialRouter, which is a partial router, was introduced in Commerce 7.5.

The SEO Uri approach

This approach is based on the SEO Uri, so the link to your product will be in form of http:///yourproduct.aspx. Note that .aspx is the default, but you are free to choose another extension, or even no extension at all. The SEO Uri can be edited in both Commerce Manager and Catalog UI

SEOCommerceManager — SEO Uri editing in Commerce Manager

Those information are stored in CatalogItemSeo for both Nodes and Entries, which each row represents the information of one node or one entry in one language. Note that only the Uri is unique and is used by the system, it’s up to your site implementation to utilize other information such as Title, Description – just follow best SEO practices.

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