From EPiServer 4.50 it is possible to define a selection of pages that can be mirrored, for example, to another system. EPiServer's content mirroring makes it possible, among other things, to define that pages with certain properties should be published in another EPiServer system. It is also possible to set up a staging and development environment that can be mirrored to a production environment for content publication. EPiServer's content mirroring can also keep track of pages that have been moved and deleted from a selection in order to keep exact page structures updated.

Content mirroring is based on the existence of a "master" and one or more mirrors. Changes that are to be mirrored to another system can either be approved manually by an editor or automatically. The content can also be mirrored to XML and HTML format for integration with other systems or for archiving purposes.

Key Features

Some of the main features of content mirroring are:

• Possibility to maintain content in one place and push the content to other sites.
• Provide EPiServer content to other structured formats, e.g. static HTML and XML.
• Web sites can be validated in a test environment before release, therefore improving quality.

The main feature of EPiServer's content mirroring solution is the possibility to maintain content in one place and "push" the content to other sites, for example releasing content to one sub-site, multiple sites in different locations, multiple static sites, or multiple front servers. The diagram below outlines the possibilities.

The diagram below outlines the possible scenarios when content mirroring may be used.

Releasing Part of the Content to Other EPiServer Sites

EPiServer's content mirroring solution makes it possible for part of the content in one EPiServer site to be pushed (copied) to another EPiServer site. This is done by defining a page selection to be copied and a destination site. A channel is then created, pointing out the destination site together with the properties for the release. This could be used to either release content to a sub-site or to multiple sites in different locations. The channel uses the EPiServer internal format as Data format.

Saving Content as XML / HTML

It is possible to display EPiServer content in other structured formats, e.g. XML or static HTML. Static HTML can be used to either show EPiServer content in an environment other Microsoft or to "burn" a copy of the site at regular intervals.

Release to Multiple Front Servers - Staging

EPiServer's content mirroring solution enables creation of solutions for staging EPiServer sites. Staging solutions provide the possibility to either release a static site or an EPiServer-based site. In either case the content flow is very similar even if the server environments are rather different.

Channel

In EPiServer, the information defining the content that should be mirrored from the Web site is defined in channels. You can have multiple channels defined in one EPiServer site. Each channel contains properties that define the pages that should be included in a channel. A channel does not know or care about where the pages are being delivered, it only makes sure the underlying publisher receives information about the changes according to the channel properties.

Channel Type

One of the major properties of a channel is the channel type. There are three types of channel to choose from:

• Tree - The tree model finds all changes made to a tree (move, delete, update, create). All these changes will be sent to all destinations. The tree model always finds differences by starting at the root page and recursing the tree. This means that a sub-page will never be included if the parent is not included. If you exclude a page (by using a filter), all sub-pages will also be excluded. This type is primarily used to be able to mirror a tree structure where the target will be a replica tree structure of the source.
• List - The list model works exactly the same way as a tree model with the difference that it won’t recurse after the first level.
• Search - The search model will only find changed (or "marked as changed") or new pages. Delete and move operations are not intercepted. This model is specifically designed to be able to mirror pages regardless of location to a single destination/list. This is useful for scenarios when news should be exported to another system (news service or another global news list in another EPiServer system).

Scheduled Mirroring

New or modified content can be released either manually or automatically. This is defined in the channel properties. Content is manually released by the editor from EPiServer's Action window.

The Mirroring service in Admin mode can be used to set up a scheduled job, so that content is automatically mirrored at, for example, a set time every day or week.

When changes are approved they are handed over to destinations as defined on the channel, these changes are queued in the database on each and every destination.

On the sender side, a "state" is kept that records which pages have been sent to a given destination. Whenever the mirroring job is run, the current site structure is extracted and then compared with the recorded "state" of the receiver site. This comparison leads to a number of operations being queued, such as a "publish", "move" and "delete". After the comparison and operations queuing, the recorded "state" of the receiver site is updated to reflect the updated situation.

The receiver side keeps a "mapping table", which records the mapping between the sender page IDs and the receiver site page IDs. So, when the receiver side receives a request from the sender to "publish", "move" or "delete" a page, it uses that sender page ID to look up the corresponding local page ID - mapping it in other words. This "mapping table" is built on-the-fly as mirroring requests are received by the Web service.

A "reset state" option is available on the sender side to clear the recorded "state", but this does not affect the receiver site. When resetting the state on the sender site, it is also a good idea to reset the receiver site at the same time. The best way to do this is currently to delete the pages in the receiver side and empty the Recycle Bin. This will ensure that the sender and receiver are in agreement. The "mapping table" will still be there, but all its targets have been deleted and it will thus clean itself up in the next mirroring.

Mirroring also picks up referenced files, and will begin a mirroring operation by sending these to the receiver using a Web service. Once that is completed, the actual page updates are sent. This will ensure that when pages are published, the relevant files will be there. It will also keep the size of each transfer down, since each file is sent separately.

Export/Mirroring at Initial Deployment

The first time content is mirrored from the sender to the receiver, the mirroring will run without error as the receiver side has no current "states". When mirroring initially starts, the sender side sees that no content has been mirrored and will send all content regardless.

At the receiver end, there is no mapping table either, so the receiver will pick up the pages and effectively build an identical parallel tree. This might not be what you want, but it should not be a problem, as you can just switch the start page to the newly mirrored tree and remove the imported one at your leisure. The initial mirroring requires a full overwrite on the target.

Mirroring Locking

Mirroring is run as a single "transaction" and sender databases are not locked for read/write when a site is mirrored. There is a slight risk of short-term inconsistencies that will be resolved at the next mirroring operation, if editing is being done at the time of the mirroring, but there is no risk of long-term inconsistencies.

The following is required to be able to configure mirroring correctly.

• Both sites must run EPiServer 4.50 or later.
• Both sites must have page types with the same name, in this case. Both page types should share at least ”MainBody” so that there is a property to display externally.

For more detailed information on content mirroring and troubleshooting, refer to the technical note "Mirroring – Configuration and Operation".