Nehmen wir einmal an, wir haben einen einfachen WebPart, der prüfen soll, ob es in einer SharePoint-Liste Änderungen gegeben hat. Eine Möglichkeit dies umzusetzen wäre, dass der WebPart über alle Listeneinträge iteriert und sich das jeweilige Änderungsdatum ansieht. Das würde zwar wahrscheinlich auch funktionieren, ist aber keine gute Umsetzung, weil es -besonders bei größeren Listen- enorm zeitaufwändig und mindestens genauso CPU-belastend ist.

SharePoint bietet hierfür eine wesentlich bessere Lösung an: das Objekt SPChangeToken. Vereinfacht ausgedrückt legt man mit einem SPChangeToken einen zeitlichen Marker fest, ab dem man Änderungen überprüfen möchte. Oder anders ausgedrückt: man legt mit SPChangeToken einen Zeitstempel fest, ab dem (bzw. nach dem) Änderungen überprüft werden sollen.

Und das geht so:

Zuerst erzeugt man sich ein Objekt vom Typ SPChangeToken und legt damit den Startzeitpunkt für die Änderungsabfrage fest. Bei meinem Beispiel mit der SharePoint-Liste könnte das so aussehen:

gChangeToken = new SPChangeToken(SPChangeCollection.CollectionScope.List, myList.ID, myList.Created);

Damit wird der Startzeitpunkt auf den Zeitstempel der Listenerstellung gelegt. Nun erfolgt eine Änderung an der Liste und diese Änderung soll erkannt und abgefragt werden:

if (myList.GetChanges(gChangeToken).Count > 0)
{
   // do something
}

Damit man nach dieser Abfrage wieder die nächsten Änderungen mitbekommt, muss man einen neuen ChangeToken erstellen:

gChangeToken = new SPChangeToken(SPChangeCollection.CollectionScope.List, myList.ID, DateTime.UtcNow);

Bei der nächsten Abfrage werden dann alle Änderungen aufgelistet, die nach dem Erstellen des neuen ChangeTokens erfolgt sind. Selbstverständlich können die Änderungen auch einzelnen abgefragt werden (die Methode GetChanges() liefert eine Collection mit den Änderungen zurück). Ein Beispiel dazu findet sich hier. Anzumerken bleibt allerdings noch, dass aufgrund der Allgemeinheit dieser Funktionalität keine Items zurückgegeben werden, sondern nur deren ID. Sofern man an den geänderten Items interessiert ist, muss man sich diese also z.B. über deren ID direkt aus der Liste holen.

Aber Achtung: im Gegensatz zu Suchergebnissen erfolgt hier kein Security Trimming. Bedeutet: auch wenn Änderungen zurückgemeldet wurden, heißt das noch lange nicht, dass der aktuelle Benutzer dieser auch sehen darf!

Dieser Mechanismus funktioniert nicht nur mit einer SharePoint-Liste, sondern auf ähnliche Art auch mit Objekten vom Typ SPWeb, SPSite und sogar der ContentDB. Informationen dazu finden sich hier.

Ach ja - das Ganze funktioniert natürlich nur, wenn in der Zentraladministration in den General Settings der WebApp (unter Resource Throttling) das Change Log aktiviert ist. Normalerweise ist hier ein Wert von 60 Tagen eingetragen.