Sync Events for Conflict Handling, Progress Reporting, Business Logic …

Let me just say that synchronization services eventing model is so rich. It is designed to enable you to build many of the features that business applications demand. Some of those features that come to mind are:

  • Monitoring and progress reporting
  • Conflict detection and resolution
  • Tracing and debug logging 
  • Business logic
  • Auditing
  • Schema creation tweaks

So what are those events that I am talking about? well, let me go through them here. To begin, I'd like to divide the events into two categories, provider events and agent events.

Sync Provider Events

Change Enumeration Events

  • SelectingChanges - This event is fired prior selecting changes in any of the tables in a group. The event is at group level.
  • ChangesSelected - This event is fired after the provider concludes enumeration of changes for all the tables in the group. This event is at group level.

Change Application Events

  • ApplyingChanges - This event is fired prior applying changes in any of the tables in the group. The event is at group level. You can access the changes dataset through this event and apply any kind of business logic your scenario demands.
  • ChangesAppliedEvent - This event is fired after the provider concludes application of changes for all the tables in the group. This event is at group level. The dataset of changes along with the set of conflicts encountered while applying are also available from the event arguments. This way you could log them to a file for auditing or tracing purposes.
  • ApplyChangeFailed - This event is fired when an attempt to apply a row resulted in a failure. This event is at row level.

Progress Event

  • SyncProgress - This event is fired at the table level after selecting changes from a given table. The event is also fired at the row level after applying a given row.

Schema Creation Events (Client Provider only)

  • CreatingSchema - This event is fired prior to creating table schema on the client database. This event is at the table level. The schema is represented by a DataSet object and using this event you could tweak the schema definition if needed.
  • SchemaCreated – This event is fired after creating a table on the client database. This event is at the table level. The connection and transaction objects are also available through this event so that you could execute extra commands in the same transaction. This is useful in case you want to add an index or a constraint to the table that just got created. 

Sync Agent Events

Session Events

  • SessionProgress – This event is fired in the context of Synchronize() call. It fires at pre-defined checkpoints in the synchronization process: reading metadata, creating schema, uploading changes, downloading changes and writing metadata. If you are trying to show synchronization progress bar in a form, for example, then this event is the one you would want to use.
  • SessionStateChanged – This event is fired to indicate the state of the agent session which is either ready of synchronizing. The event is fired in the context of Synchronize() call.

As you can see, you have many points to plug in your code and perform myriad of tasks while synchronization is in progress. Many of these events were driven by the experience we have working with SQL Server merge replication customers. I'd be interested to know what you think and if these events would help you building your custom logic.

One final note before I go is that not all the events listed here are available in the current beta 1 bits; few are coming up in beta 2.

 

Update: Just to let you know, I left Microsoft to start a new company, Raveable Hotel Reviews. See examples: Romantic Hotels in NYC , Best Hotels in Seattle , Top 10 Hotels in Myrtle Beach , Kid Friendly Hotels in Chicago , Hotels with in-room jacuzziand Best Hotels in Miami. Your feedback is welcome on twitter.com/raveable, raveable blog.