There are many mechanisms for monitoring the health of Sitecore, but Heartbeat.aspx is the simplest. It is easy to monitor with third party tools and requires no knowledge of technological underpinnings. With the release of Sitecore 9, however, things have gotten a bit more complicated. Heartbeat checks every database, even unused ones. this can lead to false negatives and problems monitoring site health in different environments. Fortunately, there is a solution!
This post is somewhat of a sequel to my previous one around multi-site and multi-language setup. When there is only one site and only one language things are pretty straightforward in terms of site context. Once multiple sites are introduced every time we are getting an item in Sitecore and/or building a link we need to make sure we do it within the correct site and correct language. For the most part Sitecore does it out of the box but there are cases when this functionality breaks down.
In previous versions of Sitecore Commerce the SQL Database Schema included 2 tables:
CommerceEntities: Stored all Commerce Entities (Catalog Items, Orders, Promotions…) as JSON.-CommerceLists: Maps Entities to Lists (SellableItems To Category for example).
Those tables quickly reached a huge amount of Data and caused significant performance issues in some cases.
To solve that, Sitecore Commerce 9 introduced a simple SQL Sharding technique driven by an Environment JSON Policy-Set: PlugIn.SQL.Sharding.PolicySet-1.0.0.json
Using the Salesforce connector we can interact with Salesforce Sales cloud and create/manage "Contacts" but what about creating "Leads".
There are many articles talking about creating custom facets and https://briancaos.wordpress.com/2015/07/16/sitecore-contact-facets-create-your-own-facet/ is a good one I suggest. Here i will describe steps involved in actually viewing these facet values from inside Sitecore Experience Profile.