Overview of Building a Synchronization Provider
This topic provides an overview of the main steps to building a synchronization provider. Whether you are building a simple or custom provider using Microsoft Sync Framework, or building a custom provider by implementing the interfaces in Windows Sync directly, your synchronization provider must be able to do the following with the data that it represents.
Your provider must be able to enumerate its data. In the synchronization system described in Windows Synchronization Architecture, a data store is a stand-alone entity. However, the synchronization provider that represents the store must be able to enumerate the data in the store, so that it can tell the synchronization session exactly what it contains.
There are two ways to provide this information: The synchronization provider can give the session a complete list of what is in the data store or, more efficiently, it can give the session a list of what data has changed since the last time the information was requested. This second enumeration method of tracking changes is often done by constructing an anchor for your data. An anchor can be a tick count, a time stamp, or a structure that you devise. The synchronization session uses the anchor to determine what data has changed between the two data stores, and passes that information back to your provider.
To differentiate between these two enumeration methods, you either implement the IFullEnumerationProvider or the IAnchorSyncProvider.
The Microsoft Sync Framework custom provider implements the ISyncKnowledge interface for you, which helps determine which changes should be sent so that you do not have to create a fully custom form of anchor.
If you create a provider using Windows Sync, you must implement ISyncKnowledge, as well as construct your own anchor structure.
No matter which option you choose, getting the enumeration system in your synchronization provider working is the first step in constructing a provider.
Your provider must be able to convert data into and out of the transport format. As described in the topic Windows Synchronization Architecture, the IPortableDeviceValues interface is the pipeline for transporting data between two synchronization providers. To send and receive change information, your synchronization provider must be able to convert data into and out of the data format that is used by IPortableDeviceValues.
The IPortableDeviceValues interface holds data as a collection of PROPERTYKEY/PROPVARIANT pairs. Each PROPERTYKEY key must be unique so that items in the collection can be searched by PROPERTYKEY or zero-based index. The data values in the collection are stored as PROPVARIANT structures. The interface provides methods that allow you to copy all the values from the collection into an IPropertyStore interface, or copy the contents of an IPropertyStore interface into the collection. Using IPortableDeviceValues, you can add or retrieve values of any data type. For full reference information on this interface, see IPortableDeviceValues in the Windows Portable Devices SDK.
Your synchronization provider must be able to handle inserting and deleting data in the data store that it represents. An example of this is inserting a new contact into a contact list.
Your synchronization provider must also be able to update existing data in the data store. An example of this is updating the phone number for a contact that is already in the contact list.
Your synchronization provider should be able to filter data. For example, some contacts in a contact list may not have a value for phone number. You may want to filter those out of a change batch and update them only if a phone number is added.
The Microsoft Sync Framework simple provider supports filtering if you implement the IFilteredSimpleSyncProvider interface. However, being able to filter data in specific ways is a good reason to implement a custom synchronization provider.
The Microsoft Sync Framework custom provider implements some filtering interfaces for you and supports change unit filtering. Change unit filtering is used when one replica does not store all of the possible fields, for example, a phone that stores only a name and phone number for a contact, while the computer data store contact also contains an address field.
Windows Sync requires you to implement all of the neccessary interfaces yourself, but it allows you to construct a fully customizable filtering scheme.
Related topics