Share via


Détection de conflit

Dernière modification : mercredi 12 novembre 2008

S’applique à : SharePoint Foundation 2010

Dans cet article
Extraction-Envoi-Actualisation
Champ owshiddenversion
Propriété vti_versionhistory
En-tête ETag DAV
Pièces jointes

Outre les performances, la détection des conflits est l'un des sujets les plus importants concernant la synchronisation.

Extraction-Envoi-Actualisation

Il est préférable que ce soit le client qui détecte et résolve les conflits. Le client peut détecter si des modifications sont en conflit, il peut afficher une alerte pour signaler à l'utilisateur qu'il doit résoudre manuellement un confit et il peut enregistrer une copie des modifications effectuées par l'utilisateur dans le dossier de stockage de celui-ci.

Pour toutes ces raisons, il est préférable que l'opération de synchronisation se divise en trois parties : une première partie pendant laquelle les données éventuellement modifiées sont extraites du serveur, une deuxième partie pendant laquelle le client détermine s'il existe des conflits avec des modifications déjà chargées dans la copie du client et une troisième partie pendant laquelle sont chargées les nouvelles données du client s'il n'existe aucun conflit.

Des objets SharePoint peuvent comprendre une logique métier appliquée au niveau de la mise à jour. Pour cette raison, la méthode UpdateListItems(String, XmlNode) renvoie les valeurs mises à jour de l'intégralité des champs et des propriétés des éléments mis à jour.

Champ owshiddenversion

Windows SharePoint Services 3.0 utilise le champ owshiddenversion (dans la classe Microsoft.SharePoint.SPBuiltInFieldId) pour détecter des conflits. Si la valeur de ce champ n’est pas fournie pendant le processus de mise à jour, le serveur remplace toutes les modifications. Un client doit toujours fournir cette valeur pendant le processus de mise à jour pour éviter toute perte de données. La valeur du champ correspond au nombre le plus récemment renvoyé par le serveur.

La valeur du champ owshiddenversion permet au serveur de déterminer si vous mettez à jour une copie ancienne d'un élément. Par exemple, un client effectue la synchronisation d'un élément et obtient la valeur « 2 » pour cet attribut. Entre-temps, un utilisateur modifie le titre de l'élément sur le serveur, et la valeur est remplacée par « 3 ». Lorsque le client envoie une modification avec la valeur « 2 » et que l'élément a été modifié depuis la dernière demande du client, le serveur renvoie une erreur TP_E_VERSIONCONFLICT (0x81020015) et la liste du contenu actuel de l'élément.

Propriété vti_versionhistory

Le champ owshiddenversion est suffisant pour effectuer une détection de conflits simples lorsque tous les clients se synchronisent avec un serveur central. La synchronisation d’égal à égal constitue toutefois un défi. Vous ne souhaitez pas créer de conflits inutiles lorsqu’une modification a été synchronisée par un client homologue.

Des conflits peuvent également exister dans un scénario de synchronisation qui n'est pas d'égal à égal. Si un client charge une modification sur le serveur et s'il ne reçoit aucun accusé de réception (c'est-à-dire, une réponse de UpdateListItems(String, XmlNode), il doit déterminer lors de la prochaine synchronisation si ces modifications les plus récentes ont bien été chargées.

En-tête ETag DAV

Les récupérations et mises à jour des documents et pièces jointes sont effectuées à l'aide du protocole HTTP/DAV (également appelé WebDAV ou DAV). Ce protocole utilise un mécanisme distinct pour la détection des conflits. Lorsque vous utilisez un accesseur get pour récupérer un fichier, qui peut inclure un document d'une liste, une pièce jointe ou une page ne faisant pas partie d'une liste, un en-tête ETag est renvoyé. L'en-tête ETag comporte un autre objet blob qui contient un GUID et un numéro de version. Lorsque vous utilisez l'accesseur put pour charger un document, un client peut demander à ce que l'en-tête ETag corresponde à celui qui a été fourni.

Notes

L'historique des versions n'est pas pris en charge par ce protocole.

Pièces jointes

Bien que vous puissiez mettre à jour des pièces jointes à l'aide du protocole HTTP/DAV, vous devez utiliser la méthode AddAttachment à partir du service Web Lists pour les ajouter. Cette méthode accepte un tableau binaire et renvoie l'URL de la pièce jointe.

Pour plus d'informations, voir AddAttachment(String, String, String, []).

Voir aussi

Concepts

GetListItemChangesSinceToken et synchronisation des applications