Einführung in die Regel-Engine von Windows Workflow Foundation

 

Jurgen Willis
Microsoft Corporation

Februar 2006

Gilt für:
   Windows Workflow Foundation (WF) Beta 2
   Visual Studio 2005

Zusammenfassung: Dieser Artikel bietet eine Übersicht über die Funktionen der Regel-Engine in Windows Workflow Foundation (WF). Es beschreibt, wie Bedingungen und RuleSets in WF verwendet werden, und erläutert das Verhalten von Auflistungen von Regeln, einschließlich Forward Chaining, Tracking und Ablaufverfolgung. (18 gedruckte Seiten)

Hinweis Dieser Artikel wurde mit Beta 2 geschrieben, und in Zukunft müssen möglicherweise einige Änderungen vorgenommen werden, damit dies in späteren Versionen von Windows Workflow Foundation funktioniert.

Inhalte

Einführung
Übersicht über Regeln in Windows Workflow Foundation
Regelauswertung
Forward Chaining
Steuerelement für die Vorwärtsverkettung
Zusätzliche Modellierungsdiskrierung
Nachverfolgung und Ablaufverfolgung
Zusammenfassung
Weitere Informationen

Einführung

Mit der Verfügbarkeit von Windows Workflow Foundation (WF) führt Microsoft neue Regelfunktionen für die WinFX-Entwicklerplattform ein. Diese Funktionen reichen von einfachen Bedingungen, die das Aktivitätsausführungsverhalten steuern, bis hin zu komplexen RuleSets, die von einer voll ausgestatteten Forward-Chaining-Regel-Engine ausgeführt werden.

Die Regelfunktion ermöglicht die deklarative Modellierung von Einheiten der Anwendungslogik im Rahmen eines gesamten Geschäftsprozesses. Beispielszenarien für die Regel-Engine-Technologie sind die Auftragsvalidierung, die Preisberechnung, die Durchsetzung von Promotionen, die Verwaltung von Ausnahmeprozessen sowie die Bewertung und Verwaltung von Ansprüchen.

Ein wichtiges Ziel bei der Entwicklung dieser Technologie war die Bereitstellung einer wirklich integrierten Workflow- und Regelumgebung. Branchenübergreifend waren Regeln und Workflows in der Regel recht unterschiedliche Technologien, die in der Regel von verschiedenen Anbietern bereitgestellt werden. Regel-Engines von Drittanbietern werden häufig von Workflow- und BPM-Anbietern (Business Process Management) eingebettet oder integriert, aber die Entwickler- und Verwaltungserfahrung ist eindeutig nicht nahtlos.

Mit WF hat Sich Microsoft sehr darauf konzentriert, eine nahtlose Entwicklerumgebung zwischen Workflow- und Regelmodellierung bereitzustellen, damit Entwickler Regeln jederzeit problemlos in ihren Workflow integrieren können. Entwickler können bestimmen, ob sie ihre Logik im Workflowmodell, in Regeln oder im Code modellieren möchten, ohne sich Gedanken über die Integrationsauswirkungen dieser Entscheidungen machen zu müssen. Dies wurde jedoch erreicht, ohne dass die Fähigkeit zum Ausführen von Regeln außerhalb des Bereichs eines Workflows geopfert wurde.

Ein zweites wichtiges Ziel war die Bereitstellung eines einfachen Modells für Entwickler, das bei der Definition von Regeln verwendet werden kann. Die Regeltechnologie war bisher oft eine Nischentechnologie, die von einer hochspezialisierten Gruppe von Regelexperten verwendet wird. Während verbesserungen an Tools die Anzahl der Personen erweitert haben, die Regeln verwenden, erforderten die Modelle häufig, dass Benutzer zu gut mit der Implementierungsmechanik der zugrunde liegenden Engine vertraut sind. Bei der Bereitstellung von Regelfunktionen in der Plattform haben wir uns für ein Modell entschieden, das von der breiten .NET-Entwicklercommunity und letztendlich von Nichtentwicklern angegangen werden kann. Obwohl es immer ein gewisses Maß an Domänenkenntnissen gibt – wie bei jeder Technologie –, ist es unser Ziel, dass alle .NET-Entwickler das Regelmodell schnell nutzen und es einfach in ihre Anwendungen integrieren können.

Wf bietet nicht nur ein ansprechbares Modell, es bietet auch eine leistungsstarke Evaluierungs-Engine, die komplexe Regelszenarien unterstützt und eine vorwärts verkettete Auswertung und eine präzise Auswertungssteuerung verlangt. Dies wird auf eine Weise bereitgestellt, die eine Reihe von Erweiterbarkeitspunkten bietet, sodass Entwickler auf unserer Plattform aufbauen und Regelfunktionen zur Unterstützung eines breiten Spektrums von Szenarien bereitstellen können.

Dieses Dokument bietet eine technische Einführung in die in WF bereitgestellten Regelfunktionen sowie eine Übersicht über die verfügbaren Features und deren Verwendung. Am Ende dieses Dokuments finden Sie eine Liste mit zusätzlichen Ressourcen, die verwendet werden können, um mehr über die Regelfunktionen in WF zu erfahren.

Übersicht über Regeln in Windows Workflow Foundation

Die Regeltechnologie wird in WF auf zwei wichtige Arten verfügbar gemacht: als Bedingungen für Aktivitäten und als vorwärts verkettete RuleSet in der Policy-Aktivität. Die Weiterleitungskette wird später im Dokument erläutert. Kurz gesagt, bezieht es sich auf die Fähigkeit, dass die Aktionen einer Regel dazu führen, dass andere, abhängige Regeln neu ausgewertet werden.

Aktivitätsbedingungen

Bedingungen werden von den folgenden vier Aktivitäten verwendet, die mit WF ausgeliefert werden:

• IfElseBranch
• While
• Replicator
• ConditionedActivityGroup (CAG)

Bedingungen werden verwendet, um das Ausführungsverhalten dieser Aktivitäten zu steuern, z. B. um zu bestimmen, ob ein bestimmtes IfElseBranch ausgeführt wird. Bedingungen können entweder als CodeConditions angegeben werden, die im Code neben einem konfigurierten Handler enthalten wird, oder als RuleConditionReference. Eine RuleConditionReference verweist auf eine RuleCondition-Definition in einer RULES-Datei, die dem Workflow im Workflowprojekt zugeordnet ist. Die Benutzeroberfläche in Visual Studio ist in Abbildung 1 dargestellt.

Abbildung 1. Erstellung von WF-Regelbedingungen

Hinzufügen einer Regelbedingung

Dies sind die Schritte, die beim Hinzufügen einer Regelbedingung zu einer IfElseBranch-Aktivität innerhalb der IfElse-Aktivität erforderlich sind:

1. Wenn eine Aktivität mit einer Bedingung ausgewählt ist (wie bei der ifElseBranch-Aktivität gezeigt), wird im Raster Eigenschaften eine Condition-Eigenschaft angezeigt.
2. In einer Dropdownliste für die Condition-Eigenschaft kann der Benutzer eine CodeCondition oder eine RuleConditionReference auswählen.
3. Wenn RuleConditionReference ausgewählt ist, kann die Condition-Eigenschaft erweitert werden, um die Eigenschaften ConditionName und Expression anzuzeigen.
4. Nachdem Sie einen Bedingungsnamen angegeben haben, werden die Auslassungspunkte in der Expression-Eigenschaft ausgewählt, um den Regelbedingungs-Editor zu starten. Dieser Editor ermöglicht es dem Entwickler, die Bedingung in Textform mit IntelliSense-ähnlicher Unterstützung einzugeben. Der Text wird in die zugeordnete Objektmodelldarstellung von RuleCondition analysiert.
5. Nachdem Sie OK ausgewählt haben, wird die Definition RuleCondition in eine <WorkflowName.rules-Datei> serialisiert, die dem Projekt hinzugefügt wird.

Um auf Felder oder Eigenschaften im Workflow zu verweisen, können Sie diese in den Editor eingeben. Nachdem der Punkt eingegeben wurde, wird ein IntelliSense-ähnliches Menü angezeigt, in dem Sie die Elemente im Workflow auswählen können (Sie können das Element auch direkt eingeben). Geschachtelte Anrufe können ebenfalls durchgeführt werden; Beispiel: this.order.Total. Statische Methoden können für Typen aufgerufen werden, auf die verwiesen wird, indem Sie den Klassennamen gefolgt von dem Methodennamen eingeben, wie im Code.

Ausdrücke werden mit den folgenden relationalen Operatoren unterstützt:

• Gleich ("==" oder "=")
• Größer als (">")
• Größer als oder gleich (">=")
• Kleiner als ("<")
• Kleiner als oder gleich ("<=")

Darüber hinaus können Sie die folgenden arithmetischen Operatoren verwenden:

• Hinzufügen ("+")
• Subtrahieren ("-")
• Multiplizieren ("*")
• Dividieren ("/")
• Modulus ("MOD")

Ausdrücke können mithilfe der folgenden Operatoren kombiniert/negiert werden:

• UND ("AND", "&&")
• OR ("OR", "||")
• NOT ("NOT", "!")
• Bitweise und ("&")
• Bitweise oder ("|")

Der Hauptgrund für einen Entwickler, eine Regelbedingung anstelle einer Codebedingung zu verwenden, ist, dass Regelbedingungen Teil des Modells werden und dynamisch zur Laufzeit bei der Ausführung von Workflowinstanzen aktualisiert werden können. Ein sekundärer Vorteil von Regelbedingungen besteht darin, dass im Rahmen des Modells komplexere Tools auf dem Modell basieren könnten, um zusätzliche Erstellungserfahrungen, Abhängigkeitsverwaltung, bedingungsübergreifende Analyse usw. bereitzustellen.

Richtlinienaktivität

Die Policy-Aktivität kapselt die Definition und Ausführung eines RuleSets. Ein RuleSet ist eine Sammlung von Regeln mit einer Reihe von Ausführungssemantik. Regeln sind wiederum If-Then-Else-Ausdrücke, die für die Workflowmember ausgeführt werden. Die Benutzeroberfläche ist in Abbildung 2 dargestellt und entspricht der Darstellung mit Regelbedingungen.

Abbildung 2. Wf RuleSet-Erstellung

Hinzufügen einer Richtlinienaktivität

Führen Sie die folgenden Schritte aus, um einen Regelsatz für die Richtlinienaktivität zu konfigurieren:

1. Ziehen Sie die Richtlinienaktivität aus der Toolbox auf den Workflow-Designer.
2. In RuleSetReference wird ein Name für das RuleSet angegeben.
3. Wenn Sie die Auslassungspunkte im Feld RuleSet-Definition auswählen, wird der Regelsatz-Editor gestartet.
4. Der Editor zeigt eine Auflistung von Regeln in einem Listenfeld an.
5. Wenn Sie eine bestimmte Regel auswählen, werden deren Bedingung, Dann-Aktionen, Else-Aktionen und eine Reihe zusätzlicher Eigenschaften angezeigt.
6. Wie im Regelbedingungs-Editor werden die Aktionen Bedingung, Dann Aktionen und Else als Text eingegeben und in die zugeordnete Objektmodelldarstellung analysiert. -Regeln werden für die Member im Workflow erstellt.
7. Wenn Sie OK auswählen, wird ruleSet in die REGELDATEI serialisiert, die dem Workflow zugeordnet ist.

Beachten Sie, dass durch Auswählen der Auslassungspunkte in der RuleSetReference-Eigenschaft der Editor gestartet wird, mit dem der Benutzer ein vorhandenes RuleSet auswählen oder RuleSets hinzufügen/umbenennen/entfernen kann, wie in Abbildung 3 dargestellt.

Abbildung 3. WF RuleSet-Browser

Regelauswertung

Jede Regel in einem RuleSet hat einen Prioritätswert mit dem Standardwert 0. Die Regeln in einem RuleSet können als sortierte Auflistung betrachtet werden, die nach den Prioritätswerten sortiert ist. Der WF-Regelauswerter wertet Regeln einzeln aus und führt die Aktionen der Regel basierend auf den Ergebnissen der Bedingungsauswertung der Regel aus.

Der Auswertungsmechanismus kann mit dem folgenden Verfahren konzeptionell beschrieben werden:

1. Beginnen Sie mit der Liste aktiver Regeln.
2. Suchen Sie die Regel mit der höchsten Priorität.
3. Werten Sie die Regel aus, und führen Sie ihre Then/Else-Aktionen entsprechend aus.
4. Wenn die Aktionen einer Regel ein Feld bzw. eine Eigenschaft aktualisieren, die von einer vorherigen Regel in der Liste (eine mit höherer Priorität) verwendet wird, werten Sie diese vorherige Regel neu aus, und führen Sie die entsprechenden Aktionen aus. Beachten Sie, dass nur die Regeln mit einer bestimmten Abhängigkeit neu ausgewertet werden.
5. Fahren Sie mit dem Vorgang fort, bis alle Regeln im RuleSet ausgewertet wurden.

Sehen wir uns ein einfaches Beispiel an. Angenommen, Sie verfügen über das folgende RuleSet, wobei A, B usw. Daten im Workflow darstellen.

Regel4 (Priorität = 4)

IF A = 15
THEN B = 5

Regel3 (P=3)

IF C = 5
THEN B = 10

Rule2 (P=2)

IF D = 2
THEN A = 15

Rule1 (P=1)

IF B = 5
THEN E = 7

Nehmen Sie an, dass Sie über folgende Eingabedaten verfügen:

• A = 0
• B = 0
• C = 5
• D = 2
• E = 0

Die Auswertung würde wie folgt ablaufen:

• Regel4 wird ausgewertet; Es wird als false ausgewertet, und da keine Else-Aktionen vorhanden sind, werden keine Aktionen ausgeführt.
• Rule3 wird als true ausgewertet, und die Aktion wird ausgeführt, wobei B = 10 festgelegt wird. Regel4 hängt nicht vom Wert von B ab, sodass die Auswertung mit Regel2 fortgesetzt wird.
• Rule2 wird als true ausgewertet, und die Aktion wird ausgeführt, wobei A = 15 festgelegt wird.
• Da Rule4 den Wert von A in seinen Bedingungen verwendet, wird er neu ausgewertet. Es wird als true ausgewertet, und seine Aktion wird ausgeführt, wobei B = 5 festgelegt wird; Regel3 und Regel2 werden nicht neu ausgewertet, da ihre Bedingungen nicht vom Wert von A abhängen. Keine vorherigen Regeln hängen vom Wert B ab, sodass die Auswertung mit Regel1 fortgesetzt wird.
• Rule1 wird als true ausgewertet, und die Aktion wird ausgeführt, wobei E = 7 festgelegt wird.

Das resultierende Dataset wäre nun:

• A = 15
• B = 5
• C = 5
• D = 2
• E = 7

Forward Chaining

Wie bereits zuvor gesehen, basiert die Verkettung auf den identifizierten Abhängigkeiten zwischen Regeln; Genauer gesagt, die Abhängigkeiten zwischen den Aktionen einer Regel und die Bedingungen anderer Regeln. Diese Abhängigkeiten können mithilfe von drei Methoden identifiziert oder deklariert werden:

• Implizit
• Attributbasiert
• Explizit

Implizit

Implizite Abhängigkeiten werden automatisch von der Engine identifiziert. Wenn ein RuleSet zum ersten Mal ausgeführt wird, wird jede Regel analysiert, um die Felder/Eigenschaften zu bewerten, die sie in ihrer Bedingung liest und in ihre Aktionen schreibt. Dies erfolgt durch Durchlaufen des Ausdrucks in der Bedingung und der Anweisungen in den Aktionen. Nehmen Sie beispielsweise die folgenden Regeln an.

Regel 1

IF this.subtotal > 10000
THEN this.discount = .05

Regel 2

IF this.discount > 0
THEN this.total = (1-this.discount) * this.subtotal

Die Engine würde die Regeln auswerten und feststellen, dass Regel 1 das Teilergebnisfeld liest und in das Rabattfeld schreibt. Regel 2 liest die Felder des Rabatts und der Teilsumme und schreibt in das Gesamtfeld. Daher ist Artikel 2 von Artikel 1 abhängig; das Ergebnis ist, dass die Engine sicherstellt, dass Regel 2 ausgewertet/neu ausgewertet wird, wenn Regel 1 ihre Then-Aktion ausführt.

Beachten Sie, dass Abhängigkeiten auf Blattknotenebene identifiziert werden. Verwenden Sie das folgende RuleSet.

Regel 1

IF this.order.Subtotal > 10000
THEN this.order.Discount= .05

Regel 2

IF this.order.Discount > 0
THEN this.order.Total = (1-this.order.Discount) * this.order.Subtotal

Artikel 3

IF this.order.CustomerType = "Residential"
THEN ...

Zwischen Regeln 1 und 2 würde weiterhin eine Abhängigkeit identifiziert. Regel 3 hätte jedoch keine Abhängigkeit von Regel 1 oder 2, da die CustomerType-Eigenschaft nicht aktualisiert wird. Anders ausgedrückt: Die Abhängigkeit wird auf der Ebene der CustomerType-Eigenschaft identifiziert, nicht auf dem Order-Objekt selbst.

Durch implizite Verkettung übernimmt WF den Großteil der notwendigen Verkettung für den Benutzer, sodass der Benutzer keine expliziten Aktualisierungen modellieren muss und in den meisten Fällen die Verkettung oder die Notwendigkeit dafür nicht wissen kann. Wir erwarten, dass dies die Modellierung komplexer RuleSets für die meisten Benutzer vereinfacht und das Konzept der Verkettung zu einer leistungsstarken, aber größtenteils verborgenen Funktion der Engine macht. Für komplexere und spezifischere Szenarien werden jedoch die beiden anderen Mechanismen zum Fördern der Verkettung bereitgestellt, attributbasiert und explizit.

Attributbasiert

Für Methodenaufrufe innerhalb einer Regel wird es schwieriger, die auftretenden Lese- und Schreibvorgänge deterministisch auszuwerten. Um dieses Problem zu beheben, stellt WF drei Attribute bereit, die auf eine Methode angewendet werden können, um deren Aktionen anzugeben:

• RuleRead
• RuleWrite
• RuleInvoke

Das Attributieren einer Methode mit dem RuleRead-Attribut gibt an, dass die angegebene Eigenschaft gelesen wird. Ebenso kann das RuleWrite-Attribut verwendet werden, um anzugeben, dass eine Methode ein bestimmtes Feld oder eine bestimmte Eigenschaft aktualisiert. Angenommen, die ersten beiden Regeln im impliziten Abschnitt wurden wie folgt umgeschrieben.

Regel 1

IF this.subtotal > 10000
THEN this.SetDiscount(.05)

Regel 2

IF this.discount > 0
THEN this.total = (1-this.discount) * this.subtotal

Die SetDiscount-Methode könnte dann wie folgt zugeordnet werden, sodass die Engine erkennen kann, dass Regel 2 aufgrund der Verwendung des Rabattfelds von Regel 1 abhängig ist.

[RuleWrite("discount")] 
void SetDiscount(double requestedDiscount)
{
     ...//some code that updates the discount field
}

Das RuleInvoke-Attribut kann verwendet werden, um Abhängigkeiten aufgrund verknüpfter Methodenaufrufe zu diktieren. Nehmen Wir beispielsweise die folgende Änderung der Regeln und Methoden an.

Regel 1

IF this.subtotal > 10000
THEN this.SetDiscountWrapper(.05)

Regel 2

IF this.discount > 0
THEN this.total = (1-this.discount) * this.subtotal

[RuleInvoke("SetDiscount")]
void SetDiscountWrapper(double requestedDiscount)
{
     ...
     SetDiscount(requestedDiscount);
     ...
}

[RuleWrite("discount")] 
void SetDiscount(double requestedDiscount)
{
}

Die Bedingung von Regel 2 ruft SetDiscountWrapper auf, das wiederum SetDiscount aufruft, das in das Rabattfeld schreibt. Mit dem RuleInvoke-Attribut kann dieser indirekte Schreibvorgang deklariert und von der Engine erkannt werden.

Es ist wichtig zu erkennen, dass das Feld oder die Eigenschaft, auf das bzw. die im Attributpfad verwiesen wird, auf ein Feld oder eine Eigenschaft in derselben Klasse wie die -Methode verweist. Dabei handelt es sich nicht unbedingt um das Stammobjekt, das zur Ausführung an das RuleSet übergeben wird. Beispielsweise können Sie die Order-Klasse wie folgt zuordnen.

public class Order
{
     private double discount;

     public double Discount
     {
     get { return discount;}
     set { discount = value;}
     }

     [RuleWrite("Discount")] 
     void CalculateDiscount(double requestedDiscount, double weighting)
     {
...//some code that updates the discount field
     }
}

Sie können dann wie folgt eine instance dieser Klasse in einem Workflow verwenden.

public class Workflow1 :  SequentialWorkflowActivity
{
     private Order discount;

     ...
}

Die Ausführung von Regel 2 würde dann zu einer Neubewertung von Regel 1 führen.

Regel 1

IF this.order.Discount > 5
THEN ...

Regel 2

IF ...
THEN this.order.CalculateDiscount( 5.0, .7)

Einige zusätzliche Punkte zur Verwendung von Attributen:

• Attribute verweisen auf die Felder/Eigenschaften der Owner-Klasse , nicht auf die Parameter auf einen Methodenaufruf.
• Feldhalter können auch in den Regelattributen verwendet werden. Beispielsweise könnte RuleWrite("order/*") verwendet werden, um anzugeben, dass alle Felder des Objekts, auf das vom Feld "order" verwiesen wird, von der -Methode geändert werden (in diesem Beispiel würde sich die Methode auf dem Workflow selbst befinden, nicht die Order-Klasse ). Der Feldhalter kann jedoch nur am Ende des Pfads verwendet werden. ein Attribut wie RuleWrite("*/Discount") ist ungültig.
• Ein Attribut wie RuleWrite("order") kann mit Verweistypen verwendet werden, um anzugeben, dass sich der Verweis geändert hat, z. B. um anzugeben, dass die Variable jetzt auf eine andere Order-instance zeigt. Es wird davon ausgegangen, dass alle Regeln, die ein Feld/eine Eigenschaft für die Variable verwenden, betroffen sind, zusätzlich zu allen Regeln, die den instance Verweis selbst testen, z. B. IF this.order == this.order2.
• Das Standardverhalten, wenn keine Methodenattribute angegeben werden, ist, dass von einem Methodenaufruf ausgegangen wird, dass alle Felder/Eigenschaften für das Zielobjekt (das Objekt, für das die Methode aufgerufen wird) gelesen, aber in keines davon geschrieben wird. Darüber hinaus wird davon ausgegangen, dass eine Methode aus den Parametern liest, die an sie übergeben werden, aber davon ausgeht, dass sie keines dieser Parameter schreibt. Es wird davon ausgegangen, dass die Parameter "Out" und "ref" in geschrieben werden, wenn sie in Regelaktionen verwendet werden.

Explizit

Der letzte Mechanismus zum Angeben von Feld-/Eigenschaftsabhängigkeiten ist die Verwendung der Update-Anweisung . Die Update-Anweisung verwendet als Argument entweder eine Zeichenfolge, die den Pfad zu einem Feld oder einer Eigenschaft darstellt, oder einen Ausdruck, der einen Feld-/Eigenschaftszugriff darstellt. Beispielsweise kann eine der beiden folgenden Anweisungen in den RuleSet-Editor eingegeben werden, um eine Update-Anweisung für die Name-Eigenschaft eines Customer-instance im Workflow zu erstellen.

Update("this/customer/Name") 

oder

Update(this.customer.Name)

Die Update-Anweisung gibt an, dass die Regel in das angegebene Feld/die angegebene Eigenschaft schreibt. Dies hat die gleiche Auswirkung wie ein direkter Satz des Felds/der Eigenschaft in der Regel oder das Aufrufen einer Methode mit einem RuleWrite-Attribut für das Feld/die Eigenschaft.

Der Befehl Update unterstützt auch die Verwendung von Feldhaltern. Sie können beispielsweise den folgenden Update-Befehl zu einer Regel hinzufügen.

Update("this/customer/*")

Dies würde dazu führen, dass alle Regeln, die eine Eigenschaft für den Kunden instance in ihren Bedingungen verwenden, neu bewertet werden. Mit anderen Worten, jede der beiden folgenden Regeln würde neu bewertet.

IF this.customer.ZipCode == 98052
THEN ...

IF this.customer.CreditScore < 600
THEN ...

Im Allgemeinen wird nicht erwartet, dass Benutzer in den meisten Szenarien explizite Update-Anweisungen modellieren müssen. Die implizite Verkettung sollte die erforderliche Abhängigkeitsanalyse und das Verkettungsverhalten in den meisten Szenarien bereitstellen. Methodenzuweisungen sollten die am häufigsten vorkommenden Szenarien unterstützen, in denen implizite Verkettung die Abhängigkeiten nicht identifizieren kann. Im Allgemeinen wäre das Attributieren von Methoden die bevorzugte Methode zum Angeben von Abhängigkeiten gegenüber der Verwendung der Update-Anweisung , da die Abhängigkeit einmal für die -Methode identifiziert und für viele verschiedene Regeln genutzt werden kann, die diese Methode verwenden. In Szenarien, in denen der Regelschreiber und die Methodenimplementierung unterschiedliche Personen sind (oder die Arbeit zu unterschiedlichen Zeiten ausgeführt wird), ermöglicht das Methodene attributieren dem Methodenschreiber , der den Code am besten kennt, die Abhängigkeiten der Methode zu identifizieren.

Es gibt jedoch einige Szenarien, in denen die Update-Anweisung die geeignete Lösung ist, z. B. wenn ein Feld/eine Eigenschaft an eine Methode für eine Klasse übergeben wird, die der Workflowautor nicht steuert und daher nicht zuordnen kann, wie im folgenden Code der Fall ist.

IF ...
THEN this.customer.UpdateCreditScore(this.currentCreditScore)
     Update(this.currentCreditScore)

Steuerelement für die Vorwärtsverkettung

Forward Chaining ist eine sehr mächtige Idee, die es ermöglicht, atomare Regeln in RuleSets ohne die Definition oder notwendigerweise sogar das Wissen über die Abhängigkeiten zwischen den Regeln zusammenzustellen.

In einigen Szenarien möchte der Regelschreiber jedoch möglicherweise mehr Kontrolle über das Verkettungsverhalten bieten, insbesondere die Möglichkeit, die durchgeführte Verkettung einzuschränken. Dadurch kann der Regelmodellierer:

• Schränken Sie die wiederkehrende Ausführung von Regeln ein, die möglicherweise zu falschen Ergebnissen führt.
• Die Leistung soll gesteigert werden.
• Außer Kontrolle geratene Schleifen sollen verhindert werden.

Diese Steuerungsebene wird in WF-Regeln durch die folgenden beiden Eigenschaften erleichtert:

• Eine Chaining Behavior-Eigenschaft im RuleSet.
• Eine Neubewertungsverhaltenseigenschaft für jede Regel.

Beide dieser Werte können im RuleSet-Editor festgelegt werden.

Verkettungsverhaltenseigenschaft

Die Chaining Behavior-Eigenschaft im RuleSet weist drei mögliche Werte auf:

• Vollständige Verkettung
• Explizite Verkettung
• Sequenziell

Die Option Vollständige Verkettung ist die Standardeinstellung und stellt das bis zu diesem Punkt beschriebene Verhalten bereit. Die Option Explizite Verkettung deaktiviert die implizite und attributbasierte Verkettung und schreibt vor, dass die Verkettung nur für explizite Update-Anweisungen erfolgen soll. Dadurch hat der Regelschreiber die vollständige Kontrolle darüber, welche Regeln eine Neubewertung verursachen. In der Regel wird dies verwendet, um zyklische Abhängigkeiten zu vermeiden, die eine übermäßige (oder sogar auslaufende) Regelreausführung verursachen, oder um die Leistung zu steigern, indem überflüssige Regelrevaluierung beseitigt wird, die nicht erforderlich ist, um die funktionale Vollständigkeit des RuleSet zu gewährleisten.

Die letzte Option ist Sequenziell. Diese Option führt dazu, dass die Engine die Regeln streng linear auswertet. Jede Regel würde einmal und nur einmal und in der Reihenfolge der Priorität ausgewertet. Regeln mit höherer Priorität könnten Sich auf Regeln mit niedrigeren Prioritäten auswirken, aber die Umgekehrtkeit wäre nicht wahr, da keine Verkettung stattfinden würde. Deshalb würde diese Option mit expliziten vorrangigen Zuweisungen verwendet werden, wenn nicht Abhängigkeiten der Regeln untereinander vorhanden wären.

Verhaltenseigenschaft neu auswerten

Das Neubewertungsverhalten für die Regel weist zwei mögliche Werte auf:

• Always
• Never

Always ist der Standardwert und stellt das zuvor beschriebene Verhalten bereit, nämlich dass die Regel immer basierend auf der Verkettung aufgrund der Aktionen anderer Regeln neu ausgewertet wird. Niemals, wie der Name schon sagt, deaktiviert diese Neubewertung. Die Regel wird einmal ausgewertet, aber nicht erneut ausgewertet, wenn sie zuvor Aktionen ausgeführt hat. Anders ausgedrückt: Wenn die Regel zuvor ausgewertet wurde und folglich ihre Then - oder Else-Aktionen ausgeführt hat, wird sie nicht erneut ausgewertet. Die Ausführung einer leeren Aktionsauflistung in den Aktionen Then oder Else markiert eine Regel jedoch nicht als ausgeführt.

In der Regel wird diese Eigenschaft auf Regelebene verwendet, um endlose Schleifen aufgrund von Abhängigkeiten zu verhindern, die die Regel hat, entweder auf ihre eigenen Aktionen oder andere Regeln. Beispielsweise würde die folgende Regel eine eigene Unendlichkeitsschleife erstellen, und eine erneute Bewertung ist nicht erforderlich, um die funktionalen Anforderungen der Regel zu erfüllen.

IF this.shippingCharge < 2.5 AND this.orderValue > 100
THEN this.shippingCharge = 0

Alternativ kann der Benutzer das Verkettungsverhalten im RuleSet so festlegen, dass nur explizite Update-Anweisungen verkettet werden (und diese Update-Anweisungen dann den relevanten Regelaktionen hinzufügen). Natürlich hätte der Benutzer dieser Regel ein zusätzliches Prädikat hinzufügen können, das überprüft, ob der Wert von ShippingCost nicht bereits 0 ist, aber die Verkettungssteuerelemente entfernen die Notwendigkeit, dass Benutzer ihre Regeln basierend auf den Bewertungsdetails definieren müssen, im Gegensatz zu ihren geschäftlichen Anforderungen.

Halt-Funktion

Als endgültiges Steuerelement kann eine Stopp-Funktion als Regelaktion hinzugefügt werden (geben Sie einfach "Anhalten" in die Then- oder Else-Aktionsfelder im Editor ein. Dadurch wird die RuleSet-Ausführung sofort beendet und die Steuerung an den aufrufenden Code zurückgegeben. Die Brauchbarkeit dieser Funktion ist natürlich nicht zwingend auf Verkettungskontrollszenarios beschränkt. Ein RuleSet mit einem bestimmten funktionalen Ziel kann beispielsweise eine Stopp-Funktion verwenden, um die Ausführung zu kurzschließen, sobald das Ziel erreicht wurde.

Zusätzliche Modellierungsdisk

Prioritätsbasierte Ausführung

Wie in einem vorherigen Abschnitt erwähnt, können Benutzer, wenn sie eine bestimmte Ausführungssequenz für das RuleSet oder eine Teilmenge von Regeln in diesem RuleSet wünschen, diese Sequenz mithilfe des Prioritätsfelds für eine Regel genau definieren. Dadurch wird häufig die Anforderung der Verkettung beseitigt, und Benutzer können die Verkettung in diesen Szenarien sogar deaktivieren. Wir haben festgestellt, dass in vielen Fällen Regelabhängigkeiten einfach durch explizite Ausführungssequenzierung erfüllt werden können.

Es ist jedoch wichtig zu beachten, dass der Vorwärtsausführungsmechanismus in WF benutzern die Möglichkeit bietet, eine Ausführungssequenz zu definieren, dies jedoch nicht erfordert. In den meisten Fällen macht das Vorwärtsverkettungsverhalten die Zuweisung von Regelprioritäten überflüssig, um das richtige RuleSet-Ergebnis zu erzielen, da Beziehungen automatisch von der Engine verwaltet werden, um sicherzustellen, dass Regelabhängigkeiten erfüllt werden.

Verwenden Sie die folgenden Regeln.

Regel 1

IF this.Weather.Temperature < 50
THEN this.Drink.Style = "Latte"

Regel 2

IF this.Drink.Style == "Latte"
THEN this.Snack.Style = "Scone"
ELSE this.Snack.Style = "Muffin"

In WF können Sie für Regel 1 eine höhere Priorität angeben, damit sie zuerst ausgeführt wird. Dadurch wird sichergestellt, dass Drink.Style festgelegt wird, bevor Regel 2 ausgewertet wird.

Sequenzierung ist jedoch nicht erforderlich, um die gewünschten Ergebnisse zu erzielen. Angenommen, Regel 2 wurde zuerst ausgewertet. In diesem Fall kann der Drink.Stylenull oder ein anderer Stil sein. Dies würde dazu führen, dass Snack.Style auf Muffin festgelegt wird. Nachdem Regel 1 jedoch ausgeführt und den Drink.Style auf Latte festgelegt hat, wird Regel 2 neu bewertet und der Snack.Style auf Scone festgelegt. Im Wesentlichen hat der Benutzer die Möglichkeit, die Sequenzierung zu diktieren, muss dies jedoch in vielen Fällen nicht tun.

Sammlungsverarbeitung

In einigen Szenarien müssen Sie Regeln möglicherweise für alle Elemente in einer Sammlung einzeln auswerten. Das Durchlaufen der Auflistung kann auf verschiedene Arten erfolgen, aber eine Möglichkeit besteht darin, ein Regelmuster wie die folgende zu verwenden:

Regel 1 (Priorität = 2)

//always execute this rule once to create the enumerator
IF 1==1 
THEN this.enumerator = this.myCollection.GetEnumerator()

Regel 2 (Priorität = 1)

IF this.enumerator.MoveNext()
THEN this.currentInstance = this.enumerator.Current

Regeln 3-N (Priorität = 0)

.... //additional rules written against this.currentInstance

Regel N+1 (Priorität = -1)

// can be any condition as long as it is evaluated every time;
// this.currentInstance will be evaluated each time 
//this.currentInstance changes, whereas 
// "1==1" would only be evaluated once
IF this.currentInstance == this.currentInstance  
                                                                           
THEN ...
         Update("this/enumerator") //this will cause Rule 2 to be reevaluated
ELSE ...
          Update("this/enumerator")

Nachverfolgung und Ablaufverfolgung

Nachverfolgung

Wenn ein RuleSet ausgeführt wird, werden Nachverfolgungsereignisse an Die Nachverfolgungsdienste gesendet, die auf den Hosts konfiguriert sind, die sich für diese Ereignisse registriert haben, indem ihrem Nachverfolgungsprofil ein UserTrackPoint hinzugefügt wird. Es wird ein RuleActionTrackingEvent gesendet, das den Namen der ausgewerteten Regel sowie das Ergebnis der Bedingungsauswertung (true/false) angibt. Ein Beispiel finden Sie im RuleActionTrackingEvent-Beispiel im SDK.

Die Auswertungsergebnisse von Regelbedingungen auf Aktivitäten können implizit durch Verfolgen der Aktivitätsausführung verfolgt werden.

Ablaufverfolgung

Zusätzliche RuleSet-Auswertungsinformationen können an eine Protokolldatei gesendet werden, indem Sie folgendes zu einer Anwendungskonfigurationsdatei hinzufügen.

<configuration>
   <system.diagnostics>
      <switches>
           <add name="Rules" value="Information"/>
      </switches>
   </system.diagnostics>
</configuration>

Die folgenden Informationen werden an die Protokolldatei gesendet:

• Bedingungsabhängigkeitsinformationen:
  • Beispiel: Regel "ReturnNumberOfStops" Bedingungsabhängigkeit: "this/currentFlight/OutboundFlight/NumberOfStops/"
• Nebenwirkungsinformationen für Aktionen:
  • Beispiel: Regel "ReturnNumberOfStops" THEN Nebeneffekt: "this/currentFlight/Score/"
• Verkettungsbeziehung:
  • Beispiel: Regel "ReturnNumberOfStops" THEN-Aktionstriggerregel "ApprovedFlights"
• RuleSet-Ausführung:
  • Beispiel: Regeln: "Executing RuleSet FlightRuleSet"
• Bedingungsauswertung:
  • Beispiel: Regeln: Auswerten der Bedingung für die Regel "SetDefaultScore"
• Ergebnis der Bedingungsauswertung:
  • Beispiel: Regeln: Bedingung wird auf True ausgewertet
• Aktionsausführung:
  • Beispiel: Regeln: Auswertung von THEN-Aktionen für die Regel "SetDefaultScore"

Alle Ablaufverfolgungsmeldungen werden derzeit auf der Ebene "Information" definiert. Daher sollten Sie in Ihrer Konfigurationsdatei eine Ebene von Informationen oder Ausführlich angeben, um die Ablaufverfolgung der Regeln anzuzeigen.

Zusammenfassung

WF bietet eine flexible Regelfunktion, die auf viele verschiedene Arten genutzt werden kann, um eine vielzahl von Szenarien zu unterstützen. Von einfachen Aktivitätsbedingungen bis hin zu anspruchsvollen Vorwärtsketten von RuleSets – die Technologie ermöglicht Es Ihnen, die Regelunterstützung nahtlos in Ihre Workflows zu integrieren. Darüber hinaus kann die Regel-Engine auch außerhalb von Workflows genutzt werden, um Regelfunktionen für jede .NET-Anwendung bereitzustellen.

Der Featuresatz ermöglicht es neuen Entwicklern, einfache Regeln auf einfache Weise in Workflows zu integrieren und gleichzeitig die Fülle und Erweiterbarkeit bereitzustellen, um viel komplexere RuleSets und Anwendungsszenarien zu unterstützen. Dieses Dokument, kombiniert mit den im nächsten Abschnitt genannten Ressourcen, soll Entwicklern, die mit WF Rules vertraut sind, helfen, sich mit der Technologie vertraut zu machen und mit ihrer Verwendung schnell produktiv zu werden.

Weitere Informationen

• MSDN-Workflowwebsite

  Zahlreiche Dokumente und Links zu Webcasts und Labs.

• Beispiele für Communitywebsites

  • External RuleSet Toolkit: Bietet ein Beispiel für das Externalisieren von Regeln aus Workflowassemblys.
  • RuleSet-Analyse– ein Tool zum Analysieren von RuleSets auf Beziehungen zwischen Regeln und zwischen Regeln und Daten.
  • Regeln in Excel– bietet ein Beispiel für die eigenständige Verwendung von Regeln außerhalb eines Workflows. Veranschaulicht außerdem, wie Regeln programmgesteuert erstellt werden, die über eine Entscheidungstabelle in Excel erstellt werden.

• SDK-Beispiele

  • IfElseWithRules– zeigt die Verwendung einer RuleCondition für eine IfElse-Aktivität (unter \Technologies\RulesAndConditions).
  • DynamicUpdateChangingRules– veranschaulicht die Verwendung der DYNAMISCHEn Update-APIs zum Ändern einer RuleCondition in einem ausgeführten Workflow instance (\Technologies\RulesAndConditions).
  • SimplePolicy: Veranschaulicht die Verwendung der APIs zum Definieren einer einfachen RuleSet- und Richtlinienaktivität (\Technologies\Activities\Policy).
  • AdvancedPolicy: Definiert ein komplexeres RuleSet (\Technologies\Activities\Policy).
  • RuleActionTrackingEventSample– zeigt, wie Die Ergebnisse der Regelauswertung in einem Nachverfolgungsanbieter (\Technologies\Tracking) erfasst werden.

• MSDN-Workflowforum

  • Bei Fragen im Zusammenhang mit WF-Regeln oder WF im Allgemeinen besuchen Sie dieses Diskussionsforum.

 

Über den Autor

Jurgen Willis ist Programm-Manager im Windows Workflow Foundation-Team und verantwortlich für Regel-Engine-Technologie und regelgesteuerte Aktivitäten. Vor seinem Eintritt bei Microsoft entwickelte und implementierte Jurgen Integrations- und Prozessmanagementlösungen für Fortune 500-Unternehmen.