Filtern von Synchronisierungsdaten

Ein Filter wird zur Einschränkung der Daten verwendet, die synchronisiert werden. In der Regel wendet der Quellenanbieter den Filter während der Änderungsenumeration zur Einschränkung der Änderungen an, die gesendet werden. Sync Framework unterstützt folgende Filtertypen:

• Elementfilter werden zur Beschränkung der Synchronisierungsdaten auf eine Teilmenge von Elementen verwendet, indem beispielsweise nur TXT-Dateien zwischen zwei Dateiordnern synchronisiert und andere Dateitypen ignoriert werden. Elemente werden nicht auf eine Weise geändert, dass eine Verschiebung eines vorhandenen Elements in den oder aus dem Filter verursacht wird. Elementfilter sind einfach anzuwenden, doch die für die Synchronisierung verwendeten Metadaten wachsen proportional zur Anzahl der Elemente im Synchronisierungsbereich.

• Änderungseinheitsfilter schränken Synchronisierungsdaten auf eine Teilmenge von Änderungseinheiten ein, sodass z. B. nur die Felder name und phone number eines Kontakts synchronisiert und die verbleibenden Änderungseinheiten ignoriert werden.

• Benutzerdefinierte Filter schränken Synchronisierungsdaten auf eine Weise ein, die Sync Framework nicht bekannt ist. Elemente können im Verlauf der Zeit in einen oder aus einem benutzerdefinierten Filter verschoben werden. Sync Framework definiert zusätzliche Metadaten, Schnittstellen und Klassen, die benutzerdefinierte Filter effizient unterstützen, während die Gesamtgröße der Metadaten klein bleibt.

Der Filter kann von der Synchronisierungsanwendung, der Quelle oder dem Zielanbieter definiert werden, oder er kann zwischen den Quellen- und Zielanbietern ausgehandelt werden.

Der Filter wird vom Quellenanbieter verwendet, wenn Änderungen erkannt werden. Während der Änderungserkennung erstellte Änderungsbatches enthalten nur die Synchronisierungsdaten, die den Filter durchlaufen.

Der Filter kann auch vom Zielanbieter verwendet werden, wenn Änderungen übernommen werden. Für das Zielreplikat übernommene Änderungen enthalten nur die Synchronisierungsdaten, die den Filter durchlaufen.

Steuern der Synchronisierungselemente

Ein Elementfilter definiert, welche Elementänderungen während der Änderungsenumeration vom Quellenanbieter gesendet werden. Da die Art der Filterung von Elementen vom Typ der Daten im Synchronisierungsbereich abhängt, ermöglicht Sync Framework dem Quellenanbieter die Definition des Filtermechanismus. Wenn zwischen dem Anbieter und der Synchronisierungsanwendung Kommunikation über den Filter erforderlich ist, kann diese mithilfe des entsprechenden Mechanismus durchgeführt werden.

Wenn der Quellenanbieter Elementänderungen filtert, erfordert Sync Framework, dass der Quellenanbieter an alle während der Änderungsenumeration gesendeten Änderungsbatchobjekte Informationen zum Filter anfügt. Durch das Vorhandensein der Elementfilterinformationen im Änderungsbatchobjekt wird Sync Framework darüber informiert, dass eine gefilterte Synchronisierung stattfindet, damit Sync Framework das Wissen für den gefilterten Änderungsbatch ordnungsgemäß behandeln kann. Wenn der Quellenanbieter die in einem Änderungsbatch enthaltenen Elemente filtert, jedoch keine Elementfilterinformationen für das Änderungsbatchobjekt angibt, kann Sync Framework das Wissen u. U. nicht ordnungsgemäß behandeln.

Wenn der Quellenanbieter die in einem Änderungsbatch enthaltenen Elemente mithilfe eines Filters einschränkt, muss der Anbieter Informationen zum Filter an das ChangeBatch-Objekt (für verwalteten Code) oder das ISyncChangeBatch-Objekt (für nicht verwalteten Code) anfügen. Die Filterinformationen werden durch ein ItemListFilterInfo-Objekt (für verwalteten Code) oder ein ISyncFilterInfo-Objekt dargestellt, für das das SYNC_FILTER_INFO_FLAG_ITEM_LIST-Flag (für nicht verwalteten Code) festgelegt wurde. Im nicht verwalteten Code erstellt der Anbieter ein ISyncFilterInfo-Objekt mithilfe von IProviderFilteredSyncServices::CreateFilterInfo. Die Filterinformationen werden an den Batch mithilfe von ChangeBatch (für verwalteten Code) oder IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (für nicht verwalteten Code) angefügt, um das Änderungsbatchobjekt zu erstellen.

Weitere Informationen zur Verwendung von Elementfilterung finden Sie unter Vorgehensweise: Filtern von Auflistungselementen.

Steuern der zu synchronisierenden Änderungseinheiten

Ein Änderungseinheitsfilter definiert, welche Änderungen von Änderungseinheiten in den jeweiligen Elementänderungen enthalten sind, die während der Änderungsenumeration vom Quellenanbieter gesendet werden. Ein Änderungseinheitsfilter ist nützlich, wenn ein Replikat nur eine Teilmenge der Änderungseinheiten speichert, die für die Elemente im Bereich definiert wurde.

Beispielsweise tauscht eine Synchronisierungscommunity Kontaktinformationen aus und definiert Änderungseinheiten für name, phone number und address. Ein Replikat in der Community ist ein mobiles Gerät, das nur name und phone number speichern kann. Dieses Replikat verwendet einen Änderungseinheitsfilter, um festzulegen, dass nur Wissen für diese zwei Änderungseinheiten nachverfolgt wird. Wenn ein Quellreplikat Daten mit dem Gerätereplikat synchronisiert, wird der Änderungseinheitsfilter verwendet, damit nur Informationen über die Änderungseinheiten name und phone number gesendet werden. Das erlangte Wissen vom Quellenanbieter wird auf den Änderungseinheitsfilter projiziert, damit das Wissen auf dem Gerätereplikat nur das Wissen der Änderungseinheiten name und phone number enthält. Ebenso aktualisiert das Replikat, das die Änderungsaktualisierungen empfängt, sein Wissen nur für den angegebenen Satz von Änderungseinheiten, wenn eine Änderung lokal auf dem Gerät vorgenommen wird und dieses anschließend in einer Synchronisierungssitzung als Quellreplikat fungiert.

Wenn ein Änderungseinheitsfilter verwendet wird, projiziert Sync Framework das erlangte Wissen für den Änderungsbatch auf den Satz von Änderungseinheiten, der vom Filter angegeben wurde. So enthält das erlangte Wissen für den Änderungsbatch nur Informationen zum angegebenen Satz von Änderungseinheiten.

Um Änderungen von Änderungseinheiten zu filtern, erstellt der Quellenanbieter ein ChangeUnitListFilterInfo-Objekt (für verwalteten Code) oder ein IChangeUnitListFilterInfo-Objekt (für nicht verwalteten Code) und gibt den Satz der Änderungseinheiten an, die synchronisiert werden. Im nicht verwalteten Code wird das IChangeUnitListFilterInfo-Objekt durch Angabe von SYNC_FILTER_INFO_FLAG_CHANGE_UNIT_LIST für die IProviderFilteredSyncServices::CreateFilterInfo-Methode erstellt. Der Quellenanbieter fügt die Filterinformationen mithilfe von ChangeBatch (für verwalteten Code) oder IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (für nicht verwalteten Code) an den Änderungsbatch an, um das Änderungsbatchobjekt zu erstellen.

Weitere Informationen zur Verwendung eines Änderungseinheitsfilters finden Sie unter Vorgehensweise: Filtern aufgelisteter Änderungseinheiten.

Steuern der zu synchronisierenden Inhalte mithilfe eines benutzerdefinierten Filters

Ein benutzerdefinierter Filter wird außerhalb von Sync Framework definiert, üblicherweise durch einen Anbieterentwickler. Er kann jedoch auch durch einen Drittanbieter definiert werden. Sync Framework ist nicht bekannt, wie der Filter festlegt, was in den Synchronisierungsbereich miteinbezogen wird. Ein benutzerdefinierter Filter kann so definiert werden, dass mit der Zeit Elemente in einen und aus einem Filter verschoben werden. Beispielsweise kann für ein Replikat, das Mediendateien speichert, ein Filter definiert werden, der alle Dateien einschließt, die mit drei Sternen oder besser bewertet sind. Wenn der Benutzer an der Bewertung einer Datei Änderungen vornimmt, kann diese in den oder aus dem Filter verschoben werden.

Beachten Sie, dass benutzerdefinierte Filter nicht von einfachen Anbietern oder von Anbietern verwendet werden können, die Einschränkungskonflikte melden oder den Änderungsübernahmedienst verwenden, da andernfalls unerwartete Ergebnisse auftreten können.

Um benutzerdefinierte Filter effizient zu unterstützen, definiert Sync Framework mehrere neue Konzepte.

• Ein Filternachverfolgungsreplikat ist ein Replikat, das Metadaten verwaltet, die definieren, welche Elemente und Änderungseinheiten sich zur Zeit in einem nachverfolgten Filter befinden, welche Elemente und Änderungseinheiten kürzlich in einen oder aus einem nachverfolgten Filter verschoben wurden sowie vergessenes Filterwissen aller Elemente und Änderungseinheiten, die sich nicht im nachverfolgten Filter befinden und vergessen wurden. Das Nachverfolgen eines Filters hat keinen Einfluss darauf, welche Elemente in einem Replikat gespeichert werden. Ein Replikat kann mehrere Filter nachverfolgen, während es alle Elemente im Synchronisierungsbereich speichert. Normalerweise kann ein Filternachverfolgungsreplikat einen gefilterten Änderungsbatch für jeden der von ihm nachverfolgten Filter bereitstellen.

• Ein gefiltertes Replikat speichert Daten zu Elementen und Änderungseinheiten nur für die Elemente und Änderungseinheiten, die sich in den Filtern befinden, sowie Metadaten für Elemente und Änderungseinheiten, die sich in den Filtern befunden haben, jedoch aus diesen verschoben wurden. Ein gefiltertes Replikat verfolgt den Filter, den es verwendet, und kann auch zusätzliche Filter nachverfolgen. Ein gefilterter Zielanbieter kann eine gefilterte Änderungsenumeration vom Quellenanbieter anfordern, oder er kann eine vollständige Änderungsenumeration anfordern und die Änderungen während der Änderungsanwendung selbst filtern.

• Inaktive Elemente sind Elemente oder Änderungseinheiten in einem gefilterten Replikat, die sich in einem Filter befanden und aus ihm verschoben wurden. Das gefilterte Replikat speichert Metadaten für inaktive Elemente, es speichert jedoch keine Daten für Element- oder Änderungsdaten.

• Vergessenes Filterwissen legt für das Nachverfolgen der Filter einen Ausgangspunkt fest. Ein Filternachverfolgungsreplikat kann Speicherplatz sparen, indem inaktive Elemente entfernt werden und das vergessene Filterwissen so heraufgestuft wird, dass es die höchste Version inaktiver Elemente, die entfernt wurden, enthält. Vergessenes Filterwissen wird auch dann verwendet, wenn ein Replikat mit dem Nachverfolgen der Filter beginnt, nachdem der Filter von anderen Replikaten in der Synchronisierungscommunity verwendet wurde.

Nachverfolgen von Filtern

Es wird empfohlen, dass alle Replikate einer Synchronisierungscommunity die Filter nachverfolgen, die in einer Community zur Anwendung kommen. Wenn ein gefiltertes Replikat eine gefilterte Änderungsenumeration von einem Filternachverfolgungsreplikat erhält, wird das Wissen des gefilterten Replikats gering gehalten. Wenn ein gefiltertes Replikat eine gefilterte Änderungsenumeration von einem Replikat erhält, das den Filter nicht nachverfolgt, wächst das Wissen im Verhältnis zu der gesendeten Anzahl von Änderungen.

Weitere Informationen zum Nachverfolgen von Filtern finden Sie unter Vorgehensweise: Nachverfolgen von Filtern und Auflisten von gefilterten Änderungen.

Filtern von Metadaten

Zum Nachverfolgen eines Filters speichert ein Replikat Filtermetadaten für jedes Element oder jede Änderungseinheit in dem Replikat. Die Filtermetadaten enthalten die Elemente der folgenden Tabelle:

Ist im Filter	Verschobene Version
Gibt an, ob sich das Element oder die Änderungseinheit im Filter befindet.	Die Änderungsversion, durch die das Element im Verhältnis zum Filter verschoben wurde. Wenn ein Element erstellt wird und sich das Element im Filter befindet, wird diese Version auf die Erstellungsversion des Elements festgelegt. Wenn sich ein Element nie im Filter befunden hat, ist diese Version auf (0,0) festgelegt.

Wenn ein Replikat mit dem Nachverfolgen des Filters beginnt, müssen alle Elemente oder Änderungseinheiten anhand des Filters ausgewertet werden. Wenn sich ein Element oder eine Änderungseinheit im Filter befindet, müssen die Filtermetadaten angeben, dass diese sich im Filter befinden, und ihre verschobene Version muss auf die letzte Änderungsversion des Elements oder der Änderungseinheit festgelegt werden. Wenn ein Element sich nicht im Filter befindet, müssen die Filtermetadaten angeben, dass es sich nicht im Filter befindet, und die verschobene Version muss auf (0,0) festgelegt sein.

Ein Filternachverfolgungsreplikat kann auch vergessenes Filterwissen für jeden von ihm nachverfolgten Filter speichern. Wenn ein Filternachverfolgungsreplikat einen aus dem Filter stammenden Filter nachverfolgt, speichert es kein vergessenes Filterwissen, es sei denn, es erhält Synchronisationsdaten von einem Replikat, das den Filter nicht nachverfolgt. Wenn ein Filternachverfolgungsreplikat beginnt, einen Filter nach seiner Erstellung nachzuverfolgen, muss es das vergessene Filterwissen mit dem aktuellen Wissen des Replikats initialisieren. Wenn auf einem Replikat Tombstones und Metadaten von Filteränderungen bereinigt werden, kann das vergessene Filterwissen verworfen und stattdessen das vergessene Wissen verwendet werden.

Aushandeln nachverfolgter Filter

Ein Filternachverfolgungsanbieter muss IFilterTrackingProvider (für verwalteten Code) oder IFilterTrackingProvider (für nicht verwalteten Code) implementieren. Diese Schnittstelle wird verwendet, um die Filter anzugeben, die auf dem Quellreplikat und dem Zielreplikat nachverfolgt werden. Das Quellreplikat sendet Filtermetadaten für die Filter, die auf dem Quellreplikat und dem Zielreplikat nachverfolgt werden.

Wenn beide Anbieter einer Synchronisierungssitzung Filternachverfolgungsanbieter sind, vermittelt Sync Framework die Aushandlung darüber, welche Filter von beiden Anbietern nachverfolgt werden. Nachverfolgte Filter werden zwischen zwei Filternachverfolgungsanbietern mithilfe folgender Schritte ausgehandelt:

1. Nach dem Aufrufen von BeginSession(für verwalteten Code) bzw. IKnowledgeSyncProvider::BeginSession (für nicht verwalteten Code) ruft Sync Framework auf dem Zielanbieter SpecifyTrackedFilters (für verwalteten Code) bzw. IFilterTrackingProvider::SpecifyTrackedFilters (für nicht verwalteten Code) auf.

2. Der Zielanbieter listet die nachverfolgten Filter auf und übergibt jeden an das RequestTrackedFilterCallback-Delegat (für verwalteten Code) bzw. an die IFilterRequestCallback::RequestFilter-Methode des IFilterRequestCallback-Objekts (für nicht verwalteten Code), das in dem Aufruf für SpecifyTrackedFilters angegeben ist.

3. Für jeden vom Zielanbieter angegebenen Filter ruft Sync Framework auf dem Quellenanbieter TryAddTrackedFilter (für verwalteten Code) bzw. IFilterTrackingProvider::AddTrackedFilter (für nicht verwalteten Code) auf.

4. Der Quellenanbieter verwaltet eine Liste von durch den Zielanbieter nachverfolgten Filtern und gibt einen Wert zurück, der angibt, ob er den gelisteten Filter nachverfolgt.

5. Sync Framework übergibt diesen Wert an den Zielanbieter.

Senden von Filtermetadaten für nachverfolgte Filter

Wenn der Zielanbieter Filter nachverfolgt, die auch vom Quellenanbieter nachverfolgt werden, muss der Quellenanbieter Filtermetadaten für die gemeinsam nachverfolgten Filter senden. Hierzu müssen Sie folgende Änderungen an der Implementierung des Quellenanbieters von GetChangeBatch (für verwalteten Code) bzw. IKnowledgeSyncProvider::GetChangeBatch (für nicht verwalteten Code) vornehmen:

• Fügen Sie dem ChangeBatch-Objekt ein FilterKeyMap-Objekt hinzu, indem Sie die FilterKeyMap-Eigenschaft festlegen (für verwalteten Code), bzw. fügen Sie dem ISyncChangeBatchWithFilterKeyMap-Objekt ein IFilterKeyMap-Objekt hinzu, indem Sie ISyncChangeBatchWithFilterKeyMap::SetFilterKeyMap aufrufen (für nicht verwalteten Code). Das Filterschlüssel-Zuordnungsobjekt enthält die Filter, die sowohl vom Quellen- als auch vom Zielanbieter nachverfolgt werden. Die FilterKeyMap-Eigenschaft muss festgelegt sein (für verwalteten Code), bzw. die SetFilterKeyMap-Methode muss aufgerufen werden (für nicht verwalteten Code), bevor im Änderungsbatch Gruppen gestartet werden.

• Fügen Sie für jede Gruppe im Änderungsbatch vergessenes Filterwissen für nachverfolgte Filter hinzu, indem Sie SetFilterForgottenKnowledge (für verwalteten Code) bzw. ISyncChangeBatchWithFilterKeyMap::SetFilterForgottenKnowledge (für nicht verwalteten Code) aufrufen.

• Senden Sie für jedes Element oder jede Änderungseinheit, die in einen oder aus einem Filter verschoben wurde, Metadaten für die Filteränderung. Metadaten für die Filteränderung werden einer Änderung hinzugefügt, indem AddFilterChange (für verwalteten Code) bzw. IFilterTrackingSyncChangeBuilder::AddFilterChange (für nicht verwalteten Code) aufgerufen wird. Die FilterChange-Eigenschaften (für verwalteten Code) bzw. SYNC_FILTER_CHANGE-Werte (für nicht verwalteten Code) geben an, ob ein Element in einen oder aus einem Filter verschoben wurde und welche Änderungsversion das Verschieben verursacht hat. Die Metadaten für die Filteränderungen werden nur hinzugefügt, wenn die verschobene Version nicht im Zielwissen des Elements enthalten ist. Bei Verwendung von Änderungseinheiten müssen Metadaten für die Filteränderungen hinzugefügt werden, wenn die verschobene Version nicht im Zielwissen einer der Änderungseinheiten enthalten ist. Achten Sie darauf, dass verschobene Versionen wie Elementversionen behandelt werden, auch wenn Änderungseinheiten verwendet werden. Aus diesem Grund muss die Eingrenzung mithilfe einer Form der Contains-Methode (für verwalteten Code) bzw. der ISyncKnowledge::ContainsChange-Methode (für nicht verwalteten Code) überprüft werden, die eine Elementversion und keine Änderungseinheitsversion verwendet.

• Wenn Änderungseinheiten verwendet werden und mindestens eine Änderungseinheit nicht im Zielwissen enthalten ist, rufen Sie ContainsMarker (für verwalteten Code) bzw. IKnowledgeWithMarkers::ContainsAllChangeUnitsRequiredMarker (für nicht verwalteten Code) auf dem Zielwissen auf, und geben Sie AllChangeUnitsRequired sowie die Element-ID des besitzenden Elements (für verwalteten Code) oder die Element-ID des besitzenden Elements (für nicht verwalteten Code) an. Wenn diese Methode angibt, dass alle Änderungseinheiten benötigt werden, senden Sie alle Änderungseinheiten für das Element und rufen Sie SetAllChangeUnitsPresent auf dem ItemChange-Objekt (für verwalteten Code) bzw. IFilterTrackingSyncChangeBuilder::SetAllChangeUnitsPresentFlag (für nicht verwalteten Code) auf.

Senden von gefilterten Änderungen

Normalerweise kann ein Quellenanbieter, der ein Filternachverfolgungsreplikat darstellt, für jeden der nachverfolgten Filter Änderungsbatches auflisten. Der Filter kann entweder von der Anwendung mithilfe eines benutzerdefinierten Mechanismus zwischen Anwendung und Quellenanbieter identifiziert werden, oder er kann zwischen dem Quellenanbieter und dem Zielanbieter ausgehandelt werden. Die Filteraushandlung wird später in diesem Dokument beschrieben.

Um einen gefilterten Änderungsbatch zu senden, fügen Sie der GetChangeBatch-Methode des Quellenanbieters die folgenden Elemente hinzu:

• Erstellen Sie ein CustomFilterInfo-Objekt (für verwalteten Code) bzw. ein ICustomFilterInfo-Objekt (für nicht verwalteten Code), das die für die Synchronisierung verwendeten Filter enthält. Erstellen Sie ein gefiltertes Änderungsbatchobjekt, indem Sie das Filterinformationsobjekt dem entsprechenden Änderungsbatchkonstruktur ChangeBatch (für verwalteten Code) übergeben bzw. indem Sie IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (für nicht verwalteten Code) aufrufen. Übergeben Sie weiterhin anstelle des vergessenen Wissens des Replikats das vergessene Filterwissen des Filters, wenn Sie ein Änderungsbatchobjekt erstellen.

• Wenn sich zuvor ein Element oder eine Änderungseinheit im Filter befand, dies aktuell aber nicht der Fall ist, geben Sie als ChangeKind-Eigenschaft Ghost an (für verwalteten Code), bzw. übergeben Sie das SYNC_CHANGE_FLAG_GHOST-Flag an ISyncChangeBatchBase::AddItemMetadataToGroup (für nicht verwalteten Code).

• Wenn der Filtertyp des Zielanbieters CurrentItemsOnly (für verwalteten Code) bzw. FT_CURRENT_ITEMS_ONLY (für nicht verwalteten Code) ist, schließen Sie nur dann ein Element in den Änderungsbatch mit ein, wenn er sich im Filter befindet. Senden Sie demnach keine inaktiven Elemente.

• Wenn der Filtertyp des Zielanbieters CurrentItemsAndVersionsForMovedOutItems (für verwalteten Code) bzw. FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (für nicht verwalteten Code) ist, schließen Sie Elemente mit ein, die sich im Filter befinden, und Filter, die aus dem Filter verschoben wurden. Informationen über das Verschieben aus dem Filter müssen dann gesendet werden, wenn ein Element oder eine Änderungseinheit sich zuvor im Filter befunden hat, sich das Element oder die Änderungseinheit aktuell im Filter befindet und die Version der Änderung, die das Element oder die Änderungseinheit aus dem Filter verschoben hat, nicht im Zielwissen enthalten ist.

Anwenden von Filtermetadaten

Wenn ein Zielanbieter einen Filternachverfolgungsanbieter darstellt und einen Änderungsanwender zum Anwenden von Änderungen am Zielreplikat einsetzt, muss der Zielanbieter IFilterTrackingNotifyingChangeApplierTarget (für verwalteten Code) bzw. IFilterTrackingNotifyingChangeApplierTarget (für nicht verwalteten Code) implementieren. Diese Schnittstelle enthält Methoden, die Sync Framework verwendet, um die Filterschlüsselzuordnung zu erhalten und vergessenes Wissen nachverfolgter Filter zu filtern. Sie enthält auch die Methoden SaveKnowledgeWithFilterForgottenKnowledge (für verwalteten Code) bzw. IFilterTrackingNotifyingChangeApplierTarget::SaveKnowledgeWithFilterForgottenKnowledges (für nicht verwalteten Code), die Sync Framework anstelle von StoreKnowledgeForScope (für verwalteten Code) bzw. ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (für nicht verwalteten Code) für Filternachverfolgungsanbieter aufruft. Sync Framework verwendet diese Methode zum Senden von aktualisiertem Wissen, vergessenem Wissen und vergessenem Filterwissen, nachdem ein Änderungsbatch angewendet wurde.

Zusätzlich zum Implementieren von IFilterTrackingNotifyingChangeApplierTarget muss die SaveItemChange-Methode bzw. die SaveChangeWithChangeUnits-Methode (für verwalteten Code) bzw. die ISynchronousNotifyingChangeApplierTarget::SaveChange-Methode oder die ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits-Methode (für nicht verwalteten Code) des Zielanbieters aktualisiert werden, damit die folgenden Schritte ausgeführt werden können.

1. Lassen Sie die Filteränderungs-Metadaten für jeden nachverfolgten Filter anzeigen, indem Sie GetFilterChange (für verwalteten Code) bzw. ISyncChangeWithFilterKeyMap::GetFilterChange (für nicht verwalteten Code) auf dem Änderungsobjekt aufrufen.

2. Wenn Metadaten für Filteränderungen vorhanden sind, überprüfen Sie, ob diese nicht veraltet sind. Eine Filteränderung ist veraltet, wenn die zugehörige verschobene Version im Zielwissen des Elements enthalten ist. Bei Verwendung von Änderungseinheiten ist eine Filteränderung nur dann veraltet, wenn die verschobene Version im Zielwissen aller Änderungseinheiten enthalten ist. Übernehmen Sie die Filteränderung nicht für das Zielreplikat, wenn sie veraltet ist.

3. Wenn Metadaten für Filteränderungen vorhanden und nicht veraltet sind, überprüfen Sie, ob auch kein Konflikt mit den Filterwechselinformationen vorliegt, die bereits im Zielreplikat vorhanden sind. Um Konflikte zu prüfen, führen Sie die folgenden Schritte aus:

   1. Rufen Sie die verschobene Version ab, die aktuell für das Element oder die Änderungseinheit im Zielreplikat gespeichert ist.

   2. Überprüfen Sie, ob die verschobene Version im Anwendungswissen des Elements oder im Anwendungswissen jeder Änderung der Änderungseinheit, die dem Element zugewiesen ist, enthalten ist.

   3. Wenn die verschobene Version nicht in dem entsprechenden Anwendungswissen enthalten ist, liegt bei der Filteränderung ein Konflikt vor. Der Zielanbieter muss den Konflikt, soweit erforderlich, beheben und eine neue verschobene Version für die Änderung zuweisen.

   4. Wenn in der verschobenen Version keine Konflikte erkannt werden, vergleichen Sie das Flag für das Hineinverschieben der Quellfilteränderung mit dem Flag für das Hineinverschieben des Zielelements oder der Änderungseinheit. Wenn der Wert oder das Flag inkonsistent ist, muss der Zielanbieter das Element oder die Änderungseinheit für den Filter auswerten und den richtigen Wert des Flags für das Hineinverschieben zusammen mit der neuen verschobenen Version zuweisen.

   5. Wenn keine Konflikte erkannt werden, speichern Sie die Filteränderungs-Metadaten zusammen mit den Metadaten für das Element.

4. Wenn für einen nachverfolgten Filter oder für einen Filter, der vom Zielreplikat, jedoch nicht vom Quellreplikat nachverfolgt wird, keine Metadaten für Filteränderungen vorhanden sind, werten Sie die Änderung anhand des Filters am Ziel aus. Aktualisieren Sie die Filtermetadaten mit der Information, ob das Element im Filter enthalten ist, und aktualisieren Sie die verschobene Version auf die Version der Änderung, wenn die Änderung dazu geführt hat, dass das Element im Verhältnis zum Filter verschoben wurde. Wenn einem Filter mehrere Änderungseinheiten zugeordnet sind und eine Änderung bei einer der Änderungseinheiten dazu führt, dass das Element im Verhältnis zum Filter verschoben wird, erstellen Sie eine neue lokale Version, und weisen Sie die neue Version als verschobene Version des Elements und als Änderungsversion für alle dem Filter zugeordneten Änderungseinheiten zu.

Gefilterte Replikate

Ein gefiltertes Replikat speichert Daten für Elemente und Änderungseinheiten nur für solche Elemente und Änderungseinheiten, die sich in seinem Filter befinden, sowie für inaktive Elemente, die Metadaten für Elemente und Änderungseinheiten darstellen, die sich im Filter befunden haben, aber verschoben wurden. Ein gefiltertes Replikat verfolgt seinen eigenen Filter nach. Es kann auch andere Filter nachverfolgen. Ein gefiltertes Replikat kann mit dem Quellenanbieter einen Filter aushandeln. In diesem Fall erstellt der Quellenanbieter einen gefilterten Änderungsbatch. Wenn der Quellenanbieter keinen gefilterten Änderungsbatch erstellen kann, kann der gefilterte Anbieter selbst die Änderungen filtern und nur jene anwenden, die sich in seinem Filter befinden.

Weitere Informationen zum Implementieren eines gefilterten Replikats finden Sie unter Vorgehensweise: Filtern eines Replikats.

Auflisten von Elementen, die in den Filter verschoben wurden

Ein gefiltertes Replikat implementiert die IFilteredReplicaNotifyingChangeApplierTarget-Schnittstelle (für verwalteten Code) bzw. die IFilteredReplicaNotifyingChangeApplierTarget-Schnittstelle (für nicht verwalteten Code). Diese Schnittstelle enthält GetNewMoveInItems (für verwalteten Code) bzw. IFilteredReplicaNotifyingChangeApplierTarget::GetNewMoveins (für nicht verwalteten Code). Sie werden von Sync Framework verwendet, um Elemente zu erhalten, die nach einem bestimmten Zeitpunkt in den Filter verschoben wurden. Der Liste, die von dieser Methode zurückgegeben wird, wird dann ein Element hinzugefügt, wenn es aktiv ist, sich im Filter befindet und die verschobene Version des Elements nicht in dem für die Methode angegebenen Wissen enthalten ist.

Senden von ungefilterten Änderungen

Wenn das gefilterte Replikat das Quellreplikat ist und das Zielreplikat keine gefilterte Änderungsauflistung anfordert oder zwischen den beiden Replikaten kein Filter ausgehandelt werden konnte, listet das Quellreplikat Änderungen so auf, als ob es nicht gefiltert wäre. Dies unterscheidet sich auf folgende Weise von dem Vorgang, gefilterte Änderungen zu senden:

• Ein ungefilterter Änderungsbatch wird erstellt.

• Beim Erstellen des Änderungsbatchs wird das vergessene Wissen übergeben und nicht das vergessene Filterwissen, wie es beim Senden gefilterter Änderungen der Fall ist.

Anwenden von gefilterten Änderungen

Wenn der Zielanbieter einen Änderungsanwender zum Anwenden von Änderungen einsetzt, muss er beim Senden von Zielversionen an den Änderungsanwender angeben, ob das Zielelement oder die Änderungseinheit ein inaktives Element ist. Geben sie hierzu Ghost für die ChangeKind-Eigenschaft an (für verwalteten Code), bzw. übergeben Sie das SYNC_CHANGE_FLAG_GHOST-Flag an IDestinationChangeVersionsBuilder::AddItemMetadata (für nichtverwalteten Code), wenn es sich bei dem Element um ein inaktives Element im Zielreplikat handelt. Ein Element gilt als inaktives Element, wenn im Ziel-Metadatenspeicher Metadaten für das Element vorhanden sind, das Element nicht gelöscht wurde und im Zielspeicher keine Daten für das Element vorhanden sind.

Wenn die Änderungen vom Quellenanbieter nicht gefiltert werden, überprüft der Zielanbieter alle vom Quellenanbieter gesendeten Änderungen anhand des Filters des Zielreplikats. Alle Änderungen, die den Filter passieren, werden vom Zielanbieter übernommen und alle entsprechenden inaktiven Elemente werden durch den Zielanbieter aktualisiert. Alle übergangenen Änderungen werden vom Zielanbieter aus dem Wissen des Änderungsbatchs ausgeschlossen.

Außerdem muss der Zielanbieter die folgenden Änderungen an den Methoden SaveItemChange bzw. SaveChangeWithChangeUnits (für verwalteten Code) oder ISynchronousNotifyingChangeApplierTarget::SaveChange bzw. ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (für nicht verwalteten Code) vornehmen.

• Behandeln Sie die Aktionen CreateGhost und UpdateGhost (für verwalteten Code) oder SSA_CREATE_GHOST bzw. SSA_UPDATE_GHOST (für nicht verwalteten Code), indem Sie die Metadaten für ein inaktives Element erstellen oder aktualisieren. Ggf. müssen auch Metadaten für die Filteränderung aktualisiert werden.

• Behandeln Sie die MarkItemAsGhost-Aktion (für verwalteten Code) bzw. die SSA_GHOST_ITEM-Aktion (für nicht verwalteten Code), indem Sie Daten des Elements bzw. der Änderungseinheit entfernen und die Metadaten des Elements bzw. der Änderungseinheit aktualisieren, um die Änderung wiederzugeben.

• Behandeln Sie die UnmarkItemAsGhost-Aktion (für verwalteten Code) bzw. die SSA_UNGHOST_ITEM-Aktion (für nicht verwalteten Code), indem Sie die Daten des Elements oder der Änderungseinheit abrufen, die Daten im Zielreplikat speichern und die Metadaten aktualisieren, um die Änderung wiederzugeben.

• Behandeln Sie die DeleteGhostAndStoreTombstone-Aktion (für verwalteten Code) bzw. die SSA_DELETE_GHOST_AND_STORE_TOMBSTONE-Aktion (für nicht verwalteten Code), indem Sie die Metadaten des inaktiven Elements als gelöscht markieren.

Bereinigen von inaktiven Elementen

Inaktive Elemente können entfernt werden, um Speicherplatz in einem gefilterten Replikat freizugeben. Beim Entfernen eines inaktiven Elements muss das vergessene Wissen des Filters aktualisiert werden, indem die verschobene Version des inaktiven Elements an die ForgetTo-Methode (für verwalteten Code) bzw. die IForgottenKnowledge::ForgetToVersion-Methode (für nicht verwalteten Code) des vergessenen Filterwissens übergeben wird.

Aushandeln des Filters

Der Zielanbieter kann den Filter angeben, der während der Änderungsenumeration vom Quellenanbieter verwendet wird. Der Quellenanbieter kann den vom Zielanbieter angeforderten Filter akzeptieren oder verweigern. Der Zielanbieter kann weiterhin Filter anfordern, bis einer gefunden wird, den der Quellenanbieter akzeptiert. Diese Aushandlung wird von Sync Framework vermittelt. Der Filter kann einen beliebigen Typ aufweisen, der für die Anbieter am besten geeignet ist.

Für die Teilnahme am Aushandeln eines Filters muss der Quellenanbieter ISupportFilteredSync (für verwalteten Code) bzw. ISupportFilteredSync (für nicht verwalteten Code) implementieren, und der Zielanbieter muss IRequestFilteredSync (für verwalteten Code) bzw. IRequestFilteredSync (für nicht verwalteten Code) implementieren.

Die Filteraushandlung wird mit den folgenden Schritten durchgeführt:

1. Vor dem Auflisten der Änderungen durch den Quellenanbieter und nach dem Aufrufen von BeginSession (für verwalteten Code) bzw. IKnowledgeSyncProvider::BeginSession (für nicht verwalteten Code) wird die Filteraushandlung von Sync Framework durch Aufrufen der SpecifyFilter-Methode (für verwalteten Code) bzw. der IRequestFilteredSync::SpecifyFilter-Methode (für nicht verwalteten Code) auf dem Zielanbieter gestartet.

2. Während der Verarbeitung von SpecifyFilter übergibt der Zielanbieter Filter an den FilterRequestCallback-Delegat (für verwalteten Code) bzw. an die IFilterRequestCallback::RequestFilter-Methode (für nicht verwalteten Code), die von Sync Framework festgelegt ist. Wenn der Zielanbieter den angeforderten Filter nicht nachverfolgt, wird der Filtertyp CurrentItemsOnly (für verwalteten Code) bzw. FT_CURRENT_ITEMS_ONLY (für nicht verwalteten Code) festgelegt. Wenn der Zielanbieter den angeforderten Filter nachverfolgt, wird der Filtertyp CurrentItemsAndVersionsForMovedOutItems (für verwalteten Code) bzw. FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (für nicht verwalteten Code) festgelegt.

3. Während der Verarbeitung von FilterRequestCallback (für verwalteten Code) bzw. RequestFilter (für nicht verwalteten Code), ruft Sync Framework die TryAddFilter-Methode (für verwalteten Code) bzw. die ISupportFilteredSync::AddFilter-Methode (für nicht verwalteten Code) des Quellenanbieters auf. Wenn der Quellenanbieter den angeforderten Filter nicht unterstützt, kann der Zielanbieter so lange Filter anfordern, bis ein unterstützter Filter gefunden wird.

4. Wenn ein vom Quellenanbieter akzeptierter Filter vom Zielanbieter nicht gefunden wird, kann dieser die Synchronisierung durch Auslösen von SyncInvalidOperationException (für verwalteten Code) abbrechen oder einen Fehlercode zurückgeben, z. B. SYNC_E_FILTER_NOT_SUPPORTED (für nicht verwalteten Code).

Wenn ein Filter erfolgreich ausgehandelt wurde, wird er vom Quellenanbieter zur Festlegung der während der Änderungsenumeration einzuschließenden Elemente verwendet.

Weitere Informationen zum Aushandeln von Filtern finden Sie unter Vorgehensweise: Aushandeln eines Filters.

Siehe auch

Konzepte

Implementieren eines benutzerdefinierten Standardanbieters
Implementieren einer Synchronisierungsanwendung
Vorgehensweise: Filtern von Auflistungselementen
Vorgehensweise: Filtern aufgelisteter Änderungseinheiten
Vorgehensweise: Aushandeln eines Filters
Vorgehensweise: Nachverfolgen von Filtern und Auflisten von gefilterten Änderungen
Vorgehensweise: Filtern eines Replikats