Filtro dei dati di sincronizzazione

Viene utilizzato un filtro per limitare i dati sottoposti a sincronizzazione. In genere, il provider di origine applica il filtro durante l'enumerazione delle modifiche per limitare le modifiche inviate. Sync Framework supporta i tipi di filtro seguenti.

• I filtri degli elementi limitano i dati di sincronizzazione a un subset di elementi, ad esempio per sincronizzare solo i file con estensione txt tra due cartelle di file, ignorando file di altri tipi. Gli elementi non vengono modificati in modo da causare lo spostamento di un elemento esistente all'interno o all'esterno del filtro. L'utilizzo dei filtri degli elementi è semplice ma le dimensioni dei metadati utilizzati per la sincronizzazione aumentano proporzionalmente al numero di elementi che si trovano nell'ambito di sincronizzazione.

• I filtri delle unità di modifica limitano i dati di sincronizzazione a un subset di unità di modifica, ad esempio per sincronizzare solo i campi name e phone number di un contatto, ignorando le unità di modifica rimanenti.

• I filtri personalizzati limitano i dati di sincronizzazione in un modo sconosciuto a Sync Framework. Gli elementi possono essere spostati all'interno e all'esterno dei filtri personalizzati nel tempo. Sync Framework definisce metadati, interfacce e classi aggiuntive che supportano in modo efficiente i filtri personalizzati mantenendo contenute le dimensioni generali dei metadati.

Il filtro può essere definito dall'applicazione di sincronizzazione o dal database di origine o di destinazione oppure può essere negoziato tra i provider di origine e di destinazione.

Il filtro viene utilizzato dal provider di origine quando vengono rilevate modifiche. La compilazione di batch di modifiche durante il rilevamento delle modifiche include solo i dati di sincronizzazione che passano il filtro.

Il filtro può inoltre essere utilizzato dal provider di destinazione per l'applicazione delle modifiche. Le modifiche applicate alla replica di destinazione includono solo i dati di sincronizzazione che passano il filtro.

Controllo degli elementi sincronizzati

Il filtro di un elemento definisce le modifiche dell'elemento che vengono inviate dal provider di origine durante l'enumerazione delle modifiche. Poiché il modo in cui vengono filtrati gli elementi dipende dal tipo di dati nell'ambito di sincronizzazione, Sync Framework consente al provider di origine di definire il meccanismo di filtro. Se è necessaria la comunicazione relativa al filtro tra il provider e l'applicazione di sincronizzazione, è possibile ottenerla tramite qualsiasi meccanismo si ritenga appropriato.

Quando il provider di origine filtra le modifiche dell'elemento, Sync Framework richiede che il provider di origine colleghi le informazioni sul filtro a tutti gli oggetti batch di modifiche inviati durante l'enumerazione delle modifiche. La presenza di informazioni sul filtro degli elementi nell'oggetto batch di modifiche indica a Sync Framework che è in corso una sincronizzazione filtrata, in modo che la conoscenza per il batch di modifiche filtrato possa essere gestita da Sync Framework in modo corretto. Se il provider di origine filtra gli elementi inclusi in un batch di modifiche ma non specifica le informazioni sul filtro degli elementi all'oggetto batch di modifiche, Sync Framework potrebbe non gestire correttamente la conoscenza.

Quando il provider di origine utilizza un filtro per limitare gli elementi contenuti in un batch di modifiche, il provider deve collegare le informazioni sul filtro all'oggetto ChangeBatch (per il codice gestito) o all'oggetto ISyncChangeBatch (per il codice non gestito). Le informazioni sul filtro vengono rappresentate da un oggetto ItemListFilterInfo (per il codice gestito) o da un oggetto ISyncFilterInfo con il flag SYNC_FILTER_INFO_FLAG_ITEM_LIST impostato (per il codice non gestito). Nel codice non gestito, il provider crea un oggetto ISyncFilterInfo tramite IProviderFilteredSyncServices::CreateFilterInfo. Le informazioni sul filtro sono collegate al batch di modifiche tramite ChangeBatch (per il codice gestito) o tramite IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (per il codice non gestito) per creare l'oggetto batch di modifiche.

Per ulteriori informazioni su come utilizzare il filtro di elementi, vedere Procedura: filtrare gli elementi enumerati.

Controllo delle unità di modifica sincronizzate

Il filtro delle unità di modifica definisce le modifiche dell'unità di modifica incluse per ciascuna modifica di elemento inviata dal provider di origine durante l'enumerazione delle modifiche. Il filtro delle unità di modifica è utile quando una replica archivia solo un subset delle unità di modifica definite per gli elementi nell'ambito.

Ad esempio, una community di sincronizzazione scambia informazioni sui contatti e definisce unità di modifica per name, phone number e address. Una replica nella community è un dispositivo portatile che può archiviare solo name e phone number. Questa replica utilizza un filtro delle unità di modifica per specificare che può rilevare la conoscenza solo per queste due unità di modifica. Quando una replica di origine sincronizza i dati nella replica del dispositivo, utilizza il filtro delle unità di modifica per inviare le informazioni relative solo alle unità di modifica name e phone number. La conoscenza acquisita dal provider di origine viene proiettata sul filtro delle unità di modifica in modo che la conoscenza sulla replica del dispositivo contenga la conoscenza relativa solo alle unità di modifica name e phone number. Analogamente, quando una modifica viene apportata in locale sul dispositivo e il dispositivo viene utilizzato come replica di origine in una sessione di sincronizzazione, la replica che riceve le modifiche aggiorna la relativa conoscenza solo per il set di unità di modifica specificato.

Quando viene utilizzato un filtro delle unità di modifica, la conoscenza acquisita per il batch di modifiche viene proiettata da Sync Framework sul set di unità di modifica specificate dal filtro in modo che la conoscenza acquisita per il batch di modifiche contenga solo le informazioni relative al set di unità di modifica specificato.

Per filtrare le modifiche di unità di modifica, il provider di origine crea un oggetto ChangeUnitListFilterInfo (per il codice gestito) o un oggetto IChangeUnitListFilterInfo (per il codice non gestito) e specifica il set di unità di modifica sincronizzate. Nel codice non gestito, l'oggetto IChangeUnitListFilterInfo viene creato specificando SYNC_FILTER_INFO_FLAG_CHANGE_UNIT_LIST per il metodo IProviderFilteredSyncServices::CreateFilterInfo. Il provider di origine collega le informazioni sul filtro al batch di modifiche tramite ChangeBatch (per il codice gestito) o tramite IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (per il codice non gestito) per creare l'oggetto batch di modifiche.

Per ulteriori informazioni su come utilizzare un filtro delle unità di modifica, vedere Procedura: filtrare unità di modifica enumerate.

Controllo degli elementi sincronizzati tramite un filtro personalizzato

Un filtro personalizzato viene definito all'esterno di Sync Framework, in genere da uno sviluppatore del provider, sebbene possa essere definito anche da terze parti. A Sync Framework non è noto il modo in cui il filtro determina gli elementi da includere nell'ambito di sincronizzazione. Un filtro personalizzato può essere definito in modo tale che gli elementi vengono spostati all'interno e all'esterno del filtro nel tempo. Ad esempio, in una replica che archivia file multimediali, è possibile definire un filtro che includa tutti i file valutati con almeno tre stelle. Se l'utente modifica la valutazione di un file, questo può essere spostato all'interno o all'esterno del filtro.

Si tenga presente che i filtri personalizzati non possono essere utilizzati da provider semplici o da provider che segnalano conflitti di vincoli o utilizzano il servizio di applicazione modifiche. In caso contrario, possono verificarsi risultati imprevisti.

Per supportare in modo efficiente i filtri personalizzati, in Sync Framework sono definiti diversi concetti nuovi.

• Una replica di rilevamento dei filtri è una replica che gestisce i metadati, che definisce quali elementi e unità di modifica si trovano attualmente in un filtro rilevato, quali elementi e unità di modifica sono stati recentemente spostati all'interno o all'esterno del filtro rilevato nonché la conoscenza dimenticata relativa ai filtri che riguarda tutti gli elementi e le unità di modifica che non si trovano nel filtro rilevato e sono stati dimenticati. Il rilevamento di un filtro non influisce sugli elementi archiviati in una replica. Una replica può rilevare più filtri durante l'archiviazione di tutti gli elementi nell'ambito di sincronizzazione. In genere, una replica di rilevamento dei filtri può fornire un batch di modifiche filtrato per qualsiasi relativo filtro rilevato.

• Una replica filtrata è una replica che archivia i dati relativi all'elemento e all'unità di modifica solo per gli elementi e le unità di modifica che si trovano nel filtro nonché i metadati per gli elementi e le unità di modifica che si trovavano nel filtro ma che sono stati spostati. Una replica filtrata rileva sempre il filtro utilizzato, ma può rilevare anche filtri aggiuntivi. Un provider di destinazione filtrato può richiedere un'enumerazione delle modifiche filtrato dal provider di origine oppure può richiedere un'enumerazione delle modifiche completa e filtrare autonomamente le modifiche durante la relativa applicazione.

• Gli elementi fantasma sono gli elementi o le unità di modifica di una replica filtrata che si trovavano nel filtro e sono stati spostati. La replica filtrata archivia i metadati per gli elementi fantasma ma non archivia i dati relativi all'elemento o all'unità di modifica.

• La conoscenza dimenticata relativa ai filtri definisce un punto iniziale per il rilevamento del filtro. La replica di rilevamento dei filtri consente di risparmiare spazio di archiviazione rimuovendo gli elementi fantasma e aumentando la conoscenza dimenticata relativa ai filtri per contenere la versione più alta degli elementi fantasma che sono stati rimossi. La conoscenza dimenticata relativa ai filtri viene utilizzata inoltre quando una replica inizia il rilevamento di un filtro dopo che il filtro è stato utilizzato da altre repliche nella community di sincronizzazione.

Rilevamento dei filtri

È consigliabile che tutte le repliche di una community di sincronizzazione rilevino i filtri utilizzati nella community. Quando una replica filtrata riceve un'enumerazione delle modifiche filtrata da una replica di rilevamento dei filtri, le dimensioni della conoscenza della replica filtrata rimangono contenute. Quando una replica filtrata riceve un'enumerazione delle modifiche filtrata da una replica che non rileva il filtro, le dimensioni della conoscenza aumentano in modo proporzionale al numero di modifiche inviate.

Per ulteriori informazioni sul rilevamento dei filtri, vedere Procedura: rilevare i filtri ed enumerare le modifiche filtrate.

Metadati dei filtri

Per rilevare un filtro, una replica archivia i metadati dei filtri per ogni elemento o unità di modifica che si trova nella replica. I metadati dei filtri contengono gli elementi indicati nella tabella seguente:

Elemento nel filtro	Versione di trasferimento
Indica se l'elemento o l'unità di modifica è nel filtro.	Versione della modifica che ha determinato lo spostamento dell'elemento in relazione al filtro. Quando un elemento viene creato e si trova nel filtro, questa versione viene impostata sulla versione di creazione dell'elemento. Se un elemento non è mai stato nel filtro, questa versione viene impostata su (0,0).

Quando una replica inizia il rilevamento di un filtro, tutti gli elementi o unità di modifica devono essere valutati rispetto al filtro. Se un elemento o unità di modifica è nel filtro, i relativi metadati del filtro devono indicare che si trova nel filtro e la versione di trasferimento corrispondente deve essere impostata sulla versione di modifica più recente dell'elemento o dell'unità di modifica. Se un elemento non è nel filtro, i relativi metadati dei filtri devono indicare che non si trovano nel filtro e la versione di trasferimento corrispondente deve essere impostata su (0,0).

Una replica di rilevamento dei filtri può archiviare inoltre la conoscenza dimenticata relativa ai filtri per ogni filtro rilevato. Quando una replica di rilevamento dei filtri rileva un filtro dall'origine del filtro, questa non archivia la conoscenza dimenticata relativa ai filtri finché non riceve i dati di sincronizzazione da una replica che non rileva il filtro. Quando una replica di rilevamento dei filtri inizia il rilevamento di un filtro dopo la generazione di quest'ultimo, tale replica deve inizializzare la conoscenza dimenticata relativa ai filtri nella conoscenza corrente della replica. Quando le rimozioni definitive e i metadati delle modifiche del filtro vengono puliti in una replica, la conoscenza dimenticata relativa ai filtri può essere eliminata ed essere utilizzata invece la conoscenza dimenticata.

Negoziazione dei filtri rilevati

Il provider di rilevamento dei filtri deve implementare IFilterTrackingProvider (per il codice gestito) o IFilterTrackingProvider (per il codice non gestito). Questa interfaccia viene utilizzata per comunicare i filtri rilevati sia nella replica di origine sia in quella di destinazione. La replica di origine invia metadati dei filtri per i filtri rilevati sia nella replica di origine sia in quella di destinazione.

Se entrambi i provider di una sessione di sincronizzazione sono provider di rilevamento dei filtri, Sync Framework funge da intermediario nella negoziazione dei filtri rilevati da entrambi i provider. I filtri rilevati vengono negoziati tra i due provider di rilevamento dei filtri tramite i passaggi seguenti:

1. Dopo la chiamata a BeginSession (per il codice gestito) oppure a IKnowledgeSyncProvider::BeginSession (per il codice non gestito), Sync Framework chiama SpecifyTrackedFilters (per il codice gestito) oppure IFilterTrackingProvider::SpecifyTrackedFilters (per il codice non gestito) nel provider di destinazione.

2. Il provider di destinazione enumera il proprio elenco dei filtri rilevati e passa ognuno dei filtri al delegato RequestTrackedFilterCallback (per il codice gestito) o al metodo IFilterRequestCallback::RequestFilter dell'oggetto IFilterRequestCallback (per il codice non gestito) specificato nella chiamata a SpecifyTrackedFilters.

3. Per ogni filtro specificato dal provider di destinazione, Sync Framework chiama TryAddTrackedFilter (per il codice gestito) o IFilterTrackingProvider::AddTrackedFilter (per il codice non gestito) nel provider di origine.

4. Il provider di origine gestisce un elenco dei filtri rilevati dal provider di destinazione e restituisce un valore che indica se esso rileva il filtro specificato.

5. Sync Framework passa il valore al provider di destinazione.

Invio dei metadati dei filtri per i filtri rilevati

Quando il provider di destinazione rileva filtri che rileva anche il provider di origine, quest'ultimo deve inviare i metadati dei filtri per i filtri rilevati tra loro. A tale scopo, aggiungere le modifiche seguenti all'implementazione del provider di origine di GetChangeBatch (per il codice gestito) o di IKnowledgeSyncProvider::GetChangeBatch (per il codice non gestito):

• Aggiungere un oggetto FilterKeyMap all'oggetto ChangeBatch impostando la proprietà FilterKeyMap (per il codice gestito) o aggiungere un oggetto IFilterKeyMap all'oggetto ISyncChangeBatchWithFilterKeyMap chiamando ISyncChangeBatchWithFilterKeyMap::SetFilterKeyMap (per il codice non gestito). L'oggetto mappa di chiavi dei filtri contiene i filtri rilevati sia dal provider di origine sia da quello di destinazione. Deve essere impostata la proprietà FilterKeyMap (per il codice gestito) o deve essere chiamato il metodo SetFilterKeyMap (per il codice non gestito) prima che vengano avviati i gruppi nel batch di modifiche.

• Per ogni gruppo nel batch di modifiche, aggiungere la conoscenza dimenticata relativa ai filtri per i filtri rilevati chiamando SetFilterForgottenKnowledge (per il codice gestito) o ISyncChangeBatchWithFilterKeyMap::SetFilterForgottenKnowledge (per il codice non gestito).

• Inviare i metadati delle modifiche del filtro per ogni elemento o unità di modifica spostato all'interno o all'esterno di un filtro rilevato. I metadati delle modifiche del filtro vengono aggiunti a una modifica chiamando AddFilterChange (per il codice gestito) o IFilterTrackingSyncChangeBuilder::AddFilterChange (per il codice non gestito). Le proprietà FilterChange (per il codice gestito) o i valori SYNC_FILTER_CHANGE (per il codice non gestito) indicano se l'elemento è stato spostato all'interno o all'esterno del filtro e la versione della modifica che ha determinato lo spostamento. I metadati delle modifiche del filtro vengono aggiunti solo se la versione di trasferimento non è inclusa nella conoscenza di destinazione dell'elemento. Quando si utilizzano unità di modifica, i metadati delle modifiche del filtro devono essere aggiunti se la versione di trasferimento non è inclusa nella conoscenza di destinazione di una qualsiasi unità di modifica. Tenere presente che le versioni di trasferimento vengono considerate come versioni dell'elemento anche quando si utilizzano unità di modifica, pertanto il contenuto deve essere controllato utilizzando un formato del metodo Contains (per il codice gestito) o del metodo ISyncKnowledge::ContainsChange (per il codice non gestito) che accetta una versione dell'elemento e non un formato che utilizza una versione dell'unità di modifica.

• Quando vengono utilizzate le unità di modifica e nella conoscenza di destinazione non è contenuta neanche una modifica dell'unità di modifica, chiamare ContainsMarker (per il codice gestito) o IKnowledgeWithMarkers::ContainsAllChangeUnitsRequiredMarker (per il codice non gestito) nella conoscenza di destinazione, specificando AllChangeUnitsRequired e l'ID elemento dell'elemento proprietario (per il codice gestito) o l'ID elemento dell'elemento proprietario (per il codice non gestito). Se questo metodo indica che tutte le unità di modifica sono necessarie, inviare tali unità per l'elemento e chiamare SetAllChangeUnitsPresent nell'oggetto ItemChange (per il codice gestito) o IFilterTrackingSyncChangeBuilder::SetAllChangeUnitsPresentFlag (per il codice non gestito).

Invio delle modifiche filtrate

In genere, un provider di origine che rappresenta una replica di rilevamento dei filtri può enumerare i batch di modifiche filtrati per qualsiasi filtro rilevato. Il filtro può essere identificato dall'applicazione, tramite un meccanismo personalizzato tra l'applicazione e il provider di origine, oppure può essere negoziato tra il provider di origine e quello di destinazione. La negoziazione del filtro è descritta più avanti in questo documento.

Per inviare un batch di modifiche filtrato, aggiungere gli elementi seguenti al metodo GetChangeBatch del provider di origine:

• Creare un oggetto CustomFilterInfo (per il codice gestito) o un oggetto ICustomFilterInfo (per il codice non gestito) che contenga il filtro utilizzato per la sincronizzazione. Creare un oggetto batch di modifiche filtrato passando l'oggetto informazioni sul filtro al costruttore del batch di modifiche appropriato ChangeBatch (per il codice gestito) o chiamando IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (per il codice non gestito). Inoltre, passare la conoscenza dimenticata relativa ai filtri del filtro durante la creazione dell'oggetto batch di modifiche, al posto della conoscenza dimenticata della replica.

• Se un elemento o unità di modifica si trovava precedentemente nel filtro ma attualmente risulta spostato, specificare la proprietà ChangeKind come Ghost (per il codice gestito) o passare il flag SYNC_CHANGE_FLAG_GHOST a ISyncChangeBatchBase::AddItemMetadataToGroup (per il codice non gestito).

• Quando il tipo di filtro del provider di destinazione è CurrentItemsOnly (per il codice gestito) o FT_CURRENT_ITEMS_ONLY (per il codice non gestito), includere un elemento nel batch di modifiche solo se presente nel filtro. In altre parole, non inviare elementi fantasma.

• Quando il tipo di filtro del provider di destinazione è CurrentItemsAndVersionsForMovedOutItems (per il codice gestito) o FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (per il codice non gestito), includere elementi che si trovano nel filtro e quelli che sono stati spostati. Le informazioni relative al trasferimento devono essere inviate quando un elemento o unità di modifica è stato precedentemente nel filtro, l'elemento o unità di modifica non è attualmente nel filtro e quando la versione della modifica relativa allo spostamento dell'elemento o unità di modifica all'esterno del filtro non è contenuta nella conoscenza di destinazione.

Applicazione dei metadati dei filtri

Quando un provider di destinazione rappresenta un provider di rilevamento dei filtri e utilizza un oggetto di applicazione modifiche per applicare le modifiche alla replica di destinazione, il provider di destinazione deve implementare IFilterTrackingNotifyingChangeApplierTarget (per il codice gestito) o IFilterTrackingNotifyingChangeApplierTarget (per il codice non gestito). Questa interfaccia contiene metodi che Sync Framework utilizza per ottenere la mappa di chiavi dei filtri e la conoscenza dimenticata relativa ai filtri dei filtri rilevati. Contiene inoltre il metodo SaveKnowledgeWithFilterForgottenKnowledge (per il codice gestito) o il metodo IFilterTrackingNotifyingChangeApplierTarget::SaveKnowledgeWithFilterForgottenKnowledges (per il codice non gestito), richiamato da Sync Framework al posto del metodo StoreKnowledgeForScope (per il codice gestito) o ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (per il codice non gestito) per i provider di rilevamento dei filtri. Sync Framework utilizza questo metodo per inviare la conoscenza aggiornata, la conoscenza dimenticata e la conoscenza dimenticata relativa ai filtri al provider una volta applicato un batch di modifiche.

Oltre all'implementazione di IFilterTrackingNotifyingChangeApplierTarget, è necessario aggiornare il metodo SaveItemChange o SaveChangeWithChangeUnits (per codice gestito) oppure il metodo ISynchronousNotifyingChangeApplierTarget::SaveChange o ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (per codice non gestito) del provider di destinazione per eseguire i passaggi seguenti:

1. Ottenere i metadati delle modifiche del filtro per ogni filtro rilevato chiamando GetFilterChange (per codice gestito) o ISyncChangeWithFilterKeyMap::GetFilterChange (per codice non gestito) nell'oggetto modifiche.

2. Quando i metadati delle modifiche del filtro sono presenti, verificare che non siano obsoleti. Una modifica del filtro è obsoleta quando la versione di trasferimento corrispondente è inclusa nella conoscenza di destinazione dell'elemento. Quando si utilizzano unità di modifica, una modifica del filtro viene considerata obsoleta se la versione di trasferimento è inclusa nella conoscenza di destinazione di tutte le unità di modifica. Non applicare una modifica del filtro obsoleta alla replica di destinazione.

3. Quando i metadati delle modifiche del filtro sono presenti e non sono obsoleti, verificare che non siano in conflitto con le informazioni sulle modifiche del filtro già presenti nella replica di destinazione. Per verificare eventuali situazioni di conflitto, eseguire i passaggi seguenti:

   1. Recuperare la versione di trasferimento attualmente archiviata per l'elemento o unità di modifica nella replica di destinazione.

   2. Verificare se la versione di trasferimento è contenuta nella conoscenza corrente dell'elemento oppure nella conoscenza corrente di ogni modifica dell'unità di modifica associata all'elemento.

   3. Se la versione di trasferimento non è contenuta nella conoscenza corrente appropriata, la modifica del filtro è in conflitto. Il provider di destinazione deve risolvere tale conflitto nel modo appropriato e assegnare alla modifica una nuova versione di trasferimento.

   4. Se non viene rilevato alcun conflitto con la versione di trasferimento, controllare il flag di trasferimento all'interno della modifica del filtro di origine rispetto al flag di trasferimento all'interno dell'elemento di destinazione o dell'unità di modifica. Se il valore del flag è incoerente, il provider di destinazione deve valutare l'elemento o l'unità di modifica rispetto al filtro e assegnare il valore del contrassegno di trasferimento all'interno corretto insieme a una nuova versione di trasferimento.

   5. Se non vengono rilevati conflitti di alcun tipo, archiviare i metadati delle modifiche del filtro insieme ai metadati per l'elemento.

4. Quando i metadati delle modifiche del filtro non sono presenti per un filtro rilevato oppure per un filtro rilevato dalla replica di destinazione ma non dalla replica di origine, valutare la modifica rispetto al filtro della destinazione. Aggiornare i metadati dei filtri da includere se l'elemento si trova nel filtro e aggiornare la versione di trasferimento corrispondente alla versione della modifica nel caso in cui la modifica abbia determinato lo spostamento dell'elemento in relazione al filtro. Quando più unità di modifica sono associate a un filtro e una modifica apportata a un'unità di modifica determina lo spostamento dell'elemento in relazione al filtro, creare una nuova versione locale e assegnare la nuova versione come versione di trasferimento dell'elemento e come versione di modifica per tutte le unità di modifica associate al filtro.

Repliche filtrate

Una replica filtrata archivia i dati relativi all'elemento e all'unità di modifica solo per gli elementi e le unità di modifica che si trovano nel relativo filtro, nonché gli elementi fantasma, ovvero i metadati per gli elementi e le unità di modifica che si trovavano nel filtro ma che sono stati spostati. Inoltre, una replica filtrata rileva il relativo filtro ed è in grado di rilevare anche altri filtri. Questo tipo di replica può negoziare un filtro con il provider di origine; in tal caso il provider di origine produce un batch di modifiche filtrato. Se il provider di origine non può produrre un batch di modifiche filtrato, il provider filtrato può filtrare le modifiche in modo autonomo e applicare solo quelle che si trovano nel relativo filtro.

Per ulteriori informazioni sull'implementazione di una replica filtrata, vedere Procedura: filtrare una replica.

Enumerazione degli elementi spostati nel filtro

Una replica filtrata implementa l'interfaccia IFilteredReplicaNotifyingChangeApplierTarget (per il codice gestito) o IFilteredReplicaNotifyingChangeApplierTarget (per il codice non gestito). L'interfaccia contiene GetNewMoveInItems (per il codice gestito) o IFilteredReplicaNotifyingChangeApplierTarget::GetNewMoveins (per il codice non gestito), utilizzato da Sync Framework per ottenere gli elementi spostati nel filtro dopo un determinato momento specifico. Un elemento viene aggiunto all'elenco restituito da questo metodo quando l'elemento è attivo, si trova nel filtro e la versione di trasferimento dell'elemento non è contenuta nella conoscenza specificata al metodo.

Invio delle modifiche non filtrate

Quando la replica filtrata è la replica di origine e la replica di destinazione non richiede un'enumerazione delle modifiche filtrata o non viene negoziato alcun filtro tra due repliche, la replica di origine enumera le modifiche come se non fosse filtrata. Si differenzia dal processo di invio delle modifiche filtrate nei modi seguenti:

• Viene creato un batch di modifiche non filtrate.

• Viene passata la conoscenza dimenticata della replica durante la creazione del batch di modifiche e non la conoscenza dimenticata relativa ai filtri come quando vengono inviate le modifiche filtrate.

Applicazione delle modifiche filtrate

Quando il provider di destinazione utilizza un oggetto di applicazione modifiche per applicare le modifiche, deve indicare se l'elemento di destinazione o l'unita di modifica è un elemento fantasma quando invia le versioni di destinazione all'oggetto di applicazione modifiche. A tale scopo, specificare Ghost per la proprietà ChangeKind (per il codice gestito) o passare il flag SYNC_CHANGE_FLAG_GHOST a IDestinationChangeVersionsBuilder::AddItemMetadata (per il codice non gestito) quando l'elemento è un elemento fantasma nella replica di destinazione. Un elemento è un elemento fantasma quando i metadati esistono per l'elemento nell'archivio dei metadati di destinazione, l'elemento non è stato eliminato e non esiste alcun dato per l'elemento nell'archivio di destinazione.

Quando le modifiche del provider di origine non sono filtrate, il provider di destinazione valuta tutte le modifiche inviate dal provider di origine rispetto al filtro della replica di destinazione. Il provider di destinazione applica le modifiche che passano il filtro e aggiorna tutti gli elementi fantasma interessati. Il provider di destinazione esclude tutte le modifiche ignorate dalla conoscenza del batch di modifiche.

Inoltre, il provider di destinazione deve apportare le seguenti modifiche al relativo metodo SaveItemChange o SaveChangeWithChangeUnits (per il codice gestito) o ISynchronousNotifyingChangeApplierTarget::SaveChange o ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (per il codice non gestito).

• Gestire CreateGhost e UpdateGhost (per il codice gestito) o le azioni SSA_CREATE_GHOST o SSA_UPDATE_GHOST (per il codice non gestito) creando o aggiornando i metadati per un elemento fantasma. Inoltre devono essere aggiornati i metadati delle modifiche del filtro, se applicabile.

• Gestire MarkItemAsGhost (per il codice gestito) o l'azione SSA_GHOST_ITEM (per il codice non gestito) rimuovendo i dati per l'elemento o unità di modifica e aggiornando i metadati per l'elemento o unità di modifica per riflettere la modifica.

• Gestire UnmarkItemAsGhost (per il codice gestito) o l'azione SSA_UNGHOST_ITEM (per il codice non gestito) recuperando i dati per l'elemento o unità di modifica, archiviando i dati nella replica di destinazione e aggiornando i metadati per riflettere la modifica.

• Gestire DeleteGhostAndStoreTombstone (per il codice gestito) o l'azione SSA_DELETE_GHOST_AND_STORE_TOMBSTONE (per il codice non gestito) contrassegnando i metadati per l'elemento fantasma come eliminati.

Pulizia degli elementi fantasma

Per liberare spazio di archiviazione in una replica filtrata è possibile rimuovere gli elementi fantasma. Quando viene rimosso un elemento fantasma, la conoscenza dimenticata relativa ai filtri per il filtro deve essere aggiornata passando la versione di trasferimento dell'elemento fantasma al metodo ForgetTo (per il codice gestito) o al metodo IForgottenKnowledge::ForgetToVersion (per il codice non gestito) della conoscenza dimenticata.

Negoziazione del filtro

Il provider di destinazione può specificare il filtro utilizzato dal provider di origine durante l'enumerazione delle modifiche. Il provider di origine può accettare o negare il filtro richiesto dal provider di destinazione. Il provider di destinazione può continuare a richiedere filtri finché non ne viene trovato uno accettato dal provider di origine. Questa negoziazione avviene tramite Sync Framework. Il filtro può essere del tipo più appropriato per i provider.

Per partecipare alla negoziazione del filtro, il provider di origine deve implementare ISupportFilteredSync (per il codice gestito) o ISupportFilteredSync (per il codice non gestito) mentre il provider di destinazione deve implementare IRequestFilteredSync (per il codice gestito) o IRequestFilteredSync (per il codice non gestito).

La negoziazione del filtro viene eseguita tramite i passaggi seguenti:

1. Prima che il provider di origine inizi l'enumerazione delle modifiche e dopo la chiamata a BeginSession (per il codice gestito) o a IKnowledgeSyncProvider::BeginSession (per il codice non gestito), Sync Framework avvia la negoziazione del filtro chiamando il metodo SpecifyFilter (per il codice gestito) o IRequestFilteredSync::SpecifyFilter (per il codice non gestito) nel provider di destinazione.

2. Durante l'elaborazione di SpecifyFilter, il provider di destinazione passa i filtri al delegato FilterRequestCallback (per il codice gestito) o al metodo IFilterRequestCallback::RequestFilter (per il codice non gestito) specificato da Sync Framework. Quando il provider di destinazione non rileva il filtro richiesto, specifica un tipo di filtro CurrentItemsOnly (per il codice gestito) o FT_CURRENT_ITEMS_ONLY (per il codice non gestito). Quando il provider di destinazione rileva il filtro richiesto, specifica un tipo di filtro CurrentItemsAndVersionsForMovedOutItems (per il codice gestito) o FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (per il codice non gestito).

3. Durante l'elaborazione di FilterRequestCallback (per il codice gestito) o RequestFilter (per il codice non gestito), Sync Framework chiama il metodo TryAddFilter (per il codice gestito) o il metodo ISupportFilteredSync::AddFilter (per il codice non gestito) del provider di origine. Se il provider di origine non supporta il filtro richiesto, il provider di destinazione può continuare a richiedere i filtri finché non ne trova uno supportato.

4. Se il provider di destinazione non è in grado di trovare un filtro accettato dal provider di origine, può terminare la sincronizzazione generando SyncInvalidOperationException (per il codice gestito) o restituendo un codice di errore, ad esempio SYNC_E_FILTER_NOT_SUPPORTED (per il codice non gestito).

Quando un filtro è stato negoziato correttamente, il provider di origine lo utilizza per determinare quali elementi includere durante l'enumerazione delle modifiche.

Per ulteriori informazioni su come negoziare i filtri, vedere Procedura: negoziare un filtro.

Vedere anche

Concetti

Implementazione di un provider standard personalizzato
Implementazione di un'applicazione di sincronizzazione
Procedura: filtrare gli elementi enumerati
Procedura: filtrare unità di modifica enumerate
Procedura: negoziare un filtro
Procedura: rilevare i filtri ed enumerare le modifiche filtrate
Procedura: filtrare una replica