Thursday, October 2, 2014

Sitecore's HeartBeat.aspx for Load Balancer Health Checks

Sitecore includes a HeartBeat page so that you can point your loadbalancer's health check at it to determine if that current machine is healthy and should take traffic.  It is a very simplistic health check but it is probably sufficient for basic Sitecore implementations.

The functionality of the included HeartBeat.aspx will enumerate all of your connection strings and try to make a simple connection over to the database.  If everything checks out Sitecore will generate a blank page with a standard HTTP 200 response.  If there are any issues connecting to any of the databases this page will return an HTTP 500 response.

There are two issues you need to be aware of if you are using this page.

Machine.Config Connection String
NET 4.5 typically configures a default ASP.NET membership provider connection string in the machine.config.  This typically points to .\SQLEXPRESS and thus out of the box the heartbeat page will fail on servers that do not have SQL Express installed.

The best approach is to just clear connection strings before you add in your Sitecore connection strings.  You could take the approach of editing the machine.config but that may not be as maintainable.
  • Clear existing connection strings before loading your Sitecore Connection Strings
    • Open \App_Config\ConnectionStrings.config
    • Add <clear /> directly under the <connectionStrings> node
Active Directory or other non-database Connection Strings
If you have your Sitecore instance configured to use the Active Directory Module you are probably adding your Active Directory connection strings to your main ConnectionStrings.config file.  These will fail the database check since they are not database connection strings.

The best way to resolve this issue to add a Sitecore setting to exclude specific connection strings from the Heart Beat check.  This setting is not configured in the default Web.Config file that is configured by Sitecore.  You can add it by including this patch config:

Thursday, September 11, 2014

Sitecore patches showModalDialog issues in Sitecore 6.4 through 7.0

Recently users working in older versions of Sitecore CMS have noticed that some features of the CMS stopped working in the latest version of Chrome (version 37+). The root cause of the issue was that Google has deprecated the showModalDialog() function that Sitecore relied on in versions 7.0 and previous. Starting in Sitecore 7.1 the functionality has been changed and is not an issue.

Up until yesterday Sitecore was recommending that all users either upgrade to 7.1, stop using Chrome, or apply a short-term fix to Chrome to temporarily re-enable this deprecated feature (see this blog post for more details ->

Today Sitecore has updated it's support KB article ( to include patches for versions 6.4 through 7.0. The patches appear to modify several Javascript files and shim in a Support DLL to modify the codebehind for several aspx/ascx files as well. This method seems to be fairly lightweight approach to fixing the issues in these older browsers and should not add much if any additional complexity to future upgrades.

If you are unable to upgrade to 7.1 (Note: if you are upgrading you should really consider moving to 7.2 update-2), then these patches seem like a good options to resolve issues with browsers that remove the showModalDialog() function.

Links to patches:
KB Article 581527

Saturday, September 6, 2014

Boost newer documents in Sitecore 7 and Solr 4

Sitecore 7 search backed by Apache Solr make for a very powerful and flexible search solution.  Unfortunately Sitecore's search abstraction layer was built to have consistency when using any underlying search technology.  This results in some unique features that are available in Solr not being included in the Sitecore 7 ContentSearch API.

If you are looking to boost your search results by a publication date (or any date field for that matter) the general recommendation from a Solr perspective is to utilize a function query as outlined in the SolrRelevancyFAQ.  Unfortunately Sitecore's API does not offer any way out of the box to generate a function query.  Digging into Solr.NET (which Sitecore's Solr implementation makes use) you are able to utilize LocalParms to attach a function query as part of your search request.  Since this is specific to Solr.NET and not something available in Lucene it is not something that has made it into Sitecore's ContentSearch API.

In order to extend Sitecore's ContentSearch to get this type of feature proved challenging and required a good deal of the ContentSearch code to be re-written.  Knowing that the supportability of such customization would be difficult to maintain between Sitecore versions I opted to look for a different approach.

Since Sitecore has limited options to manipulate what is actually be sent over to Solr I discovered the _val_ hook that Solr provides as part of FunctionQuery.  This will allow us to embed a function query inside of the actual search query.  We will be able to utilize this as a field in Sitecore so that we won't require any customization to the ContentSearch code.

Creating the Search Model
You will need to create a search model that utilizes Sitecore.ContentSearch.SearchTypes.SearchResultsItem as its base class.  It isn't necessary to use the base class but it will get you all of the standard Sitecore fields already defined.


Update Solr Schema
You will need to manually define "_val_" in your Schema.xml so that Sitecore does not attempt to make it a dynamic field.  To do this we will add the _val_ field to the <fields> node in your Solr Core's schema.xml.  Without doing this Solor will pick this up as a string field and append the _s suffix.  Please remember you will either need to re-load this Solr Core or restart Solr so it picks up the new Schema.xml.

<field name="_val_" type="string" />

Date Boost Search Query
Now that your model is setup you just need to define the DateBoost Predicate.  This will be added to your GetQueryable Linq statement.  I am utilizing Sitecore's Predicate Builder to make the code more readable.

The date boost function query is utilizing the recommended function from the SolrRelevancyFAQ which is recip(ms(NOW, {FieldName}), 3.16e-11, 1, 1) where {FieldName} is replaced with your Sitecore Field name.  Please note you need to use the full dynamic field name that Solr knows about here which likely ends in a _tdt if you are accessing one of Sitecore's standard Date/Time fields.  The recip function can be adjusted based on how aggressive you wish to have the date boosting.  How much boosting you will need will depend on what other fields you are searching on, other boosting happening on the fields or document, and what your requirements are for how much impact document date has on the score it receives.

You will now be able to execute that search and utilize Sitecore's Search logs to view the query that is being sent over to Solr.  You will see that the _val_ hook is being added as expected and you should see that documents that contain the letter "A" that have more recent Publication Dates (a custom field defined on our template) will have a higher score then older documents.  This simple search example works well for our boosting since our scores are normalized around 1.  The more complex your search query the more you may have to adjust the recip() function to get the desired results.

Some additional information regarding Sitecore and search boosting can be found at John West's blog: