Active tests not showing

A/B Testing is great

Sitecore’s Experience Optimization content testing functionality is a powerful tool in the Sitecore XP arsenal.  When coupled with a solid engagement value strategy, marketers can get deep insights into what actually works (rather than what we think may work).

….when it works

Recently we hit an issue in a recently upgraded (8.2 -> 9.0.1) installation that would not display newly created tests correctly.  The process of creating the test all went smoothly, the test would actually be running…but it would not display in the “Active Tests” tab of Experience Optimization.  Drafts and Historical tests all displayed as expected.

I just created a new test….but no active tests 😦

Testing through our environments identified that things were working locally, but any upstream deployments all reproduced the issue.

All tests get indexed by your search provider upon creation.  As part of the upgrade we’d also switched search providers to Azure Search (locally we use SOLR) so thought I’d investigate the [sitecore-testing-index].  All looked ok ¯\_(ツ)_/¯ .  Documents were being added for each test we created with what seemed appropriate data. There was also a fairly cryptic INFO message in the logs when attempting to load the Active tests:

9300 02:31:53 INFO AzureSearch Query [sitecore_testing_index]: &search=This_Is_Equal_ConstNode_Return_Nothing

After hitting up colleagues and Sitecore community slack we were still at a loss, so raised a Sitecore support ticket.  After an open dialogue and many configs later, we had a solution!

The solution

This was a config issue with Azure search.  One of the Sitecore fields to be added to the [sitecore-testing-index] is a flag to whether the test is running (“__is running“).  The default configs fail to add this field to the index correctly.  Easily fixed…’s a one line change (isn’t it always?).

The Content Testing configs for 9.0.1 (and 9.0.2) provided in the Sitecore package downloads (for Azure AppService) you’ll see the following:

<field fieldName="__is_running" cloudFieldName="is_running____" boost="1f" type="System.Boolean" settingType="Sitecore.ContentSearch.Azure.CloudSearchFieldConfiguration, Sitecore.ContentSearch.Azure" />

This code needs to change to the following  (I recommend patching it to avoid any future deployment/upgrade issues):

<field fieldName="__is running" cloudFieldName="is_running_____b" boost="1f" type="System.Boolean" settingType="Sitecore.ContentSearch.Azure.CloudSearchFieldConfiguration, Sitecore.ContentSearch.Azure" />

The changes are subtle, but important! Firstly, it’s referencing the field name correctly (with a space). Secondly it is giving the index field name a _b suffix to further indicate it is a boolean.

After making this change and then rebuilding the [sitecore-testing-index] in the control panel, marketers and analytics teams rejoiced as they were able to view all of their glorious active tests.



Marketing Automation stored procedures and tables missing

Seen this message in the exception logs of your shiny new Azure app service instance of Sitecore 9?

Could not find stored procedure ‘xdb_ma_pool.AutomationPool_Stall’

ARRRRRGH.  Missing Stored Procedures?!?! Who’s been dropping stuff in my DB!  It’s newly deployed…how can this be! It worked on my dev machine! Never fear, there’s an explanation and easy fix.

No…you haven’t been dropping DB objects in your sleep.  This just appears to be an oversight in the Marketing Automation SQL dacpac in the Sitecore 9 Azure App Service web deploy packages.  In fact there are a few other objects missing too:

Stored Procedures


This has been confirmed by Sitecore support and they’ve published a KB . Also the KB now contains a SQL script to create the missing objects.  Running this script on the Marketing Automation DB in your Azure environment should create the missing objects and resolve the issue.   This is confirmed as an issue on 9.0.1 and 9.0.2.

We’ll be adding this as a post-install script to all our ARM template deployments to avoid any manual steps in future deployments.