Sitecore Experience Commerce – XC9 – First Look and Feel

Sitecore released their much awaited module – Sitecore Experience Commerce (or XC9 in short) in late January 2018. As an avid Sitecore enthusiast, I was eager to learn more about it. On a free weekend, I decided to install and play with it. This blog is about the first look and feel about the XC9 module and only explores very high level features. The detailed documentation about the module can be found at the official site.

The Storefront

Once the installation is complete, the modules comes with an sample store called the Storefront.

The home page comes with featured carousel and product list components (SXA based)

Clicking on any of the top menu items (for example Appliances) will present the list of products with filtering and sorting options:

Clicking on an individual item will take the user through to the product details page, where the user can add the product in their shopping cart:

The Checkout Process

The checkout process is very user friendly and can be compared with any top of the line commerce stores. For example if the user decides to add a laptop and click on the ‘View Cart‘ link from the top right, the user will be shown the summary of cart:

The user can either click ‘checkout‘ or click ‘continue shopping great products‘. If the user decides to click the ‘checkout‘ button, the next screen asks for delivery details to calculate additional shipping charges:

The user can check ‘Ground’ option and click ‘Continue to billing’. The next screen asks for ‘Billing’ details and also includes shipping charges:

Before the user can continue,  the user must validate credit card details. At the moment, the system is configured to use Braintree sandbox account. The user can enter any of the test credit card details available from the Braintree website and click ‘Validate Payment’:

Once the credit card has been validated, the user can proceed to the final review screen before hitting ‘Confirm Order‘ button:

The final screen will show order confirmation number:

That was an amazing experience for buying a product and as a user, I am very much impressed!

The Business Tools

So that was the customer experience, now lets see what is there in the for the back office administrators. After installing the XC9 module a new icon as ‘Business Tools’ should be available for admin users from the Sitecore Experience Platform dashboard.

The Business Tool dashboard comes with 7 sub-modules to manage the store.

  • Merchandising
  • Inventory
  • Pricing
  • Promotions
  • Orders
  • Customers
  • Relationship Definitions

Since the user has just made a purchased, lets checkout what is in the ‘Order’ module

Clicking on the ‘Order’ link from the dashboard or side link, the admin user can see one order is in the ‘Pending’ state:

Clicking on the pending order link, the admin user can see the details about the order:

This out of the box back office processing system for admin users looks amazing as they can instantly see all the order summaries and details. I will pause the exploring rest of the commerce modules as they require much more detail and perhaps another blog.

The Storefront Content Tree

The Storefront content tree is based upon conventions and structure introduced by SXA module. The SXA modules comes with 80+ components for speeding up the development process.

A new set of commerce components are added in the SXA toolbox library.

All of the pages in the Storefront are developed using SXA or Commerce-SXA components.


As you can see, Sitecore Experience Commerce 9 is a very rich and extensive module for developing an online store. In this blog, I have only scratched the surface of the module and I am super excited about it. The 40+ commerce SXA components, the 7 back office processing modules, and additional 80+ standard SXA components for rapid website development, all together deliver a knockout punch in the online commerce industry

In my opinion, Sitecore XC9 module will definitely meet the expectations of any business looking for a modern, cloud-ready and secure online store. So, if you manage an online store and looking for replacement options, do evaluate  Sitecore Experience Commerce out before making any decisions.




SXA Rendering Variants – The Hidden Gem of Sitecore Experience Accelerator (SXA)

Sitecore Experience Accelerator  (SXA) is a great productivity tool as it reduces your development time by giving you pre-built components. There were few new concepts and features that were also introduced with SXA like Page design and Partial design, pluggable themes, grid and column layout etc, but as the topic suggest, I will be focusing upon “Rendering Variant” concept and will try to explain how can this change the way you architect your website (assuming that is based on SXA).

Problem Statement

Let’s begin with a problem statement, the UX team have prepared a landing page and they have the various content components on the page displaying Image, Rich Text and Link all in a box but in various styles as below:

  1. Half-width component with Image and Text
  2. Half-width component with Image, Text and Link
  3. Full-width component with Image on Left, Text and Link on Right
  4. Full-width component with Image on Right, Text and Link on Left

They also want the content authors to have the ability to add them, remove them and order them in any way they like.

Sounds familiar ?

If I am not using SXA module, one of the approach would be to make these different components available via Experience Editor which content editor can add/remove/order from the content page. This means that there will be different “View Renderings” for each of the components types. Different view rendering mean different Data Source Templates and Data Folder Templates. So for the simple content based components above, we end up having 4 different view renderings, which more or less have same content but it is displayed differently.

SXA Approach


There is nothing wrong with the above approach, but if you website is based on SXA module you would have another tool to  meet your goal in a more effective manner.

The SXA provides a feature called Rendering Variant which optimizes the process of showing different variations of the same component. The variations can be setup via content editor and can also be supplemented with predefined styles and scripts.

The best way to explain Rendering Variants is by an example. I will be using the out of the box “Promo” component that comes with SXA. I am only interested in 3 data fields PromoText, PromoIcon and PromoLink (there are other properties too, but let’s keep it simple)

Promo Data Template

Rendering Variants are located under the /Site/Presentation/Rendering Variants node. In my case, the location was:

/sitecore/content/Tenant Folder/Tenant 1/Site 1/Presentation/Rendering Variants/Promo

Out of the box there was one rendering variant already present as ‘Default’.

Default rendering variant

I made a copy of that component and called it ‘Promo with Image and Text’

Promo with Image and Text rendering variant definition

I then deleted last child item ‘Promo Link’ from the recently created rendering variant and clicked save. The ‘Default’ rendering variant was renamed to  ‘Promo with Image Text and Link’ for readability purposes. And just by doing these few content item operations, I was able to achieve my 2 component variations (under like 1 minute, thanks to SXA)

To verify my changes I tested them out in experience editor. First I added a column splitter component to divide the page into 2 equal halves, then I  uploaded some stock images, added the Promo component from the Toolbox in each of the half , added random text and selected my variants via the dropdown. They worked like a charm!

Promo with Image and Text, Promo with Image, Text and Link

Similarly, I created a copy of the existing variants and called it “Promo with Image left” . I then added a ‘Section’ item for the variant definition and called it ‘Container’. I then moved “Promo Icon” under it. I also added the bootstrap class of ‘col-xs-6’ to ‘Container’ item and to the ‘Promo Text’ item.

Section item surrounding PromoIcon field in rendering variant definition

As you can see in the screen shot above, there are other types of variant definition items as well, check them out from the official site and see how flexible they are to give you almost any kind of rendering variation that you like.

For “Promo with Image Right” I created a copy of the “Promo with Image Left” and just reversed the order ‘Promo Text’ and ‘Container’ sections:

Image Left and Image Right rendering variant definitions

To verify my changes, I navigated to the Experience Editor, dropped the ‘Promo’ component on the page and changed its rendering variant via the dropdown to get the results below:

Promo component with Image Left

Promo component with Image Right

And that’s it, without even writing a single line of code, I was able to get all 4 component variations. In theory the number of variations that could be achieved using rendering variants are unlimited and totally depend upon your UX and Design.


If you are starting a new website based upon SXA module, you must consider rendering variants for your components as it will change the way you architect the website. This was a simple post but it showed the true power of SXA and how Rendering Variants can reduce back-end development efforts and also improve the content authoring experience. Kudos to SXA development team for this awesome feature!

Have fun

Note: If you want to play around with the, here is the link to the rendering variant package. I have used Sitecore 8.2 update 5 and SXA 1.5.


Sitecore 9 was announced at the recently held Sitecore Symposium 2017 and it comes with lots of new features and improvements. One of the major change to the platform is the way you install Sitecore on a server or local machine. The standard .exe installer has been replaced with a Windows PowerShell module which is called Sitecore Installation Framework (SIF). The SIF comes with Sitecore related pre-built tasks and configuration files to facilitate installation of Sitecore.

As a Sitecore enthusiast, I wanted to get my hands dirty with this new SIF module. After reading the official guide, I found out there were few pre-requites that were required even before running the SIF module. The 2 main ones were SQL Server 2016 and SOLR 6.6.1. In addition, the Solr instance must be running over https to make sure all the communication is secured.

The details of the installation process is given in the official guide but I will just mention few high level steps for local install:

Step 1: Configure and Install SOLR

So lets install Solr, sounds easy as I have done it few times before and I am sure you would have too. However, installing the secure certificate was bit tricky on localhost, but thanks to the Sitecore community, this SSL script from Kam’s blog worked like a charm and I had Solr 6.6.1 running over https in no time.

Step 2: Install SQL Server 2016

I had multiple versions of SQL Server (2012,2014) running side by side on my machine and installation of SQL Server 2016 Express wasn’t a problem as well. I ran the standard SQL Server 2016 installer and it was installed as expected (or I thought so).

Step 3 : Install Sitecore via SIF

As per the installation guide, I registered the SIF module via PowerShell and ran the following script: (I just added -Verbose at the end of each command so I can see the debug information during install)

I was expecting it to install Sitecore 9, but after the first run I got this error:

The error suggested that I have to install additional SQL server modules for Web Deploy to work, as given on the Microsoft’s website



The group of 3 errors listed above share the following diagnosis and resolution:

Diagnosis: SQL DAC and its dependencies are not installed.

Resolution: Use Web Platform Installer to install:

  1. Microsoft SQL Server 2012 Data-Tier Application Framework
  2. SQL Server 2012 Transact-SQL ScriptDom
  3. SQL Server System CLR Types 11.0

I installed the above dependencies and ran the script. It failed again with the same error message.

I was sure that my SQL server installation is correct and I have installed module related to ScriptDom but what is wrong with Web Deploy ?

Then I found this article on Sitecore KB for Sitecore Azure Toolkit 1.1 which mentioned to add registry values for the Web Deploy for DAC dependencies path.

I was bit skeptical at first but decided to go ahead with this approach. I added the 2 registry values via regedit. For one of the values, I have to point the path to the recently installed SQL Server 2016 SDK folder. For the second registry value, I have to point the path towards VS 2015 DAC folder. I do want to mention here I also had multiple versions of VS (2013, 2015 and 2017) installed on my local machine.

The registry values were:

DacFxDependenciesPath : C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies

DacFxPath : C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130

The actual screen shot of the registry values for Web Deploy:

Ran the script again and BOOM! it worked.

So it turns out since I had multiple version of SQL servers and also multiple versions of VS installed on my local machine, the Web Deploy 3.6 was not able to figure out what is the path for the SQL dependency dlls to install the SQL DAC packages for Sitecore 9.

By the way, if you are installing Sitecore 9 for the first time,  Do check out the following posts:
How to Install Sitecore 9 with the Sitecore Install Framework 
Gotchas while installing Sitecore 9 using the Sitecore installation framework

The lazy developer’s way to install Sitecore 9
Introducing SIF-less for Easy Sitecore 9 Installation
Low-effort SOLR Installs 

I hope this blog will help any other developer facing the same error.

Happy Sitecoring 🙂

Sitecore Ship not working with 8.2-update-1 or failing silently

Back in May 2017, we started working an new and exciting project with Sitecore version 8.2 update-3. I was setting up the continuous integration/auto deployment for the project. Once CI/CD was setup as described in my previous blog posts I encountered the issue that Sitecore Ship module, which is responsible for synchronizing the Sitecore content items, was not working as expected. It was showing a 200 OK response in the Team City logs but in reality it was failing silently.

Doing a quick google about the issue I found at that I am not the only one having the issue, there are other people who are experiencing the same issue as well. I also came across this blog by another Sitecore developer who was facing exactly the same issue and he decided to switch to TDS package deployer instead of Sitecore Ship.

I haven’t personally tried out the TDS Sitecore package deployer before and looking at the blog post decided to take this approach. It was fairly easy to configure package deployer and after adjusting some of the Team City build steps, the .update package deployment started working!!

After testing package deployer with the continuous integration setup for few days, I realized that although the build process is copying across the .update files, there is no feedback from the package deployer (or a 200 OK response) that package has been installed successfully. In order to confirm, I have to RDP or FTP to the server and  check that .update files have been correctly installed or if they have failed for any reason.

So back to square 1, let’s figure out what is wrong with Sitecore Ship ?

Looking at the open issues list of the Sitecore Ship GitHub repository, I saw people reporting similar issues where Sitecore Ship was failing silently or not working on Azure Deployments.

Interestingly, there was also a pull request #69 submitted to fix this issue with 8.2 update-2 in Jan 2017 which had some really positive feedback.  As of today, this pull request has not been merged to the main repository or available via NuGet gallery.

In my case, the project was on 8.2 update-3 (one update higher than the submitted pull request version), and it wasn’t a straight forward fix. I was skeptical but I decided to repeat what has been done in pull request #69 and compile it against 8.2 update-3 version of the Sitecore and try it out.

This is what I did to get my fix:

1-Cloned the GitHub repository locally

2-Updated the solution’s .NET version to 4.5.2

3-Updated the Sitecore NuGet package version to 8.2 update 3

4-Modified the code for Sitecore.Ship.Update.UpdatePackageRunner class as mentioned in the comment section (and below)

5-Build and compiled the code and then replaced the dlls in the bin folder on QA server.

6-Ran the Team City build server script again and it worked like MAGIC!

The underlying issue, as mentioned in one of the comments ,was that there has been some updates to the Sitecore.Update.dll and the code that was responsible for deploying the items was not working any more. Also the solution’s target .NET version has to be upgraded to 4.5.2.

I believe that the pull request will be tested and merged into the main repository soon so everything is available via standard NuGet packages. However if have read till here and using either 8.2 update 3 or update 5 for your CI/CD setup, you can download the compiled dlls from my dropbox and give it a go!

For 8.2 udpate-4 you either wait for the NuGet package or do what I mentioned above.

Happy Sitecoring 🙂



Getting Started with Sitecore and Microsoft Azure Apps – Part 2 – Deploying through ARM templates

In previous blog, I have shown one-click deployment of Sitecore on Microsoft Azure. In this blog, we will explore the topics of Azure Resource Management (ARM) templates and Sitecore Azure Toolkit to do our Microsoft Azure deployments.

Before we begin!

What are ARM templates anyway ?

If you have not heard about them before, you are not the only one.

Simply put, they are JSON files where you can define the structure and configuration values (just like web.config file but in json format) of what you want to deploy. For more information about ARM templates, please visit Microsoft documentation.

Sitecore Azure Toolkit streamlines your Microsoft Azure deployments using ARM templates and gives you out of the box integrations for Microsoft Application Insights, Microsoft Azure Redis Cache and Microsoft Azure Search. This toolkit is a great starting point if you are at beginner level.


In order to do Sitecore deployments, there are some prerequisites that you will need to install on your machine as mentioned in the documentation.

As of today, you will need the following tools and packages:

Once you have installed the tools and downloaded pre-built Web Deploy packages, you can follow the step by step guide below and do a Sitecore Azure PaaS deployment for XP1 configuration:

Step 1: Upload Web Deploy packages

The first step will be to upload the Web Deploy packages at a location which can be accessed over the internet during our installation process. Microsoft Azure provides storage accounts to store any kind of data that can be accessed over internet. Create a new storage account within the Azure portal using this guide  and then upload the individual server role packages. I am using Sitecore 8.2 up-3 and for XP1 configurations so I have uploaded the following packages:

  • Sitecore 8.2 rev.
  • Sitecore 8.2 rev.
  • Sitecore 8.2 rev.
  • Sitecore 8.2 rev.

Once you have uploaded the packages, open ‘Microsoft Azure Storage Explorer’ and connect to your account. Generate a shared access signature URL for each of the packages and note it down for later use as shown below:


For example, one of the shared access URL will look like this

At the end, you should have 4 web deploy packages URL.

Step 2: Setup MongoDB collections for analytics

The next step will be to setup MongoDB for the deployment. You can either provision a new VM through Microsoft Azure and install MongoDB and then create your databases or you can use 500 MB of FREE MongoDB storage provided by

If you have never used mlab for Sitecore before, please follow this guide  by Sitecore MVP David Peterson to create 4 individual MongoDB for your site. 

Step 3: Update azure.parameters.json

Once you have noted down shared access URLs for web deploy packages and also got connection strings for MongoDBs, the next task is to update the azure.parameters.json file.

Assuming that you have downloaded the Sitecore Azure Quick Start ARM templates from GitHub , navigate to the ‘xp’ folder and update the azure.parameters.json file with the parameters that you have recorded earlier.

You can leave licenseXml value as blank as it will be passed through the command line.

Step 4: Setup Sitecore Azure Toolkit folder

I downloaded the Sitecore Azure Toolkit zip package and copied to a location C:\azure\sitecore-azure on my local machine. Then I copied the Sitecore license file and the ‘xp‘ folder that I modified in the previous step in the same folder location. This will make sure that I do not make any path related errors while I am running the PowerShell commands

Step 5: Run PowerShell Commands

Okay, the moment of truth has arrived.

Open PowerShell in administrative mode and navigate to the Sitecore Azure Toolkit folder. In my case it will be ‘C:\azure\sitecore-azure‘ and then run the following 2 commands to setup PowerShell:

  • Add-AzureRMAccount – this will show a pop-up to login to your Azure account
  • Import-Module .\tools\Sitecore.Cloud.Cmdlets.psm1 -verbose – this will load the Sitecore specific Azure commands into the session.


Now we are ready to provision our environment with just one command. If you have followed the steps as above and have entered values in your parameters.json, just entered the following command:

Start-SitecoreAzureDeployment -location ‘East US’ -Name ‘SitecoreAzureXP1DeploymentMay2017’ -ArmTemplatePath ‘.\xp\azuredeploy.json’ -ArmParametersPath ‘.\xp\azuredeploy.parameters.json’ -LicenseXmlPath ‘.\license.xml’ -SetKeyValue @{}

This will show a message that deployment has started:

Then you can go and make yourself a cup of coffee as you have to wait for another 15-20 minutes before the deployment will be completed and you see a success message.

Navigate to to your dashboard portal and you should see all of your services running for the deployment!



I think the topic is complicated enough and a simple video can give a better overview:



Overview of XP1 Architecture

When you deploy Sitecore with XP1 configuration using quick start templates and Sitecore Azure Toolkit, you get the following services:

  • CM App Service Plan & CM Web App
  • CD App Service Plan & CD Web App
  • Reporting App Service Plan & Reporting Web App
  • Processing App Service Plan & Processing Web App
  • SQL Server with Core, Master and Reporting DB
  • SQL Server with Web DB
  • Application Insights (used for logging exceptions and much more)
  • Azure Search
  • Redis Cache

In order to understand it better, you can see the following topology diagram.


That’s it, Sitecore Azure Toolkit really makes it easy to do customized your Microsoft Azure PaaS deployments. It is a great tool and you should really check it out!




Getting Started with Sitecore and Microst Azure Apps – Part 1 – One-Click Azure PaaS Deployment

Sitecore Web Content Management System (WCMS) has recently release a version which supports deploying Sitecore WCMS as Platform as a Service (PaaS). As a passionate Sitecore technologist, this is great news and I am pretty excited about it.

Pieter Brinkman from Sitecore has done a great job explaining the benefits of using Microsoft Azure Web Apps and I think in few years from now, everyone will be using Microsoft Azure as their preferred hosting option.

In this post, I will post a short video screen cast of showing how easy it is to take advantage of this new offering from Sitecore and get an instance of Sitecore up and running in few minutes.

So if you never looked into Microsoft Azure web apps or didn’t get time to do it yourself, this video is for you.


Once the deployment is finished, you will see the following services within the resource group:

  • CM App Service Plan & CM Web App
  • CD App Service Plan & CD Web App
  • SQL Server with Core and Master DB
  • SQL Server with Web DB
  • Application Insights (used for logging exceptions and much more)
  • Azure Search
  • Redis Cache

In technical Sitecore terms, this is called XM1 configuration, where Sitecore is deployed in CMS-only mode. You can use this deployment if you are not planning to use analytics and marketing features of Sitecore. An overview of this deployment topology is shown below:

In the next post, I will show how can we use ARM Templates, Sitecore Azure Toolkit and PowerShell to do Sitecore deployments on Microsoft Azure. The ARM templates provides more flexibility and control over the deployment topology.

Stay tuned.



Sitecore DevOp Series – Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

This is last part of the Sitecore DevOp series. Previously, we have installed a local instance of the Sitecore site, configured VS project, configured TDS, configured Sitecore Glass added our project to source control , congured DB and QA servers and configured CI server. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

There are 2 processes that you need to track during the build:

  • Code submissions (check-ins)
  • CI build events (start/stop/failures)

By default, we can use emails as notifications whenever CI server triggers a build or when source control detects a check-in, but in my opinion, this is not the most effective way. Depending upon your team size, there may be many check-ins every day, and many CI builds. If you start getting hundreds of emails everyday, you will simply create a rule/folder where all such emails will be directed and forgotten.

Also, not all of your team members will receive such notifications emails and you still have to send a ‘pre deployment’ email to notify team and ‘post deployment’  email to confirm that deployment has ended.

If you are a team lead or QA or PM, I am sure you would have asked or heard questions like these:

‘When are we deploying latest build on QA?’

‘Is our latest build finished on QA?’

‘What all did we deploy? 

… and so on.

There are better communication tools out there like Slack or HipChat. You can integrate either of them or another messaging tool of your choice. Personally, I like Slack and will be discussing how to integrate Slack with our TeamCity server and BitBucket project in this blog post.

Step 1: Create a Slack Channel

If you don’t have a Slack account, create a free one. Then create a free Slack channel for your project, invite all team members and also create 2 open public channels for incoming notifications:

  • #bitbucket
  • #teamcity


Step 2: Configure TeamCity for Slack Notifications

Navigate to Apps and Integration section and click on the link



Step 3: Generate a webhook for CI server

Within the slack admin interface, search for incoming hooks:


Select ‘Incoming Webhook’ and then select the one of your channel:


Once you click Add Incoming WebHooks integration, it will generate a unique Webhook URL, copy this URL for later.


Step 4: Install a Slack plug-in for TeamCity

Download a TeamCity plug-in for slack notifications and install it as per the instructions on the documentation


There is no admin interface for setting up the incoming hook for the plug-in as of now. So you have to RDP and update a config settings to the relevant web hook

<slackNotifier postSuccessful="true" postFailed="true" postStarted="true">

Once it is installed correctly, for every build start, build finished and build failed you and every team member will get a notification in the channel.  How cool is that 🙂


Step 6: Generate a webhook for BitBucket

Slack is also very friendly with BitBucket source control. Search for a BitBucket integration on Slack and generate a Webhook URL for your #bitbucket channel


Step 7 : Configure Bitbucket

Within your bitbucket admin interface for the project, navigate to settings and add a new webhook for the channel. Copy/paste the URL that was generated.


Once it is done, commit and push some changes, you will start getting notifications in Slack!


So now every time someone in your team is going to do a check-in, you and all your team will get a notification. Install Slack for mobile and desktop and keep tracking those notifications.

With this blog post, we have come to the end of the Sitecore DevOp Series.

Thanks for the reading the blog post and the series, I hope it will benefit the Sitecore community. Any comments feedback will be appreciated.


Updated April 2017

My Talk at DC Sitecore User Group

Short video demo

Updated September 2017

Extending To Helix Principles

The project setup shown in blog series was simple as it was intended for the newer audience and I didn’t want to add complexity of Helix principles. Having said so, if you are starting a new project based upon Helix principles, you can easily extend the automated deployment setup as shown below.

All you have to do is add foundation, feature or project specific TDS projects for content item serialization and add additional steps for TDS projects in the Team City server. More details about deployments using helix principles can be found here


Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket