Sitecore Commerce Series: Exploring Reference Storefront

Storefront Home Page

Sitecore Commerce 8.2.1 comes along with a sample solution which is supposed to be used as a reference:
Sitecore Reference Storefront Powered by Sitecore Commerce

The last update package (Sitecore.Reference.Storefront.Powered.by.SitecoreCommerce.10.2.65.zip) which is part of the Commerce installation package contains the sample web store
Once you install the update package and the two Sitecore packages with the images:

  • Adventure Works Images.zip
  • Sitecore.Commerce.Habitat.Images-1.0.0.zip

you will have the Storefront shop installed on your Sitecore instance.

The source code of the Storefront implementation is available on GitHub: https://github.com/Sitecore/Reference-Storefront
When you are cloning the repository make sure you are using the appropriate release for your Sitecore Commerce version:
https://github.com/Sitecore/Reference-Storefront/releases

You can find two different solution files in the repository:

  • Commerce Engine Storefront Solution

    Commerce.Engine.Storefront.sln – containing the Storefront shop implementation

  • Commerce Server Storefront Solution

    Commerce.Server.Storefront.sln – containing the Storefront shop implementation plus 2 TDS Projects containing
    the definition and content items, part of the Storefront website. If you have installed the Storefront update package you already
    have these items

In this blogpost I will use the first solution: Commerce.Engine.Storefront.sln

The solution consists of 3 different projects:

  1. Commerce Storefront Project

    Commerce.Storefront

    This is the main web project which contains the controllers used for the site components. Other interesting parts of it are the Managers related to the web store features like OrderManager, PricingManager, ShippingManager and others. They give really good examples of the Commerce API which unfortunately is not so well documented.

  2. Common

    While Commerce.Storefront stores the controllers, this project contains mostly the models constructed by the controllers.
    There are some utils helpers, extension methods and other more common managers in the Common project as well.

  3. CommonSettings

    The common settings project, which is a web project as well, focuses on the front-end of the application. It contains the View files, the CSS and JavaScript files.

The Commerce Storefront solution is not structured in the best possible way (even the file structure is misleading) but it gives a really good overview for
the features for Commerce Engine and Commerce Connect module . All the available code examples help developers to get real idea of Sitecore Commerce and its API.
A new version of the Storefront solution will be released together with Sitecore Commerce 9.

Sitecore Commerce Series: Installing Sitecore Commerce 8.2.1

azman

Installing Sitecore Commerce 8.2.1 is not so straight forward and the module isn`t supported by SIM
You can find the documentation here: Sitecore Commerce 8.2.1 Update 2 Deployment Guide but there are many tricky parts and if you don`t follow the instructions strictly or you want to customize your commerce instance you will have troubles. And unfortunately Sitecore Commerce errors are not so descriptive.

In this post I will list the gotchas that I had during the installation process.

  1. Prefix the application pool identity with “.\”

    You must prefix the application pool identity with “.\” for the application pools of the Sitecore instance, Commerce Authoring and Commerce Server services.
    You might not notice this note in the instructions but it is really important!

  2. Exception after installing Sitecore.Reference.Storefront.Powered.by.SitecoreCommerce.10.2.65.update package

    After installing the last update package called Sitecore.Reference.Storefront.Powered.by.SitecoreCommerce.10.2.65.update you will get an exception.
    This is pretty normal as noted in the documentation and most probably you will have to reinstall the package after you update the Commerce Server Profile Schema

  3. The profile web service must have Windows Authentication enabled

    The web service called CFSolutionStorefrontsite_ProfilesWebService (one of the commerce services) must have Windows Authentication enabled.
    Unfortunately this small requirement is not mentioned in the documentation.
    Windows Authentication

  4. If you receive any errors during or after the installation process you should check:

    • If the Commerce Services are up and running:

      • Open http://localhost:1004/CFSolutionStorefrontsite_ProfilesWebService/ProfilesWebService.asmx and confirm it`s up
      • Open http://localhost:1004/CFSolutionStorefrontSite_CatalogWebService/CatalogWebService.asmx and confirm it`s up
    • If the Commerce Authoring service is up and running:

      • Open http://localhost:5000/api/$metadata and verify that you can retrieve metadata
    • If the user CSFndRuntimeUser has Administration role for the commerce services authorization stores:

      • Run azman.msc and open the authorization store xml file located at: “C:\inetpub\wwwroot\CSServices\CFSolutionStorefrontsite_CatalogWebService\CatalogAuthorizationStore.xml”. Verify the user CSFndRuntimeUser has administration privileges
      • Run azman.msc and open the authorization store xml file located at: “C:\inetpub\wwwroot\CSServices\CFSolutionStorefrontsite_ProfilesWebService\ProfilesAuthorizationStore.xml”. Verify the user CSFndRuntimeUser has administration privileges

      azman

  5. Just before you start installing Sitecore Commerce 8.2.1 watch the installation video:

7 MUSTs for building Sitecore experience-editor-ready websites

For some years now the Experience Editor is the recommended way for editing content with Sitecore. It`s intuitive, easy-to-use, and most of the content editors prefer to use it rather than the Content editor which is more often used among the developers.

It`s up to us the Sitecore devs to make content editors` Sitecore experience better and to optimize the process of content entry end edit.
Placeholder settings item

Following the listed guidelines will make our editors` job easier:

  1. Always set meaningful name to your components!

    The names of all components should indicate their purpose. Avoid using pascal or camel case names – they are understandable just for us 🙂

    Bad examples:

    • Product
    • cookieDisclaimer
    • Meta

    Good examples:

    • Page Title
    • Rich Text With Border-Top
    • Page Metadata
    • One Column Container
  2. Don`t miss the Datasource Location and Datasource Template when creating components!

    • Datasource Location specifies where the editor is allowed to look for the data source when using the Experience editor.
    • Datasource Template specifies the types of data sources users can use.

    Both fields are required for building smooth experience for the editors and save them from traversing the entire tree while searching for suitable datasource for a component

  3. Always use placeholder settings!

    For each of the placeholder you define in your code you should create a placeholder settings item under “/sitecore/layout/Placeholder Settings”. Placeholder settings items indicate which components are compatible with your placeholder. Not every component is compatible with a given placeholder so this setting will save your implementation from rendering errors and not expected layout behavior.

    Placeholder settings item

  4. Set a Thumbnail!

    The image in the Thumbnail field is shown in the “Select a Rendering” window when adding a new component to a page. This field usually has an image showing how the component looks like. For that reason, you can use “Take a screenshot” function and directly make a picture of the component on the page. Using that field helps editors to intuitively choose the right component for the current placeholder.

    Thumbnail field

  5. Don`t be afraid of using Rendering Parameters!

    You should use Rendering Parameters to control the way a component shows on the page – to change its shape or layout. If you have a component that needs to support different sizes or background colors for example, Rendering Parameters are the best way to implement it. It`s conceptual mistake to use the datasource item to manage the way a given component looks. The datasource items should only manage the data (the content) while the Rendering Parameters control the presentation.

  6. Use the field title!

    In many cases your template fields` names are prefixed with a namespace or are too short and not so descriptive. In this scenario, you can use the title field of each field to give a really meaningful name which will not confuse the content editors.

  7. Define compatible renderings if there are any!

    The Compatible Renderings field is used to connect two or more components that are compatible in the same placeholders and may have the same datasource type (if the component uses datasource). This feature is widely used for scaffolding components. If a component has compatible renderings set, the editor can switch between them with just s single click.

10 Things You Should Know About Sitecore Upgrades

search

Almost every Sitecore developer needs to perform Sitecore upgrade at some point. Unfortunately, the process is heavy and there are lots of failure points and tricky parts.

In that blog post I will share some of the most important things that I learn while performing Sitecore upgrades.

  1. Do not start without an upgrade assessment and an action plan!

    Sitecore upgrade can take between 20 and 300 (or even more) hours depending on many things like how far is your
    current version from the target version, how many Sitecore customizations are in place,
    how much data is stored in the Analytics database etc. Every single thing matters, so do not start an upgrade before having
    a good action plan.

  2. Upgrade incrementally!

    Always perform Sitecore upgrades incrementally: you should go through every single revision between your starting and your target Sitecore version. Do not try to use shortcuts.

  3. Patch the configuration files!

    Following the Sitecore best practices every single change that you have in the Sitecore section
    of web.config (or Sitecore.config in the later versions)
    should be applied via
    Sitecore Include Files.
    This is good but not every project follows that guide and in some cases the changes are
    applied directly to the web.config which makes your upgrade process a nightmare.
    It`s always better to spend some time on applying the changes under the Sitecore section using patch include files before starting the actual upgrade process!
    Try to keep your web.config (Sitecore.config) as close to the original one as possible.

  4. Always back-up!

    search

    You never know what can go wrong while upgrading Sitecore! You should have this in mind and create a backup of your files and database on every single revision that you go though.
    On top of that keep your backups a certain time after you finish the upgrade process – some problems can appear when the users start to exploit the upgraded system.

  5. Each server counts!

    When upgrading Sitecore you should perform the upgrade steps for each server: CD, CM, DEV, QA, STAGING etc. If you want to reduce the upgrade time you have the option to
    try to make some of the servers equivalent: for example, if you have CD, CM, DEV and QA servers you can try to merge the content of the DEV and QA instances. In this way, your
    QA and DEV instances will be pretty much the same: having the same content. In this scenario, you will need to perform the upgrade for DEV and QA just once.

  6. Check the pipeline processors!

    When customizing Sitecore pipelines always play a main role. If you have custom pipeline processors you should check if they are still compatible. You also may need
    to change the pipeline that you are using to apply your customizations.

  7. Check the search implementation!

    search

    Sitecore offers different search options Lucene, SOLD, Coveo etc. Each of them hides compatibility problems that should be covered prior to starting the actual upgrade process.
    Have in mind that some parts of the Sitecore Content Search API are different for the different Sitecore versions. It`s the case for the search configuration as well.
    In some cases you may need to implement your search functionality from scratch! This should be added to your upgrade estimate, right?

  8. Check third-party services integrations!

    Sometimes Sitecore is just a piece of the whole puzzle. You may have Geo Location, Translation, CRM, eCommerce services integrated with your Sitecore solution.
    Check all of them and especially the Sitecore API each of them uses for integration. You should be able to predict compatibility/integration problems in advance!

  9. What about the modules!?

    Go through every single Sitecore module installed. Some modules need to be upgraded as well, other are deprecated. For instance, Sitecore Social Connected, Language Fallback and
    GeoLocation modules come with Sitecore out of the box for the later versions.
    You even may need to implement a functionally that was covered by a module which is not available for your target version.

  10. Plan content freeze period

    In a perfect case scenario, your content team should stop entering content while you are performing the upgrade. Cool but in many cases this is not possible.
    Imagine a news website to stop showing news for a week or even a month. Not good, right. In this scenario, you should evaluate content migration strategy.
    With some clients manual copy/paste would fit but usually it`s not the case.
    The tool that I use in situations like this is RAZL. RAZL allows side-by-side comparison and merge between two Sitecore instances.
    The two Sitecore instances do not need to have the same Sitecore version so the tool works out perfectly for content migration.

  11. Enjoy!

Hedgehog ist ein Berliner

Hedgehog was invited to participate at the #SUGDE event on 29 September 2016. The only available speaker was me so I started packing my bags.

We took off together with Stefan Ivanov our Business Development Manager. It was the first journey to Berlin for both of us and we were very exited about it! The flight went smoothly and we arrived in the capital early in the morning. Of course we did not miss the opportunity to take a selfie in front of the
Reichstag building

georgi-bilyukov-and-stefan-ivanov-in-berlin

We had some time to walk around and buy souvenirs and presents for our friends. Berlin is a really beautiful city and the time that we had was not enough for me. I will definitely go there again!

We arrived at the #SUGDE event place at about noon where we met Chris Wojciech – one of the #SUGDE organizers and the person who invited us.

After some snacks and of course Sitecore discussions, the event began.

The first session by Sebastian Winter was about Sitecore upgrades. It was a very interesting war story about the upgrade case that he had with the complicated infrastructure of Metro Sebastian shared some good practices that he followed during the upgrade process.

Just after Sebastian it was my turn. The topic of the session was “Continuous Integration and Continuous Delivery ” with our products TDS and Razl.

georgi-bilyukov-sitecore-user-group

Most of the people at the event already were actively using TDS but Razl was pretty much new for them. I went thought TDS new features that came with the latest version and how Razl can be used for moving content between different Sitecore instances.

georgi-bilyukov-sugde

I think that the presentation went well since I received good feedback from the public.

The next presentation was about NitroNetSitecore by Lars Schilling. It was a very interesting session about a new paradigm for building Sitecore components.

Just after, Christopher Huemmer walked us through Sitecore Multisite implementation best practices.

The last session for this #SUGDE event was by Friederike Heinze. She did a recap of the Sitecore Symposium in New Orleans. I did not have a chance to go to the Symposium and I found out that I`ve missed a lot. Next year I will definitely go there. It will be in Las Vegas which makes it even more interesting!

By tradition just after the event we all headed to a German beer house where I tried German homemade beer – the taste was really wonderful.

sugde-beering

There Mark Cassidy received a plushy hedgehog.

stefan-ivanov-giving-hedgehog

On the next day we joined October fest just for a beer

georgi-bilyukov-and-stefan-ivanov-october-fest

Just after, we took off back to Bulgaria full of good impressions and memories!

Sitecore Taglist Field

Recently I had the task to build a Sitecore Content Editor field which will be used for tagging content items.

The requirements for the field were:

  • Easy-to-use
  • Search-friendly (especially when working with large collections of items)
  • Autocomplete support

After certain time spent in research I found a jQuery plugin which pretty much satisfies the requirements: jQuery Chosen

The clients accepted the proposal and I my final task became: Integrate jQuery Chosen into Sitecore Content Editor.

The first thing that I had to do was to include jQuery Chosen source files (JavaScript and CSS) into Sitecore Content Editor.

My original idea was to add the files dynamically while rendering the field itself. Unfortunately this plan failed: The files were added dynamically but I introduced a bug as a side effect: When you click on a content item that has my custom field, the content editor was blinking 2 – 3 times before rendering the fields.

This behavior is unacceptable and I had to switch the strategy.

Then I found a really good blog post by Pavel VellerInjecting Resources into Sitecore Content and Page Editor. This approach was adopted and finally I had the source files included into the content editor without any side effects:

InjectScriptsConfig

The next mission was to write the field`s back-end. I tried to inherit from multilist field but this did not work out well. Finally I used “Sitecore.Web.UI.HtmlControls.Control” as a base class and decided to render the html select element myself. This time the plan succeeded and finally I had everything in place!:

RenderMultilistCode

I don`t like how I have to evaluate HTML/CSS/JavaScript code from the back-end but this is the way to go when building Sitecore Content Editor custom fields.

Now I was almost ready: I had just to add the field in the Core database and register the assembly in the section of Sitecore.config:

CoreDatabase

ControlSourcesConfig

This all story resulted in a multilist-like, good-looking, autocomplete field for Sitecore Content Editor!

The source code is available at GitHub: https://github.com/Bilyukov/SitecoreTaglist
You can find it on Sitecore Marketplace as a module as well:

Enjoy!

Sitecore Publish Status Module

When you work with many items in the Content Editor in Sitecore sometimes it is difficult to track which version of a particular item is published. It becomes even more difficult when you have many languages in the current Sitecore instance.

This problem inspired my colleagues Alex Kamburov, Nikola Gotsev and me to develop a module that simplifies the content editors` work.

Publish Status Module adds a panel in the Publish ribbon of the Content Editor. When you select an item in the Sitecore content tree you can immediately see the current publish status for the English language and also there is a button to see the publish status for all languages.

There are 6 different statuses for an item:
1) Latest is published
2) Not latest revision
3) Not latest version
4) Not published for language
5) Not published to database
6) No publishing targets

 

Publish Status screenshot

 

 

The module supports Sitecore 7.0 and above including Sitecore 8.

 

PublishStatus-80

 
 

You can download the module form Sitecore Marketplace:

https://marketplace.sitecore.net/Modules/Publish_Status.aspx?sc_lang=en

The source of the module can be found at GitHub:

https://github.com/Bilyukov/SitecorePublishModule

Enjoy!

ASP.NET MVC 5 Route Attributes

Step by step Microsoft has switched their main web technology during the last few years. Web Forms with its component model is now replaced by the Model-View-Controller design pattern. Web Forms is not deprecated yet, but my personal opinion is that it is just a matter of time. The main reason of keeping that technology alive is the fact many CMS-es are built on top of it. Once these systems fully support MVC and switch their main stream to it, Web Forms will follow the faith of it`s fellow WinForms.

Continue reading “ASP.NET MVC 5 Route Attributes” »

JavaScript Prototype Based Inheritance – Magic Revealed

JavaScript becomes more and more widely used language – not only for front-end but back-end (Node.js) too. Almost every web project contains thousands lines JS – layout and animations, AJAX calls etc. Talking about web we cannot skip the modern single page applications where all the user flow and server calls are controlled by the script language.

When we have so much logic implemeted in JavaScript we need a really good code structure, readability and reusability, don`t we?

Nothing can do this job better than the object oriented programming!

In JavaScript the object oriented concept is realized using JavaScript prototype. The simplest and probably most understandable explanation of prototype is:

In JavaScript the prototype is a shared object withing all the instances of a given class.

So we use this “shared object” to achieve inheritance.

In the image bellow I defined a class Animal

animal

The constructor takes a config object with age and name fields. Age is kept as a private class variable and name is stored as a public class field. Private scope in JS is achieved using var keyword. In this way “_age” lives just in the scope of constructor function Animal and behaves like a private class field. I defined two functions getAge and setAge to manipulate the private field “_age”. Have in mind that you can add functions and properties to the prototype of a given class outside it`s constructor:

function_outside

Note: Using this approach we do not have access to the private class field (in our case “_age”).

Now we have class Animal with one private and one public field and 3 functions.

Let`s inherit the Animal Class:

catclass
The key of inheritance here is the line:

Cat.prototype = new Animal();

Another words the prototype of the class Cat becomes and instance of the Animal class and in this way it has all its fields and functions.
One very important part of all the magic here is to pass the configuration object to the Animal constructor:

Animal.call(this, config);

I added function sayMiau and breed field just to show that Cat can have it`s own functions and fields.

Let`s do some tests of the written above:

test

In JavaScript we can even modify the prototype of native objects.
In the next example I extended the String prototype by adding the c#-like format function:

string_extension

You can see the code of all the examples here:
https://github.com/Bilyukov/javascript-oo-programming