Фильтрация данных синхронизации

Фильтр используется для ограничения синхронизируемых данных. Обычно поставщик источника применяет фильтр в ходе перечисления изменений, чтобы ограничить отправляемые изменения. Sync Framework поддерживает следующие типы фильтров.

• Фильтры элементов ограничивают данные синхронизации подмножеством элементов, например синхронизируют между двумя папками только TXT-файлы, не обрабатывая файлы других типов. Элементы не изменяются таким способом, который вызывает перемещение существующего элемента в фильтр или из фильтра. Фильтры элементов просты в использовании, но объем метаданных, используемых при синхронизации, растет пропорционально количеству элементов в области синхронизации.

• Фильтры базовых единиц ограничивают данные синхронизации подмножеством базовых единиц, например синхронизируют только поля name и phone number контакта, не обрабатывая остальные базовые единицы.

• Пользовательские фильтры ограничивают данные синхронизации способами, неизвестными платформе Sync Framework. Элементы могут время от времени включаться в пользовательские фильтры или исключаться из них. Платформа Sync Framework определяет дополнительные метаданные, интерфейсы и классы, которые эффективно поддерживают пользовательские фильтры, сдерживая в то же время рост общего объема метаданных.

Фильтр может определяться приложением синхронизации, поставщиком источника или назначения либо согласовываться между поставщиком источника и поставщиком назначения.

Фильтр используется поставщиком источника в ходе обнаружения изменений. Пакеты изменений, которые формируются в ходе обнаружения изменений, включают только данные синхронизации, проходящие фильтр.

Кроме того, фильтр может использоваться поставщиком назначения во время применения изменений. В изменения, которые применяются в реплике назначения, входят только данные синхронизации, проходящие фильтр.

Выбор элементов для синхронизации

Фильтр элементов определяет, какие изменения элементов отправляются поставщиком источника в ходе перечисления изменений. Поскольку способ фильтрации элементов зависит от типа данных в области синхронизации, Sync Framework позволяет поставщику источника определять механизм фильтрации. Обмен необходимыми данными о фильтре между поставщиком и приложением синхронизации можно организовать любым подходящим механизмом.

Если поставщик источника фильтрует изменения элементов, Sync Framework требует, чтобы поставщик добавлял ко всем объектам пакета изменений, отправляемым в ходе перечисления изменений, сведения о фильтре. Сведения о фильтре элементов, находящиеся в объекте пакета изменений, сообщают Sync Framework о том, что выполняется фильтруемая синхронизация, чтобы Sync Framework правильно обрабатывала набор знаний для отфильтрованного пакета изменений. Если поставщик источника фильтрует элементы, входящие в пакет изменений, но не указывает в объекте пакета изменений сведения о фильтре, то Sync Framework может неправильно обрабатывать набор знаний.

Если поставщик источника использует фильтр для ограничения элементов, содержащихся в пакете изменений, он должен добавлять сведения об этом фильтре к объекту ChangeBatch (для управляемого кода) или ISyncChangeBatch (для неуправляемого кода). Сведения о фильтре представляются в виде объекта ItemListFilterInfo (для управляемого кода) или ISyncFilterInfo с установленным флагом SYNC_FILTER_INFO_FLAG_ITEM_LIST (для неуправляемого кода). В неуправляемом коде поставщик создает объект ISyncFilterInfo путем вызова метода IProviderFilteredSyncServices::CreateFilterInfo. Сведения о фильтре прикрепляются к пакету изменений путем вызова метода ChangeBatch (для управляемого кода) или IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (для неуправляемого кода) для создания объекта пакета изменений.

Дополнительные сведения о фильтрации элементов см. в разделе Как отфильтровать перечисляемые элементы.

Выбор базовых единиц для синхронизации

Фильтр базовых единиц определяет, какие изменения базовых единиц включаются в каждое изменение элемента, которое отправляется поставщиком источника в ходе перечисления изменений. Фильтр базовых единиц полезен в случае, когда в реплике хранится лишь подмножество базовых единиц, определенных для элементов из области.

Например, сообщество синхронизации обменивается контактной информацией и определяет базовые единицы для параметров name, phone number и address. Одна из реплик в сообществе представляет собой мобильное устройство, которое может сохранять только объекты name и phone number. Эта реплика с помощью фильтра базовых единиц указывает, что отслеживается только набор знаний для этих двух базовых единиц. Когда реплика источника синхронизирует данные с этой репликой-устройством, применяется фильтр базовых единиц, чтобы отправлять только данные о базовых единицах name и phone number. Набор известных знаний с поставщика источника проецируется на фильтр базовых единиц, чтобы в набор знаний на реплике-устройстве попадали только объекты знаний о базовых единицах name и phone number. Аналогично, если на устройстве выполняется локальное изменение, а затем устройство участвует в сеансе синхронизации в качестве реплики источника, то реплика, принимающая изменения, обновляет набор знаний только для указанного набора базовых единиц.

Если используется фильтр базовых единиц, Sync Framework проецирует набор знаний для пакета изменений на набор базовых единиц, указанный в фильтре, чтобы в набор знаний для пакета изменений попадали только данные об указанном наборе базовых единиц.

Для фильтрации изменений базовых единиц поставщик источника создает объект ChangeUnitListFilterInfo (для управляемого кода) или IChangeUnitListFilterInfo (для неуправляемого кода) и указывает набор синхронизируемых базовых единиц. В неуправляемом коде объект IChangeUnitListFilterInfo создается путем передачи параметра SYNC_FILTER_INFO_FLAG_CHANGE_UNIT_LIST методу IProviderFilteredSyncServices::CreateFilterInfo. Поставщик источника прикрепляет к пакету изменений сведения о фильтре путем вызова метода ChangeBatch (для управляемого кода) или IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (для неуправляемого кода) для создания объекта пакета изменений.

Дополнительные сведения об использовании фильтра базовых единиц см. в разделе Как отфильтровать перечисляемые базовые единицы.

Управление набором синхронизируемых объектов с помощью пользовательского фильтра

Пользовательский фильтр определяется за пределами платформы Sync Framework, обычно разработчиком поставщика, хотя его может создать и сторонний разработчик. Платформа Sync Framework ничего не знает о способе, которым фильтр определяет, что необходимо включить в область синхронизации. Пользовательский фильтр можно определить таким образом, что элементы будут время от времени включаться в фильтр и исключаться из него. Например, для реплики, в которой хранятся файлы мультимедиа, можно создать фильтр, включающий все файлы, которые получили оценку не ниже трех звезд. При изменении оценки файла, он может быть включен в фильтр или исключен из него.

Учтите, что пользовательские фильтры не могут быть использованы простыми поставщиками, а также поставщиками, которые сообщают о конфликтах ограничений или пользуются службами применения изменений, так как это может привести к непредвиденным результатам.

Для эффективной поддержки пользовательских фильтров платформа Sync Framework определяет несколько новых основных понятий.

• Отслеживающая фильтры реплика — это реплика, которая поддерживает метаданные, определяющие, какие элементы и базовые единицы включены в настоящий момент в отслеживаемый фильтр, какие элементы и базовые единицы были за последнее время включены в отслеживаемый фильтр или исключены из него, а также утраченный набор знаний фильтра, относящийся ко всем элементам и базовым единицам, которые были исключены из отслеживаемого фильтра и утрачены. Отслеживание фильтра не влияет на то, какие элементы хранятся в реплике. Реплика может отслеживать несколько фильтров при сохранении всех элементов из области синхронизации. Как правило, отслеживающая фильтры реплика может выполнять фильтрованный пакет изменений для любого из отслеживаемых фильтров.

• Фильтруемая реплика — это реплика, которая хранит данные элементов и базовых единиц только для элементов и базовых единиц, имеющихся в фильтре, а также метаданные для элементов и базовых единиц, которые были исключены из фильтра. Фильтруемая реплика всегда отслеживает используемый ею фильтр. Кроме того, она может отслеживать и другие фильтры. Поставщик назначения с фильтрацией может запросить у поставщика источника перечисление изменений с фильтрацией или запросить полное перечисление изменений и самостоятельно отфильтровать изменения в процессе их применения.

• Фантомы — это элементы или базовые единицы в фильтруемой реплике, которые были исключены из фильтра. Фильтруемая реплика сохраняет метаданные фантомов, но не сохраняет данные элементов или базовых единиц.

• Утраченный набор знаний фильтра определяет начальную точку для отслеживания фильтра. Отслеживающая фильтры реплика может сэкономить расходуемый объем хранилища путем удаления фантомов и расширения утраченного набора знаний фильтра путем включения в него старших версий удаленных фантомов. Утраченный набор знаний фильтра используется также в момент, когда реплика начинает отслеживать фильтр после его использования другими репликами сообщества синхронизации.

Отслеживание фильтров

Рекомендуется, чтобы все реплики в сообществе синхронизации отслеживали фильтры, используемые в этом сообществе. Если фильтруемая реплика получает перечисление изменений с фильтрацией от отслеживающей фильтры реплики, набор знаний фильтруемой реплики сохраняет небольшой размер. Если фильтруемая реплика получает перечисление изменений с фильтрацией от реплики, не отслеживающей изменения, размер набора знаний растет пропорционально количеству отправленных изменений.

Дополнительные сведения об отслеживании фильтров см. в разделе Как отслеживать фильтры и перечислять фильтруемые изменения.

Метаданные фильтра

Для отслеживания фильтра реплика сохраняет метаданные фильтра для каждого включенного в эту реплику элемента или базовой единицы. Метаданные фильтра содержат элементы, перечисленные в следующей таблице.

Включен ли в фильтр	Версия перемещения
Указывает, включен ли элемент или базовая единица в фильтр.	Версия изменения, которое вызвало включение элемента в фильтр или исключение из фильтра. Если элемент включен в фильтр при создании, эта версия равна версии создания элемента. Если элемент никогда не был включен в фильтр, эта версия равна (0,0).

Когда реплика начинает отслеживание фильтра, необходимо проверить условие фильтра для всех элементов и базовых единиц. Если элемент или базовая единица включены в фильтр, соответствующие метаданные фильтра должны указывать на это, а версии перемещения должна быть присвоена версия последнего изменения элемента или базовой единицы. Если элемент не включен в фильтр, соответствующие метаданные фильтра должны указывать на это, а версии перемещения должно быть присвоено значение (0,0).

Отслеживающая фильтры реплика может также хранить утраченный набор знаний фильтра для каждого отслеживаемого фильтра. Если отслеживающая фильтры реплика отслеживает фильтр с момента его создания, она не хранит утраченный набор знаний фильтра, пока не получает данные синхронизации от реплики, не отслеживающей фильтр. Если отслеживающая фильтры реплика начинает отслеживание фильтра в некоторый момент времени после создания фильтра, она должна инициализировать утраченный набор знаний фильтра текущим набором знаний реплики. Если в реплике очищаются отметки полного удаления и метаданные изменений фильтра, можно удалить утраченный набор знаний фильтра и использовать вместо него утраченный набор знаний реплики.

Согласование отслеживаемых фильтров

Отслеживающий фильтры поставщик должен реализовать интерфейс IFilterTrackingProvider (для управляемого кода) или IFilterTrackingProvider (для неуправляемого кода). Этот интерфейс используется для связи с фильтрами, отслеживаемыми как в исходной, так и в конечной реплике. Исходная реплика отправляет метаданные фильтров, отслеживаемых как в исходной, так и в конечной реплике.

Если оба поставщика в сеансе синхронизации отслеживают фильтры, платформа Sync Framework служит посредником при согласовании того, какие фильтры отслеживают оба поставщика. Отслеживаемые фильтры согласуются между двумя отслеживающими фильтры поставщиками в процессе выполнения следующих шагов.

1. После вызова метода BeginSession (для управляемого кода) или IKnowledgeSyncProvider::BeginSession (для неуправляемого кода) Sync Framework вызывает SpecifyTrackedFilters (для управляемого кода) или IFilterTrackingProvider::SpecifyTrackedFilters (для неуправляемого кода) или в поставщике назначения.

2. Поставщик назначения перечисляет отслеживаемые им фильтры и передает каждый из них делегату RequestTrackedFilterCallback (для управляемого кода) или методу IFilterRequestCallback::RequestFilter объекта IFilterRequestCallback (для неуправляемого кода), указанного при вызове метода SpecifyTrackedFilters.

3. Для каждого из фильтров, указанных поставщиком назначения, платформа Sync Framework вызывает метод TryAddTrackedFilter (для управляемого кода) или IFilterTrackingProvider::AddTrackedFilter (для неуправляемого кода) на поставщике источника.

4. Поставщик источника ведет список фильтров, отслеживаемых поставщиком назначения, и возвращает значение, показывающее, отслеживается ли им заданный фильтр.

5. Платформа Sync Framework передает это значение поставщику назначения.

Отправка метаданных отслеживаемых фильтров

Если поставщик назначения отслеживает фильтры, которые отслеживает и поставщик источника, то поставщик источника должен передавать метаданные совместно отслеживаемых фильтров. Для этого выполните следующие изменения в реализации на поставщике источника метода GetChangeBatch (для управляемого кода) или IKnowledgeSyncProvider::GetChangeBatch (для неуправляемого кода).

• Добавьте объект FilterKeyMap к объекту ChangeBatch путем установки свойства FilterKeyMap (для управляемого кода) или добавьте объект IFilterKeyMap к объекту ISyncChangeBatchWithFilterKeyMap путем вызова метода ISyncChangeBatchWithFilterKeyMap::SetFilterKeyMap (для неуправляемого кода). Объект схемы ключей фильтра содержит фильтры, отслеживаемые как поставщиком источника, так и поставщиком назначения. Необходимо задать значение свойства FilterKeyMap (для управляемого кода) или вызвать метод SetFilterKeyMap (для неуправляемого кода) перед запуском любых групп в пакете изменений.

• Для каждой группы в пакете изменений добавьте утраченные наборы знаний отслеживаемых фильтров путем вызова метода SetFilterForgottenKnowledge (для управляемого кода) или ISyncChangeBatchWithFilterKeyMap::SetFilterForgottenKnowledge (для неуправляемого кода).

• Передавайте метаданные изменений фильтра для каждого элемента или базовой единицы, которые были включены в отслеживаемый фильтр или исключены из него. Метаданные изменений фильтра добавляются к изменениям путем вызова метода AddFilterChange (для управляемого кода) или IFilterTrackingSyncChangeBuilder::AddFilterChange (для неуправляемого кода). Свойства FilterChange (для управляемого кода) или значения SYNC_FILTER_CHANGE (для неуправляемого кода) указывают, был ли элемент включен в фильтр или исключен из него, а также версию изменения, вызвавшего это включение или исключение. Метаданные изменения фильтра добавляются только в тех случаях, когда его версия перемещения не содержится в наборе знаний назначения для элемента. При использовании базовых единиц метаданные изменений фильтра должны добавляться, если версия перемещения не содержится в наборе знаний назначения какой-либо из базовых единиц. Учтите, что версии перемещения обрабатываются как версии элементов, даже если используются базовые единицы, поэтому проверка наличия базовой единицы должна производиться с помощью формы метода Contains (для управляемого кода) или метода ISyncKnowledge::ContainsChange (для неуправляемого кода), которая принимает версию элемента, а не использует версию базовой единицы.

• Если используются базовые единицы и хотя бы одно изменение базовой единицы не содержится в наборе знаний назначения, вызовите метод ContainsMarker (для управляемого кода) или IKnowledgeWithMarkers::ContainsAllChangeUnitsRequiredMarker (для неуправляемого кода) на наборе знаний назначения, указав параметр AllChangeUnitsRequired и идентификатор владельца элемента (для управляемого кода) или идентификатор владельца элемента (для неуправляемого кода). Если этот метод указывает, что требуются все базовые единицы, передайте все базовые единицы для элемента и вызовите метод SetAllChangeUnitsPresent объекта ItemChange (для управляемого кода) или метод IFilterTrackingSyncChangeBuilder::SetAllChangeUnitsPresentFlag (для неуправляемого кода).

Отправка изменений с фильтрацией

Обычно поставщик источника, который представляет отслеживающую фильтры реплику, может перечислить фильтрованные пакеты изменений для любых отслеживаемых фильтров. Фильтр может быть определен приложением с помощью пользовательского механизма между приложением и поставщиком источника или путем согласования между поставщиком источника и поставщиком назначения. Согласование фильтров описано далее в данном документе.

Для передачи фильтрованного пакета изменений добавьте следующие элементы в метод GetChangeBatch на поставщике источника.

• Создайте объект CustomFilterInfo (для управляемого кода) или ICustomFilterInfo (для неуправляемого кода), содержащий фильтр, используемый при синхронизации. Создайте объект фильтрованного пакета изменений, передав объект информации о фильтре соответствующему конструктору объекта пакета изменений ChangeBatch (для управляемого кода) или вызвав метод IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (для неуправляемого кода). Кроме того, при создании объекта пакета изменений передайте утраченный набор знаний фильтра вместо утраченного набора знаний реплики.

• Если элемент или базовая единица были ранее включены в фильтр, но сейчас исключены из него, задайте свойству ChangeKind значение Ghost (для управляемого кода) или передайте флаг SYNC_CHANGE_FLAG_GHOST методу ISyncChangeBatchBase::AddItemMetadataToGroup (для неуправляемого кода).

• Если тип фильтрации поставщика назначения равен CurrentItemsOnly (для управляемого кода) или FT_CURRENT_ITEMS_ONLY (для неуправляемого кода), включайте элемент в пакет изменений, только если он включен в фильтр, то есть не передавайте фантомы.

• Если тип фильтрации поставщика назначения равен CurrentItemsAndVersionsForMovedOutItems (для управляемого кода) или FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (для неуправляемого кода), включайте элементы как включенные в фильтр, так и исключенные из него. Информация об исключении должна передаваться, если элемент или базовая единица были ранее включены в фильтр, но сейчас исключены из него, а версия изменения, в результате которого они были исключены из фильтра, не содержится в наборе знаний назначения.

Применение метаданных фильтра

Если поставщик назначения отслеживает фильтры и использует объект применения изменений для применения изменений к конечной реплике, он должен реализовать интерфейс IFilterTrackingNotifyingChangeApplierTarget (для управляемого кода) или IFilterTrackingNotifyingChangeApplierTarget (для неуправляемого кода). Этот интерфейс содержит методы, которые платформа Sync Framework использует для получения схем ключей фильтра и утраченных наборов знаний отслеживаемых фильтров. Кроме того, он содержит метод SaveKnowledgeWithFilterForgottenKnowledge (для управляемого кода) или IFilterTrackingNotifyingChangeApplierTarget::SaveKnowledgeWithFilterForgottenKnowledges (для неуправляемого кода), который платформа Sync Framework вызывает вместо метода StoreKnowledgeForScope (для управляемого кода) или ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (для неуправляемого кода) для отслеживающих фильтры поставщиков. Платформа Sync Framework использует этот метод для передачи обновленного набора знаний, утраченного набора данных и утраченного набора знаний фильтра поставщику после применения пакета изменений.

Помимо реализации интерфейса IFilterTrackingNotifyingChangeApplierTarget, необходимо обновить метод SaveItemChange или SaveChangeWithChangeUnits (для управляемого кода), либо метод ISynchronousNotifyingChangeApplierTarget::SaveChange или ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (для неуправляемого кода) поставщика назначения, чтобы выполнить следующие шаги.

1. Получите метаданные изменений фильтра для каждого отслеживаемого фильтра путем вызова метода объекта изменений GetFilterChange (для управляемого кода) или ISyncChangeWithFilterKeyMap::GetFilterChange (для неуправляемого кода).

2. При наличии метаданных изменений фильтра убедитесь в том, что они не устарели. Изменения фильтра являются устаревшими, если версия перемещения содержится в наборе знаний назначения элемента. Если используются базовые единицы, изменения фильтра считаются устаревшими только в тех случаях, когда версия перемещения не содержится в наборе знаний назначения всех базовых единиц. Если изменения фильтра устарели, не применяйте их к конечной реплике.

3. Если метаданные изменений фильтра существуют и не являются устаревшими, убедитесь, что они не конфликтуют с информацией об изменениях фильтра, уже имеющейся в конечной реплике. Для проверки наличия конфликтов выполните следующие шаги.

   1. Получите версию перемещения, хранящуюся для элемента или базовой единицы в конечной реплике.

   2. Проверьте, содержится ли версия перемещения в определяющем наборе знаний элемента или в определяющем наборе знаний каждой базовой единицы, связанной с элементом.

   3. Если версия перемещения не содержится в соответствующем определяющем наборе знаний, изменение фильтра вызывает конфликт. Поставщик назначения должен разрешить его соответствующим образом и назначить изменению новую версию перемещения.

   4. Если с версией перемещения конфликты не обнаружены, сравните флаг вхождения изменения фильтра источника с флагом вхождения элемента назначения или базовой единицы. Если значение флага не согласовано, то поставщик назначения должен вычислить элемент или базовую единицу изменения по фильтру и присвоить флагу вхождения правильное значение вместе с новой версией перемещения.

   5. Если конфликты любого типа не обнаружены, сохраните метаданные изменений фильтра вместе с метаданными элемента.

4. Если для отслеживаемого фильтра или для фильтра, отслеживаемого конечной репликой, а не исходной репликой, имеются метаданные изменений фильтра, оцените изменение относительно фильтра назначения. Обновите метаданные фильтра, включив в него элемент, а затем обновите версию перемещения до версии изменения, если изменение явилось причиной перемещения элемента по отношению к фильтру. При наличии нескольких базовых единиц, связанных с фильтром, и изменений, вызывающих перемещение элемента относительно фильтра, создайте новую локальную версию и назначьте ее версией перемещения элемента и версией изменений для всех базовых единиц, связанных с фильтром.

Фильтруемые реплики

Фильтруемая реплика хранит данные элементов и базовых единиц для элементов и базовых единиц, имеющихся в фильтре, а также фантомы, то есть метаданные для элементов и базовых единиц, которые были исключены из фильтра. Фильтруемая реплика отслеживает свой фильтр и может также отслеживать другие фильтры. Фильтруемая реплика может согласовывать фильтр с поставщиком источника. В этом случае поставщик источника создает фильтрованный пакет изменений. Если поставщик источника не может создать фильтрованный пакет изменений, фильтруемый поставщик может самостоятельно отфильтровать изменения и применить только те из них, которые включены в фильтр.

Дополнительные сведения о реализации фильтруемой реплики см. в разделе Как фильтровать реплики.

Перечисление элементов, включенных в фильтр

Фильтруемая реплика реализует интерфейс IFilteredReplicaNotifyingChangeApplierTarget (для управляемого кода) или IFilteredReplicaNotifyingChangeApplierTarget (для неуправляемого кода). Этот интерфейс содержит метод GetNewMoveInItems (для управляемого кода) или IFilteredReplicaNotifyingChangeApplierTarget::GetNewMoveins (для неуправляемого кода), который платформа Sync Framework использует для получения элементов, которые были включены в фильтр после определенного момента времени. Элемент включается в список, возвращаемый этим методом, если он активен, включен в фильтр и версия его перемещения не содержится в наборе знаний, переданном методу.

Отправка изменений без фильтрации

Если фильтруемая реплика является исходной, а конечная реплика не требует перечисления фильтруемых изменений, либо не удалось выполнить согласование фильтров между двумя репликами, то исходная реплика перечисляет изменения так, как будто они не фильтруются. Существуют следующие отличия от процесса отправки фильтрованных изменений.

• Создается пакет изменений без фильтрации.

• При создании пакета изменений передается утраченный набор знаний реплики, а не утраченный набор знаний фильтра, как при отправке фильтруемых изменений.

Применение фильтрованных изменений

Если поставщик назначения использует объект применения изменений, он должен указать при отсылке версий назначения объекту применения изменений, является ли элемент или базовая единица назначения фантомом. Для этого задайте значение Ghost свойству ChangeKind (для управляемого кода) или передайте флаг SYNC_CHANGE_FLAG_GHOST в метод IDestinationChangeVersionsBuilder::AddItemMetadata (для неуправляемого кода), если элемент является фантомом в конечной реплике. Элемент является фантомом, если для него имеются метаданные в хранилище метаданных назначения, он не удален, но в хранилище назначения отсутствуют данные для него.

Если изменения от поставщика источника не отфильтрованы, поставщик назначения применяет ко всем изменениям, отправленным поставщиком источника, условие фильтра конечной реплики. Поставщик назначения применяет изменения, которые проходят через фильтр, и обновляет все затронутые фантомы. Поставщик назначения исключает все пропущенные изменения из набора знаний пакета изменений.

Поставщик назначения должен также внести следующие изменения в метод SaveItemChange или SaveChangeWithChangeUnits (для управляемого кода) либо метод ISynchronousNotifyingChangeApplierTarget::SaveChange или ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (для неуправляемого кода).

• Управляйте действиями CreateGhost и UpdateGhost (для управляемого кода) либо SSA_CREATE_GHOST и SSA_UPDATE_GHOST (для неуправляемого кода) путем создания или обновления метаданных для фантома. Метаданные изменений фильтра должны быть также обновлены при необходимости.

• Управляйте действием MarkItemAsGhost (для управляемого кода) или SSA_GHOST_ITEM (для неуправляемого кода) путем удаления данных для элемента или базовой единицы и соответствующего обновления метаданных для них.

• Управляйте действием UnmarkItemAsGhost (для управляемого кода) или SSA_UNGHOST_ITEM (для неуправляемого кода) путем извлечения данных для элемента или базовой единицы, сохранения этих данных в конечной реплике и соответствующего обновления метаданных.

• Управляйте действием DeleteGhostAndStoreTombstone (для управляемого кода) или SSA_DELETE_GHOST_AND_STORE_TOMBSTONE (для неуправляемого кода) путем пометки метаданных фантома как удаленных.

Очистка фантомов

Чтобы освободить в хранилище свободное место для фильтруемой реплики, можно удалить фантомы. При удалении фантома необходимо обновить утраченный набор знаний фильтра, передав версию перемещения фантома методу утраченного набора знаний фильтра ForgetTo (для управляемого кода) или IForgottenKnowledge::ForgetToVersion (для неуправляемого кода).

Согласование фильтра

Поставщик назначения может указывать фильтр, используемый поставщиком источника в ходе перечисления изменений. Поставщик источника может принять или отклонить фильтр, запрошенный поставщиком назначения. Поставщик назначения может продолжать запрашивать фильтры, пока не обнаружит фильтр, который будет принят поставщиком источника. Такое согласование управляется средствами Sync Framework. Фильтр может иметь любой тип, лучшим образом подходящий для поставщиков.

Чтобы участвовать в согласовании фильтров, поставщик источника должен реализовать интерфейс ISupportFilteredSync (для управляемого кода) или ISupportFilteredSync (для неуправляемого кода), а поставщик назначения — интерфейс IRequestFilteredSync (для управляемого кода) или IRequestFilteredSync (для неуправляемого кода).

Согласование фильтров достигается выполнением следующих действий.

1. Прежде чем поставщик источника начнет перечисление изменений и после вызова метода BeginSession (для управляемого кода) или IKnowledgeSyncProvider::BeginSession (для неуправляемого кода), платформа Sync Framework начинает согласование фильтров путем вызова метода SpecifyFilter (для управляемого кода) или IRequestFilteredSync::SpecifyFilter (для неуправляемого кода) на поставщике назначения.

2. В процессе выполнения метода SpecifyFilter поставщик назначения передает фильтры делегату FilterRequestCallback (для управляемого кода) или методу IFilterRequestCallback::RequestFilter (для неуправляемого кода), указанному платформой Sync Framework. Если поставщик назначения не отслеживает запрошенный фильтр, он указывает тип фильтрации CurrentItemsOnly (для управляемого кода) или FT_CURRENT_ITEMS_ONLY (для неуправляемого кода). Если поставщик назначения отслеживает запрошенный фильтр, он указывает тип фильтрации CurrentItemsAndVersionsForMovedOutItems (для управляемого кода) или FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (для неуправляемого кода).

3. В процессе выполнения метода FilterRequestCallback (для управляемого кода) или RequestFilter (для неуправляемого кода) платформа Sync Framework вызывает метод поставщика источника TryAddFilter (для управляемого кода) или ISupportFilteredSync::AddFilter (для неуправляемого кода). Если поставщик источника не поддерживает запрошенный фильтр, то поставщик назначения может продолжить запрашивать фильтры до тех пор, пока не найдет поддерживаемый.

4. Если поставщик назначения не может найти фильтр, принятый поставщиком источника, он завершает синхронизацию, вызвав исключение SyncInvalidOperationException (для управляемого кода) или вернув код ошибки, такой как SYNC_E_FILTER_NOT_SUPPORTED, (для неуправляемого кода).

Как только согласование фильтра успешно завершено, поставщик источника пользуется им для определения элементов, которые необходимо включить в процесс перечисления изменений.

Дополнительные сведения о согласовании фильтров см. в разделе Как согласовать фильтр.

См. также

Основные положения

Реализация стандартного пользовательского поставщика
Реализация приложения синхронизации
Как отфильтровать перечисляемые элементы
Как отфильтровать перечисляемые базовые единицы
Как согласовать фильтр
Как отслеживать фильтры и перечислять фильтруемые изменения
Как фильтровать реплики