Freigeben über


Konflikterkennung

Letzte Änderung: Mittwoch, 12. November 2008

Gilt für: SharePoint Foundation 2010

Inhalt dieses Artikels
Abrufen - Senden - Aktualisieren
owshiddenversion-Feld
vti_versionhistory-Eigenschaft
ETag-DAV-Header
Anlagen

Neben Leistungsüberlegungen ist die Konflikterkennung eines der wichtigsten Themen bei der Synchronisierung.

Abrufen - Senden - Aktualisieren

Am besten ist es, wenn Konflikte vom Client erkannt und aufgelöst werden. Der Client kann erkennen, ob Änderungen tatsächlich miteinander in Konflikt stehen oder nicht. Er kann eine Warnung auslösen, um den Benutzer zu benachrichtigen und zur manuellen Behebung des Konflikts aufzufordern, und er kann eine Kopie der vom lokalen Benutzer vorgenommenen Änderungen im Speicher des Benutzers speichern.

Aus diesem Grund sollte ein Synchronisierungsvorgang aus drei Abschnitten bestehen: Zuerst werden Daten, die möglicherweise geändert wurden, vom Server abgerufen. Anschließend bestimmt der Client, ob Konflikte mit Änderungen vorliegen, die bereits in die Clientkopie hochgeladen wurden. Falls kein Konflikt vorliegt, werden abschließend die neuen Clientdaten hochgeladen.

Zum Zeitpunkt der Aktualisierung wird möglicherweise Geschäftslogik auf SharePoint-Objekte angewendet. Aus diesem Grund gibt die UpdateListItems(String, XmlNode)-Methode die aktualisierten Werte aller Felder und Eigenschaften der aktualisierten Elemente zurück.

owshiddenversion-Feld

Windows SharePoint Services 3.0 verwendet das Feld owshiddenversion (in der Microsoft.SharePoint.SPBuiltInFieldId-Klasse), um Konflikte zu erkennen. Wenn dieser Feldwert während des Aktualisierungsvorgangs nicht angegeben wird, werden alle Änderungen vom Server überschrieben. Ein Client muss diesen Feldwert während des Aktualisierungsvorgangs immer angeben, um Datenverluste zu vermeiden. Der Feldwert entspricht der Nummer, die der Server zuletzt zurückgegeben hat.

Anhand des Werts im owshiddenversion-Feld kann der Server bestimmen, ob Sie eine veraltete Kopie eines Elements aktualisieren. Angenommen, ein Client synchronisiert ein Element und erhält den Wert "2" für dieses Attribut. In der Zwischenzeit wurde der Titel dieses Elements auf dem Server durch einen anderen Benutzer geändert, sodass sich der Wert in "3" ändert. Wenn der Client eine Änderung mit dem Wert "2" sendet und das Element seit der letzten Anforderung durch den Client geändert wurde, gibt der Server den Fehler TP_E_VERSIONCONFLICT (0x81020015) und eine Liste der aktuellen Inhalte des Elements zurück.

vti_versionhistory-Eigenschaft

Für die einfache Konflikterkennung und wenn alle Clients mit einem zentralen Server synchronisieren, ist das Feld owshiddenversion ausreichend. Die Peer-zu-Peer-Synchronisierung stellt Sie jedoch vor weitere Herausforderungen, da Sie das Auslösen unnötiger Konflikte vermeiden möchten, wenn eine Änderung durch einen Peerclient synchronisiert wurde.

Konflikte können auch in Situationen auftreten, die kein Peer-zu-Peer-Szenario darstellen. Wenn ein Client eine Änderung erfolgreich auf den Server hochlädt, aber keine Bestätigung (Antwort von UpdateListItems(String, XmlNode)) erhält, muss der Client bei der nächsten Synchronisierung feststellen, ob seine jüngsten Änderungen hochgeladen wurden.

ETag-DAV-Header

Das Abrufen und Aktualisieren von Dokumenten und Anlagen erfolgt mithilfe des HTTP/DAV-Protokolls (auch WebDAV oder DAV genannt). Dieses Protokoll verwendet einen speziellen Mechanismus für die Konflikterkennung. Wenn Sie einen get-Accessor zum Abrufen einer Datei verwenden, die ein Dokument in einer Liste, eine Anlage oder eine Seite außerhalb einer Liste enthalten kann, wird ein ETag zurückgegeben. Das ETag umfasst ein weiteres BLOB (Binary Large Object), das eine GUID und eine Versionsnummer enthält. Wenn Sie den put-Accessor zum Hochladen eines Dokuments verwenden, muss ein Client anfordern, dass das ETag mit dem angegebenen ETag übereinstimmt.

HinweisHinweis

Ein Versionsverlauf wird für dieses Protokoll nicht unterstützt.

Anlagen

Obwohl es möglich ist, Anlagen mithilfe des HTTP/DAV-Protokolls zu aktualisieren, müssen Sie zum Hinzufügen von Anlagen die AddAttachment-Methode aus dem Lists-Webdienst verwenden. Diese Methode akzeptiert ein binäres Array und gibt die URL der Anlage zurück.

Weitere Informationen finden Sie unter AddAttachment(String, String, String, []).

Siehe auch

Konzepte

GetListItemChangesSinceToken und Synchronisieren von Anwendungen