An edge case of remote events with Publishing Service

I've been working on an international deployment of Sitecore recently, and resolving some problems around how publishing raises remote events has demonstrated that there are some things about the publishing process that I didn't entirely understand... I doubt this is a common scenario, but it still seems worth writing down what I've learned – So here's another crib sheet for my future self:

The scenario: url copied!

I won't go into the reasons for why, but this deployment has Sitecore broken up into three bits:

1. A shared Master database that lives in a central location
2. A Sitecore cluster in Europe which has all the roles other than the Master DB
3. A Sitecore cluster in Australia which has all the roles other than the Master DB

So authors log in to the Sitecore instance that's geographically closest to them, and do their editing there. When they're done they hit "publish" and the changes are sent to Publishing Targets for both the EU and AU web databases.

Since there's a WAN link between the central Master DB and the local Web DBs, this seemed like a use-case for Publishing Service, as it's much faster processing should be much better at dealing with the network latency involved in this scenario.

And mostly this works ok...

But it was noticable that when an author published in Europe, it updated fine, but caches and indexes did not update in Australia. And that made sense, as checking under the surface the Events tables in the Australian databases did not get any "a publish has happened" messages written to them...

So clearly I got something wrong – and after failing to fix it myself I spent some time discussing the scenario with Sitecore Support.

My bad assumptions... url copied!

Initially I looked at the role diagram for the site, and thought that Publishing Service instances need to know about both the EU and AU databases, but they are the only bits of the system that need to.

So Publishing Service can be configured to see the "web" Publishing Target databases in EU and AU, plus the central Master. But the CM and CD instances only care about their local web database and Master. So they don't need to know about the remote web databases at all.

That seems logical – and the publish operations largely work. But the "events don't happen remotely" thing suggested it wasn't right.

What I learned from support... url copied!

So it turns out that the "a publish has happened" events are not actually generated by Publishing Service. It does the work of moving items between databases, but it doesn't do the work of triggering all the events. That work still happens inside the CM instance.

That means that this scenario requires you have to have all your remote databases configured as Publishing Targets for both the CM role and for Publishing Service.

So fix my issue, I had to change the configuration so that:

• All of the web databases appear in the CM server connection string files with unique names. e.g. naming them "web_europe" and "web_australia"
• All of the web databases need to be configured as Publishing Targets in both of the CM instance, using these unique names. This requires both a config patch to configure the event queues etc, and making sure there are the right items under "/system/Publishing Targets" in Master that define these publishing targets, using the unique database names.
• The definitions on the CM box need to have their "database" attributes updated to use the unique database names.
• The configuration for the target databases in Publishing Service must use the same unqiue names, and must specify the unique database names for each target. (So Publishing Service needs these databases in its connection strings file too)

Once both Publishing Service and all of the CM boxes knew about all of the databases, the events started to appear in the remote database after a publish, and magically caches cleared and indexes updated after each publish.

You don't appear to need to change the CD server config to match the CM changes.

Once again, Sitecore Support saves my bacon – Thank you!

↑ Back to top