Remote Events
Remote events have been part of Sitecore for quite a while. There are built-in events and you can also trigger your own. You queue them up on your CM instance and then receive and re-raise them on the other end of the tunnel – on all your CD instances. I won’t go into much details about how you do it. Here’s an excellent post from Ben Vangansewinkel that says it all.
Transient Data
When you have a data to send from your CM to your CDs you would probably go for items and publishing as your first option and you’d be right. Native, safe, reliable, fast (and now lightning fast with the parallel publishing in 7.2). And what about an occasional occurrence of a transient data? Short-lived and non-critical? A data that your CM has access to and your CDs don’t but it’s them – the CDs – who need it?
[su_note note_color=”#fafafa”]It turns out you can use remote events queue as a data pipe connecting CM with all your CDs and offering you quite a bandwidth.
[/su_note]
Event Queue
Event Queue is essentially a table in the core database. You can trace the Sitecore.Eventing.EventManager.QueueEvent() down to the Sitecore.Data.Eventing.SqlEventQueue that runs the INSERT. The field that interests us the most is InstanceData defined as NVARCHAR(MAX).
If you traced that QueueEvent() call you probably saw how your custom event object gets serialized using System.Runtime.Serialization.Json.DataContractJsonSerializer into the QueuedEvent.InstanceData.
Bandwidth
NVARCHAR(MAX) can store up to 2GB. That’s 2GB of JSON (well, not exactly but still plenty). Should be more than enough for occasional, short-lived, non-critical, transient data. All that you you need to do to use it is to annotate your event object with [DataContract]. Try it!
Notes
Why am I emphasizing those certain data characteristics you may ask? Well, sending data off from a CM to your CDs using event queues has its constraints. Our pipe is fire-and-forget and you can’t really request that an event be resent if you need to replay it for whatever reason. The queue is persistent (it’s a table after all) but it’s cleaned periodically. And like with a any technology – use it where it fits and be careful when you start using it for what it was not designed for. That said, we had a need the other day on one of the client projects where using event queues as data pipes came very, very handy. Maybe you will too find it useful.
