Modell des Workflowmoduls

Der Workflowprozess besteht aus einer Folge von Status und Ereignissen, der Reihenfolge, in der sie auszuführen sind, Berechtigungen, die definieren, wer sie ausführen kann, und einem Skript, das für jedes Ereignis ausgeführt wird. Das Workflowmodul ist eine Komponente der Infrastruktur von Workflow Designer für SQL Server, die den Workflow ermöglicht.

Das Workflowmodul wird zum Erzwingen der Workflowdefinition und zum Ausführen von Workflowereignissen verwendet. Wenn für eine Benutzertabelle Workflow aktiviert wird, werden für die Tabelle workflowbezogene Einfüge-, Aktualisierungs- und Löschtrigger erstellt. Jede Änderung an einem Element der Tabelle löst den entsprechenden Workflowtrigger aus, der eine gespeicherte Prozedur aufruft. Die gespeicherte Prozedur wiederum ruft das Workflowmodul auf.

Funktionen des Workflowmoduls

Das Workflowmodul hat drei Funktionen. Erstens überprüft es, ob die Änderung für den aktuellen Workflowstatus gültig ist. Wenn beispielsweise kein Löschen-Ereignis für den aktuellen Status definiert ist, wird in dem Status Benutzern das Löschen von Elementen nicht ermöglicht.

Zweitens überprüft es, ob der aktuelle Benutzer zum Ausführen des Workflowereignisses berechtigt ist. Handelt es sich bei dem Ereignis z. B. um einen Übergang von Aktiv nach Gelöst, prüft das Modul, ob der aktuelle Benutzer zum Ausführen dieses speziellen Ereignisses berechtigt ist.

Drittens wertet das Workflowmodul das Gültigkeitsprüfungsskript aus, sofern das Ereignis gültig ist und der Benutzer die Ausführungsberechtigung besitzt. Gibt die Gültigkeitsprüfung True zurück, wird das Ereignis ausgeführt. Wenn das Ereignis erfolgreich abgeschlossen wird, gibt der Modulaufruf einen Erfolg zurück, und der Trigger führt einen Commit für die Änderung aus. Tritt beim Ausführen des Gültigkeitsprüfungs- oder Ereignisskripts ein Fehler auf, meldet das Modul den Fehler an den Trigger. Der Trigger löst einen Microsoft® SQL Server™-Fehler aus und führt einen Rollback für die Änderung durch.

Workflow Designer für SQL Server bietet drei Optionen auf Tabellenebene, die die Funktionsweise des Workflowmoduls steuern. Die Optionen können auf den Eigenschaftenseiten des jeweiligen Workflowprozesses festgelegt werden und sind in der modObjects-Tabelle gespeichert.

• **Workflowprozess aktivieren (EnableWorkflow-Eigenschaft)   **Steuert, ob für eine bestimmte Tabelle Workflow erzwungen wird. Hat die Eigenschaft den Wert True (Standard), wird das Modul für jede Datenänderung aufgerufen. Wenn Sie diese Eigenschaft in False ändern, wird der Workflowprozess deaktiviert. Daraufhin können Datenbankaktualisierungen durchgeführt werden, die nicht den Workflowregeln entsprechen. Verwenden Sie diese Einstellung, wenn Sie den Workflowprozess unterbrechen möchten, um Daten in der Tabelle zu bearbeiten.

• **Gelöschte Zeilen für Skript verfügbar machen (MakeDeletedRowsAvailable-Eigenschaft)   **Steuert, ob die ursprünglichen Werte (die in der DELETED-Tabelle innerhalb des Triggers gespeichert sind) zur Laufzeit verfügbar gemacht werden. Hat die Eigenschaft den Wert True, sind die einer Aktualisierungs-, Lösch- oder Einfügeaktion des Benutzers vorausgehenden Datenwerte einer Zeile für das Workflowskript über das Session-Objekt verfügbar. Das Skript kann dann zur Gültigkeitsprüfung oder zu sonstigen Verarbeitungszwecken Werte in der aktualisierten Zeile mit den ursprünglichen Werten vergleichen. Legen Sie diese Eigenschaft auf False (Standard) fest, um die Leistung zu verbessern. Voraussetzung ist, dass gelöschte Zeilen für das Skript nicht erforderlich sind.

• Workflow in separatem Prozess ausführen (SeparateProcess-Eigenschaft)   Steuert, ob das Workflowmodul in demselben Microsoft® Windows®-Prozess ausgeführt wird wie SQL Server. Die Ausführung in einem separaten Prozess isoliert den Workflowcode vom Server und führt zu stabileren Workflowanwendungen. Die Ausführung des Workflowmoduls im gleichen Prozess wie SQL Server ermöglicht eine bessere Leistung, aber Fehler im Workflowskript könnten Störungen von SQL Server hervorrufen.

  Es wird empfohlen, das Workflowmodul als separaten Prozess auszuführen, bis Sie ein vollständiges Debugging und umfassende Tests des Workflowprozesses vorgenommen haben. Standardmäßig wird das Modul in einem separaten Prozess ausgeführt.

  **Anmerkung   **Der gesamte Workflowcode wird im Kontext des Benutzerkontos ausgeführt, das Sie für das Workflowmodul konfigurieren. Welche Berechtigungen diesem Konto auf dem Server erteilt werden, hängt von den Anforderungen der Workflowanwendung und der Vertraulichkeit anderer Daten auf dem Computer ab.

Schemaanforderungen für Workflow

Jede workflowaktivierte Tabelle besitzt eine Statusspalte, die den Workflowstatus enthält, über den die einzelnen Elemente durch den Workflowprozess bewegt werden. Die Statusspalte ist von einem ganzzahligen Datentyp und weist eine FOREIGN KEY-Einschränkung mit einer Schlüsselwort-Nachschlagetabelle auf, in der die Namen der Workflowstatus gespeichert sind. Wenn Sie für eine Tabelle Workflow aktivieren, fügt Workflow Designer diese Spalte (modStateID) und die zugehörige Nachschlagetabelle zur Tabelle hinzu.

Siehe auch

Planen von Workflowanwendungen für SQL Server | Richtlinien für das Entwickeln einer Workflowanwendung | Modell der Sicherheitsberechtigungen | Datenbanktools und -technologien | Grundlegendes zu Workflowprozessen für SQL Server