Filtrar los datos de sincronización

Los filtros se utilizan para restringir los datos que se sincronizan. Normalmente, el proveedor de origen aplica los filtros durante la enumeración de cambios para restringir los cambios que se envían. Sync Framework admite los tipos de filtros siguientes.

• Los filtros de elementos restringen los datos de sincronización a un subconjunto de elementos, por ejemplo para sincronizar únicamente los archivos .txt entre dos carpetas de archivos, omitiendo los archivos de otros tipos. Los elementos no se modifican de forma que un elemento existente pase a incluirse o excluirse del filtro. Los filtros de elementos son fáciles de usar, pero los metadatos utilizados para la sincronización crecen proporcionalmente al número de elementos que están en el ámbito de sincronización.

• Los filtros de unidades de cambio restringen los datos de sincronización a un subconjunto de unidades de cambio, por ejemplo para sincronizar únicamente los campos phone number y name de un contacto, omitiendo las unidades de cambio restantes.

• Los filtros personalizados restringen los datos de sincronización de manera que sean desconocidos para Sync Framework. Los elementos pueden incluirse y excluirse de los filtros personalizados a lo largo del tiempo. Sync Framework define metadatos, interfaces y clases adicionales que admiten de forma eficaz los filtros personalizados, manteniéndose pequeño el tamaño total de los metadatos.

El filtro puede definirlo la aplicación de sincronización o el proveedor de origen o destino; también puede negociarse entre los proveedores de origen y destino.

El proveedor de origen utiliza el filtro cuando detecta cambios. Los lotes de cambios que se generan durante la detección de cambios solo contienen los datos de sincronización que pasan el filtro.

El proveedor de destino únicamente puede utilizar el filtro cuando aplica los cambios. Los cambios que se aplican a la réplica de destino solamente contienen los datos de sincronización que pasan el filtro.

Controlar qué elementos se sincronizan

Los filtros de elementos determinan los cambios de elementos que el proveedor de origen envía durante la enumeración de cambios. Como el modo en que los elementos se filtran depende del tipo de datos del ámbito de sincronización, Sync Framework permite al proveedor de origen definir el mecanismo de filtro. Si debe establecerse algún tipo de comunicación sobre el filtro entre el proveedor y la aplicación de sincronización, puede hacerse utilizando cualquier mecanismo que resulte adecuado.

Cuando el proveedor de origen filtra los cambios de elementos, Sync Framework necesita que el proveedor de origen adjunte información sobre el filtro a todos los objetos del lote de cambios enviados durante la enumeración de cambios. La presencia de información del filtro de elementos en el lote de cambios informa a Sync Framework de que se está produciendo una sincronización filtrada, de modo que Sync Framework puede administrar correctamente el conocimiento sobre el lote de cambios filtrados. Si el proveedor de origen filtra los elementos incluidos en un lote de cambios pero no especifica información del filtro de elementos en el objeto del lote de cambios, Sync Framework no podrá administrar correctamente el conocimiento.

Cuando el proveedor de origen utiliza un filtro para restringir los elementos que se encuentran en un lote de cambios, el proveedor debe adjuntar información sobre el filtro al objeto ChangeBatch (en código administrado) o ISyncChangeBatch (en código no administrado). La información del filtro se representa en un objeto ItemListFilterInfo (en código administrado) o un objeto ISyncFilterInfo que tiene la marca SYNC_FILTER_INFO_FLAG_ITEM_LIST establecida (en código no administrado). En código no administrado, el proveedor crea un objeto ISyncFilterInfo mediante el uso de IProviderFilteredSyncServices::CreateFilterInfo. La información del filtro se adjunta al lote de cambios utilizando ChangeBatch (en código administrado) o IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (en código no administrado) para crear el objeto de lote de cambios.

Para obtener más información sobre cómo se utiliza el filtrado de elementos, vea Filtrar elementos enumerados.

Controlar qué unidades de cambio se sincronizan

Un filtro de unidades de cambio define las modificaciones realizadas en las unidades de cambio que se incluyen en cada uno de los cambios de elementos que el proveedor de origen envía durante la enumeración de cambios. Un filtro de unidades de cambio resulta útil cuando una réplica almacena exclusivamente un subconjunto de las unidades de cambio definidas para los elementos del ámbito.

Por ejemplo, una comunidad de sincronización intercambia información de contacto y define las unidades de cambio para name, phone number y address. Una réplica de la comunidad es un dispositivo móvil que solo puede almacenar name y phone number. Esta réplica utiliza un filtro de unidades de cambio para especificar que solamente realiza el seguimiento del conocimiento de estas dos unidades de cambio. Cuando una réplica de origen sincroniza los datos con la réplica del dispositivo, utiliza el filtro de unidades de cambio para enviar exclusivamente información sobre las unidades de cambio phone number y name. El conocimiento aprendido del proveedor de origen se proyecta sobre el filtro de unidades de cambio de modo que el conocimiento de la réplica del dispositivo contenga únicamente información de las unidades de cambio phone number y name. De igual forma, cuando una modificación se realiza localmente en el dispositivo y posteriormente el dispositivo actúa como réplica de origen en una sesión de sincronización, la réplica que recibe los cambios actualiza solamente su conocimiento sobre el conjunto de unidades de cambio especificado.

Cuando se utiliza un filtro de unidades de cambio, Sync Framework proyecta el conocimiento aprendido sobre el lote de cambios en el conjunto de unidades de cambio especificado por el filtro, de modo que el conocimiento aprendido sobre el lote de cambios contiene únicamente información sobre el conjunto de unidades de cambio especificado.

Para filtrar las modificaciones de las unidades de cambio, el proveedor de origen crea un objeto ChangeUnitListFilterInfo (en código administrado) o IChangeUnitListFilterInfo (en código no administrado) y especifica el conjunto de unidades de cambio que se sincronizan. En código no administrado, el objeto IChangeUnitListFilterInfo se crea especificando SYNC_FILTER_INFO_FLAG_CHANGE_UNIT_LIST en el método IProviderFilteredSyncServices::CreateFilterInfo. El proveedor de origen adjunta la información del filtro al lote de cambios utilizando ChangeBatch (en código administrado) o IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (en código no administrado) para crear el objeto de lote de cambios.

Para obtener más información sobre cómo se utiliza un filtro de unidades de cambio, vea Filtrar unidades de cambio enumeradas.

Controlar lo que se sincroniza utilizando un filtro personalizado

Un filtro personalizado se define fuera de Sync Framework; normalmente lo define un desarrollador de software del proveedor, aunque también lo puede definir un tercero. Sync Framework no tiene conocimiento de cómo el filtro determina lo que se ha de incluir en el ámbito de sincronización. Un filtro personalizado se puede definir de modo que los elementos se incluyan y excluyan del filtro a lo largo del tiempo. Por ejemplo, en una réplica que almacena archivos multimedia, un filtro puede definirse de modo que incluya todos los archivos con una valoración de tres estrellas o más. Cuando el usuario cambia la valoración en un archivo, puede incluirlo o excluirlo del filtro.

Tenga en cuenta que los filtros personalizados no los pueden usar los proveedores simples ni los proveedores que notifiquen conflictos de restricción o utilicen el servicio de aplicación de cambios; de lo contrario, pueden producirse resultados inesperados.

Para admitir de forma eficaz los filtros personalizados, Sync Framework define varios conceptos nuevos.

• Una réplica de seguimiento de filtros es una réplica que mantiene los metadatos que definen qué elementos y unidades de cambio se encuentran actualmente en un filtro objeto de seguimiento, qué elementos y unidades se han incluido o excluido recientemente del filtro objeto de seguimiento, y el conocimiento olvidado de filtro que abarca todos los elementos y unidades de cambio que no están el filtro objeto de seguimiento y se han olvidado. El seguimiento de un filtro no afecta a qué elementos se almacenan en una réplica. Una réplica puede realizar el seguimiento de varios filtros al tiempo que almacena todos los elementos en el ámbito de sincronización. Normalmente, una réplica de seguimiento de filtros puede proporcionar un lote de cambios filtrado para cualquiera de sus filtros objeto de seguimiento.

• Una réplica filtrada es una réplica que almacena datos de elementos y unidades de cambio solo para los elementos y unidades de cambio que están en el filtro, así como metadatos para los elementos y unidades de cambio que estaban en el filtro pero se han excluido. Una réplica filtrada siempre realiza el seguimiento del filtro que utiliza y también puede realizar el seguimiento de filtros adicionales. Un proveedor de destino filtrado puede solicitar una enumeración de cambios filtrada del proveedor de origen, o puede solicitar una enumeración de cambios completa y filtrar los cambios durante la aplicación de cambios.

• Los fantasmas son elementos o unidades de cambio de una réplica filtrada que estaban en el filtro y se han excluido. La réplica filtrada almacena metadatos para los fantasmas, pero no almacena datos de elementos o unidades de cambio.

• El conocimiento olvidado de filtro define un punto inicial para el seguimiento del filtro. Una réplica de seguimiento de filtros puede ahorrar espacio de almacenamiento quitando fantasmas y avanzando el conocimiento olvidado de filtro para contener la versión más alta de los fantasmas que se han quitado. El conocimiento olvidado de filtro también se utiliza cuando una réplica empieza el seguimiento de un filtro después de que el filtro lo hayan utilizado otras réplicas en la comunidad de sincronización.

Seguimiento de filtros

Se recomienda que todas las réplicas en una comunidad de sincronización realicen el seguimiento de los filtros que se utilizan en la comunidad. Cuando una réplica filtrada recibe una enumeración de cambios filtrada de una réplica de seguimiento de filtros, el conocimiento de la réplica filtrada se mantiene pequeño. Cuando una réplica filtrada recibe una enumeración de cambios filtrados de una réplica que no realiza el seguimiento del filtro, el tamaño del conocimiento crece proporcionalmente al número de cambios enviados.

Para obtener más información sobre el seguimiento de filtros, vea Realizar el seguimiento de filtros y enumerar los cambios filtrados.

Metadatos de filtro

Para realizar el seguimiento de un filtro, una réplica almacena metadatos de filtro para cada elemento o unidad de cambio en la réplica. Los metadatos de filtro contienen los elementos en la tabla siguiente:

Cuando una réplica empieza el seguimiento de un filtro, todos los elementos o unidades de cambio deben evaluarse con el filtro. Si un elemento o unidad de cambio está en el filtro, sus metadatos de filtro deben indicar esta circunstancia y su versión de movimiento debe establecerse en la última versión de cambio del elemento o unidad de cambio. Si un elemento no está en el filtro, sus metadatos de filtro deben indicar esta circunstancia y su versión de movimiento debe establecerse en (0,0).

Una réplica de seguimiento de filtros también puede almacenar el conocimiento olvidado de filtro para cada filtro del que realiza el seguimiento. Cuando una réplica de seguimiento de filtros realiza el seguimiento de un filtro desde el origen del mismo, no almacena el conocimiento olvidado de filtro a menos que reciba datos de sincronización de una réplica que no realiza el seguimiento del filtro. Cuando una réplica de seguimiento de filtros empieza el seguimiento de un filtro después de que este se haya originado, debe inicializar el conocimiento olvidado de filtro en el conocimiento actual de la réplica. Cuando los marcadores de exclusión y los metadatos de cambio de filtro se limpian en una réplica, el conocimiento olvidado de filtro puede descartarse y utilizarse en su lugar el conocimiento olvidado.

Negociar los filtros objeto de seguimiento

Un proveedor de seguimiento de filtros debe implementar IFilterTrackingProvider (en código administrado) o IFilterTrackingProvider (en código no administrado). Esta interfaz se utiliza para comunicar los filtros que son objeto de seguimiento tanto en la réplica de origen como en la réplica de destino. La réplica de origen envía metadatos de filtro para los filtros de los que se realiza el seguimiento en la réplica de origen y la réplica de destino.

Cuando ambos proveedores en una sesión de sincronización son proveedores de seguimiento de filtros, Sync Framework media en la negociación de qué filtros son objeto de seguimiento por ambos proveedores. Los filtros objeto de seguimiento se negocian entre dos proveedores de seguimiento de filtros mediante los pasos siguientes:

1. Después de llamar a BeginSession(en código administrado) o a IKnowledgeSyncProvider::BeginSession (en código no administrado), Sync Framework llama a SpecifyTrackedFilters (en código administrado) o a IFilterTrackingProvider::SpecifyTrackedFilters (en código no administrado) en el proveedor de destino.

2. El proveedor de destino enumera su lista de filtros objeto de seguimiento y pasa cada uno al delegado RequestTrackedFilterCallback (en código administrado) o al método IFilterRequestCallback::RequestFilter del objeto IFilterRequestCallback (en código no administrado) que se especifica en la llamada a SpecifyTrackedFilters.

3. Para cada filtro especificado por el proveedor de destino, Sync Framework llama a TryAddTrackedFilter (en código administrado) o a IFilterTrackingProvider::AddTrackedFilter (en código no administrado) en el proveedor de origen.

4. El proveedor de origen mantiene una lista de los filtros objeto de seguimiento por el proveedor de destino y devuelve un valor que indica si realiza el seguimiento del filtro especificado.

5. Sync Framework pasa este valor al proveedor de destino.

Enviar metadatos de filtro para los filtros objeto de seguimiento

Cuando el proveedor de destino realiza el seguimiento de filtros de los que el proveedor de origen también realiza el seguimiento, el proveedor de origen debe enviar metadatos de filtro para los filtros objeto de seguimiento mutuo. Para ello, agregue los cambios siguientes a la implementación del proveedor de origen de GetChangeBatch (en código administrado) o IKnowledgeSyncProvider::GetChangeBatch (en código no administrado):

• Agregue un objeto FilterKeyMap al objeto ChangeBatch estableciendo la propiedad FilterKeyMap (en código administrado) o agregue un objeto IFilterKeyMap al objeto ISyncChangeBatchWithFilterKeyMap llamando a ISyncChangeBatchWithFilterKeyMap::SetFilterKeyMap (en código no administrado). El objeto de mapa de claves de filtro contiene los filtros de los que el proveedor de origen y el proveedor de destino realizan el seguimiento. Se debe establecer la propiedad FilterKeyMap (en código administrado) o llamar al método SetFilterKeyMap (en código no administrado) antes de que se inicien los grupos en el lote de cambios.

• En cada grupo del lote de cambios, agregue el conocimiento olvidado de filtro para los filtros objeto de seguimiento llamando a SetFilterForgottenKnowledge (en código administrado) o a ISyncChangeBatchWithFilterKeyMap::SetFilterForgottenKnowledge (en código no administrado).

• Envíe metadatos de cambio de filtro para cada elemento o unidad de cambio incluido o excluido de un filtro objeto de seguimiento. Los metadatos de cambio de filtro se agregan a un cambio llamando a AddFilterChange (en código administrado) o a IFilterTrackingSyncChangeBuilder::AddFilterChange (en código no administrado). Las propiedades de FilterChange (en código administrado) o los valores de SYNC_FILTER_CHANGE (en código no administrado) indican si el elemento se ha incluido o excluido del filtro y la versión del cambio que ha producido el movimiento. Los metadatos de cambio de filtro solamente se agregan cuando la versión de movimiento no está en el conocimiento de destino del elemento. Cuando se utilizan unidades de cambio, se deben agregar los metadatos de cambio de filtro si la versión de movimiento no se encuentra en el conocimiento de destino de cualquiera de las unidades de cambio. Tenga en cuenta que las versiones de movimiento se tratan como versiones de elemento incluso cuando se utilizan unidades de cambio, por lo que la contención se debe comprobar utilizando una forma del método Contains (en código administrado) o del método ISyncKnowledge::ContainsChange (en código no administrado) que tome una versión del elemento y no una que utilice una versión de la unidad de cambio.

• Cuando se utilizan unidades de cambio y al menos una modificación de las unidades de cambio no está en el conocimiento de destino, llame a ContainsMarker (en código administrado) o a IKnowledgeWithMarkers::ContainsAllChangeUnitsRequiredMarker (en código no administrado) en el conocimiento de destino, especificando AllChangeUnitsRequired y el identificador del elemento propietario (en código administrado) o el identificador del elemento propietario (en código no administrado). Si este método indica que se requieren todas las unidades de cambio, envíe todas las unidades de cambio para el elemento y llame a SetAllChangeUnitsPresent en el objeto ItemChange (en código administrado) o a IFilterTrackingSyncChangeBuilder::SetAllChangeUnitsPresentFlag (en código no administrado).

Enviar cambios filtrados

Normalmente, un proveedor de origen que representa una réplica de seguimiento de filtros puede enumerar lotes de cambios filtrados para cualquiera de los filtros objeto de seguimiento. El filtro puede ser identificado por la aplicación, utilizando un mecanismo personalizado entre la aplicación y el proveedor de origen, o puede ser negociado entre el proveedor de origen y el proveedor de destino. La negociación de filtros se describe más adelante en este documento.

Para enviar un lote de cambios filtrado, agregue los elementos siguientes al método GetChangeBatch del proveedor de origen:

• Cree un objeto CustomFilterInfo (en código administrado) o ICustomFilterInfo (en código no administrado) que contenga el filtro utilizado para la sincronización. Cree un objeto de lote de cambios filtrado pasando el objeto de información de filtro al constructor de lote de cambios ChangeBatch apropiado (en código administrado) o llamando a IProviderFilteredSyncServices::CreateFilteredEnumerationChangeBatch (en código no administrado). Además, pase el conocimiento olvidado de filtro del filtro al crear el objeto de lote de cambios, en lugar del conocimiento olvidado de la réplica.

• Cuando un elemento o unidad de cambio estaba anteriormente en el filtro, pero no lo está actualmente, especifique la propiedad ChangeKind como Ghost (en código administrado) o pase la marca SYNC_CHANGE_FLAG_GHOST a ISyncChangeBatchBase::AddItemMetadataToGroup (en código no administrado).

• Cuando el tipo de filtrado del proveedor de destino es CurrentItemsOnly (en código administrado) o FT_CURRENT_ITEMS_ONLY (en código no administrado), incluya un elemento en el lote de cambios sólo si está en el filtro. Es decir, no envíe fantasmas.

• Cuando el tipo de filtrado del proveedor de destino es CurrentItemsAndVersionsForMovedOutItems (en código administrado) o FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (en código no administrado), incluya los elementos que están en el filtro y los elementos que se han excluido. Se debe enviar información de la exclusión cuando un elemento o unidad de cambio estaba anteriormente en el filtro, el elemento o unidad de cambio no está actualmente en el filtro, y la versión del cambio que excluyó el elemento o unidad de cambio del filtro no está en el conocimiento de destino.

Aplicar metadatos de filtro

Cuando un proveedor de destino representa un proveedor de seguimiento de filtros y utiliza un aplicador de cambios para aplicar cambios en la réplica de destino, el proveedor de destino debe implementar IFilterTrackingNotifyingChangeApplierTarget (en código administrado) o IFilterTrackingNotifyingChangeApplierTarget (en código no administrado). Esta interfaz contiene métodos que Sync Framework utiliza para obtener el mapa de claves de filtro y el conocimiento olvidado de filtro de los filtros objeto de seguimiento. También contiene el método SaveKnowledgeWithFilterForgottenKnowledge (en código administrado) o IFilterTrackingNotifyingChangeApplierTarget::SaveKnowledgeWithFilterForgottenKnowledges (en código no administrado), al que Sync Framework llama en lugar de StoreKnowledgeForScope (en código administrado) o ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (en código no administrado) para los proveedores de seguimiento de filtros. Sync Framework utiliza este método para enviar el conocimiento actualizado, el conocimiento olvidado y el conocimiento olvidado de filtro al proveedor después de la aplicación de un lote de cambios.

Además de implementar IFilterTrackingNotifyingChangeApplierTarget, deben actualizarse el método SaveItemChange o SaveChangeWithChangeUnits (en código administrado), o el método ISynchronousNotifyingChangeApplierTarget::SaveChange o ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (en código no administrado) del proveedor de destino para realizar los pasos siguientes:

1. Obtenga los metadatos de cambio de filtro para cada filtro objeto de seguimiento llamando a GetFilterChange (en código administrado) o a ISyncChangeWithFilterKeyMap::GetFilterChange (en código no administrado) en el objeto de cambio.

2. Cuando los metadatos de cambio de filtro estén presentes, asegúrese de que no estén obsoletos. Un cambio de filtro está obsoleto cuando su versión de movimiento está incluida en el conocimiento de destino del elemento. Cuando se utilizan unidades de cambio, un cambio de filtro está obsoleto solamente si la versión de movimiento está incluida en el conocimiento de destino de todas las unidades de cambio. Si el cambio de filtro está obsoleto, no lo aplique a la réplica de destino.

3. Cuando los metadatos de cambio de filtro estén presentes y no estén obsoletos, asegúrese de que no estén en conflicto con la información de cambio de filtro presente en la réplica de destino. Para comprobar si existen conflictos, realice estos pasos:

   1. Obtenga la versión de movimiento almacenada actualmente para el elemento o unidad de cambio en la réplica de destino.

   2. Compruebe si la versión de movimiento está en el conocimiento que da origen del elemento, o en el conocimiento que da origen de cada modificación de las unidades de cambio asociada al elemento.

   3. Si la versión de movimiento no está en el conocimiento que da origen apropiado, el cambio de filtro está en conflicto. El proveedor de destino debe resolverlo como corresponda y asignar una nueva versión de movimiento para el cambio.

   4. Si no se detectan conflictos con la versión de movimiento, compruebe la marca de inclusión del cambio de filtro de origen con la marca de inclusión de la unidad de cambio o elemento de destino. Si el valor de la marca no es coherente, el proveedor de destino debe evaluar la unidad de cambio o elemento frente al filtro y asignar el valor correcto de la marca de inclusión junto con una nueva versión de movimiento.

   5. Si no se detectan conflictos de ningún tipo, almacene los metadatos de cambio de filtro junto con los metadatos del elemento.

4. Cuando los metadatos de cambio de filtro no estén presentes para un filtro objeto de seguimiento, o para un filtro que es objeto de seguimiento por la réplica de destino pero no por la réplica de origen, evalúe el cambio con el filtro en el destino. Actualice los metadatos de filtro que se van a incluir si el elemento está en el filtro, y actualice la versión de movimiento a la versión del cambio si el cambio hizo que el elemento cambiara de situación respecto al filtro. Cuando haya varias unidades de cambio asociadas a un filtro y un cambio en cualquiera de ellas haga que el elemento cambie de situación respecto al filtro, cree una nueva versión local y asigne esta nueva versión como versión de movimiento del elemento y como versión del cambio para todas las unidades de cambio asociadas al filtro.

Réplicas filtradas

Una réplica filtrada almacena datos de elementos y unidades de cambio solo para los elementos y unidades de cambio que están en su filtro, así como fantasmas, que son metadatos para los elementos y unidades de cambio que estaban en el filtro pero se han excluido. Una réplica filtrada también realiza el seguimiento de su filtro y, además, puede realizar el seguimiento de otros filtros. Una réplica filtrada puede negociar un filtro con el proveedor de origen, en cuyo caso el proveedor de origen crea un lote de cambios filtrado. Si el proveedor de origen no puede crear un lote de cambios filtrado, el proveedor filtrado puede filtrar los cambios por sí mismo y aplicar solamente los que estén en su filtro.

Para obtener más información sobre la implementación de una réplica filtrada, vea Filtrar una réplica.

Enumerar los elementos incluidos en el filtro

Una réplica filtrada implementa IFilteredReplicaNotifyingChangeApplierTarget (en código administrado) o la interfaz IFilteredReplicaNotifyingChangeApplierTarget (en código no administrado). Esta interfaz contiene el método GetNewMoveInItems (en código administrado) o IFilteredReplicaNotifyingChangeApplierTarget::GetNewMoveins (en código no administrado), que Sync Framework utiliza para obtener elementos que se han incluido en el filtro después de un momento determinado. Un elemento se agrega a la lista devuelta por este método cuando el elemento está activo, el elemento está en el filtro y la versión de movimiento del elemento no está en el conocimiento especificado para el método.

Enviar cambios no filtrados

Cuando la réplica filtrada es la réplica de origen y la réplica de destino no solicita una enumeración de cambios filtrada, o un filtro no se negocia correctamente entre las dos réplicas, la réplica de origen enumera los cambios como si no se filtrase. Esto difiere del proceso de enviar los cambios filtrados de las maneras siguientes:

• Se crea un lote de cambios no filtrado.

• El conocimiento olvidado de la réplica se pasa cuando se crea el lote de cambios y no se pasa el conocimiento olvidado de filtro como cuando se envían los cambios filtrados.

Aplicar cambios filtrados

Cuando el proveedor de destino utiliza un aplicador de cambios para aplicar cambios, debe indicar si el elemento o unidad de cambio de destino es un fantasma cuando envía las versiones de destino al aplicador de cambios. Para ello, especifique Ghost para la propiedad ChangeKind (en código administrado) o pase la marca SYNC_CHANGE_FLAG_GHOST a IDestinationChangeVersionsBuilder::AddItemMetadata (en código no administrado) cuando el elemento es un fantasma en la réplica de destino. Un elemento es un fantasma cuando existen metadatos para el elemento en el almacén de metadatos de destino, el elemento no se ha eliminado y no existen datos para el elemento en el almacén de destino.

Cuando los cambios del proveedor de origen no se filtran, el proveedor de destino evalúa todos los cambios enviados por el proveedor de origen con el filtro de la réplica de destino. El proveedor de destino aplica los cambios que pasan el filtro y actualiza los fantasmas afectados. El proveedor de destino excluye los cambios omitidos del conocimiento del lote de cambios.

El proveedor de destino también debe realizar los cambios siguientes en su método SaveItemChange o SaveChangeWithChangeUnits (en código administrado), o ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits o ISynchronousNotifyingChangeApplierTarget::SaveChange (en código no administrado).

• Administre las acciones CreateGhost y UpdateGhost (en código administrado), o SSA_CREATE_GHOST o SSA_UPDATE_GHOST (en código no administrado), creando o actualizando los metadatos para un fantasma. Los metadatos de cambio de filtro también deben actualizarse, si procede.

• Administre la acción MarkItemAsGhost (en código administrado) o SSA_GHOST_ITEM (en código no administrado) quitando los datos del elemento o unidad de cambio y actualizando los metadatos del elemento o unidad de cambio para reflejar el cambio.

• Administre la acción UnmarkItemAsGhost (en código administrado) o SSA_UNGHOST_ITEM (en código no administrado) recuperando los datos del elemento o unidad de cambio, almacenando los datos en la réplica de destino y actualizando los metadatos para reflejar el cambio.

• Administre la acción DeleteGhostAndStoreTombstone (en código administrado) o SSA_DELETE_GHOST_AND_STORE_TOMBSTONE (en código no administrado) marcando los metadatos para el fantasma como eliminados.

Limpiar fantasmas

Para liberar espacio de almacenamiento en una réplica filtrada, deben quitarse los fantasmas. Cuando se quita un fantasma, el conocimiento olvidado de filtro para el filtro debe actualizarse pasando la versión de movimiento del fantasma al método ForgetTo (en código administrado) o IForgottenKnowledge::ForgetToVersion (en código no administrado) del conocimiento olvidado de filtro.

Negociar el filtro

El proveedor de destino puede especificar el filtro que el proveedor de origen utiliza durante la enumeración de cambios. El proveedor de origen puede aceptar o rechazar el filtro que el proveedor de destino solicita. El proveedor de destino puede continuar solicitando filtros hasta que encuentre alguno que el proveedor de origen acepte. Sync Framework actúa como plataforma de mediación en esta negociación. El filtro puede ser de cualquier tipo que sea apropiado para los proveedores.

Para participar en la negociación de filtros, el proveedor de origen debe implementar ISupportFilteredSync (en código administrado) o ISupportFilteredSync (en código no administrado) y el proveedor de destino deben implementar IRequestFilteredSync (en código administrado) o IRequestFilteredSync (en código no administrado).

La negociación de filtros se logra a través de los pasos siguientes:

1. Antes de que el proveedor de origen empiece a enumerar los cambios y después de llamar a BeginSession (en código administrado) o a IKnowledgeSyncProvider::BeginSession (en código no administrado), Sync Framework inicia la negociación de filtros llamando al método SpecifyFilter (en código administrado) o a IRequestFilteredSync::SpecifyFilter (en código no administrado) en el proveedor de destino.

2. Durante el procesamiento de SpecifyFilter, el proveedor de destino pasa los filtros al delegado FilterRequestCallback (en código administrado) o al método IFilterRequestCallback::RequestFilter (en código no administrado) especificado por Sync Framework. Cuando el proveedor de destino no realiza el seguimiento del filtro solicitado, especifica un tipo de filtrado de CurrentItemsOnly (en código administrado) o FT_CURRENT_ITEMS_ONLY (en código no administrado). Cuando el proveedor de destino realiza el seguimiento del filtro solicitado, especifica un tipo de filtrado de CurrentItemsAndVersionsForMovedOutItems (en código administrado) o FT_CURRENT_ITEMS_AND_VERSIONS_FOR_MOVED_OUT_ITEMS (en código no administrado).

3. Durante el procesamiento de FilterRequestCallback (en código administrado) o RequestFilter (en código no administrado), Sync Framework llama al método TryAddFilter (en código administrado) o ISupportFilteredSync::AddFilter (en código no administrado) del proveedor de origen. Si el proveedor de origen no admite el filtro solicitado, el proveedor de destino puede continuar solicitando filtros hasta encontrar uno admitido.

4. Si el proveedor de destino no puede encontrar un filtro aceptado por el proveedor de origen, puede terminar la sincronización produciendo la excepción SyncInvalidOperationException (en código administrado) o devolviendo un código de error, como SYNC_E_FILTER_NOT_SUPPORTED (en código no administrado).

Cuando se ha negociado un filtro correctamente, el proveedor de origen lo utiliza para determinar qué elementos incluir durante la enumeración de cambios.

Para obtener más información sobre cómo se negocian los filtros, vea Negociar un filtro.

Vea también

Conceptos

Implementar un proveedor estándar personalizado
Implementar una aplicación de sincronización
Filtrar elementos enumerados
Filtrar unidades de cambio enumeradas
Negociar un filtro
Realizar el seguimiento de filtros y enumerar los cambios filtrados
Filtrar una réplica