Gewusst wie: Ablauf von Aktionen mit "PostActions" und "BypassLocks"
Letzte Änderung: Dienstag, 10. August 2010
Gilt für: SharePoint Server 2010
Für die ordnungsgemäße Verwendung von Datensätzen müssen Sie benutzerdefinierte Richtlinienaktionen richtig einsetzen. Das Objektmodell gibt wenige Warnungen oder Fehler aus, falls benutzerdefinierte Richtlinienaktionen falsch registriert oder falsch verwendet werden. Deshalb sind für die Verwendung benutzerdefinierter Richtlinienaktionen fundierte Kenntnisse der Funktionsweise des Objektmodells erforderlich.
Dieses Thema enthält Tipps und Codebeispiele, um mit dem Objektmodell für das Ablaufen von Aktionen mithilfe von PostActions und BypassLocks zu sorgen. Da Aufbewahrungsrichtlinien für Datensätze in allen Situationen funktionieren sollen, sollten Sie eine benutzerdefinierte Aktion schreiben, damit mit Aufbewahrungsrichtlinien ein Datensatz verwaltet werden kann, selbst wenn die entsprechende erstellte Aktion nicht für die Verwaltung von Datensätzen gedacht ist. In diesem Thema wird erläutert, wie Sie eine benutzerdefinierte Richtlinienaktion in Code einbinden, mit dem die OnExpirationWithPostActions(SPListItem, XmlNode, Time)-Methode für das Arbeiten mit Datensätzen implementiert wird, und wie Sie Sperren für Datensätze umgehen, wenn vom Code keine gesperrten Datensätze verarbeitet werden sollen.
Wenn Sie die neue IExpirationActionWithPostActions-Schnittstelle verwenden und die OnExpirationWithPostActions(SPListItem, XmlNode, Time)-Methode implementieren, geben Sie die richtige ExpirationPostActions-Aktion zurück, um das SPItem-Objekt zu aktualisieren, falls es sich um einen Datensatz handelt.
Wenn Sie die IExpirationAction-Schnittstelle verwenden oder nur die Expiration-Klasse implementieren, werden mit der Datensatzverwaltungslösung in Microsoft SharePoint Server 2010 benutzerdefinierte Richtlinienaktionen standardmäßig ordnungsgemäß verwaltet.
Beispiel
Mit dem ExpirationPostActions-Beispiel wird veranschaulicht, wie Sie eine PostActions-Anweisung deklarieren, die für ein Element bei dessen Ablauf ausgeführt wird. Mit dem Code wird das Ablaufdatum des Elements neu berechnet, das Element aktualisiert und ein Überwachungsereignis für die Aktion protokolliert, nachdem eine benutzerdefinierte Aktion ausgeführt wurde.
Mit dem Code wird außerdem überprüft, ob das Element vom Feature für die direkte Datensatzverwaltung gesperrt wurde. Im Code werden mithilfe von PostActions Datensätze verworfen, die an das Systemkonto ausgecheckt wurden, das Element wird aktualisiert und anschließend wird das Element erneut an das Systemkonto ausgecheckt.
public ExpirationPostActions OnExpirationWithPostActions(SPListItem item, XmlNode parametersData, DateTime expiredDate)
{
/* Recalculates the item's expiration date, updates
* the item, and logs an audit event for the action. */
ExpirationPostActions postActions = ExpirationPostActions.Default;
//Do whatever you want to do on the item.
//Check to see whether In-Place Records Management has locked the item.
if (Records.IsLocked(item))
{
/* In-Place Records Management locks items by checking them
* out to the System Account. For our changes to persist
* for these items, the code updates the checked-in version. */
postActions |=
/* Discards the check-out to System Account before
* updating the item. */
ExpirationPostActions.UndoCheckOutBeforeUpdate |
/* Checks the item back out to the System Account after
* updating the item. */
ExpirationPostActions.KeepCheckedOutToSystem;
}
return postActions;
}
Zum Aktualisieren eines gesperrten Elements muss von allen anderen Anforderungen die BypassLocks(SPListItem, ByPassLockedItemDelegateMethod)-Methode in einem erhöhten Bereich aufgerufen werden.
using Microsoft.SharePoint;
using Microsoft.SharePoint.Publishing;
using Microsoft.Office.RecordsManagement.RecordsRepository;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
Records.BypassLocks(myListItem, delegate(SPListItem item)
{
//Perform any action on the item.
});
});