Just Sitecore Things

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 !

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"

Thank you !

• 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

We also should remember about mentioned earlier registration piplines and blocks in the configuration classes. You will have it also below in the examples of code.

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. 

Cheers!

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. But...it'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 ! :)

Cheers!

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.

• DateTime
• Decimal
• Integer
• Boolean

• Manage Tags
• Link to entity
• Associate Items definitions