Sitecore tips and tricks and community news !

Post Top Ad

Post Top Ad

Saturday, May 25, 2019

12:26 PM

Sitecore Azure ARM PaaS on ASE - Redis

Azure ARM deployment is a very good way to setup our environments in PaaS architecture. Moreover, it allows to customize many things, depends on our project (client) needs.

But sometimes simple things can be complicated, especially when you customizations have some influence on deployment process.

In this post I will share with you with Redis troubleshooting which I did during setuping Sessions on Azure. Especially because of Azure ASE which has an influance on this setup. Some default things don't work out of the box, what can be irritating.

During ARM deployment you can see error like this:

Let's take a look a few potential issues:

We will start with something general (not related to Azure ASE)
  1. Check setting InProc and OutProc of you private and shared sessions in configs (according to docs):
    1. For Private session go to your site root folder, open the web.config file, and locate the sesssionState section:
      <sessionState mode="Inproc" cookieless="false" timeout="20"
    2.  For shared session:
      1.  go to your website root folder, navigate to the App_Config\Sitecore\Marketing.Tracking folder.
      2. Open the Sitecore.Analytics.Tracking.Config file.
      3. Locate the line where you can define the default shared session state provider using the following path: sitecore/tracking/sharedSessionState.
  • TIP: Check if the relation between configuration is correct because could be wrong (I had e.g. private session set as out of proc, but shared session was InProc by default). Available combinations let's check here:
    2. ASE resolving URL
     ASE often can be cut off from external access, what means when Sitecore will try to reach default Redis URL it will not achieve it. Because of that you have to change it to IP in connection string. get Ip of Redis, you have to upgrade it from Standard to Premium level

    3. ASE network influence:  
    By default during ARM deployment Sitecore puts every service in default place in your resource group. You have to take care of network and IP ranges which will have it, because being in the same RG doesn't mean it will be in the same network. It may cause to migrate later Redis to different subnet etc.
     4. SSL certificate and ASE
    You can have an issue with connection because of SSL certificate, when it will be self-signed. By default, Sitecore recommend to make it through SSL, but we have to think what in our situation when we use ASE? Well, it's isolated environment and if Redis and CD services communicate in ASE scope SSL is not so important maybe. I leave this decision to you.
    I hope it will help for somebody, because I have spent plenty of time on that topic :)

Thursday, May 2, 2019

12:43 PM

Sitecore 9.0.2 SXA 1.7.1 Azure PaaS ARM installation

During installation SXA 1.7.1 with Sitecore (in this case version 9.0.2) we have defined parameter which we have to fill in our module package in parameters file.
According to docs and default sitecore ARM templates those parameters are:

Ok, so we have them. So let's check what files we can download as a part of SXA scwdp packages:

So we see that we should also have "solrSupportSxaMsDeployPackageUrl". Where it is?
- Well, nowhere.

- Becuase it's not needed :) 

It was doing only thing like:

Since Sitecore 9.0.2 support Solr by default from ARM templates, additional packages since that version are not needed. In SXA version 1.8 is even removed. 
So, to omit that you can do something like:
"modules": {
  "value": {
    "items": [{      
        "name": "sxa",
          "templateLink": "new link"

I hope it will help,


Saturday, April 20, 2019

12:10 PM

SXA - Custom Creative Exchange - Parallel team workflow

Recently SXA is getting much more popular in Sitecore development world. It's a natural way, because it brings many features and improvements which can help and mainly speed up process of creation site in Sitecore.

Usage SXA is also connected with changing workflow between particular parts of your team. Backend guys have to be aware of new tenants, themes, components, modules and other features which SXA provides. 
Frontend guys have to be aware of new HTML structure which by default brings SXA components for them. So they can focus only on styling elements on the page (Of course we can have custom things as well).

Hence, we see that now frontend part has to get in someway elements prepared by backend to style them. To do that SXA provides a default mechanism called "Creative Exchange" with the last version "Live".

What is it?

1. Default Creative Exchange approach:

In standard approach backend developer build site structure using components, but it doesn't have to be styled yet. After his job is done he export special package using Creative Exchange exporter for frontend guys.

They get this package where are *.sass and *.css styles files, HTML of components etc. They can now style components using mainly sass. After their work, they zip package once again and backend developer is importing this to the Sitecore, where Themes are updated with new styles.

It sounds really cool, but recently it has been even improved by the newest version "Creative Exchange Live" which work in real-time. 
It enables developers to modify themes and other site content without having to import the files back into the site. Creative Exchange Live works with Gulp tasks that enable you to make changes to themes and other content and synchronize to the Sitecore environment immediately.

It seems to be even better as I wrote, because we don't have to generate any packages.

But we still we have a few obstacles in the team which we can appear:

1. Whenever you have worked already with Creative Exchange or you haven't but you would like to try, potentially there is a risk to keep your friendship with frontend guys: You will ask why? Usually frontend guys love to build magic with the newest frontend technologies, which everyone knows how fast are changing. So creating CSS or sass for them is a bit obsolete.

2. If we use the older version (not "Live") we have to have this whole generating package process which can be inconvenient for people in the team

3. If we choose "Live" version everything work but in one scope of work, like one developer environment. It means it would be good if developer will be a full stack who will have a content and later will style that or it brings a need to install Sitecore, especially for frontend guys to let them use this real-time styling.

2. Our Custom Creative Exchange

Every path for above has some constraints. Because of that for our teamwork we prepared something new and special. Which will combine advantages of Live version but without need to install Sitecore on frontend guys environments, no generating packages etc. Let's take a look:

What we can see at first look is that comparing to default Creative Exchange, point of merging content and styles is moved to right side. It means that no more Sitecore is responsible for that, hence Sitecore is not needed for this and for frontend developers. Since now responsibilities connected with merging takes Apache server which was setup especially for that.

But how? from where it takes content?

Let's go through this flow:
  1. Setup backend devs and frontend devs in one network
  2. Frontend developer setup on his/her machine Vagrant environment which consists Apach server responsible for merging content with styles and whole frontend environment
  3. Backend developer does backend work, he prepared page with components on the page
  4. Frontend developer put in Apache config file IP of backend developer to whom wants to connect
  5. During making request to particular page from backend developer (where content has been created) Apache is filtering traffic according to predefined rules.
    1. If there is no connection to styles it brings content from particular machine which IP was used (backend guys for our example)
    2. If it's connected with styles, traffic is redirected to own frontend developer resources to get content from his/her styles files. 
So now I think that everything is clear.

Apache analyzes traffic send from frontend developer and decides from which source it has to get. If it's content case, it gets from an external machine, but if it connected with styling it redirects traffic and gets source from frontend machine.

It means that we:
- don't have to use packages
- don't have to install Sitecore for frontend guys
- have separated environments but still real-time connection between content and styles for frontends 

That's it! :)

Below I put config for virtual hosts in Apache

12:05 PM

SUGCON 2019 - London

This year we had a pleasure to be a part of Sitecore SUGCON 2019 conference in London. It was 3rd time when I was participating in this event which was a big pleasure for me :)


I think it's hard to find more business and representative place than London to organize such a conference. The main event was organized in London City, so there wasn't an issue with transport, etc. Inside SUGCON everything was prepared in a perfect way and there was enough amount of space to feel comfortable for, everyone.


 During the whole SUGCON there were a lot of great presentations. Each of the participants had to choose one from a few which were presenting simultaneously. From my point view I remember very good presentations regarding Publishing Services, Commerce and JSS, JSS and SXA, Azure and SIF. But probably other people had different paths in the agenda so they will have different memories ;)

Besides presentations, it was a brilliant time to meet guys from other countries, with whom we got to know a few years ago. Socializing, networking, discussing, keeping relations, that is a fantastic time.

At the end, we had to make little afterparty with friends, mainly SUGPL guys. In London is plenty of places to spend this time in perfect mood! :)

Thank you guys and see next time! :)

Saturday, March 30, 2019

6:56 PM

SUGPL#9 - International Event in Warsaw

This time we have a special meeting with guests from other countries which wanted to share their experience with SUGPL members. Our second event in 2019 was organized in Warsaw!

Organizers ;)

We have started of course with small introduction

Like at the begining I wrote our presenters came from abroad. So 1st presenter was Atanas Desev from Bulgaria who decribed for us Universal Tracker.

The second one was well known in our community Sebastian Winter from Germany who presented for us SXA.

The third presenter was Mark Cassidy who showed for us approach to speed up 10x Sitecore developemnt.

At the end we had afterparty with lots of burgers ;)


Sunday, March 10, 2019

4:04 PM

Hackathon 2019

It's the 3rd year in a line when I, I should say even "we", are starting Sitecore Hackathon. Last year in 2018 we have won this competition in xConnect module category with a team called "Las Vegans". This time we also tried to make everything to write something cool.


In this year we agreed that we keep "LasVegans" name for the team. But one of our previous members couldn't attend in this year, so we have invited our friend Rafał Dołżyński. Hence we started competition in the below composition
Robert Dębowski
Tomasz Juranek
Rafał Dołżyński


After last year and winning the xConnect category, we wanted to change something so in this year we choose UI module category.
Our idea was to prepare special mechanism of tagging connected with NL services. We have extended default SXA approach to very manageable tags with big possibilities to customization.


We decided to take the same "sleep approach" like last year when it worked :) Lot's of discussing, coding, talking and writing :) But it was worth it!


We did it! it was very close because we have finished uploading video and link to it around 3minutes to deadline ;) But we manage to do it ! Success tastes amazing :)! 


Third, year but still a new experience. But one thing is not changing - exhausted and satisfaction of finishing everything at the end :) 

See you next year!
11:57 AM

xCommerce Extending 2/3 - Policies

At this point we already have known general overview of ways which are possible to extend or customize xCommerce. We did extension of an entity via xCommerce composer tool. But we also have mentioned that there are ways to customize platform from code. We saw 2 main ways, by Policies and Composition, what means the best way - to create independent plugins.

Let's take a look on both of them.

At the beginning what you need is:

Sitecore Commerce Engine SDK, example:

1. Policies

By definition:

A named, versionable and variable set of data that can be used as facts within behaviors to influence behavioral outcomes. source

Policies is the simplest I think approach, but we should avoid using it. Why? Because it has an influence on internal xCommerce code, which can be changed e.g during upgrade. To have less stress and work we shouldn't touch internal xCommerce thing but extend it via composition approach.

Policies you can find in this place inside the SDK solution

Let's assume that we would like to extend our Customer entity. What we should to do is to find this entity in policies and add your custom field.

Yes, we did it! we have added a new property! Is it enough?
- Well, not exactly. We still need create a way to make it visibile outside.

But how to do that?

You still (like in a composition) create you feature project (plugin) and define there a few elements of your change.'s still less work than in composition. Usually, needed for you would be , command and controller. In policies like in composition approach your are adding new properties of entity as a new components. Difference is that, when you are changing policy this components are higher in hierarchy of childviews of your entity and you don't have to do much, to later gets them in Sitecore.
By composition approach those components will be buried much more lower to get it.

Now we understand that we have to think about chain of commands and controllers which uses it in xCommerce and extend those places with our custom property. Hence you have to think where you should to go to. To make it very useful is DotPeek, where you can find whole process flow.

Some custom command to make possible to get it like:

And a controller:

So we can say that xComerce part is done. Now we have to go to Sitecore side and try to receive new parameters.

Sitecore side:

Depend what your are doing, in our case it's customer so let's check registration controller which we use and would like to extend with custom fields. In our scenario is our custom controller written with some changes, which gets custom properties pushed by xCommerce in Customer component.

That's it. It's much more faster way to achieve customization of xCommerce entity - but remember that you are changing internal commerce files ! :)


Wednesday, February 20, 2019

3:34 PM

SUGPL#8 - xCommerce Speaker and organizator

It was time to start the new year with our Sitecore community! To do that we have organized new SUGPL meetup in Białystok.
Moreover, I was one of the speakers on this event, where I have presented xCommerce architecture which can be modified during customizations.

As we can see above I was the first presenter of this meetup. My main goal of the presentation was to let people know how xCommerce is built and where they can put own code to make it custom. What is the flow of xCommerce and how they can change it.

The second presentation was made by Artsem Prashkovich who described Sitecore Service Bus.

The third presentation prepared Jakub Koba who talked about Machine Learning in Sitecore

After charging of new knowledge as usual we have started SUGPL after party, where our guests from Belarus SUG join as well. Good time with excellent people, it's worth to repeat as many times as it can be!


Thursday, January 24, 2019

12:06 PM

xCommerce Extending 1/3 - Overview

When we are working with Experience Commerce usually we are using SXA, CXA and entities already prepared for us by authors of this environment. It's a very pleasure way to build our solution with components which are out of the box.

But we have sometimes situation that our business requirement needs custom things like additional fields in forms or other places. In general, it needs to put own custom data inside already defined entities.

So what to do in this situation?

1. Code approaches

  • Composition
    • Entities can be extended by adding components to the Components property on the entity.
    • Components are just classes that are injected into the entity by a plugins with pipeline and blocks
    • It's a independent way to add something more, without relation to other plugin or other elements.
  • Policies
    • In simple understanding we can treat Policy like a config or setting file in some way. You can for instance add a new field for the customer entity etc.
2. UI approach - Composer

Since Sitecore Experience Commerce 9.0.2 is available new feature called "Composer". It's a tool which allow you to extend some entities from UI Dashboard

Let's take a look

1. At the beginning you are going to.... Merchandising tool , not composer ;). In that place you can create a new version of the entity

 2. After creation new version of entity you have unlocked rest of context menu, where you are able to create a new view for this entity

3.When you already have a new view, you can add a new property for this view to fill it. You can define there a name, but moreover a type. In this example I put string, but besides that you have:
  • DateTime
  • Decimal
  • Integer
  • Boolean

 4. Since we have already done new view with the property, we have to extract our custom view to a template, to share it e.g. for all sellable items. To make it we have special action in our context menu. Take a look:

5. Until now, when we did our template we should go to composer menu in xCommerce to manage this new 'item'.

6. When we click it and go inside we will see a new panel. It has also 3 additional button on the right side. There are actions which help you to use and share your custom view. They consist actions:
  • Manage Tags
  • Link to entity
  • Associate Items definitions

At the end, composer is a great tool when you need to add some custom properties especially in situation when you will use it later in this xCommerce dashboard.

But if you are looking more sophisticated solutions, check the next post, where you can find information about extending xCommerce from code perspective.