Sincronización de listas de SharePoint

Artículo
09/24/2014

Última modificación: martes, 16 de marzo de 2010

Hace referencia a: SharePoint Foundation 2010

Las implementaciones de Microsoft Sync Framework en SharePoint Foundation proporcionan dos funcionalidades importantes: la sincronización de listas y la sincronización de bibliotecas de documentos. A continuación se describe la sincronización de listas y las importantes características que la admiten.

Sincronización de listas

Para admitir la sincronización de listas, es necesario que todos los elementos de lista tengan identificadores únicos para el seguimiento de actualizaciones de versión. SharePoint Foundation usa la propiedad UniqueId para cumplir con este requisito.

Control de versiones del elemento de lista

Los elementos de lista que aceptan o devuelven funciones de base de conocimiento están asociados con dos unidades de cambio de versión de Sync Framework: una unidad de cambio para la versión de servidor del elemento de lista y otra para la versión del contenido. La versión de unidad de cambio del servidor se actualiza cuando se realizan cambios en los campos del servidor de solo lectura; la versión de unidad de cambio del contenido, por otro lado, se actualiza cuando se cambia cualquier otra parte del elemento de lista.

Las respectivas versiones de unidad de cambio del servidor y del contenido siempre se evalúan para buscar actualizaciones como un par, incluso cuando las actualizaciones solo corresponden a campos del servidor de solo lectura y no se requieren actualizaciones en el cliente. A continuación se muestra una lista de los campos del servidor de solo lectura asociados con los cambios en la unidad de cambio del servidor.

Campos del servidor de solo lectura

1	Identificador
2	ows_hiddenversion
3	ContentTypeId
4	ContentType
5	Modified
6	Created
7	Author
8	Editor
9	FileRef
10	FileDirRef
11	LastModified
12	CreatedDate
13	FileSize
14	FSObjType
15	PermMask
16	CheckoutUser
17	VirusStatus
18	InstanceID
19	_CheckinComment
20	_Level
21	_IsCurrentVersion
22	_HasCopyDestination
23	_CopySource
24	_ModerationStatus
25	_ModerationStatus
26	WorkflowVersion

Actualizaciones en el servidor

Las actualizaciones de los elementos de lista se capturan en el servidor durante las operaciones de carga. Esto evita las colisiones de actualizaciones entre clientes del explorador que puedan intentar actualizar el mismo elemento al mismo tiempo. La actualización durante la carga del servidor es necesaria debido a que Sync Framework usa un campo de versión de SharePoint principal (ows_hiddenversion) para detectar conflictos de sincronización. Además, existen algunas actualizaciones de elementos desencadenadas por acciones del lado servidor; por ejemplo, actualizaciones al campo Autor basadas en el identificador del usuario que carga el elemento.

Una vez completadas estas acciones del servidor, las actualizaciones deben sincronizarse de vuelta a los clientes. Si estos cambios se limitan a campos del servidor de solo lectura, solo se actualizará la versión de servidor y la versión del contenido permanecerá sin cambios. Sin embargo, si hay cambios en otros campos además de los campos del servidor de solo lectura, o si se cambia el contenido del elemento, entonces se actualizará tanto la versión de servidor como la del contenido. Esta operación se trata como una actualización del explorador realizada por el usuario.

Tenga en cuenta que las acciones realizadas por las siguientes operaciones del lado servidor producen cambios en la versión del contenido del elemento y, por lo tanto, requieren actualizaciones en el cliente:

Comprobación de antivirus
Acción IRM
Análisis de operaciones como reparaciones de vínculos o disminución de nivel de propiedades
Cambios de esquema en la lista o en el tipo de contenido
Actualizaciones del controlador de eventos de documento

Enumeración de cambios

Dado que los metadatos de actualización se capturan durante la carga en el servidor, solo los cambios registrados en el servidor se mantienen en el registro de cambios y se proporcionan en la enumeración de cambios. En otras palabras, una enumeración de cambios refleja el estado más reciente del conocimiento proporcionado por el cliente que se encuentra presente en el servidor; este estado de conocimiento se usa para consultar el registro de cambios y obtener el conjunto de cambios que puede ser de interés para el cliente. Posteriormente, Sync Framework comprueba los elementos del conjunto de resultados de consultas con respecto al conocimiento del cliente y determina si debe enviarse al cliente un elemento especificado.

Tenga en cuenta que es posible que el conocimiento del cliente mantenga un conjunto de excepciones de consulta (ya sea intervalos de elementos o elementos específicos) que filtre elementos no deseados y los excluya del conjunto de resultados.

Procesamiento por lotes de cambios en los elementos de lista

En lugar de tratarse de un flujo continuo, las actualizaciones simultáneas se proporcionan en lotes de elementos que se transfieren en paquetes. El cliente especifica el tamaño de lote y los elementos individuales se devuelven en el orden en que aparecen en el registro de cambios.

Los lotes se pasan al cliente junto con una copia del conocimiento del servidor. Una vez procesados los cambios, los clientes podrán agregar conocimiento del servidor nuevo a su propio almacén de conocimientos. Finalmente, el cliente establecerá la versión de servidor adquirida más recientemente en el campo de versión de servidor del último elemento recibido.

Un cliente puede especificar una o varias excepciones con respecto a su conocimiento para los elementos de un lote especificado. El uso de excepciones garantiza que un cliente no obtenga conflictos falsos en los casos en que se interrumpe una operación de sincronización. Hay excepciones tanto positivas como negativas. Las excepciones positivas tienen conocimiento del servidor completo sobre los elementos en lotes que éste recibe, mientras que las excepciones negativas tienen el conocimiento del cliente inicial sobre los elementos que omite en el lote. Tenga en cuenta, sin embargo, que debido a que el procesamiento de excepciones en el servidor degrada el rendimiento del servidor, los clientes deben evitar el uso de excepciones para el procesamiento por lotes de cambios y, en su lugar, deben organizar los lotes en función del conocimiento del servidor.

Excepciones

El servidor detecta y usa la información de la excepción en los siguientes casos:

Enumeración de cambios
- El servidor pasa elementos por medio de una función contains() que filtra los elementos especificados y los excluye del conjunto de resultados.
- El servidor devuelve información de la excepción en el elemento MadeWithKnowledge del método GetListItemChangesWithKnowledge(String, String, XmlNode, XmlNode, String, XmlNode, String, XmlNode, XmlNode).
Detección de conflictos
- Cuando se detecta un conflicto en el servidor, éste crea una excepción para el elemento conflictivo.
Actualizaciones del elemento
- El servidor ignora las excepciones de unidad de cambio en el conocimiento de sincronización. No almacena las excepciones de unidad de cambio en el conocimiento del servidor si recibe esta información del cliente.

Detección y resolución de conflictos

Los conflictos en el servidor se producen cuando el campo ows_hiddenversion del elemento de servidor difiere del valor del campo ows_hiddenversion recibido del cliente. Cuando se produce un conflicto como este, el servidor no intenta resolverlo. En su lugar, agrega la excepción del elemento a su conocimiento y devuelve el error al cliente.

Los conflictos se producen en el cliente cuando la versión del conocimiento del servidor no es congruente con el conocimiento del cliente. Cuando esto ocurre, el cliente debe usar la versión del contenido del cliente para resolver el conflicto. En este escenario, la versión de servidor se ignora con el fin de resolver el conflicto.

Los conflictos más serios se producen cuando la versión del contenido del elemento de servidor no es congruente con el conocimiento del cliente y cuando la versión del contenido del elemento de cliente no es congruente con el conocimiento del servidor. Se hace referencia a esto como un conflicto "verdadero". Sync Framework no puede resolver este tipo de conflicto, sino que debe hacerlo el usuario mediante la interfaz de usuario.

Los conflictos falsos se producen cuando la versión de servidor del elemento no es congruente con el conocimiento del cliente, pero las versiones del contenido son congruentes con el conocimiento del cliente o del servidor. Este tipo de conflicto se resuelve automáticamente mediante el cliente, sin la intervención del usuario. Si la versión del contenido del cliente es congruente con el conocimiento del servidor, el elemento de servidor gana la carrera de resolución.

Cuando un conflicto true o false se resuelve a favor de la versión del cliente, el cliente crea un conjunto de uniones que combina su conocimiento con el del servidor y establece el campo ows_hiddenversion del elemento del cliente en el valor que existe en el elemento de servidor y, posteriormente, sincroniza la versión del cliente del elemento con respecto al estado del servidor.