Anwenden von Änderungen
Nachdem der Zielanbieter ein Änderungsbatch abgerufen und Konflikte behandelt hat, müssen die Änderungen auf das Zielreplikat angewendet werden. Dies erfolgt in der Regel in der ProcessChangeBatch-Methode (für verwalteten Code) oder in der ProcessChangeBatch-Methode (für nicht verwalteten Code) des Zielanbieters, und kann am einfachsten durch die Verwendung eines von Sync Framework zur Verfügung gestellten Änderungsanwenderobjekts erreicht werden.
Wie Änderungen übernommen werden
Nachdem der Zielanbieter den Änderungsbatch vom Quellenanbieter erhalten hat, wendet der Zielanbieter die Änderungen auf das Zielreplikat an. Ein von Sync Framework zur Verfügung gestelltes Änderungsanwenderobjekt kann durch die Erstellung eines NotifyingChangeApplier-Objekts (für verwalteten Code) oder durch Aufruf von IProviderSyncServices::CreateChangeApplier (für nicht verwalteten Code) abgerufen werden. Die ApplyChanges-Methode (für verwalteten Code) oder ApplyChanges-Methode (für nicht verwalteten Code) erkennt Konflikte und ruft Methoden für den Zielanbieter auf, um Änderungen auf das Zielreplikat anzuwenden.
Verarbeiten eines Änderungselements
Für die Verarbeitung eines Änderungselements ruft der Änderungsanwender zuerst die LoadChangeData-Methode (für verwalteten Code) oder die ISynchronousDataRetriever::LoadChangeData-Methode (für nicht verwalteten Code) für den Quellenanbieter auf, um die Datenübertragung zu starten. Diese Methode gibt ein object (für verwalteten Code) oder eine IUnknown-Schnittstelle (für nicht verwalteten Code) zurück, die den Datenübertragungsmechanismus darstellen. Der Änderungsanwender ruft dann für den Zielanbieter die SaveItemChange-Methode (für verwalteten Code) oder die ISynchronousNotifyingChangeApplierTarget::SaveChange-Methode (für nicht verwalteten Code) auf und übergibt das Datenübertragungsobjekt als Teil des Änderungsspeicherungskontexts. Der Zielanbieter kann die Daten anschließend an das Zielreplikat übertragen. Alle Fehler beim Abrufen der Daten oder bei der Verarbeitung von Änderungen werden durch die RecordRecoverableErrorForItem-Methode (für verwalteten Code) oder die ISaveChangeContext::SetRecoverableErrorOnChange-Methode (für nicht verwalteten Code) angegeben. Mit dieser Methode wird ein behebbarer Fehler für dieses Element in dem Objekt für erlangtes Wissen im Änderungsbatch aufgezeichnet.
Aktualisieren von erlangtem Wissen
Während die Änderungen angewendet werden, aktualisiert der Änderungsanwender das im Änderungsbatch enthaltene erlangte Wissen. Das erlangte Wissen ist das auf die Änderungen des Änderungsbatches projizierte Wissen des Quellreplikats und stellt das im Zielreplikat enthaltene Wissen nach der Anwendung aller Änderungen im Änderungsbatch dar. Das erlangte Wissen wird folgendermaßen aktualisiert:
Wenn aufgrund von Unterbrechungen oder Abbrüchen nur eine Teilmenge der Änderungen angewendet wurde, verwendet der Änderungsanwender den Project-Operator, um das Wissen auf die angewendete Gruppe von Änderungen zu beschränken.
Wenn das Übernehmen einiger Änderungen fehlschlägt, schließt der Änderungsanwender sie auch vom Wissen aus.
Beachten Sie, dass Anbieterimplementierer diese Projektions-, Vereinigungs- und Ausschlussvorgänge nicht manuell ausführen müssen. Der Änderungsanwender führt diese Vorgänge im Auftrag des Anbieters aus.
Speichern von aktualisiertem Zielwissen
Nachdem das erlangte Wissen aktualisiert wurde, wird es mit dem Wissen des Zielreplikats kombiniert. Der Zielanbieter muss das Wissen des Zielreplikats atomar durch dieses Wissen ersetzen. Diese Unteilbarkeit kann erreicht werden, indem aktualisiertes Wissen nur einmal pro Batch gespeichert wird, wenn alle Änderungen in einem Batch innerhalb einer einzigen Transaktion angewendet werden. Dies wird vom Änderungsanwender durch Aufrufen der StoreKnowledgeForScope-Methode (für verwalteten Code) oder der ISynchronousNotifyingChangeApplierTarget::SaveKnowledge-Methode (für nicht verwalteten Code) für den Zielanbieter am Ende jedes Batches unterstützt. Das an diese Methode übergebene Wissen ist das aktualisierte Wissen, das auf das Zielreplikat angewendet werden soll. Alternativ dazu kann der Zielanbieter die GetUpdatedDestinationKnowledge-Methode (für verwalteten Code) oder die ISaveChangeContext::GetKnowledgeForScope-Methode (für nicht verwalteten Code) aufrufen, um das aktualisierte Wissen abzurufen.
Wenn die Anbieter Änderungseinheiten verwenden, um Unterelemente darzustellen, unterscheidet sich das Anwenden von Änderungen in einigen Punkten. Weitere Informationen finden Sie unter Synchronisieren von Änderungseinheiten.
Besondere Überlegungen für hierarchische Replikate
Die Synchronisierung von hierarchischen Replikaten kann mit bestimmten Komplikationen einhergehen, die durch die Batchverarbeitung der Änderungssätze von der Quelle zum Ziel verursacht werden. Sync Framework unterstützt das Konzept der Datenhierarchie nicht. Es hängt daher gänzlich von den Anbietern ab, diese Situationen ordnungsgemäß zu behandeln.
Die häufigste Komplikation ist die Reihenfolge übergeordneter und untergeordneter Beziehungen in Aktualisierungsvorgängen. Betrachten Sie z. B. folgendes Szenario:
Das Quellreplikat hat einen neuen Ordner erstellt, der einen Satz neuer Elemente enthält.
Der Zielanbieter fordert Änderungen vom Quellenanbieter an. Der Quellenanbieter sendet die Liste der Änderungen in zwei Batches. Der Änderungsbatch, der die Erstellung des übergeordneten Ordners enthält, trifft jedoch nach dem Änderungsbatch ein, der die untergeordneten Elemente enthält.
Der Zielanbieter muss entscheiden, an welchem Ort der Satz von Elementen gespeichert wird, der im ersten Batch eingetroffen ist, da die Speicherortinformationen erst mit dem zweiten Batch eintreffen werden.
Reduzieren von hierarchischen Aktualisierungen
Bei Aktualisierungen ist die einfachste Methode zur Reduzierung von Komplexitäten der Beziehung zwischen über- und untergeordneten Elementen, den Quellenanbieter für die Sortierung der globalen IDs verantwortlich zu machen. Mit diesem Verfahren treffen die übergeordneten Elemente stets vor den untergeordneten Elementen ein.
Wenn die Zielanbieter die Übertragung von Aktualisierungen verarbeiten, die in einem hierarchischen Speicher erstellt wurden, erhalten sie die Beziehungen zwischen über- und untergeordneten Elementen möglicherweise nicht in der richtigen Reihenfolge. Für Zielanbieter muss diese Situation behebbar sein, entweder durch Löschen der falschen Änderung und dem Vermerken einer Ausnahme in ihrem Wissen oder durch Einreihen in eine Warteschlange und spätere Anwendung der Änderung. Da die Elemente sehr groß sein können, ist das Löschen der Änderung und der Vermerk von Ausnahmen wahrscheinlich die effektivste Vorgehensweise.
Reduzieren von hierarchischen Löschungvorgängen
Zielanbieter legen fest, ob ein Element ein Containerelement ist. Für leere Container können Löschvorgänge sofort ausgeführt werden. Wenn der Container jedoch Elemente enthält, die nicht zum Löschen markiert wurden, stehen dem Anbieter folgenden Optionen zur Verfügung:
Die Löschungvorgänge können zur späteren Verarbeitung in die Warteschlange gestellt werden. Nachdem alle untergeordneten Elemente im Container zum Löschen markiert wurden, kann der eigentliche Löschvorgang ausgelöst werden.
Der Anbieter kann diese Anforderung verwerfen und eine Ausnahme im Wissen vermerken, um den nicht ordnungsgemäßen Empfang eines Elements anzugeben.
Die folgende Regel ist für Szenarien zu beachten, in denen ein übergeordnetes Element in der Hierarchie gelöscht und ein untergeordnetes Element hinzugefügt wird: Löschvorgänge in der Warteschlange gelten nur bis zum Ende einer paarweisen Sitzung und werden unter den Teilnehmern nicht beibehalten.
Siehe auch
Verweis
IProviderSyncServices-Schnittstelle
ISynchronousNotifyingChangeApplier::ApplyChanges
IAsynchronousNotifyingChangeApplier::ApplyChanges
ISynchronousNotifyingChangeApplierTarget::SaveKnowledge
IAsynchronousNotifyingChangeApplierTarget::SaveKnowledge
ISynchronousDataRetriever-Schnittstelle
IAsynchronousDataRetriever-Schnittstelle
ISyncKnowledge::ExcludeItem
ISyncKnowledge::Union
ISaveChangeContext-Schnittstelle
NotifyingChangeApplier
ApplyChanges
StoreKnowledgeForScope
IChangeDataRetriever
ExcludeItem
Contains
SaveChangeContext