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”

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”

Redirect your product URL:s in Episerver Commerce

Why redirect?

A very good thing about Episerver Commerce is that even you enabled the partial routing system, the old SEO Uri:s will continue to work (of course, as long as you keep the Uri:s unchanged). So they can coexist in same website – but that might not what you want – you might want to stick with only one routing system – it’s been told that the more popular your URL is, the higher rank it gets in the search engine results.

From hierarchial URL to SEO URL:

This one is pretty easy, just call this during your site’s initialization, the true parameter means you want to enable Outgoing Seo URI, and the next statement configures the redirect:

From SEO URI to hierarchial URI:

This one is tricky, there is no such built-in method allows us to do so. We can’t even override SeoUriRouter because it’s registered automatically and there is no way to guarantee that our router will be able to run before it. (If a matching router is found, the processing will stop).

Continue reading “Redirect your product URL:s in Episerver Commerce”

Episerver Commerce 2015 – year in review

While I’m proud of how great Commerce were in 2014, there are still areas where we need to improve. One of those is performance.
We paid attentions to important parts of the system, where customers demand the most. And the results were, quite impressive. From 8.11 to 8.15, many profiling and improvements had been done, and the results are quite expensive: loading cart performance increased with a fold of 4, loading Entry with CatalogEntryResponseGroup.Full performance increased with a fold of 3, etc.

Performance, performance, performance

While I’m proud of how great Commerce were in 2014, there are still areas where we need to improve. One of those is performance.
We paid attentions to important parts of the system, where customers demand the most. And the results were, quite impressive. From 8.11 to 8.15, many profiling and improvements had been done, and the results are quite expensive: loading cart performance increased with a fold of 4, loading Entry with CatalogEntryResponseGroup.Full performance increased with a fold of 3, etc.

However, the biggest change – “rewrite” catalog system, had to wait for Commerce 9.

Commerce 9 was, in no doubts, big release, in term of changes. And it surely is the biggest in term of performance gain. With the changes in underlying catalog system database, the performance gain is, massive. In some areas, the change is a whopping 10 fold, and other areas, 2-4x times faster. If you are still on Commerce 8.x, while it was a great product at its time, you are highly recommended to upgrade to latest 9.x version. Many customers’ve done it, and they’re more than happy with the performance. 2015 was the year which I can finally be happy with overall performance of Commerce. Of course, there are still rooms for improvement and we are not perfect yet, but let’s open a champaign for the performance gain we got.

New promotion system

I am OK with the old promotion system as an editor/administrator, but I’m no fan of it as a developer. When a bug is reported by the QA, I can follow the bug report to re-produce the bug for investigation, but when it comes to write an integration test to verify the correctness of bugfix (and of course, prevent the same mistake to be happenned in the future), I usually grin my teeth. So I’m all in favors for the new promotion system, when I can easily write tests for my fixes, and even unit tests (woo hoo). And did I mention a much more intuiative and well-designed UI?

Continue reading “Episerver Commerce 2015 – year in review”