HomeDev GuideRecipesAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Events and event providers

Use the event system to distribute events across load-balanced Optimizely CMS 13 instances. Configure the built-in, Azure, or custom event providers.

Use the event system to distribute events between Optimizely Content Management System (CMS) websites in a load-balanced environment. The event system keeps data consistent across instances by broadcasting changes (such as cache invalidations) from one site to all others. The system is provider-based: use the built-in provider, the Azure provider, or develop a custom provider for your hosting environment.

Event providers

Optimizely offers an Azure event provider on the NuGet feed, optimized for Microsoft Azure. The Azure provider uses Service Bus for distributing events and requires no server or network configuration.

Develop a custom event provider if your hosting environment requires a different transport mechanism.

Configure an event provider

Register a custom event provider in Startup.cs by replacing the default provider in the service container. The following example registers MyEventProvider:

public void ConfigureServices(IServiceCollection services)
{
    services.AddCmsEvents();
    services.AddSingleton<EventProvider, MyEventProvider>();
}

For information on defining and publishing custom event types, see Send and receive custom events.

Event system process flow

The following list describes the event system lifecycle from startup through message delivery.

  1. When a CMS website starts, the system performs these actions: a. Creates a secret if one does not exist in the site database. b. Initializes the event host for sending and receiving remote event messages. c. Initializes each configured event provider. d. Enables the event system after initialization completes.
  2. Application code calls IEventPublisher.PublishAsync to publish an event object.
  3. The system invokes HandleAsync on each registered IEventSubscriber<T> that matches the event type.
  4. IEventPublisher passes the message to the registered EventProvider for remote delivery.
  5. The EventProvider on the receiving instance delivers the message to the event host.
  6. The event host calls IEventPublisher, which invokes all matching IEventSubscriber<T> services with a context argument indicating that the event was broadcast.

Test the event system

CMS uses the event system for cache invalidation across instances. To verify that cache events propagate correctly, edit a page on one CMS site and confirm that the change appears on a second load-balanced site:

  1. On CMS #1, go to a page in the example website.
  2. On CMS #2, enter edit view and go to the same page as in step 1.
  3. On CMS #2, add, edit, or delete text on the page and click Publish.
  4. On CMS #1, refresh the page and confirm it reflects the changes from step 3.