Just Sitecore Things

In current days we are using e-commerce very often, even more then year before. What are our experiences with them? How many products they offer for us, how much properties those products have?

Usually that would be  clothes with some sizes, colors. But what if those products will be many and each will have more than 100 properties? How we should to build xCommerce architecture to deliver proper product and fulfill client expectations?

1. Context

Imagine that you have to deliver e-commerce solution based on xCommerce for client which:

• Has multi-site solution (32 sites)
  
• Has global market solution (32 markets)
  
• Has around 45 000 products per each market
• Each product has over 100 properties (parameters)
• Solution has 24 languages

How we should to bit this topic, what is crucial in xCommerce approaching here? 

Answer is catalogs and indexing part.

I will skip here topic Azure or Solr, we decided to use SOLR.

But in terms of catalog and indexing. We should to ask what is the the main risk here?

Answer is amount of the data that we can unexpected create (or let xCommerce to create) and later push SOLR to index it. Here fun fact - indexing then can take e.g. 40 days :]

2. Issue

Why?

Firstly what is the default xCommerce shop creation approach?

To create each site with own catalog. In this scenario let's calculate

Well let's calculate:

45 000 products * 32 markets (catalogs) * 23 languages = (*o*) this is the numcber of entries which we will have in xCommerce and later they will be indexed (or tried to index at least) by SOLR.

3. Solution

So what we should do ? Is there any way to mitigate this issue?

Yes, we have to decide to change the default approach and use only 1 shared catalog for each site. It's possible. To obtain the results you only have to remember to:

1. Assign catalog to main commerce catalogs node
   
   
   
   
   
   
2. Do not assign any catalog to node under specific site catalog node
   
   
   
   
   
3. Link you Commerce catalog setting in each site Settings node to shared catalog in main commerce catalog node (point 1)
   
   
   
   
   
4. Change you custom queries to SOLR to check your sort of MarketId to filter proper products

Enjoy !

When we are using xCommerce we have products representation from xCommerce also on Sitecore side. You can see this products as an items with whole description as it usual has. There is also field describing template of an particular item. It should indicate to the product xCommerce template. 

In our scenario we had custom product templates because of our custom composers. Hence in Sitecore we see this custom templates as a definition of particular product (it consist custom product fields inside).

Issue

However, from time to time, randomly, this templates just... disappear. Since that moment Sitecore recognize this products as a default ones, described by default xCommerce product template.

That cause the issue with indexing, because custom fields weren't seen and indexed. What mean disaster for proper working application.

Walkaround

As a walkaround you can clear Commerce cache which push Sitecore to refresh xCommerce templates and get proper one. 

Unfortunately it doesn't mean it will work since that moment to infinity ;) It can broke one more time randomly.

So what we can do?

Solution

It's connected with CatalogRepository.CheckTemplatesMapping() method. When commerce items are loading this method is started.

After instance is restarted, when commerce items are loaded from Content Editor (when we navigate to catalog items in Content Editor) then Context.ContentDatabase is not null and there is possibility to load information about custom composer templates. 

But, if we open commerce items on Storefront after instance was restarted, before they are opened in Content Editor,  Context.ContentDatabase is null on Storefront. 
Hence, correct composer templates are not possible to load. 

Solution is to open CE and set up in path '/sitecore/content/<StorefrontTenant>/<Storefront>/Settings/Site Grouping/Storefront' new property "content" to 'Other properties' with "master" value. 

That will give us always filled database context.

Thanks !

Indexing is wide and complex process.  Usually we get default solution to use default indexes, to save our time and effort. Probably in most common scenarios it is sufficient solution. But what when we have a lot of data and we would like to separate our data from default content data or we would like to separate invoking particular object indexing, scale this process etc.

The best option is to create our own custom index.

This approach is also doable to obtain in xCommerce. What we have to do is to write our own custom patches to switch indexing configuration to ours.

1. Custom Product Index declaration with commerce templates indexing

2. Product Index strategies and crawlers definition for xCommerce

3. We have to get rid of the products inside default master_index. It's done to don't keep duplicated data what also will have an influence on index rebuilding process. Especially in time consuming.

4. We have to indicate for xCommerce new index. To make it we need to prepare new Index Resolver with custom values.

Hello,

Last time I had a chance to check search engine in project with xCommerce. Its main responsibility is to collect products and it is based on SOLR services. During checking it, appeared the issue. When the SOLR engine started to indexing products which we had in DB it has eaten whole VM resources and after some time it just hang out. 

Now all of us can say - but why? 

Well it's really the best question we can ask (and the easier one), but unfortunately answer is not so easy to find. To find answer we can start with checking crawling process made by crawlers or strategies

Crawling you say? - Well, yes.

Details:

To be precise: we were working with Sitecore 9.0.2 + SXA 1.8 + xCommerce 9.0.3. We were using commerce API to add products from the external system and in general, it works fine. What we discovered is the difference in indexing implementation between Crawlers which are triggered manually and Strategies which work in the background. As a result, we see differences in SOLR results.

> Strategy that we use is: SellableItemsIntervalAsynchronousStrategy
> Crawler: AllCatalogItemsCrawler.

What is the gap? 

Well, when the strategy is fired up after the product import we see in SOLR many documents of the same product in the same language, like 30, 60 which has the same SitecoreId but different paths with "/[orphan]" as a root. We also figured out that Commerce keeps the same amount of entities in Mappings, where 30 entries have the same SitecoreId but different DeterministicID (also different to its SitecoreId).

We see that Strategy implementation is different than Crawler one and doesn't skip "orphan" items as crawler does. Hence after strategy activity, we see those 30docs in SOLR of 1 product, but after manual rebuilding the index which executes the crawler, we see only 1 (entry which doesn't have an orphan path, but correct one)

Solution:

The easiest solution is to implement skipping orphan entities in Strategies. To obtain that behavior we need to change base class for strategies: "CatalogSystemIntervalAsynchronousStrategyBase"

I had some issue last time to deploy Sitecore XP (Scaled Production) in Extra Small topology and each time I got an error: 

 "serviceRequestId": null, "statusMessage": "{\"Code\":\"TooManyRequests\",\"Message\":\"Too many requests. Please try again later.\",\"Target\":null,\"Details\":[{\"Message\":\"Too many requests. Please try again later.\"},{\"Code\":\"TooManyRequests\"},{\"ErrorEntity\":{\"Code\":\"TooManyRequests\",\"Message\":\"Too many requests. Please try again later.\"}}],\"Innererror\":null}"

Solution

I tried to deploy this architecture thorugh ARM templates. That was good idea, because then in the PS console I saw an error. It said that an issue was the name of newly created resource group in Azure. It pass the Azure validation of the name, but it broke Sitecore scripts. 

The name of RG couldn't consist any big letter, dashes etc. That was the safer approach which solev an issue.

Bests! 

• server farm
• hosting environment profile

• manually change commerce engine policies and other settings after cloud deployment
• upgrade only xCommerce part to 9.0.3 version which already work perfect with this parameter as well. 

• internal hosting infrastructure or
• external providers

• DevOps maintanance
• Flexibility (issue)
• Complicated solution 

• Simpler maintanance
• Felxibility (pros)
• Easy to scale
• Fancy solution!

• Marketplace
• ARM templates

• Where we will host app
• How we gonna to deploy on it

• Azure Gateway

•  Logic Apps

• Hybrid Connection

• ASE (App Service Environment)

• 2 kinds of ERPs
• CRM
• Some Data Warehouse
• Product managemet system (PIM)

• Plugins
• Controllers and Commands
• Pipelines
• Blocks

• Independent features
• Only accepted way to extend Commerce Engine
• Don’t remove default ones just like that ;)

• Controllers works in the same way as usuall
• Commands are invoking inside the controllers
• Commands invokes Pipelines

• You can create your own pipelines and hook into pipelines defined in other plugin
• Similar to standard Sitecore pipeline mechanism
• In SXC9 they are in the code not XML
• Aggregate SXC Blocks
• Comparing to XML approach No „ShowConfig.ASPX” but JSON preview
• In Commerce, there is no config patching facilities. Instead we can create our custom plugin and can patch our Blocks through the code.
   

• Equivalent for Sitecore processors
• Chaining calls
• Remember about returning element

• Controller
• Command
• Pipeline
• Blocks

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:

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:
 

 Sitecore Documentation - Session States

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. But...to 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 :)

 Cheers!