In this tutorial, I will give a quick whistlestop guide on two things. First, how to debug production issues that occur on Episerver DXP. The second part will cover some general good practice tips that you can adopt to prevent serious issues occurring within your website.

When it comes to DXP, the first thing you will need to do is get access to the Paas Portal. If you do not have access you will need to get in contact with Episerver support, here When you have access to the PAAS portal, you will have access to a tab called 'troubleshooting'. When a production error crops up, this is usually the first place you should check. Within the PAAS portal, you will have access to several useful tools. If you have website issues then your first port of call should be the error log stream.

View Episerver Logs

The log stream will show you errors that occur in real-time. You can also generate historic logs. In order to get error and logs to display within the stram you need to ensure that you use the Episerver log manager in code, like this:

Other useful features within the PAAS portal is the ability to purge the Cloudflare CDN cache and also perform an IIS reset. Out-of-the-box these three features are the only things that will be available to you to get your website up and running again.

You will also have access to the application insights dashboard. This should be acceptable via the Azure portal. The insights dashboard is something that should be created by Episerver when the DXP site is set-up. Another thing to be mindful of is that you may not get an instant response from the Episerver support desk when an issue occurs. Often an issue that someone in your organization thinks is critical, may take an Episerver support technician several hours to look into.

Lastly, if you are thinking then you will simply roll-back code or fix-forward and quickly push a fix from development into production then be aware this process takes time. Pushing code up from integration, onto pre-prod, and then finally onto production takes around an hour. If you have some critical bit of functionality that is not working and you can not quickly push new code into production to fix it, and, you may not have instant access to a support technician to help you then you need to write defensive code whenever you add new features.

For this reason, whenever I build a website on DXP I make heavy use of feature-flags. This is the key to sorting production issues. Having the ability to turn features on and off from within the CMS is critical when things go wrong. These feature-flags obviously need to be enabled/disabled without doing a release. This rules out adding feature flags via config. Instead, you will need to add feature-flags inside of the CMS, either in a settings page or block. An example of how a feature flag looks in code can be seen below:

Another thing to note when using DXP is that whatever is created on integration is the thing that gets copied to PreProd and Prod. When using DXP, remember to leverage config transforms. You can create three different config transforms for each environment. Create three config files named:

  • web.integration.config
  • web.preprod.config
  • web.prodution.config

You will need to ensure that all the transforms and made on integration though. You will not be able to run different variables or apply different transforms after pushing code from int to pre-prod and pre-prod to prod.