Replicator 7.4 - Conflicts and Replicator

Conflicts and Replicator

September 2023

This Knowledge Base article details information about conflicts when replicating, as well as the best practices that should be implemented in order to keep conflicts at a minimum. Lastly, a detailed outline of the various conflict handling settings is provided here, describing what occurs with each configuration option, as well as where and how to monitor conflicts.

The examples in this document assume bidirectional replication is configured between two web applications, Corporate Portal and London Branch Portal. Connections are configured between these web applications as follows:

Description of conflicts

Conflict Settings

Best Practices

Description of conflicts

A conflict is detected when Replicator is applying an updated or changed list item and the contents of the event already contain an older item. The conflict is handled only on the web application where the event is being applied. They are handled according to settings defined locally on the inbound web application, on the replicator connection.

In the following scenario, Cora from Corporate updated an announcement at 1:01 PM (Eastern time). Lloyd from the London office updated the same announcement at 1:02 PM (Eastern time). The update from Corporate was sent to London, and the update from London was sent to Corporate.

On Corporate no conflict occurs because the update from London is the most recent change. On London, however, a conflict does occur because an update is sent from Corporate which is older than the update made on London. The way in which this conflict is handled depends on the conflict setting you have configured for the inbound connection on London.
 

Different conflict settings can be defined for each inbound connection.

Conflict Settings

You can customize the settings of each Replication Connection to deal with conflicts in a specific way. Conflict settings can be set to automatically resolve a conflict using Skip Event or Apply Event settings, or to manually resolve a conflict using the Generate Conflict setting.

Skip Event

Choosing Skip Event as the conflict setting for a replication connection means that in the event of a conflict, the inbound web application automatically keeps the most recent list item. The following is a depiction of how Skip Event functions:

If Skip Event has been set as the conflict setting for the Corporate to London Connection, then London Branch Portal�s change will be kept, as it is the most recent change. The conflict at London Branch Portal will therefore be automatically handled by keeping the most recent event.

After replication completes, both web applications have the item that was updated at 1:02 PM.

Apply Event

Choosing Apply Event as the conflict setting for a replication connection means that in the event of a conflict, the web application on the inbound server will automatically apply the inbound update or change, regardless of the time at which the change was made. This allows you to specify that the outbound web application is an authoritative source of content and will therefore automatically be applied.

The following is an example and depiction of how Apply Event functions:

If Apply Event has been set as the conflict setting for the Corporate to London connection, then the inbound change will be applied. The inbound conflict at London Branch Portal will therefore be automatically handled by applying the inbound event.

After replication completes, the London application is updated with the 1:01 PM update.

Generate Conflict

Choosing Generate Conflict as the conflict setting for a replication connection means that specified users must decide how to resolve the conflict. In the event of an inbound conflict, replication will be paused, the accounts specified for notifications on the inbound connection will receive an email notification, and a conflict report will be generated on the Monitor Conflicts page. The Monitor Conflicts page is accessed through Site Settings or the Central Administration Application Management page. The conflict must be resolved by choosing Accept or Reject in the email notification or on the Monitor Conflicts page.

Monitoring Conflicts

The Monitor Conflicts page is accessed through the following:

·Site Settings for the inbound site where the conflict was detected.

·Central Administration Application Management page for the inbound web application.

The Monitor Conflicts page displays conflict reports, which are only generated for connections with a conflict setting of Generate Conflict. This page displays all the details about the conflict. You must select Accept or Reject in order to resolve the conflict, so that replication can continue.

Accept

In the example above, selecting Accept will apply the inbound package �therefore behaving in the same manner as Apply Event.

Essentially you are manually applying the Apply Event setting.

Reject

Rejecting will reject the inbound package, keeping the most recently updated event � therefore behaving in the same manner as Skip Event.

Essentially you are manually applying the Skip Event setting.

Receiving Conflict Notifications

When a conflict occurs, regardless of the conflict handling setting, we send email notifications to the individual(s) you specify.