Optimierung der Ausführung des Azure Logic Apps Rules Engine (Vorschau)

Gilt für: Azure Logic Apps (Standard)

Das Azure Logic Apps Rules Engine stellt den Ausführungskontext für einen Regelsatz bereit, das Sie mit dem Microsoft Rules Composer erstellen können. In diesem Leitfaden werden die Kernkonzepte für die Funktionsweise des Regelmoduls erläutert und Optimierungsempfehlungen für Vorgänge und Ausführung bereitgestellt.

Kernkomponenten

• Regelsatz-Executor

  Diese Komponente implementiert den Algorithmus, der für die Auswertung der Regelbedingung und das Ausführen der Aktion verantwortlich ist. Der Standardregelsatz-Executor ist ein entscheidungsnetzwerkbasiertes Rückschlussmodul mit Vorwärtsverkettung zur Optimierung von Vorgängen im Arbeitsspeicher.

• Regelsatzkonvertierer

  Diese Komponente verwendet ein RuleSet-Objekt als Eingabe und erzeugt eine ausführbare Darstellung des Regelsatzes. Der Standardkonvertierer im Arbeitsspeicher erstellt ein kompiliertes Entscheidungsnetzwerk aus der Regelsatzdefinition.

• Regelsatz-Überwachungsinterceptor

  Diese Komponente empfängt die Ausgabe des Regelsatzausführers und leitet diese an Regelsatzverfolgungs- und Überwachungstools weiter.

Auswerten von Bedingungen und Ausführen von Aktionen

Das Azure Logic Apps Rules Engine ist ein hocheffizientes Ableitungsmodul, das Regeln mit .NET-Objekten oder XML-Dokumenten verknüpfen kann. Das Regelmodul verwendet einen dreistufigen Algorithmus für die Ausführung von Regeln mit den folgenden Phasen:

• Übereinstimmung

  In der Übereinstimmungsphase gleicht das Regelmodul Fakten mit den Prädikaten ab, die den Faktentyp verwenden, bei dem es sich um Objektverweise handelt, die im Arbeitsspeicher des Regelmoduls verwaltet werden, indem die in den Regelbedingungen definierten Prädikate verwendet werden. Aus Effizienzgründen erfolgt der Musterabgleich für alle Regeln im Regelsatz, und Bedingungen, die als regelübergreifend freigegeben werden, werden nur einmal abgeglichen. Das Regelmodul speichert möglicherweise partielle Bedingungsvergleiche im Arbeitsspeicher, um nachfolgende Musterabgleichsvorgänge zu beschleunigen. Die Ausgabe aus der Musterabgleichsphase enthält Aktualisierungen der Agenda des Regelmoduls.

• Konfliktlösung

  In der Konfliktlösungsphase untersucht das Regelmodul Regeln, die für die Ausführung geeignet sind, um die nächste auszuführende Regelaktionen zu bestimmen, basierend auf einem vordefinierten Lösungsschema. das Regelmodul fügt alle Kandidatenregeln hinzu, die während der Abgleichsphase zur Agenda des Regelmoduls gefunden wurden.

  Das standardmäßige Konfliktlösungsschema basiert auf den Regelprioritäten in eines Regelsatzes. Die Priorität ist eine Regeleigenschaft, die Sie im Microsoft Rules Composer konfigurieren können. Je größer die Zahl ist, desto höher ist die Priorität. Wenn mehrere Regeln ausgelöst werden, führt das Regelmodul zuerst die Aktionen mit höherer Priorität aus.

• Aktion

  In der Aktionsphase führt das Regelmodul die Aktionen in der aufgelösten Regel aus. Regelaktionen können neue Fakten im Regelmodul geltend machen, was dazu führt, dass der Zyklus fortgesetzt wird und auch als Vorwärtsverkettung bezeichnet wird.

  Wichtig

  Der Algorithmus kommt niemals der derzeit ausgeführten Regel zuvor. Das Regelmodul führt alle Aktionen in der derzeit ausgeführten Regel aus, bevor die Übereinstimmungsphase wiederholt wird. Andere Regeln für die Agenda des Regelmoduls werden jedoch nicht ausgeführt, bevor die Übereinstimmungsphase erneut beginnt. Die Übereinstimmungsphase kann dazu führen, dass das Regelmodul diese Regeln aus der Agenda entfernt, bevor sie jemals ausgeführt werden.

Beispiel

Das folgende Beispiel zeigt, wie der dreistufige Algorithmus für Übereinstimmung, Konfliktauflösung und Aktion funktioniert:

Regel 1: Auswerten des Einkommens

• Deklarative Darstellung

  Holen Sie die Bonität des Antragstellers nur ein, wenn das Verhältnis von Einkünften zu Krediten des Antragstellers kleiner als 0,2 ist.

• IF—THEN-Darstellung unter Verwendung von Geschäftsobjekten

  IF Application.Income / Property.Price < 0.2
  THEN Assert new CreditRating( Application)
  

Regel 2: Bewerten der Bonität

• Deklarative Darstellung

  Lassen Sie einen Antragsteller nur zu, wenn der Score des Antragstellers mehr als 725 beträgt.

• IF—THEN-Darstellung unter Verwendung von Geschäftsobjekten:

  IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725
  THEN SendApprovalLetter(Application)
  

Die Fakten sind in der folgenden Tabelle zusammengefasst:

Aktualisierungen des Arbeitsspeichers und der Agenda

Zunächst sind der Arbeitsspeicher und die Agenda dem Regelmodul leer. Nachdem Ihre Anwendung die Fakten zu Anwendung und Eigenschaft hinzugefügt hat, aktualisiert das Regelmodul den Arbeitsspeicher und die Agenda wie dargestellt:

• Das Regelmodul fügt Regel 1 zu ihrer Agenda hinzu, da die Bedingung Application.Income / Property.Price < 0.2 während der Übereinstimmungsphase zu true ausgewertet wird.

• Im Arbeitsspeicher ist keine CreditRating-Tatsache vorhanden, daher wird die Bedingung für Regel 2 nicht ausgewertet.

• Regel 1 ist die einzige Regel in der Agenda, sodass die Regel ausgeführt wird und dann von der Agenda verschwindet.

• Regel 1 definiert eine einzelne Aktion, die zu einer neuen Tatsache führt, was das CreditRating-Dokument des Antragstellers ist, das dem Arbeitsspeicher hinzugefügt wird.

• Nach Abschluss der Ausführung von Regel 1 kehrt das Steuerelement zur Übereinstimmungsphase zurück.

  Das einzige zuzuordnende Objekt ist der CreditRating-Fakt, sodass die Ergebnisse der Übereinstimmungsphase folgendes sind:

  Arbeitsspeicher	Agenda
  - Anwendung - Grundstück - CreditRating	Regel 2

• Regel 2 wird jetzt ausgeführt, die eine Funktion aufruft, die ein Genehmigungsschreiben an den Antragsteller sendet.

• Nach Abschluss von Regel 2 kehrt das Steuerelement zur Übereinstimmungsphase zurück. Es stehen jedoch keine neuen Fakten zur Verfügung und die Agenda ist leer, sodass die Vorwärtsverkettung beendet wird und die Regelsatzausführung abgeschlossen ist.

Agenda und Priorität

Um zu verstehen, wie das Azure Logic Apps Rules Engine Regeln auswertet und Aktionen ausführt, müssen Sie auch mehr über die Konzepte Agenda und Priorität erfahren.

Agenda

Die Agenda des Regelmoduls ist ein Zeitplan, in dem Regeln für die Ausführung in die Warteschlange gestellt werden. Die Agenda ist für eine Modulinstanz vorhanden und wirkt sich auf einen einzelnen Regelsatz, nicht auf eine Reihe von Regelsätzen aus. Wenn ein Fakt im Arbeitsspeicher bestätigt wird und die Bedingungen einer Regel erfüllt sind, platziert das Modul die Regel auf der Agenda und führt diese Regel basierend auf der Priorität aus. Das Modul führt die Aktionen einer Regel von oben nach unten aus und führt dann die Aktionen für die nächste Regel auf der Agenda aus.

Das Regelmodul behandelt die Aktionen in einer Regel als Block, sodass alle Aktionen ausgeführt werden, bevor das Modul zur nächsten Regel wechselt. Alle Aktionen in einem Regelblock werden unabhängig von anderen Aktionen im Block ausgeführt. Weitere Informationen zur Assertion finden Sie unter Optimieren des Regelmoduls mit Steuerfunktionen .

Das folgende Beispiel zeigt, wie die Agenda funktioniert:

Regel 1

IF
Fact1 == 1
THEN
Action1
Action2

Regel 2

IF
Fact1 > 0
THEN
Action3
Action4

Wenn Fakt 1, der einen Wert von 1 hat, in das Modul bestätigt wird, haben sowohl Regel 1 als auch Regel 2 ihre Bedingungen erfüllt. Das Modul verschiebt also beide Regeln auf die Agenda, um ihre Aktionen auszuführen.

Priorität

Standardmäßig werden alle Regeln als Priorität für die Ausführung auf 0 festgelegt. Sie können diese Priorität jedoch für jede einzelne Regel ändern. Die Priorität kann weniger oder mehr als 0 betragen, wobei höhere Werte eine höhere Priorität kennzeichnen. Das Modul führt Aktionen von der höchsten Priorität bis zur niedrigsten Priorität aus.

Das folgende Beispiel verdeutlicht, wie sich die Priorität auf die Ausführungsreihenfolge für Regeln auswirkt:

Regel 1 (Priorität = 0)

IF
Fact1 == 1
THEN
Discount = 10%

Regel 2 (Priorität = 10)

IF
Fact1 > 0
THEN
Discount = 15%

Obwohl die Bedingungen für beide Regeln erfüllt sind, wird Regel 2 aufgrund ihrer höheren Priorität zuerst ausgeführt. Der endgültige Rabatt beträgt 10 Prozent aufgrund des Ergebnisses der für Regel 1 ausgeführten Aktion, wie in der folgenden Tabelle dargestellt:

Nebenwirkungen der Aktion

Wenn sich die Ausführung einer Aktion auf den Zustand eines Objekts oder einen Ausdruck auswirkt, der unter Bedingungen verwendet wird, wird diese Aktion als „Nebeneffekt“ für dieses Objekt oder diesen Ausdruck bezeichnet. Dieser Ausdruck bedeutet nicht, dass die Aktion Nebenwirkungen hat, sondern dass das Objekt oder der Ausdruck potenziell von einer oder mehreren Aktionen betroffen ist.

Gehen wir beispielsweise von folgender Regel aus:

Regel 1

IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"

Regel 2

IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")

In diesem Beispiel hat OrderForm.UpdateStatus einen „Nebeneffekt“ für OrderForm.Status, was bedeutet, dass OrderForm.Status potenziell von einer oder mehreren Aktionen betroffen ist.

Die SideEffects-Eigenschaft für .NET-Klassenmember wird als Standardwert auf true festgelegt, wodurch verhindert wird, dass das Regelmodul ein Element mit Nebenwirkungen zwischenspeichert. In diesem Beispiel speichert das Regelmodul OrderForm.Status im Arbeitsspeicher nicht zwischen. Stattdessen ruft das Modul den neuesten Wert von OrderForm.Status jedes Mal ab, wenn das Modul Regel 1 auswertet. Wenn der Wert der SideEffects-Eigenschaft falseist, speichert das Regelmodul den Wert zwischen, wenn das Modul OrderForm.Status zum ersten Mal auswertet. Bei späteren Auswertungen in Vorwärtsverkettungsszenarien verwendet das Modul jedoch den zwischengespeicherten Wert.

Der Microsoft Rules Composer bietet derzeit keine Möglichkeit zum Ändern des SideEffects-Eigenschaftswerts. Sie können den Wert der SideEffects-Eigenschaft jedoch programmgesteuert über das Business Rules Framework, bei dem es sich um eine Microsoft .NET-kompatible Klassenbibliothek handelt, festlegen. Sie legen diesen Wert bei der Bindung fest, indem Sie die ClassMemberBinding-Klasse verwenden, um Objektmethoden, Eigenschaften und Felder anzugeben, die in Regelbedingungen und Aktionen verwendet werden. Die ClassMemberBinding-Klasse verfügt über eine Eigenschaft mit dem Namen SideEffects, die einen booleschen Wert enthält, der angibt, ob der Zugriff auf das Element seinen Wert ändert.

Überlegungen zur Leistung

In diesem Abschnitt wird erläutert, wie das Azure Logic Apps Rules Engine in verschiedenen Szenarien und mit unterschiedlichen Werten für Konfigurations- und Optimierungsparameter ausgeführt wird.

Faktentypen

Das Regelmodul benötigt weniger Zeit, um auf .NET-Fakten als auf XML-Fakten zuzugreifen. Wenn Sie eine Wahl zwischen .NET-Fakten oder XML-Fakten in einem Regelsatz haben, sollten Sie .NET-Fakten verwenden, um eine bessere Leistung zu erzielen.

Regelpriorität

Die Prioritätseinstellung für eine Regel kann weniger oder mehr als 0 betragen, wobei höhere Werte eine höhere Priorität kennzeichnen. Aktionen werden in der Reihenfolge ausgeführt, die von der höchsten Priorität bis zur niedrigsten Priorität beginnen. Wenn der Regelsatz das Verhalten der Vorwärtsverkettung mithilfe von Assert- oder Update-Aufrufen implementiert, können Sie die Verkettung mithilfe der Eigenschaft Priorität optimieren.

Angenommen, Regel 2 hat eine Abhängigkeit von einem Wert, der von Regel 1 festgelegt wird. Wenn Regel 1 eine höhere Priorität hat, wird Regel 2 nur ausgeführt, nachdem Regel 1 ausgelöst und der Wert aktualisiert wurde. Wenn Regel 2 dagegen eine höhere Priorität hat, kann die Regel einmal ausgelöst, und dann erneut ausgelöst werden, nachdem Regel 1 ausgelöst und der Fakt in der Bedingung für Regel 2 aktualisiert wurde. Dieses Szenario kann möglicherweise zu den richtigen Ergebnissen führen, aber das zweimalige Auslösen hat Auswirkungen auf die Leistung im Gegensatz zum einmaligen Auslösen.

Weitere Informationen finden Sie unter Erstellen von Regeln mithilfe von Microsoft Rules Composer.

Logische OR-Operatoren

Das Regelmodul ist für die Ausführung logischer UND-Operatoren optimiert und rekonstruiert die Regel, die das Modul in eine disjunktive Normalform untergliedert, sodass der logische ODER-Operator nur auf oberster Ebene verwendet wird.

Wenn Sie mehr logische ODER-Operatoren in Bedingungen verwenden, erzeugt die Erhöhung mehr Permutationen, die das Analysenetzwerk des Regelmoduls erweitern. Daher kann das Regelmodul eine lange Zeit in Anspruch nehmen, um die Regel zu normalisieren.

Die folgende Liste enthält mögliche Problemumgehungen für dieses Problem:

• Ändern Sie die Regel in eine disjunktive Normalform, sodass sich der ODER-Operator nur auf der obersten Ebene befindet.

  Erwägen Sie die programmgesteuerte Erstellung der Regel, da Sie feststellen können, dass das Erstellen einer Regel in disjunktiver Normalform im Microsoft Rules Composer schwierig sein kann.

• Entwickeln Sie eine Hilfskomponente, welche die ODER-Vorgänge ausführt und einen Wahrheitswert zurückgibt. Verwenden Sie die Komponente dann in der Regel.

• Teilen Sie die Regel in mehrere Regeln auf, und lassen Sie die Regel auf ein Flag überprüfen, das von einer zuvor ausgeführten Regel festgelegt wurde, oder verwenden Sie ein Objekt, das von einer zuvor ausgeführten Regel bestätigt wurde, z. B.:

  • Regel 1: IF (a == 1 OR a == 3) THEN b = true

    Regel 2: IF (b == true) THEN …

  • Regel 1: IF (a == 1 OR a == 3) THEN Assert(new c())

    Regel 2: IF (c.flag == true) THEN …

Update-Aufrufe

Die Update-Funktion aktualisiert eine Tatsache, die im Arbeitsspeicher des Regelmoduls vorhanden ist, was zu einer erneuten Bewertung aller Regeln führt, welche die aktualisierte Tatsache in Bedingungen verwenden. Dieses Verhalten bedeutet, dass Aktualisierungsfunktionsaufrufe teuer sein können, insbesondere, wenn viele Regeln aufgrund aktualisierter Fakten eine erneute Auswertung erfordern. In einigen Fällen können Sie vermeiden, die Regeln neu auszuwerten.

Betrachten Sie z. B. folgende Regeln:

Regel 1

IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)

Regel 2

IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)

Alle übrigen Regeln im Regelsatz verwenden StatusObj.Flag in ihren Bedingungen. Wenn Sie die Update-Funktion für das StatusObj--Objekt aufrufen, werden alle Regeln neu ausgewertet. Unabhängig vom Wert im Feld Betrag werden alle Regeln außer Regel 1 und Regel 2 zweimal ausgewertet: Einmal vor dem Update-Aufruf und einmal nach dem Update-Aufruf.

Stattdessen können Sie den Flag-Wert auf false festlegen, bevor Sie den Regelsatz aufrufen. Verwenden Sie dann nur Regel 1 im Regelsatz, um das Flag festzulegen. In diesem Fall wird die Funktion Update nur aufgerufen, wenn der Wert größer als 5 ist. Die Update-Funktion wird nicht aufgerufen, wenn der Wert kleiner oder gleich 5 ist. Auf diese Weise werden alle Regeln außer Regel 1 und Regel 2 zweimal ausgewertet, wenn der Wert größer als 5 ist.

Verhalten der SideEffects-Eigenschaft

In den Klassen XmlDocumentFieldBinding und ClassMemberBinding bestimmt die SideEffects-Eigenschaft, ob der Wert des gebundenen Felds, Elements oder der Spalte zwischengespeichert werden soll.

In der XmlDocumentFieldBinding-Klasse ist der Standardwert der SideEffects-Eigenschaft "false". In der ClassMemberBinding-Klasse ist der Standardwert der SideEffects-Eigenschaft jedoch true.

Wenn das Modul also zum zweiten Mal oder zu einem späteren Zeitpunkt innerhalb des Regelsatzes auf ein Feld in einem XML-Dokument zugreift, ruft das Modul den Wert des Felds aus dem Cache ab. Wenn das Modul jedoch zum zweiten oder späteren Zeitpunkt innerhalb des Regelsatzes auf ein Element eines .NET-Objekts zugreift, ruft das Modul den Wert aus dem .NET-Objekt ab, nicht aus dem Cache.

Dieses Verhalten bedeutet: Wenn Sie die SideEffects-Eigenschaft in einer .NET ClassMemberBinding auf false festlegen, können Sie die Leistung verbessern, da das Modul den Wert des Elements ab dem zweiten Mal aus dem Cache abruft. Sie können den Eigenschaftswert jedoch nur programmgesteuert festlegen, da der Microsoft Rules Composer die SideEffects-Eigenschaft nicht verfügbar macht.

Instanzen und Selektivität

Die Klassen XmlDocumentBinding und ClassBinding weisen jeweils die folgenden Eigenschaften auf, die vom Regelmodul zur Optimierung der Bedingungsauswertung verwendet werden. Diese Eigenschaftswerte ermöglichen es dem Modul, die wenigen möglichen Instanzen zuerst in Bedingungsauswertungen zu verwenden und dann die verbleibenden Instanzen zu verwenden.

• Instanzen: Die erwartete Anzahl von Klasseninstanzen im Arbeitsspeicher.

  Wenn Sie die Anzahl der Objektinstanzen vorher kennen, können Sie die Instanzen-Eigenschaft auf diese Zahl festlegen, um die Leistung zu verbessern.

• Selektivität: Der Prozentsatz der Klasseninstanzen, welche die Regelbedingungen erfolgreich übergeben.

  Wenn Sie den Prozentsatz der Objektinstanzen kennen, welche die Bedingungen vorher übergeben, können Sie die Eigenschaft Selektivität auf diesen Prozentsatz festlegen, um die Leistung zu verbessern.

Sie können diese Eigenschaftswerte nur programmgesteuert festlegen, da der Microsoft Rules Composer sie nicht verfügbar macht.

Unterstützung für die Klassenvererbung

Vererbung ist die Möglichkeit, alle Funktionen einer vorhandenen Klasse zu verwenden und diese Funktionen zu erweitern, ohne die ursprüngliche Klasse neu zu schreiben. Dies ist ein wichtiges Feature in OOP-Sprachen (Object Oriented Programming).

Das Azure Logic Apps Rules Engine unterstützt die folgenden Arten der Klassenvererbung:

• Implementierungsvererbung: Die Funktion, die Eigenschaften und Methoden einer Basisklasse ohne andere Codierung zu verwenden.

• Schnittstellenvererbung: Die Funktion, nur Eigenschaftennamen und Methodennamen zu verwenden, aber die untergeordnete Klasse muss die Implementierung bereitstellen.

Mit dem Regelmodul können Sie Regeln in Bezug auf eine allgemeine Basisklasse schreiben, aber die im Regelmodul bestätigten Objekte können aus abgeleiteten Klassen stammen.

Das folgende Beispiel verfügt über eine Basisklasse namens Employee, während die abgeleiteten Klassen RegularEmployee und ContractEmployee benannt werden:

class Employee
{
    public string Status()
    {
        // member definition
    }
    public string TimeInMonths()
    {
        // member definition
    }
}

class ContractEmployee : Employee
{
   // class definition
}
class RegularEmployee : Employee
{
   // class definition
}

Gehen Sie in diesem Beispiel davon aus, dass Sie über die folgenden Regeln verfügen:

Regel 1

IF Employee.TimeInMonths < 12
THEN Employee.Status = "New"

At run time, if you assert two objects, a **ContractEmployee** instance and a **RegularEmployee** instance, the engine evaluates both objects against the Rule 1.

You can also assert derived class objects in actions by using an **Assert** function. This function causes the engine to reevaluate rules that contain the derived object and the base type in their conditions as shown in the following example, which demonstrates implementation inheritance:

**Rule 2**

```text
IF Employee.Status = "Contract"
THEN Employee.Bonus = false
Assert(new ContractEmployee())

Nach der Assertion überprüft das Modul alle Regeln, die den Typ Employee oder den ContractEmployee in ihren Bedingungen enthalten. Obwohl nur die abgeleitete Klasse bestätigt wird, wird die Basisklasse auch dann bestätigt, wenn Regeln mithilfe von Methoden in der Basisklasse und nicht in der abgeleiteten Klasse geschrieben werden.

Zugehöriger Inhalt

• Was ist das Azure Logic Apps Rules Engine?
• Erstellen von Regeln mit Microsoft Rules Composer
• Erstellen eines Azure Logic Apps-Regel-Engine-Projekts