Jeremy Davis
Jeremy Davis
Sitecore, C# and web development
Article printed from: https://blog.jermdavis.dev/posts/2019/shooting-myself-in-the-foot-with-marketing-automation

Shooting myself in the foot with Marketing Automation

Published 08 July 2019
SIF Sitecore ~1 min. read

I had another of my fun chats with Sitecore Support recently, for an issue that seemed to get no useful results in Google when I looked. So, as is my way, I'm filling that search-engine void today. This turned out to be entirely my fault – but it seems like the sort of mistake that others might encounter too... So if you've deployed a distributed instance of Sitecore and found Marketing Automation was behaving oddly, read on...

The issue url copied!

I've been working on a large deployment of Sitecore v9.1 Update 1, using the XP1 SIF scripts. Mostly this has been pretty pain-free. I was able to edit the assorted json files to fill in the specific bits of configuration I needed for my deployment, and then run the right scripts in the right places to make it all work.

But after the initial deployment I noticed that one aspect of the site was not working correctly. When you tried to browse to the Marketing Automation UI, you'd get a pause and then a cryptic error:

Marketing Automation Error

Digging into the Sitecore logs on my CM server, I found this error, sitting on top of a very long stack trace. I've trimmed off the end, as it just repeats much the same thing for a long time, but the interesting bit was:

13976 14:53:30 ERROR [Sitecore Services]: HTTP GET
URL https://author.redacted.com/sitecore/api/ma/plans/?cultureName=en-GB&sc_site=shell

Exception System.InvalidOperationException: Get plan statistics did not complete successfully. StatusCode: 404, ReasonPhrase: 'Not Found', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
  Connection: close
  Date: Mon, 03 Jun 2019 12:53:30 GMT
  Server: Microsoft-HTTPAPI/2.0
  Content-Length: 315
  Content-Type: text/html; charset=us-ascii
}
   at Sitecore.Xdb.Common.Web.Synchronous.SynchronousExtensions.SuspendContextLock[TResult](Func`1 taskFactory)
   at Sitecore.Marketing.Automation.Data.AutomationPlanRepository.<GetAll>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Sitecore.Marketing.Automation.Client.Controllers.AutomationPlansController.<GetAll>d__8.MoveNext()

					

There was nothing in the Marketing Automation service's logs to indicate an error at their end, and the IIS logs had this request on the CM server, but with a 500 status code rather than the 404 implied above.

Google didn't help me, so after a bit of head scratching I raised a support ticket.

The solution url copied!

Having looked in more detail at all the config for my CM and Marketing Automation instances, support pointed out an obvious issue: The connection strings file on my CM server had the URL for Marketing Automation as an HTTP endpoint:
<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
  <!-- 
    Sitecore connection strings.
    All database connections for Sitecore are configured here.
  -->

  <add name="xdb.marketingautomation.operations.client" connectionString="http://xma.redacted.com" />
  <add name="xdb.marketingautomation.reporting.client" connectionString="http://xmareporting.redacted.com" />

</connectionStrings>

					

But the scripts which set up the services behind those endpoints only gave them HTTPS bindings – becasue xConnect services are secure-by-default. So that was clearly causing a failure when the CM instance tried to talk to the Marketing Automation services and got no response from the remote server, because it had no HTTP binding.

A bit of further digging lead to the embarrasing discovery that I'd managed to typo the Marketing Automation URL in the CM server SIF json file. Somehow I'd managed to use "http" instead of "https" there, and hence the CM server was set up to use the wrong URL.

So don't be me. Proof-read your SIF scripts carefully before you deploy...

↑ Back to top