If you read the documentation on using CMS-only mode to run Sitecore without xDB you'd be forgiven for thinking that a config patch such as this is the simple end of the story:
<configuration> <sitecore> <settings> <setting name="Xdb.Enabled" value="false" /> <setting name="Xdb.Tracking.Enabled" value="false" /> </settings> </sitecore> </configuration>
Unfortunately as someone on Slack recently discovered, this doesn't help if you're trying to run Sitecore (XP container images, but in CMS-only mode without the xConnect instances) in containers.
The issue is fairly obvious when you notice CM is not starting and take a look at an example of the logs
920 08:52:34 ERROR Health check Sitecore.XConnect.Client.WebApi.CollectionWebApiClient completed after 0.0038ms with status Unhealthy and 'Error during CollectionWebApiClient initialization: An error occurred while sending the request.'
1920 08:52:35 ERROR Health check Sitecore.XConnect.Client.WebApi.ConfigurationWebApiClient completed after 0.0054ms with status Unhealthy and 'Error during ConfigurationWebApiClient initialization: An error occurred while sending the request.'
1920 08:52:36 ERROR Health check Sitecore.XConnect.Client.WebApi.SearchWebApiClient completed after 0.0068ms with status Unhealthy and 'Error during SearchWebApiClient initialization: An error occurred while sending the request.'
Yes, there are in fact health checks on CM and CD which check the status of xConnect, and completely ignore the config settings I mentioned above.
Not to worry, there are a couple of options at this point:
- Use a config patch to remove the health checks (the easier option)
- Update and override the health checks so that they respect the
Xdb.Enabledsetting
Config patch
Here's an easy patch you can apply which should remove these from your Sitecore configuration and complete the disabling of xDB:
Updating the code
The "proper" way, I feel, would be to update the code to respect the Xdb.Enabled setting. This is what the setting is indicating, and what the documentation explains that it is for.
To take XConnectCollectionHealthCheckServicesConfigurator as an example:
public class XConnectCollectionHealthCheckServicesConfigurator : Sitecore.XConnect.Client.Configuration.HealthCheckServicesConfigurators.XConnectCollectionHealthCheckServicesConfigurator
{
protected override IHealthCheck CreateCommonWebApiHealthCheck(IServiceProvider provider)
{
if (Sitecore.Configuration.Settings.GetBoolSetting("Xdb.Enabled", true))
return base.CreateCommonWebApiHealthCheck(provider);
else
return new SuccessHealthCheck();
}
}
public class SuccessHealthCheck : IHealthCheck
{
public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
{
return Task.FromResult(HealthCheckResult.Healthy());
}
}
We add our settings check, and - because there does not seem to be any easy out-of-the-box way to return a successful health check - we also need to create a class for that. Repeat for all 3 health checks, and you're good to go.
Enjoy running your Sitecore topology nice and lean!
