Built-in event filtering and built-in datasources

Outscaling configuration can sometimes become quite complex, especially when you have a scenario of multiple cms server instances, each with their own publication server instance, and each pair does have its own database as well. Creating and configuring the server instances isn't that hard, but what events do you need to include within the EventClasses registry parameter and what Datasources do you need to create?

Built-in Event filtering

The Outscaling EventSubscriber is one of the core components of Outscaling. It is responsible for listening to events raised from within the Smartsite cms engine and add them to the Outscaling EventQueue (if the event originates from the local cms engine itself) or handle/execute the event (if the event originates from a remote server instance).

In earlier versions of iXperion, you needed to figure out what events to include within the EventClasses registry parameter (Events\EventSubscribers\Outscaling within the site's registry). With just one cms server instance and one publication server instance, that's not such a problem since the appropriate value for EventClasses is included within the EmptySix template site.

But when the number of server instances increases, and it e.g. includes an cms server instance with its own database, it becomes harder to determine which events to include within the EventClasses parameter and it is easy to forget an eventtype which is necessary for Outscaling to function properly.

Well, no more with iXperion release 1.2. In earlier versions it is not recommended to use "*" as value for the EventClasses parameter, since in that case every event raised from within the cms engine will be added to the EventQueue. And although Outscaling's background component already had its internal event filtering to skip  events which are not applicable for a particular subscriber, using "*" would result in an EventQueue cluttered with events which shouldn't be there.

However, as of iXperion 1.2 it is recommended to use "*" as value for the EventClasses parameter. The Outscaling EventSubscriber have been adjusted and when it is started and EventClasses equals "*", it will switch on its internal event filtering.

This built-in event filtering analyzes your Outscaling configuration, in particular the configured server instances, and builds an exclusion list of event types which are not applicable for any subscriber. This list is expanded with event types listed within the ExcludeFilter registry parameter.

Then, when the EventSubscriber receives an event, it checks the event type against the exclusion list. If it is included within this exclusion list, the event is skipped. Otherwise, it is added to the EventQueue.

Built-in Datasources

Another complex configuration job is getting the Outscaling Datasources right. Again, this is especially true when you have an Outscaling scenario of multiple cms server instances, each with their own database. For each combination of a particular datasource (usually a table within the database, including relations), the local cms server instance and a particular subscriber, you would need to create an Outscaling Datasource.

Then, you would also need to be aware of which datasources for which type of subscriber are applicable. The list of required datasources for a subscriber which is an cms server instance is quite different then the list for an publication engine subscriber.

Because Outscaling is perfectly capable of determining which datasources are required, within iXperion 1.2 you are no longer required to create all these Outscaling Datasources. The Outscaling Background Component now just builds a list of default required datasources in memory. This list is created for each subscriber, and differs on the type of subscriber.

For a subscriber which is an cms server instance (with separate database), the built-in datasources include:

For a subscriber which is an publication engine subscriber (always shared database), only the last two datasources (LocalizationCultures and vwLocalizedStrings) are used as built-in datasource.

In the rare occasion you need/want to exclude a built-in datasource from synchronizing automatically, you must create an Outscaling Datasource for this datasource (and the appropriate source and target server) and set the update mode to either manual or disabled.

Note: the built-in datasources are all configured using the options direction=push and update mode=realtime. Whenever your Outscaling scenario needs to use pulling for a particular datasource, you would need to add an Outscaling Datasource with the appropriate configuration. Also, when you have a custom table which needs to be synchronized, and obviously this one isn't listed within the built-in datasources,  you need to create an Outscaling Datasource for this table.