Manage events and event providers

The events system provides a mechanism for distributing events between IIS applications and Optimizely websites in a load-balanced environment. The event system in Optimizely is provider-based, and you can use the built-in event provider or develop your own customized one.

Event providers

An event provider, optimized for Microsoft Azure, is available on the NuGet feed. The event provider for Azure uses Service Bus for distributing events and requires no configuration of servers or network details. An event provider for Amazon Web Services is also available on the NuGet feed.

An alternative is to develop a custom event provider adapted to your hosting environment.

Configure an event provider

Add the provider configuration to the appsettings.json to use another custom event provider. For example:

{
  "EPiServer" : {
    "Cms" : {
      "EventProvider" : {
        "Provider" : "Custom Provider type"
      }
    }
  }
}

See Use the Event API.

Event system process flow

The following procedure describes the logical setup and execution of event system actions.

1. When an Optimizely Content Management System (CMS) website starts, it does the following:
   a. Creates a secret if one does not already exist in the site database.
   b. Initializes the Event Broker responsible for sending and receiving event messages remotely.
   c. Initializes each Event Provider that was configured.
   d. Enables the Event system when the initialization process is completed (for example, when CMS or Optimizely Customized Commerce has completed initialization).
2. Code in a site obtains an Event object instance and subscribes to the Raised and optionally to the Missed event.
3. Code in a site obtains an Event object instance and calls the Raise method (the Cache Manager could raise a cache changed event, for example).
4. The Event object instance fires the Raised event to notify the local subscribers.
5. The Event object instance informs the Event Broker about the event.
6. The Event Broker sends the event to the other sites on the same server and other servers in the network using the configured Event Provider. In addition to the event information, a cryptographic HMAC block is also sent in the message to let the receiver test the event's authenticity (the provider can turn off this functionality if a secure channel is already present).
7. The Event Broker on another instance (an IIS site on the local server or remote server) receives the sent message and does the following:
   a. Makes sure the message was sent from another instance sharing the same database. If no match is found, the action is logged, the message is dropped, and no further action is taken.
   b. Verifies the HMAC using the event data and the secret stored in the database (unless the provider disabled validation).
   c. If the verification fails, the action is logged, the message is dropped, and no further action is taken.
   d. Obtains the Event object instance for the event and calls the Raise method to notify the local subscribers.

Test the event system

Examples of CMS functionality that use the events system are Cache updates. To test cache events, edit a page on one CMS site and ensure the change is reflected on the second load-balanced CMS website:

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 some text on the page and click Publish.
4. On CMS #1, refresh the page and ensure it reflects the information saved in step 3.