void Save()
Das speichert den Zustand des Work-Items zusammen mit allen ggf. per AddSuccessor hinzugefügten Workern und allen anderen Änderungen in der UnitOfWork. Ebenfalls werden damit die Fortschrittsanzeigen in den Clients aktualisiert.
void UpdateClient()
Die Methode aktualisiert nur eventuelle Fortschrittsanzeigen in den Clients. Der Zustand des Work-Items wird dabei nicht persistiert. Normalerweise sollte Save bevorzugt werden, dass auch den Zustand des Work-Items persistiert. Nur wenn sich außer dem Fortschritt nichts geändert hat und sich der Erledigungsgrad des Workers ohnehin in anderen Datenbankobjekten manifestiert, ist diese Methode zu empfehlen.
void AddSuccessor(…)
Die Methode fügt einen Nachfolger für den aktuellen Worker hinzu. Das bedeutet, es wird ein Klon des aktuellen Workers angefertigt und anschließend zur UnitOfWork hinzugefügt. Beim nächsten Aufruf von Save wird dieser Worker dann eingeplant. Die Vorgehensweise ist essentiell, da der Nachfolger normalerweise dieselbe InstanceGuid hat, und diese erst dann eingeplant werden darf, wenn der aktuelle Worker sich beendet hat.
Der Klon wird mit CreateSuccessor angefertigt. Siehe dort bezüglich seiner Eigenschaften.
Es gibt mehrere Überladungen der Methode. Diese Ändern den geklonten Worker, bevor er eingeplant wird. Die allgemeinste Überladung erlaubt beliebige Änderungen an dem Worker.
Beispiel:
AddSuccessor((FollowUpReminderEmailTask next) =>
{
next.LastRunTime = ScheduledStartTime;
next.ScheduledStartTime = NextRun().ToUniversalTime();
});void HasSuccessor()Prüft, ob es in der aktuellen UnitOfWork bereits einen Nachfolger (mit der gleichen InstanceGuid) gibt.
Das kann vor allem dazu verwendet werden, um in der Überschreibung von WorkItemFinished zu prüfen, ob das Work-Item schon neu automatisch neu gestartet wurde (z.B. wegen eines automatischen Neustarts).
void RemoveSuccessor()
Prüft, ob es in der aktuellen UnitOfWork bereits einen Nachfolger (mit der gleichen InstanceGuid) gibt und entfernt diesen gegebenenfalls. Dies funktioniert nur, wenn die UnitOfWork noch nicht gespeichert wurde. Danach kann die Ausführung nur noch mit StopExecutionOfWorkItem aufgehalten werden.
void LogError(…), LogWarning(…), LogInfo(…), LogDebug(…)
Meldungen über Ereignisse während der Verarbeitung ins Logfile und ins Anwendungsprotokoll schreiben sofern konfiguriert. Die Methoden berücksichtigen dabei die ggf. unterschiedlichen Sprachen für die beiden Log-Ziele.
Wenn nur ins Anwendungslog geschrieben werden soll, sollte Logger?.Add… verwendet werden.
void LogCriticalError(Exception ex, string message = null)
Damit wird eine kritische, also nicht sinnvoll behandelbare Ausnahme protokolliert. Die Protokollierung erfolgt an 3 Stellen:
- Im Logfile auf dem Webserver.
Dort wird immer Name und Oid des Workers, sowie die vollständige Exception incl. Callstack geschrieben. - Im Anwendungsprotokoll des Workers, falls verfügbar.
Dort wird Standardmäßig nur eine Fehlermeldung mit der Exception-Message ohne Callstack geschrieben. - An die UI. Wenn es sich um ein Work-Item eines Benutzers handelt, wird dieser per Server-Toast auf den Fehler hingewiesen. Auch hier ist die Fehlermeldung ohne Callstack.
Optional kann ein abweichender Meldungstext angegeben werden. Dieser kann per Platzhalter auf Name, Oid, und Exception-Message zugreifen, Siehe XmlDoc.