Filtrage des données de synchronisation

Article
08/18/2010

Un filtre permet de restreindre les données synchronisées. En règle générale, le fournisseur de source applique le filtre pendant l'énumération des modifications pour restreindre les modifications envoyées. Sync Framework prend en charge les types de filtres suivants.

Les filtres d'éléments restreignent les données de synchronisation à un sous-ensemble d'éléments, par exemple pour synchroniser uniquement des fichiers .txt entre deux dossiers de fichiers, tout en ignorant les fichiers des autres types. Les éléments ne changent pas d'une façon qui provoque l'inclusion de l'élément dans le filtre ou son exclusion du filtre. Les filtres d'élément sont simples à utiliser, mais les métadonnées utilisées pour la synchronisation augmentent proportionnellement au nombre d'éléments qui sont dans l'étendue de la synchronisation.
Les filtres d'unités de modification restreignent les données de synchronisation à un sous-ensemble d'unités de modification, de façon par exemple à ne synchroniser que les champs name et phone number d'un contact, en ignorant les autres unités de modification.
Les filtres personnalisés limitent les données de synchronisation d'une façon qui est inconnue à Sync Framework. Les éléments peuvent être inclus dans les filtres personnalisés et en être exclus avec le temps. Sync Framework définit des métadonnées, interfaces et classes supplémentaires, qui prennent efficacement en charge des filtres personnalisés tout en conservant une taille globale des métadonnées minimale.

Le filtre peut être défini par l'application de synchronisation, ou par le fournisseur de source ou de destination, mais il peut aussi être négocié entre ces derniers.

Le filtre est utilisé par le fournisseur de source lorsqu'il détecte des modifications. Les lots de modifications générés pendant la détection des modifications incluent uniquement les données de synchronisation qui passent le filtre.

Le filtre peut également être utilisé par le fournisseur de destination lorsqu'il applique des modifications. Les modifications appliquées au réplica de destination incluent uniquement les données de synchronisation qui passent le filtre.

Contrôle des éléments qui sont synchronisés

Un filtre d'élément définit les modifications d'élément qui sont envoyées par le fournisseur de source pendant l'énumération des modifications. La façon dont les éléments sont filtrés dépendant du type de données de l'étendue de la synchronisation, Sync Framework permet au fournisseur de source de définir le mécanisme de filtrage. Si une communication sur le filtre est nécessaire entre le fournisseur et l'application de synchronisation, elle peut être réalisée à l'aide d'un mécanisme approprié.

Lorsque le fournisseur de source filtre des modifications d'éléments, Sync Framework impose au fournisseur de source de joindre les informations relatives au filtre à tous les objets de lot de modifications envoyés pendant l'énumération des modifications. La présence d'informations de filtres d'éléments dans l'objet de lot de modifications informe Sync Framework qu'une synchronisation filtrée est en cours, ce qui permet à Sync Framework de gérer correctement la connaissance du lot de modifications filtré. Si le fournisseur de source filtre les éléments inclus dans un lot de modifications sans spécifier les informations de filtres d'éléments à l'objet de lot de modifications, Sync Framework risque de ne pas gérer correctement la connaissance.

Lorsque le fournisseur de source utilise un filtre pour restreindre les éléments contenus dans un lot de modifications, il doit joindre les informations relatives au filtre à l'objet ChangeBatch (pour le code managé) ou ISyncChangeBatch (pour le code non managé). Les informations de filtre sont représentées par un objet ItemListFilterInfo (pour le code managé) ou un objet ISyncFilterInfo dont l'indicateur SYNC_FILTER_INFO_FLAG_ITEM_LIST est défini (pour le code non managé). Dans le code non managé, le fournisseur crée un objet ISyncFilterInfo en utilisant IProviderFilteredSyncServices::CreateFilterInfo. Les informations de filtre sont jointes au lot de modifications en utilisant ChangeBatch(SyncIdFormatGroup, SyncKnowledge, ForgottenKnowledge, FilterInfo) (pour le code managé) ou IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (pour le code non managé) pour créer l'objet de lot de modifications.

Pour plus d'informations sur l'utilisation du filtrage d'éléments, consultez Procédure : filtrer des éléments énumérés.

Contrôle des unités de modification qui sont synchronisées

Un filtre d'unités de modification définit les modifications d'unités de modification qui sont incluses pour chaque modification d'élément envoyée par le fournisseur de source pendant l'énumération des modifications. Un filtre d'unités de modification est utile lorsqu'un réplica ne stocke qu'un sous-ensemble des unités de modification définies pour les éléments de l'étendue.

Par exemple, une communauté de synchronisation échange des informations de contact et définit des unités de modification pour name, phone number et address. Un réplica de la communauté est un appareil mobile qui peut stocker uniquement name et phone number. Ce réplica utilise un filtre d'unités de modification afin de spécifier qu'il ne suit la connaissance que pour ces deux unités de modification. Lorsqu'un réplica source synchronise des données vers le réplica de l'appareil, il utilise le filtre d'unités de modification de façon à n'envoyer que les informations relatives aux unités de modification name et phone number. La connaissance acquise du fournisseur de source est projetée sur le filtre d'unités de modification pour que la connaissance sur le réplica de l'appareil ne concerne que les unités de modification name et phone number. De la même façon, lorsqu'une modification est apportée localement sur l'appareil et que celui-ci fait par la suite office de réplica source dans une session de synchronisation, le réplica qui reçoit les modifications met à jour sa connaissance uniquement pour le jeu spécifié d'unités de modification.

Lorsqu'un filtre d'unités de modification est utilisé, Sync Framework projette la connaissance acquise pour le lot de modifications sur le jeu d'unités de modification spécifié par le filtre afin que la connaissance acquise pour le lot de modifications ne contienne que les informations relatives au jeu spécifié d'unités de modification.

Pour filtrer des modifications d'unités de modification, le fournisseur de source crée un objet ChangeUnitListFilterInfo (pour le code managé) ou IChangeUnitListFilterInfo (pour le code non managé) et spécifie le jeu des unités de modification synchronisées. Dans le code non managé, l'objet IChangeUnitListFilterInfo est créé en spécifiant SYNC_FILTER_INFO_FLAG_CHANGE_UNIT_LIST pour la méthode IProviderFilteredSyncServices::CreateFilterInfo. Le fournisseur de source joint les informations de filtre au lot de modifications en utilisant ChangeBatch(SyncIdFormatGroup, SyncKnowledge, ForgottenKnowledge, FilterInfo) (pour le code managé) ou IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (pour le code non managé) pour créer l'objet de lot de modifications.

Pour plus d'informations sur l'utilisation d'un filtre d'unité de modification, consultez Procédure : filtrer des unités de modification énumérées.

Contrôle des éléments qui sont synchronisés à l'aide d'un filtre personnalisé

Un filtre personnalisé est défini en dehors de Sync Framework, en général par un développeur de fournisseur, mais il peut également être défini par un tiers. Sync Framework n'a aucune connaissance de la façon dont le filtre détermine ce qu'il convient d'inclure dans l'étendue de la synchronisation. Un filtre personnalisé peut être défini de telle façon que les éléments soient inclus dans le filtre et en soient exclus avec le temps. Par exemple, sur un réplica qui stocke des fichiers multimédias, un filtre peut être défini pour inclure tous les fichiers classés trois étoiles ou plus. Lorsque l'utilisateur modifie le classement d'un fichier, il peut être inclus dans le filtre ou en être exclu.

N'oubliez pas que les filtres personnalisés ne peuvent pas être utilisés par des fournisseurs simples, ou par des fournisseurs qui signalent des conflits de contraintes ou qui utilisent le service d'application de modifications, sinon des résultats inattendus peuvent se produire.

Pour prendre efficacement en charge des filtres personnalisés, Sync Framework définit plusieurs nouveaux concepts.

Un réplica de suivi de filtre est un réplica qui gère les métadonnées qui définissent les éléments et unités de modification qui se trouvent actuellement dans un filtre suivi, les éléments et unités de modification qui ont été récemment inclus et exclus, et la connaissance oubliée du filtre qui couvre l'ensemble des éléments et unités de modification qui ne sont pas dans le filtre suivi et ont été oubliés. Le suivi d'un filtre n'affecte pas les éléments qui sont stockés dans un réplica. Un réplica peut effectuer le suivi de plusieurs filtres tout en stockant tous les éléments dans l'étendue de la synchronisation. En général, un réplica de suivi de filtre peut fournir un lot de modifications filtré pour tous ses filtres suivis.
Un réplica filtré est un réplica qui stocke uniquement les données d'élément et d'unité de modification pour les éléments et unités de modification qui sont dans le filtre, ainsi que les métadonnées pour les éléments et unités de modification qui étaient dans le filtre, mais ont été exclus. Un réplica filtré effectue toujours le suivi du filtre qu'il utilise et peut également effectuer celui d'autres filtres. Un fournisseur de destination filtré peut demander une énumération des modifications filtrée auprès du fournisseur de source, ou il peut demander une énumération des modifications complète et filtrer les modifications lui-même pendant l'application des modifications.
Les fantômes sont des éléments ou unités de modification dans un réplica filtré qui étaient dans le filtre et ont été exclus. Le réplica filtré stocke des métadonnées pour les fantômes, mais ne stocke pas de données d'élément ni d'unité de modification.
La connaissance oubliée du filtre définit un point de départ pour le suivi de filtre. Un réplica de suivi de filtre peut enregistrer l'espace de stockage en supprimant des fantômes et en avançant la connaissance oubliée du filtre pour contenir la version la plus récente des fantômes supprimés. La connaissance oubliée du filtre est également utilisée lorsqu'un réplica commence à suivre un filtre après que celui-ci a été utilisé par d'autres réplicas dans la communauté de synchronisation.

Suivi de filtres

Il est recommandé que tous les réplicas dans une communauté de synchronisation effectuent le suivi des filtres utilisés dans la communauté. Lorsqu'un réplica filtré reçoit une énumération des modifications filtrée d'un réplica de suivi de filtre, la taille de la connaissance du réplica filtré est minimisée. Lorsqu'un réplica filtré reçoit une énumération des modifications filtrée d'un réplica qui ne suit pas le filtre, la taille de la connaissance augmente par rapport au nombre de modifications envoyé.

Pour plus d'informations sur le suivi des filtres, consultez Procédure : suivre des filtres et énumérer des modifications filtrées.

Métadonnées de filtre

Pour effectuer le suivi d'un filtre, un réplica stocke des métadonnées de filtre pour chaque élément ou unité de modification dans le réplica. Les métadonnées de filtre contiennent les éléments dans le tableau suivant :

Est dans le filtre	Version de déplacement
Indique si l'élément ou l'unité de modification est dans le filtre.	Version de la modification qui a provoqué l'inclusion ou l'exclusion de l'élément par rapport au filtre. Lorsqu'un élément est créé et qu'il est dans le filtre, cette version est définie sur la version de création de l'élément. Lorsqu'un élément n'a jamais été dans le filtre, cette version a pour valeur (0,0).

Lorsqu'un réplica commence à effectuer le suivi d'un filtre, tous les éléments ou unités de modification doivent être évalués par rapport au filtre. Si un élément ou une unité de modification est dans le filtre, ses métadonnées de filtre doivent indiquer sa présence dans le filtre et sa version de déplacement doit être définie sur la version de modification la plus récente de l'élément ou de l'unité de modification. Si un élément n'est pas dans le filtre, ses métadonnées de filtre doivent indiquer son absence et sa version de déplacement doit avoir pour valeur (0,0).

Un réplica de suivi de filtre peut également stocker la connaissance oubliée du filtre pour chaque filtre suivi. Lorsqu'un réplica de suivi de filtre effectue le suivi d'un filtre depuis l'origine du filtre, il ne stocke pas la connaissance oubliée du filtre à moins de recevoir des données de synchronisation d'un réplica qui n'effectue pas le suivi du filtre. Lorsqu'un réplica de suivi de filtre commence à suivre un filtre un peu après son origine, il doit initialiser la connaissance oubliée du filtre vers la connaissance actuelle du réplica. Lorsque les objets tombstone et métadonnées de modification du filtre sont nettoyées sur un réplica, la connaissance oubliée du filtre peut être ignorée et la connaissance oubliée utilisée à la place.

Négociation des filtres faisant l'objet d'un suivi

Un fournisseur de suivi des filtres doit implémenter IFilterTrackingProvider (pour le code managé) ou IFilterTrackingProvider (pour le code non managé). Cette interface est utilisée pour communiquer les filtres suivis à la fois sur le réplica source et le réplica de destination. Le réplica source envoie des métadonnées de filtre pour les filtres suivis à la fois sur le réplica source et le réplica de destination.

Lorsque les deux fournisseurs dans une session de synchronisation sont des fournisseurs de suivi des filtres, Sync Framework arbitre la négociation des filtres faisant l'objet d'un suivi par les deux fournisseurs. Les filtres suivis sont négociés entre deux fournisseurs de suivi des filtres en procédant comme suit :

Après avoir appelé BeginSession (pour le code managé) ou IKnowledgeSyncProvider::BeginSession (pour le code non managé), Sync Framework appelle SpecifyTrackedFilters (pour le code managé) ou IFilterTrackingProvider::SpecifyTrackedFilters (pour le code non managé) sur le fournisseur de destination.
Le fournisseur de destination énumère sa liste de filtres suivis et passe chacun d'eux au délégué RequestTrackedFilterCallback (pour le code managé) ou à la méthode IFilterRequestCallback::RequestFilter de l'objet IFilterRequestCallback (pour le code non managé) spécifié dans l'appel à SpecifyTrackedFilters.
Pour chaque filtre spécifié par le fournisseur de destination, Sync Framework appelle TryAddTrackedFilter (pour le code managé) ou IFilterTrackingProvider::AddTrackedFilter (pour le code non managé) sur le fournisseur de source.
Le fournisseur de source gère une liste de filtres suivis par le fournisseur de destination et retourne une valeur qui indique s'il effectue le suivi du filtre spécifié.
Sync Framework passe cette valeur au fournisseur de destination.

Envoi de métadonnées de filtre pour les filtres suivis

Lorsque le fournisseur de destination effectue le suivi des filtres que le fournisseur de source suit également, le fournisseur de source doit envoyer des métadonnées de filtre pour les filtres mutuellement suivis. Pour cela, ajoutez les modifications suivantes à l'implémentation de fournisseur de source de GetChangeBatch (pour le code managé) ou IKnowledgeSyncProvider::GetChangeBatch (pour le code non managé) :

Ajoutez un objet FilterKeyMap à l'objet ChangeBatch en définissant la propriété FilterKeyMap (pour le code managé) ou ajoutez un objet IFilterKeyMap à l'objet ISyncChangeBatchWithFilterKeyMap en appelant ISyncChangeBatchWithFilterKeyMap::SetFilterKeyMap (pour le code non managé). L'objet de mappage de touches filtre contient les filtres suivis à la fois par le fournisseur de source et le fournisseur de destination. La propriété FilterKeyMap doit être définie (pour le code managé) ou la méthode SetFilterKeyMap appelée (pour le code non managé) avant que des groupes ne soient démarrés dans le lot de modifications.
Pour chaque groupe dans le lot de modifications, ajoutez la connaissance oubliée du filtre pour les filtres suivis en appelant SetFilterForgottenKnowledge (pour le code managé) ou ISyncChangeBatchWithFilterKeyMap::SetFilterForgottenKnowledge (pour le code non managé).
Envoyez des métadonnées de modification du filtre pour chaque élément ou unité de modification qui a été inclus dans un filtre suivi ou en a été exclu. Les métadonnées de modification du filtre sont ajoutées à une modification en appelant AddFilterChange (pour le code managé) ou IFilterTrackingSyncChangeBuilder::AddFilterChange (pour le code non managé). Les propriétés FilterChange (pour le code managé) ou valeurs SYNC_FILTER_CHANGE (pour le code non managé) indiquent si l'élément est inclus dans le filtre ou exclu du filtre ainsi que la version de la modification qui a provoqué le déplacement. Les métadonnées de modification du filtre sont ajoutées uniquement quand la version de déplacement n'est pas contenue dans la connaissance de destination de l'élément. Lorsque les unités de modification sont utilisées, les métadonnées de modification du filtre doivent être ajoutées si la version de déplacement n'est pas contenue dans la connaissance de destination de l'une des unités de modification. Gardez à l'esprit que les versions de déplacement étant considérées comme des versions d'éléments même lorsque des unités de modification sont utilisées, la relation contenant-contenu doit être vérifiée à l'aide d'une forme de la méthode Contains (pour le code managé) ou de la méthode ISyncKnowledge::ContainsChange (pour le code non managé) qui accepte une version d'élément et non une qui utilise une version d'unité de modification.
Lorsque les unités de modification sont utilisées et qu'au moins une modification d'unité de modification n'est pas contenue dans la connaissance de destination, appelez ContainsMarker (pour le code managé) ou IKnowledgeWithMarkers::ContainsAllChangeUnitsRequiredMarker (pour le code non managé) sur la connaissance de destination, en spécifiant AllChangeUnitsRequired et l'ID d'élément de l'élément propriétaire (pour le code managé) ou l'ID d'élément de l'élément propriétaire (pour le code non managé). Si cette méthode indique que toutes les unités de modification sont requises, envoyez toutes les unités de modification pour l'élément et appelez SetAllChangeUnitsPresent sur l'objet ItemChange (pour le code managé) ou IFilterTrackingSyncChangeBuilder::SetAllChangeUnitsPresentFlag (pour le code non managé).

Envoi de modifications filtrées

En général, un fournisseur de source qui représente un réplica de suivi de filtre peut énumérer des lots de modifications filtrées pour chacun des filtres suivis. Le filtre peut être identifié par l'application, en utilisant un mécanisme personnalisé entre l'application et le fournisseur de source, ou il peut être négocié entre le fournisseur de source et le fournisseur de destination. La négociation des filtres est décrite plus loin dans ce document.

Pour envoyer un lot de modifications filtrées, ajoutez les éléments suivants à la méthode GetChangeBatch du fournisseur de source :

Créez un objet CustomFilterInfo (pour le code managé) ou ICustomFilterInfo (pour le code non managé) qui contient le filtre utilisé pour la synchronisation. Créez un objet de lot de modifications filtrées en passant l'objet des informations de filtre au constructeur du lot de modifications approprié ChangeBatch (pour le code managé) ou en appelant IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (pour le code non managé). Par ailleurs, passez la connaissance oubliée du filtre lors de la création de l'objet de lot de modifications, au lieu de la connaissance oubliée du réplica.
Lorsqu'un élément ou une unité de modification figurait précédemment dans le filtre, mais n'y est pas actuellement, spécifiez la propriété ChangeKind comme Ghost (pour le code managé) ou passez l'indicateur SYNC_CHANGE_FLAG_GHOST à ISyncChangeBatchBase::AddItemMetadataToGroup (pour le code non managé).
Lorsque le type de filtrage du fournisseur de destination est CurrentItemsOnly (pour le code managé) ou FT_CURRENT_ITEMS_ONLY (pour le code non managé), incluez un élément dans le lot de modifications uniquement s'il est dans le filtre. Autrement dit, n'envoyez pas de fantômes.
Lorsque le type de filtrage du fournisseur de destination est CurrentItemsAndVersionsForMovedOutItems (pour le code managé) ou FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (pour le code non managé), incluez des éléments qui sont dans le filtre et des éléments qui ont été exclus. Les informations d'exclusion doivent être envoyées quand un élément ou une unité de modification était précédemment dans le filtre, l'élément ou l'unité de modification n'est actuellement pas dans le filtre, et la version de la modification qui a exclu l'élément ou l'unité de modification hors du filtre n'est pas contenue par la connaissance de destination.

Application des métadonnées de filtre

Lorsqu'un fournisseur de destination représente un fournisseur de suivi des filtres et utilise un applicateur de modifications pour appliquer des modifications au réplica de destination, le fournisseur de destination doit implémenter IFilterTrackingNotifyingChangeApplierTarget (pour le code managé) ou IFilterTrackingNotifyingChangeApplierTarget (pour le code non managé). Cette interface contient des méthodes que Sync Framework utilise pour obtenir le mappage de touches filtre et la connaissance oubliée du filtre des filtres suivis. Elle contient également la méthode SaveKnowledgeWithFilterForgottenKnowledge (pour le code managé) ou IFilterTrackingNotifyingChangeApplierTarget::SaveKnowledgeWithFilterForgottenKnowledges (pour le code non managé), que Sync Framework appelle au lieu de StoreKnowledgeForScope (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (pour le code non managé) pour les fournisseurs de suivi des filtres. Sync Framework utilise cette méthode pour envoyer la connaissance mise à jour, la connaissance oubliée et la connaissance oubliée du filtre au fournisseur après l'application d'un lot de modifications.

En plus d'implémenter IFilterTrackingNotifyingChangeApplierTarget, la méthode SaveItemChange ou SaveChangeWithChangeUnits (pour le code managé), ou ISynchronousNotifyingChangeApplierTarget::SaveChange ou ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (pour le code non managé) du fournisseur de destination doit être mise à jour pour effectuer les étapes suivantes :

Obtenez les métadonnées de modification du filtre pour chaque filtre suivi en appelant GetFilterChange(UInt32) (pour le code managé) ou ISyncChangeWithFilterKeyMap::GetFilterChange (pour le code non managé) sur l'objet de modification.
Lorsque des métadonnées de modification du filtre sont présentes, vérifiez qu'elles ne sont pas obsolètes. Une modification de filtre est obsolète lorsque sa version de déplacement est contenue par la connaissance de destination de l'élément. Lorsque les unités de modification sont utilisées, une modification du filtre est obsolète uniquement si la version de déplacement est contenue dans la connaissance de destination de toutes les unités de modification. Si la modification du filtre est obsolète, ne l'appliquez pas au réplica de destination.
Lorsque les métadonnées de modification du filtre sont présentes et ne sont pas obsolètes, vérifiez qu'elles ne sont pas en conflit avec les informations de modification du filtre déjà présentes dans le réplica de destination. Pour rechercher les conflits, effectuez les étapes suivantes :
1. Obtenez la version de déplacement actuellement stockée pour l'élément ou l'unité de modification dans le réplica de destination.
2. Vérifiez si la version de déplacement est contenue dans la connaissance courante de l'élément ou dans la connaissance courante de chaque modification d'unité de modification associée à l'élément.
3. Si la version de déplacement n'est pas contenue dans la connaissance courante appropriée, la modification de filtre est en conflit. Le fournisseur de destination doit la résoudre de façon appropriée et attribuer une nouvelle version de déplacement pour la modification.
4. Si aucun conflit n'est détecté avec la version de déplacement, vérifiez l'indicateur d'inclusion de la modification du filtre de la source par rapport à l'indicateur d'inclusion de l'élément de destination ou de l'unité de modification. Si la valeur de l'indicateur est incohérente, le fournisseur de destination doit évaluer l'élément ou l'unité de modification par rapport au filtre et attribuer la valeur d'indicateur d'inclusion correcte avec une nouvelle version de déplacement.
5. Si aucun conflit n'est détecté, stockez les métadonnées de modification du filtre avec les métadonnées pour l'élément.
Lorsque les métadonnées de modification du filtre ne sont pas présentes pour un filtre suivi, ou pour un filtre qui est suivi par le réplica de destination mais pas par le réplica source, évaluez la modification par rapport au filtre sur la destination. Mettez à jour les métadonnées de filtre afin qu'elles incluent la présence ou non de l'élément dans le filtre, et mettez à jour la version de déplacement vers la version de la modification si cette dernière a entraîné le déplacement de l'élément par rapport au filtre. Lorsque plusieurs unités de modification sont associées à un filtre et qu'une modification apportée à l'une d'entre elles entraîne le déplacement de l'élément par rapport au filtre, créez une nouvelle version locale et attribuez-la en tant que version de déplacement de l'élément et en tant que version de modification pour toutes les unités de modification associées au filtre.

Réplicas filtrés

Un réplica filtré stocke uniquement les données d'élément et d'unité de modification pour les éléments et unités de modification qui sont dans son filtre, ainsi que les fantômes, qui sont des métadonnées pour les éléments et unités de modification qui étaient dans le filtre, mais ont été exclus. Un réplica filtré effectue aussi le suivi de son filtre et peut également effectuer celui d'autres filtres. Un réplica filtré peut négocier un filtre avec le fournisseur de source, auquel cas le fournisseur de source produit un lot de modifications filtrées. Si le fournisseur de source ne peut pas produire de lot de modifications filtrées, le fournisseur filtré peut filtrer les modifications lui-même et appliquer uniquement celles qui sont dans son filtre.

Pour plus d'informations sur l'implémentation d'un réplica filtré, consultez Procédure : filtrer un réplica.

Énumération des éléments inclus dans le filtre

Un réplica filtré implémente l'interface IFilteredReplicaNotifyingChangeApplierTarget (pour le code managé) ou IFilteredReplicaNotifyingChangeApplierTarget (pour le code non managé). Cette interface contient le GetNewMoveInItems (pour le code managé) ou IFilteredReplicaNotifyingChangeApplierTarget::GetNewMoveins (pour le code non managé), que Sync Framework utilise pour obtenir les éléments qui ont été inclus dans le filtre après un certain moment. Un élément est ajouté à la liste retournée à partir de cette méthode lorsque l'élément est actif, l'élément est dans le filtre et la version de déplacement de l'élément n'est pas contenue dans la connaissance spécifiée à la méthode.

Envoi de modifications non filtrées

Lorsque le réplica filtré est le réplica source et que le réplica de destination ne demande pas d'énumération des modifications filtrées, ou qu'un filtre n'est pas négocié avec succès entre les deux réplicas, le réplica source énumère les modifications comme s'il n'était pas filtré. Ce processus diffère du processus d'envoi de modifications filtrées en raison des éléments suivants :

Un lot de modifications non filtrées est créé.
La connaissance oubliée du réplica est passée lors de la création du lot de modifications et non pas la connaissance oubliée du filtre comme lorsque les modifications filtrées sont envoyées.

Application des modifications filtrées

Lorsque le fournisseur de destination utilise un applicateur de modifications, il doit indiquer si l'élément de destination ou l'unité de modification est un fantôme lorsqu'il envoie des versions de destination à l'applicateur de modifications. Pour cela, spécifiez Ghost pour la propriété ChangeKind (pour le code managé) ou passez l'indicateur SYNC_CHANGE_FLAG_GHOST à IDestinationChangeVersionsBuilder::AddItemMetadata (pour le code non managé) lorsque l'élément est un fantôme dans le réplica de destination. Un élément est un fantôme lorsque des métadonnées existent pour l'élément dans le magasin des métadonnées de destination, l'élément n'a pas été supprimé et aucune donnée n'existe pour l'élément dans le magasin de destination.

Lorsque les modifications du fournisseur de source ne sont pas filtrées, le fournisseur de destination évalue toutes les modifications envoyées par le fournisseur de source par rapport au filtre du réplica de destination. Le fournisseur de destination applique les modifications qui passent le filtre et met à jour les fantômes affectés. Le fournisseur de destination exclut toutes les modifications ignorées de la connaissance du lot de modifications.

Le fournisseur de destination doit également apporter les modifications suivantes à sa méthode SaveItemChange ou SaveChangeWithChangeUnits (pour le code managé), ou ISynchronousNotifyingChangeApplierTarget::SaveChange ou ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (pour le code non managé).

Gérez les actions CreateGhost et UpdateGhost (pour le code managé) ou SSA_CREATE_GHOST ou SSA_UPDATE_GHOST (pour le code non managé) en créant ou mettant à jour les métadonnées pour un fantôme. Les métadonnées de modification du filtre doivent également être mises à jour, le cas échéant.
Gérez l'action MarkItemAsGhost (pour le code managé) ou SSA_GHOST_ITEM (pour le code non managé) en supprimant les données pour l'élément ou l'unité de modification et en mettant à jour les métadonnées pour l'élément ou l'unité de modification pour refléter la modification.
Gérez l'action UnmarkItemAsGhost (pour le code managé) ou SSA_UNGHOST_ITEM (pour le code non managé) en récupérant les données pour l'élément ou l'unité de modification, en stockant les données dans le réplica de destination et en mettant à jour les métadonnées pour refléter la modification.
Gérez l'action DeleteGhostAndStoreTombstone (pour le code managé) ou SSA_DELETE_GHOST_AND_STORE_TOMBSTONE (pour le code non managé) en marquant les métadonnées pour le fantôme comme étant supprimées.

Nettoyage des fantômes

Pour libérer de l'espace de stockage sur un réplica filtré, les fantômes peuvent être supprimés. Lorsqu'un fantôme est supprimé, la connaissance oubliée pour le filtre doit être mise à jour en passant la version de déplacement du fantôme à la méthode ForgetTo (pour le code managé) ou IForgottenKnowledge::ForgetToVersion (pour le code non managé) de la connaissance oubliée du filtre.

Négociation du filtre

Le fournisseur de destination peut spécifier le filtre utilisé par le fournisseur de source pendant l'énumération des modifications. Le fournisseur de source peut accepter ou refuser le filtre que le fournisseur de destination demande. Le fournisseur de destination peut continuer à demander des filtres jusqu'à ce que le fournisseur de source en accepte un. Sync Framework sert de médiateur dans cette négociation. Le filtre peut être de n'importe quel type dès lors qu'il convient aux fournisseurs.

Pour participer à la négociation du filtre, le fournisseur de source doit implémenter ISupportFilteredSync (pour le code managé) ou ISupportFilteredSync (pour le code non managé) et le fournisseur de destination doit implémenter IRequestFilteredSync (pour le code managé) ou IRequestFilteredSync (pour le code non managé).

Pour négocier l'utilisation des filtres, procédez comme suit :

Avant que le fournisseur de source ne commence à énumérer les modifications et après avoir appelé BeginSession (pour le code managé) ou IKnowledgeSyncProvider::BeginSession (pour le code non managé), Sync Framework démarre la négociation des filtres en appelant la méthode SpecifyFilter (pour le code managé) ou IRequestFilteredSync::SpecifyFilter (pour le code non managé) sur le fournisseur de destination.
Lors du traitement de SpecifyFilter, le fournisseur de destination passe des filtres au délégué FilterRequestCallback (pour le code managé) ou à la méthode IFilterRequestCallback::RequestFilter (pour le code non managé) spécifié par Sync Framework. Lorsque le fournisseur de destination n'effectue pas le suivi du filtre demandé, il spécifie un type de filtrage de CurrentItemsOnly (pour le code managé) ou FT_CURRENT_ITEMS_ONLY (pour le code non managé). Lorsque le fournisseur de destination effectue le suivi du filtre demandé, il spécifie un type de filtrage de CurrentItemsAndVersionsForMovedOutItems (pour le code managé) ou FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (pour le code non managé).
Lors du traitement de FilterRequestCallback (pour le code managé) ou RequestFilter (pour le code non managé), Sync Framework appelle la méthode TryAddFilter(Object) (pour le code managé) ou ISupportFilteredSync::AddFilter (pour le code non managé) du fournisseur de source. Si le fournisseur de source ne prend pas en charge le filtre demandé, le fournisseur de destination peut continuer à demander des filtres jusqu'à ce qu'il en trouve un pris en charge.
Si le fournisseur de destination ne peut pas trouver un filtre accepté par le fournisseur de source, il peut terminer la synchronisation en levant SyncInvalidOperationException (pour le code managé) ou en retournant un code d'erreur, tel que SYNC_E_FILTER_NOT_SUPPORTED, (pour le code non managé).

Lorsqu'un filtre a été négocié avec succès, le fournisseur de source l'utilise pour déterminer les éléments à inclure pendant l'énumération des modifications.

Pour plus d'informations sur la négociation de filtres, consultez Procédure : négocier un filtre.