Try our conversational search powered by Generative AI!

Scott Reed
Feb 22, 2019
  2691
(7 votes)

Episerver Commerce A Developer View (Part 1)

Recently at the Episerver London meetup I did a presentation on Episerver Commerce and it was suggested to break it down in to a set of blog posts so all you lovely Episerver developers can read it so that’ just what I’m going to do.

I’ve been working on a massive charity project for the last year and a half and in that time I have learnt the ins and outs of Episerver Commerce so here’s a round up of my talk covering 3 areas

  1. Introduction to Episerver Commerce
  2. Core Features - https://world.episerver.com/blogs/scott-reed/dates/2019/3/episerver-commerce-a-developer-view-part-2/
  3. Developers Tips
  4. Experience Driven Commerce

1. Introduction to Episerver Commerce

So what is Episever Commerce, well this is what Episerver say

“Episerver Commerce is a complete digital commerce suite that has the industry’s highest ROI.

It has everything you need to manage catalogues, orders, customer data and payments across regions. The solution also helps you easily provide better experiences. You can seamlessly combine content and product information, and automatically personalize journeys using artificial intelligence.”

So, broken down what really does this give us as developers to build amazing experience driven commerce websites.

  • Customizable CMS and Commerce Episerver platform with a dev centric approach to building, upgrading and deploying
  • The DXC Service, hosting for your CMS and Commerce application on the Microsoft Azure platform. Provisioned and managed by Episerver and provided with scalability, security and performance out of the box. This is the place to get the best from Episerver
  • Personalization – With Insight and the profile store you can build machine learning driven personalized experiences. Couple this with Campaign and you get an end to end multichannel personalized experience making it's great for end users and increasing sales and coversions.

History

Episerver Commerce was originally a product called Mediachase which Episerver acquired in March 2012. Since that time Episerver have continually improved commerce, bringing legacy mediachase features in to the native CMS experience. Today it has a powerful set of features and a complex ability to customize features

Here are a few of the latest Forrester statistics to show how Episerver can really benefit a commerce driven company or organization.

Project Structure

So, what does it look like for us as developers when we start working on a commerce build?

 At the heart of it when you start developing, you’ll start by doing the same as a CMS build.

 Install the CMS via the VS Extension

 Once you have the CMS installed and configured, you create an empty asp.net project and install the correct Nuget packages in both the blank application and in the CMS application as explained here.

 As shown on the left, the blank application becomes the Commerce Manager application.

Catalogue Management

The entire catalogue management experience has been built in to the native CMS editing experience to give management a really slick and quick experience. This is what users come to expect when working with Episerver so its great to have the native experience for the core of what CMS editors will be doing in the standard look, feel and way of working.

Good

  • The same great experience as the main CMS editing interface brought to products.
  • Supports Drag and Drop of commerce items, media across CMS and Commerce views.
  • Reordering & Filtering at the category and product level so users can control sorting.
  • Pricing & Inventory really easy to use and information shown in main views.

Bad

  • Sometimes Buggy/Slow – This will happen if you have a large poorly structured catalogue. One of the most important things with Episerver Commerce is to map out your catalogue upfront. If you find yourselves with too many products under a category considers restructuring as the more the interface has to load the slower it is.
  • Direct Saving - Some areas such as inventory and pricing directly save their changes to the database. This means users do not get the same publishing system with drafts / scheduling of publishing.
  • Poor Block Support – Normally with Blocks you can put them on a page level or globally in the shared blocks area. However, with commerce product/variant level blocks just does not work making it hard to deliver the same standard editing experiences without using shared blocks. This is something I REALLY hope is fixed.
  • Weird Asset System – To add media to a commerce item there an control on the item that allows you to click a plus and pick a media item. Sounds great so far…however there’s a string group key which is just odd to use, and the system implicitly uses the first image as the product image. IMO this area needs some work to make it cleaner.

Marketing View

The marketing view has been built from the ground up to create a really good interface for managing campaigns and discounts for items, orders and shipping.

Good

  • Nice interface that’s easy to use and very powerful.
  • Ability to configure discount order and exclusions so that discounts can’t be used together.
  • Easy to extend in code

Bad

  • Exclusions in a weird place, require clicking the toggle view button on the campaign view which has no indication this is what it is.

Commerce Manager

The commerce manager is the part of the system that essentially the old mediachase product. It’s still plagued with a lot of fiddly issues which are unlikely to be fixed.

System Features (Covered in my next blog post)                       

  • Markets
  • Warehouses
  • Payments
  • Tax
  • Shipping

Order Features

  • Carts (Serializable)
  • Customer Data
  • Purchase Orders
  • Delivery Options
  • Admin Searching Carts/POs

Bad

  • Slow – Using commerce manager is very slow, some areas more that others. There is also a habit of parts randomly breaking until an IIS Reset or full browser cache clear.
  • Ugly – Let’s face it Episerver wins the CMS UI war with how great their experience is. However the legacy commerce manager system is very outdated.
  • Leftover Features – Although features can be turned off from view they are still in the codebase and if you leave them on you can get confusingly different views of data across the CMS UI and Commerce Manager, for example Catalogue management.
  • Confusing Navigation – The navigation is often confusing, you can get items with links on and then a little icon next to the link. Clicking the link often takes you to one interface and the icon another. It can be hard to remember which one is the correct one to click.
  • Hard to extend – Some areas aren’t too bad such as the business foundation bits but generally it’s difficult extending commerce manager. Areas such as the purchase order/cart search areas are very difficult to extend.
  • Catalogue Manager Oddities – If you do leave the catalogue management area on in commerce manager you get some different data. One such example is a published flag which actually does not match to the catalogue managers view of published in the CMS view.

However, the great thing is that Episerver are updating this, as they did with the above-mentioned catalogue management and marketing area. They are writing a new shiny customer and order management area called the Customer Service UI.

This is still in beta but has come a long way so I’m hoping for a stable release soon.

Currently the only thing I don’t like is the creating of new carts is hidden away behind the “Open Cart” button. I’d much rather see a dedicated button for this in the main UI.

Conclusion

The commerce products are a great suite of products and there’s so much you can do. There are a few issues with the older parts but Episerver are fixing these and re-writing core areas all the time so this is only going to get better.

In the next blog post I’ll break down the core features of Commerce mentioned above in to some more detail.

Part 2: https://world.episerver.com/blogs/scott-reed/dates/2019/3/episerver-commerce-a-developer-view-part-2/

Feb 22, 2019

Comments

Henrik Fransas
Henrik Fransas Feb 22, 2019 01:48 PM

Thanks Scott, I was just thinking about writing a simular blog serie on learning Commerce since I am sitting and trying to do just that now...

This will help during the learning process!

Feb 22, 2019 02:36 PM

Thanks, I've posted the my full talk on my LinkedIn so if you want to get to the meat of the series, the developer tips check that out.

Bob Bolt
Bob Bolt Feb 22, 2019 05:35 PM

Scott, Can you provide a link to your LinkedIn video?

Luc Gosso (MVP)
Luc Gosso (MVP) Feb 26, 2019 09:37 AM

Thanks for sharing Scott! on slide 24 "database", you state "Consider direct database work for importing bypassing APIs"

Thought that was a big "NO NO", will you blog about it? interested in what parts you referencing to and example.

I believe that is a parts where partners get it wrong and build it wrong usually.

Mar 12, 2019 12:40 PM

So Luc, the database importing directly, personally when we build our import mechanism for a recently client we built it using scheduled jobs and the standard IContentRepository. This worked as expected but it was very slow as we had on a fresh import around 50k total nodes, products and variants.

It was so slow in fact in the DXC that the job would crash overnight, something I thought was down to the autoheal policty in Azure but after turning it off I think it's just due to the thread running so long. I had to in the end re-work it to allow it to resume when crashed which was no ideal.

Personally I have a decade of SQL experience and have built complex systems in SQL with agent jobs and such. I understand that writing against the database will have issues with schema changes however I think as long as you know what you are doing you can mitigate these issues and writing for example a C# agent job that can process and import everything directly within the database or a tool that can do it would have been vastly more efficient and we could have done more clever bulk importing techniques. I think really it depends on the data size but if you're importing such a massive amount of data you obviously have to start exploring other techniques.

Please login to comment.
Latest blogs
Optimizely and the never-ending story of the missing globe!

I've worked with Optimizely CMS for 14 years, and there are two things I'm obsessed with: Link validation and the globe that keeps disappearing on...

Tomas Hensrud Gulla | Apr 18, 2024 | Syndicated blog

Visitor Groups Usage Report For Optimizely CMS 12

This add-on offers detailed information on how visitor groups are used and how effective they are within Optimizely CMS. Editors can monitor and...

Adnan Zameer | Apr 18, 2024 | Syndicated blog

Azure AI Language – Abstractive Summarisation in Optimizely CMS

In this article, I show how the abstraction summarisation feature provided by the Azure AI Language platform, can be used within Optimizely CMS to...

Anil Patel | Apr 18, 2024 | Syndicated blog

Fix your Search & Navigation (Find) indexing job, please

Once upon a time, a colleague asked me to look into a customer database with weird spikes in database log usage. (You might start to wonder why I a...

Quan Mai | Apr 17, 2024 | Syndicated blog