Outscaling configuration (basic scenario)

A running Smartsite site consists in fact of two site instances/applications: the .NET Publication Engine, the front-end, and the Cms Manager back-end. The .NET Publication Engine is responsable for rendering items, where as the Cms Manager back-end is used to add, edit and delete items.

So, when an item has been added (or for that fact edited or deleted) using the Cms Manager, the Publication Engine must be notified of this change to keep its internal state synchronized and, when appropriate, to invalidate certain cache dependencies.

For this state synchronization process standard Smartsite Outscaling II is used. In this case it is a scenario consisting of one CMS server (the Cms Manager server instance/application) and a Publication server (the .NET Publication Engine server instance), sharing the same database and filesystem.

On the Publication Engine instance there is a (WCF) service running to which Outscaling will connect, namely the StateSyncService service.

Server Instances

As mentioned before, the Outscaling configuration should include two Server Instances.

Cms Manager Server Instance

The Cms Manager instance should be configured as indicated in the images shown below.

• The Instance ID setting must correspond with the InstanceID registry setting (in the site root).
• Synchronization Mode for this Server Instance is of no consequence, since it is this Server Instance responsable for synchronizing the Publication Engine Server Instance, so it is the Synchronization Mode on that Server Instance that determines how and when the synchronozation process takes place.
• Do not forget to check the Enabled checkbox.

The Cms Manager Server Instance should have one subscriber: the Publication Engine Server Instance, which in this case uses SMARTSITE.PUBLICATION as its InstanceID (which is just an arbitrary value).

Since this Server Instance will connect to the Publication Engine Server Instance and not vice-versa (that is as far as Outscaling concerned), it is strictly speaking not necessary to fill in the URL, Username and Password properties.

For this Server Instance the Advanced tab does not contain properties which should be set.

Publication Engine Server Instance

The Publication Engine instance should be configured as indicated in the images shown below.

• The InstanceID can contain an arbitrary value, since in this case it does not have to correspond with a registry value.
• Be sure to select the same Database Instance and Filesystem Instance as the Cms Manager Server Instance.
• The Synchronization Mode should be set to Realtime.
• The Enabled option must be checked.

On the Subscribers tab there should be no subscriber selected.

• The URL property should point to the configured listener address for the StateSyncService (WCF) service
  (which can be found within the Web.config).
• When a named pipe listener is being used (the address starts with net.pipe) it is not necessary to fill in user credentials and an Authentication scheme. Otherwise, when a (basic) http listener is used, a valid Windows account as Username and Password must be suplied, since a basic http binding is used and WCF defaults to checking the credentials to be a valid Windows account.

To get logging information (which will be viewable in Outscaling Log within the Outscaling Console) whenever synchronization events are sent to this server instance, fill in SixOutscalingII.Logger as Outscaling Hook Object.

Registry Configuration

On the Cms Manager Server Instance the Outscaling configuration is not complete without the necessary registry settings.

The Outscaling Background Component should be registered as usual, however in this case it is adviced to use 1 or 2 (seconds) as Interval value.

The Outscaling EventSubscriber should also be registered and enabled. The EventClasses property should contain the following events:

• ContentChange.Activation
• ContentTypes
• Outscaling
• DataEditor
• Security

ContentChange.Activation event is used to notify the Publication Engine of item changes, which will result in flushing cache dependencies. Events belonging to the ContentTypes eventclass will be used to notify the Publication Engine of any contenttype changes. DataEditor events, which are usually only interesting for a server instance which does not share the database, are used within the Publication Engine to invalidate TableCache objects.

As an optimization, ContentTypes.Reload should be added as ExcludeFilter.

Note: as of Smartsite iXperion release 1.2, it is recommended to use "*" as value for the EventClasses property, since Outscaling now includes built-in event filtering.

Cms to Cms synchronization

When you need to synchronize between two (or more) cms instances (iXperion 1.01 or higher), each with their own database, you would need to add an server instance for each cms and add it as subscriber on the appropriate server instance. The configuration further needed is similar to Outscaling within Smartsite 5.2 and 5.3.

Most notable difference is the fact that you should include the SOAPEvent within the EventClasses registry setting of Outscaling's EventSubscriber. Also, make sure the Outscaling webservices have been properly configured and enabled (on all cms instances which are a subscriber of another cms instance).

Notice however, when using an Outscaling configuration including two or more Cms instances, you need to enable an extra http handler for Outscaling's external webservice handling. This http handler mapping must appear first within the list of httpHandlers, since the other http handler mapping uses a wildcard mapping. See the <location path="cms"> article for more details.

IIS 7.0

When using IIS 7.0, notice that the ASP role service is required when you (are going to) run an Outscaling scenario, including two CMS server instances which must be synchronized. This has to do with the fact that Outscaling uses an interface included within the asp.dll, so you need to install this role service. On the other hand, it is not required to set the restriction to Allowed for Active Server Pages (ISAPI and CGI Restrictions, machine-level configuration), so if you don't want to allow/enable ASP on your site(s), that's no problem. See Role Services for more details.

Date/Time of the servers

When synchronizing cms instances with each other (each having their own database) it's very important to keep the servers date/time synchronized. Otherwise, the Check Item Status dialog may report items to be out-of-sync which in fact are not. This especially happens when the date/time of the subscriber is behind in time, compared to the sending cms instance.

Use e.g. the Windows Time Service to synchronize with an external time source.