Unified Commerce Solutions with EPiServer, Avensia Storefront and Dynamics for Finance & Operations

Episerver Commerce and Microsoft Dynamics 365 for Finance and Operations (formerly branded Dynamics AX) are two of the global leaders in their respective Commerce and ERP fields. In this article, we’ll explore how we can integrate these platforms to empower businesses with full unified commerce solutions.

We’ll start with the fundamental reasons we would tackle such an integration as we explore the concept of Unified Commerce…

Unified Commerce

Most retailers use detached and sometimes completely disconnected applications to manage different aspects of their business from the Point of Sale (POS) in retail stores to their eCommerce shop. This results in duplicated data and processes across channels often introducing inconsistencies in pricing, promotions, inventory management, loyalty, CRM and just about every other aspect of running a successful business.

Some use complex integrations to manage the synchronization of data across these applications but that can be a less than efficient taking into account expensive builds and the cost of maintaining these integrations over time. It’s also a less than a scalable solution which can introduce new challenges over time as businesses mature.

The fact is that retailers are accumulating unprecedented amounts of data throughout their various online and offline channels. In order to streamline internal processes and provide customers with a seamless experience across online and offline channels, retailers are abandoning disconnected systems and moving to a unified commerce environment where online and offline experiences come together as retailers use in-store data to personalise experience across the web and vice versa.

The result is that customer experiences across brands improve. There are savings in the time and money being eaten up by integrations, the risk of errors are reduced while companies get the power and scalability of managing their data in one centralised place. In essence unified commerce transformations have the potential to streamline processes, reduce costs and increase channel revenues. To deliver unified commerce experiences we need integrate with the Enterprise Resource Planning systems (ERP’s) that retailers run their business on.

Explaining ERP’s

To understand what an ERP is, you need to take a step back to think about all the processes involved in running a business. With regard to an e-commerce shop alone there is stock/inventory management, pricing, loyalty, promotions, order and delivery management but then retailers also need software to manage human resources, accounting, staff and the list goes on. PIM (Product Information Management) is sometimes managed from within the ERP too.

The purpose of an ERP system is to provide an interface with one central source of truth for data across a shared database so various departments like IT, accounting, sales and Point of Sale staff can rely on the same up to date information.

Microsoft’s ERP sits within its D365 offerings.

Introducing Microsoft Dynamics 365 for Finance & Operations

The first release, formerly known as Microsoft Dynamics AX was in 2006 following on from an acquisition in 2004. Through the following decade, a number of upgrades were released. Then over 2016 & 2017 a major revision of the platform was released with a completely new UI delivered through the web browser. This was branded as Microsoft Dynamics 365 for Finance and Operations with an additional version more heavily customised to retail businesses branded as Microsoft Dynamics 365 for Retail.

Dynamics 365 for Finance and Operations consists of a collection of connected subsystems such as Catalog Management, Pricing, Promotions etc. It also includes an integrated PIM (Product Information Management) system.

Dedicated channels will typically be set up for offline retail and online stores. An abstraction of data relevant for the channel will be configured to be published via the “Real Time Service” to relevant channel databases.


At this point, it is important that we understand the Retail Server component from D365 for Retail at a high level.

Retail Server

Retail Server provides a set of services exposed via an API with encapsulated business logic for E-Commerce and Point of Sale (POS) clients. It is through these services with which we can build a unified commerce solution with Episerver.


While the Odata Web API layer exposes the services, the Commerce Runtime (CRT) is responsible for executing the channels business logic as per the configuration of that instance of D365 for Retail.

Data created by customers in the retail online channel are stored in the Dynamics Channel database using Dynamics Retail Server. Real-Time Service then imports them back into the headquarter database.

Delivering Unified Commerce with Episerver

To make this integration work there are two fundamental things we need to accomplish:

  • Synchronize the Product Catalog between D365 for Retail and Episerver to up to date product data is displayed on the E-Commerce site
  • D365 for Retail integrated Shopping Experience


Product Catalog Synchronization

The Avensia Storefront Connector is a licensed product which is an integration engine that integrates D365 for Retail with Episerver making features configured in D365 available in Episerver. Avensia also provides a Storefront starter site which can be set up to provide an e-commerce shop connected to a channel in the D365 for Finance & Operations demo environment.

Storefront comes with two core scheduled jobs. The staging job manages the fetching of category and product information from the Retail channel and staging it in a database. The second jobs manage the importing of this data into the Episerver Commerce product catalogue maintaining any hierarchical category, product and variant information.

Shopping Experience

Retail Server is called directly from the Episerver Commerce site pages to manage the cart and checkout process ensuring that all calculations are driven by the data and configuration set up in the channel database.

When a customer navigates to the product page we query Retail Server directly for pricing and stock real-time calculations.

As customers add products to their shopping cart, price and discounts are calculated with the cart being managed by Dynamics business logic. Dynamics is then used for all calculations as the customer progresses through the checkout flow setting delivery methods, payment methods and creating the order.

Data in order confirmation pages and emails would subsequently be pulled from the Order History Retail Server service.


EPiServer Commerce with Avensia Storefront provides the perfect platform to provide a fully integrated Unified Commerce solution on D365.

The power of EPiServer and additional products such as Perform, Campaign, Social and Insight can give brand managers the power to maximise the impact increasing revenues significantly when used properly.

Choosing between Umbraco and EPiServer CMS

EPiServer and Umbraco are excellent .Net CMS platforms.

EPiServer is an enterprise level fully licensed product while Umbraco is an open source option driven by a passionate community of developers.

If you are choosing between these two options, there are a number of factors that you should consider and I want to touch on these without delving too deep into any particular topic.

Both EPiServer and Umbraco come with MVC versions which provide full control of rendered markup. They also support standard CMS features such as publishing pipelines, versioning, personalisation, reusable content blocks and forms. The extent to which these features are polished and customisable varies but the fact is that they are supported by both platforms.

So what are the major factors to consider when choosing between these platforms?


This is obvious so let’s get it out of the way first.

EPiServer is a very polished enterprise level CMS with a price tag to match. If your client does not have a budget to match the investment required, it is better to look at open source options and this is where you will invariably turn to Umbraco.

Admin UI

Think about the user personas who will be editing and approving content. How technology savvy are they and how intuitive will they expect the editing and administrative interface to be.

The UI of EPiServer provides the content editor with inline page editing. Would such an intuitive feature be viewed as a big win for your target audience?

What are the functional requirements for administration and how much customisation is required? Is there a requirement for advanced content approval workflows? Will the administrator need a strong level of control over the execution of scheduled tasks for example?

The UI of Umbraco is very functional and can be customised through custom page properties. However, it is not as customizable or polished as the EPiServer UI.


Personalisation provides the ability to personalise the content being served to particular users. It is a very powerful marketing tool when used to its potential.

CMS’s administrators can define sets of attributes that a user must fulfil to belong to a particular group of visitors and thus be served personalised content. The possibilities for defining this criterion are endless. It could be related to the profile of the user by attributes such as age or location. It could also be defined by external factors such as the day of the week, time of day or weather if we get more advanced.

There is a Personalisation Groups package for Umbraco which comes with a number of criteria you can use.

However, EPiServer is more powerful in the personalisation space and for me, this is where it starts to stand out from open source competitors. Personalisation comes out of the box and there is an impressive array of criteria included which allows you to create visitor groups for anything from number of site visits to the referrer or search key words.

The interface for defining visitor groups and ability to in page edit the configuration on a given page provide a very intuitive experience for editors.

EPiServer also has a simple programming interface so developers can quickly create custom criteria.

EPiServer is the clear winner on this feature. The question is that if an advanced level of personalisation is a pivotal requirement or if it may be in the future.


Is e-Commerce either a requirement now or will it be in the future? If so, what scale of commerce do you need to plan for?

Umbraco has a number of both paid and licensed e-Commerce packages with Merchello being an open source option I have experience with. While there is an initial learning curve from a developer perspective, it does a solid job at providing single market e-Commerce capabilities. It also provides a nice interface for catalogue, customer and sales management. If you need a CMS application with basic commerce, I do recommend checking out the Umbraco and Merchello combination.

EPiServer Commerce is an enterprise commerce add-on and a whole different beast. By enterprise commerce, I mean that it has the power to cope with multi-market solutions where each market is customisable in terms of products, pricing, warehouse integration,  ERP integrations, sales, payment providers, tax and all the complexities this level of solution brings to the table.

In essence, these options are competing at totally different sides of the commerce market and it should be quite obvious which end of the market the solution you are scoping is veering to as you delve into your business requirements.

Systems integration

Neither Umbraco or EPiServer come with integrated analytics or CRM. This, in my opinion, is a good thing because I want the flexibility to use the best solutions out there for my requirement rather than use a half-baked implementation that comes bundled with a CMS.

Both products have connectors which are sometimes free and sometimes licensed to connect to your platform of choice. Although it is possible to develop your integrations on both platforms, using to a suitable connector can drastically reduce the cost of development.

If there are custom implementations required on an internal system such as an ERP, the EPiServer service API is developer friendly providing the tools do this efficiently. The Umbraco API is not as powerful so there will be more leg work for the development team which can impact project costs.


Both CMS’s have single site multi-lingual localisation capabilities.

EPiServer has very strong localisation support and does not add significantly to the development cost. It’s UI is very clean ensuring that it can be very easily managed by an administrator. On certain projects, this can be a very real cost saver.

If localisation is not a core requirement, Umbraco may well be sufficient. It does require more developer work and does not have the intuitive UI of EPiserver but it may be enough.


Think about the roadmap of the application after initial build. How often do you expect there to be maintenance and future development phases carried out?

Largely the deployment process will be quite standard but they do differ on CMS templates. The object which defines a CMS template is called a “document type” in Umbraco and a “content type” in EPiServer but they are the same concept.

Umbraco requires an administrator to manually set up and configure “document types” in the admin UI each time new or updated templates are deployed. This get’s inefficient as you deploy to stage, UAT and live environments. More importantly it adds the inevitability of human error.

EPiServer on the other hand allows the developer to set up “content types” programmatically. As code is deployed, new or updated templates will be automatically configured.

Limiting configuration and user error associated with deployment could be a minor win or it could be a game changer. This really depends on the complexity of the project at hand.

Developer Support

Although Umbraco is a free CMS option, you need to sign up to a subscription if you want developer support from the Umbraco team. Before you buy a subscription, consider that there is a large and very active community of developers who will often be able to provide assistance in resolving issues.

As you would expect with a licensed product, EPiServer provides developer support through it’s service desk and from my experience reasonably fast turn around times.

So which is better?

Both are excellent platforms.

The question is which is better for your client and the project at hand.

Strive to choose the right tool for the right job by assessing the information above and you will be on the right path.

8 Web Security Standards for every .Net MVC web application

Security is a beast! As a bare minimum, we need to ensure our applications meet industry best practices when released into the wild.

The vast majority of attacks seek to exploit common vulnerabilities so by implementing basic standards we can dramatically reduce risk.

Reviewing the 8 practices below are a great start when assessing the security of your coding practices.

1. Always use an ORM

SQL injection, the injection of untrusted SQL into the database via a query inputted to the application, is still one of the most common vulnerabilities on the web today. The fact this most basic type of attack is still prevalent points to the volume of poorly designed and implemented applications on the web today.

Protecting yourself against SQL Injection is easy and can be done in numerous ways by simply ensuring that data inputted to your application is never directly injected at database level.

Parameterised stored procedures with input validated against a whitelist is an acceptable approach as long as the developer does not concatenate strings within the SP.

However, the best way to protect your application is to use an ORM every time you are querying or writing to the database. There are numerous options for .Net ORM’s with the Entity Framework being the most popular choice but it really is a personal preference.

2. Using Get and Post attributes correctly

Get data is appended to the query string and available publicly while Post data is passed to the server as part of the request body.

Action methods should be decorated with the appropriate Get or Post attribute.

Get should be used when a call is made to a controller function that retrieves data to load a page.

 public ActionResult Index(string username)
 // ... etc

Any controller function that accepts and processes data should have the Post attribute.

 public ActionResult Delete(string username)
 // ... etc

3. Anti-Forgery Tokens

When the server is processing a request, it should validate that the source of the request to confirm that the user is not the subject of a Cross-Site Request Forgery (CSRF) attack.

MVC provides antiforgery token helpers to that gives you a means to detect and block CSRF attacks through putting a hidden field in the form and then checking that the correct value was submitted on the server side.

To use this first place an HTML.AntiForgeryToken() helper in the form

@using (Html.BeginForm()) {


  <!-- Rest of code here -->

This will output a token in the HTML and also give the visitor a corresponding cookie.

Next we need to validate that incoming post at the target action method.

To do this we just need to add the ValidateAntiForgeryToken attribute to the action method.

public ViewResult SubmitPasswordChangeUpdate()
 // add code here

As a standard all form requests should be validated with anti-forgery tokens. Otherwise you have opened a vulnerability in your application.

4. SSL

SSL will ensure that personal information going up the line is encrypted in the request body.

Ensure your site has a valid SSL certificate. Then force any pages that either retrieve or send personal information from http to https .

Use the .Net RequiresHttps action filter by applying the attribute where required as follows:

public ActionResult SignIn()
    return View();

Or why not apply the filter globally to force all pages to Https.

protected void Application_Start()
    GlobalFilters.Filters.Add(new RequireHttpsAttribute());

    // rest of code here

5. Cachable SSL Pages

Any pages that are forced onto HTTPS and contains sensitive data should disable caching. Add “Cache-Control: no-cache, no-store, must-revalidate” to the response headers.

This can be achieved in .Net by setting specific response values. Do this by creating a custom action filter attribute as demonstrated here:

public class NoCacheAttribute : ActionFilterAttribute
   public override void OnResultExecuting(ResultExecutingContext filterContext)
      if (filterContext == null)
throw new ArgumentNullException(filterContext);
var cache = GetCache(filterContext);
protected virtual HttpCachePolicyBase GetCache(ResultExecutingContext filterContext)
      return filterContext.HttpContext.Response.Cache;

6. Password Storage

Ensure you have a strong password policy implemented. As an absolute minimum your policy should insist on 7 character comprising of lowercase, uppercase, numeric and special characters.

You can do that by setting membership provider attributes in the web.config or by configuring the provider to use a regular expression to validate passwords as in this example.

     <providers add passwordStrengthRegularExpression= "^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$" ...></providers>

Passwords stored in the database should be hashed using a salt. Better yet you could move to a more robust hashing algorithm than .Net’s standard SHA1.

7. Error Handling and Custom Error Pages

It is imperative that we never give away information to a potential threat about the internal workings of our system.

If a visitor can generate an error message like below it is technically poor and not a good user experience.

All unhandled exceptions should be redirected to a custom error page that only contains a friendly generic message (i.e. message that does not reveal any information nor the type of error that occurred).

This can also be set in the web.config like below:

 <customErrors mode="RemoteOnly" defaultRedirect="Error">
 <error statusCode="404" redirect="Error"" >

8 Secure Cookie

These days we live a large amount of our lives online and how do websites know who we are? Through cookies of course!

If there is an XSS vulnerability on the site, a malicious user could inject some JS that could modify cookies on page load or worse still, send the cookies to a remote server! If somebody has your browser cookies they essentially have your identity for that website.

A HTTP only cookie tell’s the browser that this cookie should only be accessed by the server. Any attempt to access the cookie from a client script will be forbidden.

You can add the following line to your application which will set the HttpOnly header on cookies for your application:

<httpCookies httpOnlyCookies="true">

HttpOnly cookies don’t make you immune from XSS attacks but they do raise the bar