Sincronizzazione delle unità di modifica
Un'unità di modifica rappresenta una modifica di un elemento secondario, ad esempio il campo numero di telefono in un elemento che rappresenta una scheda contatto. Tramite le unità di modifica, i provider possono sincronizzare in modo più efficiente le modifiche dell'elemento secondario. Alcuni esempi di provider che potrebbero sfruttare le opportunità offerte dalle unità di modifica sono i provider PIM (Personal Information Management) e i provider che gestiscono immagini con i relativi metadati.
Unità di modifica
Le unità di modifica consentono la rappresentazione di modifiche compatte dell'elemento secondario e un livello più preciso di rilevamento delle modifiche. In questo modo è possibile ridurre il numero di conflitti generati quando vengono apportate modifiche all'elemento.
Considerare un elemento che rappresenta una scheda contatto salvata in modo permanente in un file system. Se la granularità del rilevamento delle modifiche fosse al livello dell'elemento (file), tutte le modifiche al file sarebbero modifiche dell'elemento e tutti i dati di contatto dovrebbero essere trasferiti. Tramite le unità di modifica, un provider può decidere invece di rilevare modifiche e risolvere conflitti di dati a livello di proprietà del contatto, ad esempio Nome, Cognome e Numero telefonico. In questo caso, se due repliche modificano in modo indipendente proprietà diverse in un contatto, ad esempio quando una replica modifica l'indirizzo di posta elettronica e un'altra allega un'immagine, non viene rilevato alcun conflitto al livello dell'elemento ed è necessario inviare solo i dati dell'unità di modifica.
Il set di unità di modifica crea in realtà uno schema nel quale l'ordine delle unità di modifica viene deciso dalle repliche che eseguono la sincronizzazione di uno schema particolare. Ad esempio, le repliche possono decidere di rappresentare le proprietà del contatto nel modo seguente:
Change Unit[0] = First Name
Change Unit[1] = Last Name
Change Unit[2] = Phone Number
Eliminazione delle unità di modifica
La durata di un'unità di modifica è legata alla durata dell'elemento. A differenza degli elementi di modifica normali, le unità di modifica non possono essere eliminate perché vengono considerate dalle repliche come proprietà di un elemento.
Aggiunta delle unità di modifica
I provider non devono tentare di creare spontaneamente unità di modifica poiché potrebbero verificarsi effetti indesiderati.
Le unità di modifica possono essere aggiunte in base ad aggiornamenti di schemi che si verificano fuori banda con una sincronizzazione dei dati. A tale scopo, le unità di modifica aggiunte devono disporre di un valore null o di un valore predefinito utilizzato da tutte le repliche. La versione dell'aggiornamento per le unità di modifica aggiunte sarà quindi la versione di creazione dell'elemento finché tali unità di modifica non vengono modificate. In base a questa modalità di gestione, le aggiunte delle unità di modifica vengono considerate dai componenti dell'applicazione in modo analogo a un'unità di modifica presente fin dall'inizio e mai modificata.
Enumerazione delle modifiche dell'unità di modifica
Quando il provider di origine utilizza unità di modifica per rappresentare elementi secondari enumerati dalla replica di origine, invia solo le unità di modifica modificate, anziché l'elemento intero. È opportuno considerare che quando un elemento contiene unità di modifica, le informazioni sulla versione vengono conservate solo per ogni unità di modifica e non per l'elemento stesso.
Enumerazione delle modifiche dell'unità di modifica tramite codice gestito
Per determinare quali unità di modifica inviare, il provider di origine utilizza il metodo Contains o Contains dell'oggetto SyncKnowledge dal provider di destinazione. Se una modifica dell'unità di modifica non è contenuta nella conoscenza di destinazione, la modifica deve essere inclusa nel batch di modifiche inviato dal provider di origine.
Le modifiche dell'unità di modifica sono contenute all'interno delle modifiche dell'elemento aggiunte al batch di modifiche. È possibile creare l'oggetto ItemChange per contenere le modifiche dell'unità di modifica tramite il costruttore ItemChange oppure è possibile aggiungere le modifiche dell'unità di modifica tramite AddChangeUnitChange.
Enumerazione delle modifiche dell'unità di modifica tramite codice non gestito
Per determinare quali unità di modifica inviare, il provider di origine utilizza il metodo ISyncKnowledge::ContainsChangeUnit dell'oggetto ISyncKnowledge dal provider di destinazione. Se una modifica dell'unità di modifica non è contenuta nella conoscenza di destinazione, la modifica deve essere inclusa nel batch di modifiche inviato dal provider di origine.
Le modifiche dell'unità di modifica sono contenute all'interno delle modifiche dell'elemento aggiunte al batch di modifiche. Per aggiungere modifiche dell'unità di modifica, specificare un valore non NULL per il parametro ppChangeBuilder del metodo ISyncChangeBatchBase::AddItemMetadataToGroup. L'oggetto ISyncChangeBuilder restituito può essere quindi utilizzato per aggiungere modifiche dell'unità di modifica alla modifica dell'elemento associata tramite ISyncChangeBuilder::AddChangeUnitMetadata.
Elaborazione delle modifiche dell'unità di modifica
Quando utilizza un oggetto di applicazione modifiche per facilitare l'elaborazione di un batch di modifiche nel metodo ProcessChangeBatch (per il codice gestito) o nel metodo IKnowledgeSyncProvider::ProcessChangeBatch (per il codice non gestito), il provider di destinazione enumera le informazioni sulla versione di destinazione per ogni modifica ricevuta dal provider di origine. Quando una modifica di origine contiene modifiche dell'unità di modifica, il provider di destinazione deve determinare quali versioni dell'unità di modifica, se disponibili, includere nel batch di versioni di destinazione. La decisione dipende dal tipo di modifica del provider di origine e dalla presenza o meno del contrassegno di eliminazione sull'elemento nella replica di destinazione. Nella tabella seguente vengono illustrate le informazioni sulla versione che il provider di destinazione deve inviare all'oggetto di applicazione modifiche.
|
La modifica di origine è un'eliminazione |
La modifica di origine è un aggiornamento |
L'elemento di destinazione viene eliminato |
Solo versione dell'elemento di destinazione. Le eliminazioni sono consentite solo sugli elementi interi. Di conseguenza, le informazioni sulla versione per un'eliminazione vengono registrate per l'elemento. |
Solo versione dell'elemento di destinazione. Le eliminazioni sono consentite solo sugli elementi interi. Di conseguenza, le informazioni sulla versione per un'eliminazione vengono registrate per l'elemento. |
L'elemento di destinazione non viene eliminato |
Tutte le versioni dell'unità di modifica di destinazione. |
Versioni dell'unità di modifica di destinazione solo per le unità di modifica enumerate dall'origine. |
Gestione dei conflitti che contengono unità di modifica
Quando un'applicazione utilizza la risoluzione dei conflitti personalizzata per modifiche che contengono unità di modifica, generalmente è necessario impostare l'azione di risoluzione dei conflitti per il conflitto di unità di modifica tramite SetResolutionAction (per il codice gestito) o IChangeConflict::SetResolveActionForChangeUnit (per il codice non gestito).
Tuttavia, quando il conflitto è causato da un aggiornamento in una replica e da un'eliminazione nell'altra replica, l'applicazione deve specificare l'azione di risoluzione dei conflitti per il conflitto di elementi tramite SetResolutionAction (per il codice gestito) o IChangeConflict::SetResolveActionForChange (per il codice non gestito).
Applicazione delle modifiche dell'unità di modifica
In genere, quando una modifica contiene unità di modifica, Sync Framework chiama SaveChangeWithChangeUnits (per il codice gestito) o ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (per il codice non gestito) per applicare la modifica alla replica di destinazione. Tuttavia, quando viene rilevato e risolto un conflitto in modo che l'elemento venga eliminato, Sync Framework chiama SaveItemChange (per il codice gestito) o ISynchronousNotifyingChangeApplierTarget::SaveChange (per il codice non gestito). Ciò avviene perché è possibile eliminare solo elementi interi e non singole unità di modifica.