Alle Workflow-Aktionen zu einer Datentabelle laufen in einer UnitOfWork, die erst am Ende, wenn alle Aktivitäten ausgeführt wurden, comitted wird. Das bedeutet im Besonderen, dass die Workflow-Aktion niemals selbst CommitWork aufrufen darf.
Workflow-Aktionen sind kurzläufige WorkItems. Das bedeutet, dass keinerlei länger dauernde Aktivitäten in der ExecuteAction Methode durchgeführt werden dürfen. Im Besonderen ist es verboten, eigene schreibende Transaktionen zu starten, andere als den übergebenen Datensatz zu verändern oder über Schnittstellen (Web-Services) auf fremde Systeme zu warten.
Bereits nach 60s werden die Aktionen vom Work-Manager hart beendet (kill), und die Zeit gilt für alle Aktionen in einem konfigurierten Workflow zusammen. Wenn längere Aktionen benötigt werden, sollte die Aktivität der Workflow-Aktion darin bestehen, einen neuen Hintergrundprozess zu starten.
Workflow-Aktionen können niemals rekursiv neue Workflows auslösen. Während der Ausführung des Workflows sind alle Workflow-Trigger deaktiviert. Dies gilt aber nicht für von Workflows gestartete Hintergrundprozesse, diese können weitere Workflows auslösen. Wenn das nicht gewünscht ist, sollte im Hintergrundprozess ein Workflow-Kontext erzwungen werden:
var workflowPrincipal = UserHelper.CurrentUser.Clone();
workflowPrincipal.AddIdentity(ExecutionEngine.WorkflowIdentity);
using (var ctx = new UserHelper.LocalUserContext(workflowPrincipal))
// …Workflow-Aktionen werden immer in der Konfigurationsreihenfolge von oben nach unten ausgeführt. Änderungen, die eine Workflow-Aktion am aktuellen Datensatz vornimmt, werden von nachfolgenden Workflow-Items gesehen. Das gilt für Bedingungen und Aktionen gleichermaßen.
Validierungsfehler an dem evtl. geänderten Datensatz treten immer erst am Ende beim CommitWork auf. Das bedeutet, wenn mehrere Feldwerte im Zusammenhang durch mehrere, verschiedene Workflow-Aktionen gesetzt werden, genügt es, wenn das Objekt am Ende nach allen Aktionen wieder einen validen Zustand hat.
Umgekehrt kann aber auch eine einzige Workflow-Aktion das Objekt in einen invaliden Zustand versetzen, der das Speichern als Ganzes verhindert. Dadurch werden dann alle Workflow-Änderungen an diesem Objekt faktisch rückgängig gemacht, also nicht gespeichert. Ein solcher Fehler wird immer protokolliert.
Workflow-Aktionen sollten soweit irgend möglich im Rahmen der UnitOfWork für den aktuellen Datensatz ablaufen. Dadurch ist sichergestellt, dass die Aktionen nicht nur zur Hälfte ausgeführt werden. Bei Nichtbeachtung dieser Regel ist es möglich, dass beispielsweise eine E-Mail mit Platzhaltern zu einem Objektzustand versendet werden, der niemals gespeichert wurde, weil anschließend die Validierung fehlgeschlagen ist.
Zur Implementierung des 2 Phase Commit kann z.B. das XPO-Event orm.Session.AfterCommitTransaction verwendet werden.