Delen via

Optimalisatie voor uitvoering van azure Logic Apps-regelengine (preview)

  • Artikel

Van toepassing op: Azure Logic Apps (Standard)

Belangrijk

Deze mogelijkheid is in preview en is onderworpen aan de aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews.

De Regelengine van Azure Logic Apps biedt de uitvoeringscontext voor een regelset, die u kunt maken met de Microsoft Rules Composer. In deze handleiding worden de belangrijkste concepten uitgelegd over de werking van de regelengine en vindt u optimalisatieaanbevelingen voor bewerkingen en uitvoering.

Kernonderdelen

  • Regelsetuitvoerders

    Met dit onderdeel wordt het algoritme geïmplementeerd dat verantwoordelijk is voor de evaluatie van de regelvoorwaarde en de uitvoering van acties. De standaardregelsetuitvoering is een discriminatienetwerkgebaseerde, doorsturende deductie-engine die is ontworpen om de in-memory bewerking te optimaliseren.

  • Regelsetvertaler

    Dit onderdeel gebruikt een RuleSet-object als invoer en produceert een uitvoerbare weergave van de regelset. De standaardvertaler in het geheugen maakt een gecompileerd discriminatienetwerk op basis van de definitie van de regelset.

  • Interceptor voor het bijhouden van regelset

    Dit onderdeel ontvangt uitvoer van de regelsetuitvoering en stuurt deze uitvoer door naar de hulpprogramma's voor het bijhouden en bewaken van regelset.

Evaluatie van voorwaarden en uitvoering van actie

De Regelengine van Azure Logic Apps is een zeer efficiënte deductie-engine die regels kan koppelen aan .NET-objecten of XML-documenten. De regelengine maakt gebruik van een algoritme met drie fasen voor het uitvoeren van regelset met de volgende fasen:

  • Lucifer

    In de matchfase komt de regelengine met feiten overeen met de predicaten die gebruikmaken van het feitentype, dat objectverwijzingen zijn die worden onderhouden in het werkgeheugen van de regelengine, met behulp van de predicaten die zijn gedefinieerd in de regelvoorwaarden. Voor efficiëntie vindt patroonkoppeling plaats voor alle regels in de regelset en voorwaarden die worden gedeeld tussen regels slechts één keer. de regelengine kan gedeeltelijke voorwaardeovereenkomsten opslaan in het werkgeheugen om volgende patroonkoppelingsbewerkingen te versnellen. De uitvoer van de patroonkoppelingsfase bevat updates voor de agenda van de regelengine.

  • Conflictresolutie

    In de fase conflictoplossing onderzoekt de regelengine regels die kandidaten zijn voor uitvoering om de volgende set regelacties te bepalen die moeten worden uitgevoerd, op basis van een vooraf bepaald oplossingsschema. de regelengine voegt alle kandidaatregels toe die tijdens de overeenkomende fase zijn gevonden aan de agenda van de regelengine.

    Het standaardschema voor conflictoplossing is gebaseerd op regelprioriteiten binnen een regelset. De prioriteit is een regeleigenschap die u kunt configureren in Microsoft Rules Composer. Hoe groter het getal, hoe hoger de prioriteit. Als er meerdere regels worden geactiveerd, voert de regelengine eerst de acties met een hogere prioriteit uit.

  • Actie

    In de actiefase voert de regelengine de acties uit in de opgeloste regel. Regelacties kunnen nieuwe feiten in de regelengine bevestigen, waardoor de cyclus wordt voortgezet en ook wel doorstuurketening wordt genoemd.

    Belangrijk

    Het algoritme preemt nooit de regel die momenteel wordt uitgevoerd. De regelengine voert alle acties uit in de huidige actieve regel voordat de overeenkomstfase wordt herhaald. Andere regels op de agenda van de regelengine worden echter niet uitgevoerd voordat de overeenkomstfase opnieuw begint. De overeenkomstfase kan ertoe leiden dat de regelengine deze regels verwijdert uit de agenda voordat ze ooit worden uitgevoerd.

Opmerking

In het volgende voorbeeld ziet u hoe het algoritme met drie fasen van overeenkomst, conflictoplossing en actie werkt:

Regel 1: Inkomsten evalueren

  • Declaratieve representatie

    Verkrijg de rating van een aanvrager alleen als de verhouding tussen inkomsten en leningen van de aanvrager kleiner is dan 0,2.

  • IF— DAN representatie met behulp van zakelijke objecten

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

Regel 2: Kredietclassificatie evalueren

  • Declaratieve representatie

    Keur een aanvrager alleen goed als de rating van de aanvrager meer dan 725 is.

  • IF— THEN Representation using business objects:

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

De volgende tabel bevat een overzicht van de feiten:

Feit Beschrijving Velden
Toepassing Een XML-document dat een toepassing voor een woninglening vertegenwoordigt. - Inkomen: $ 65.000
- SSN: XXX-XX-XXXX
Eigenschappen Een XML-document dat de eigenschap vertegenwoordigt die moet worden gekocht. - Prijs: $ 225.000
Creditrating Een XML-document met de kredietclassificatie van de aanvrager van de lening. - Waarde: 0-800
- SSN: XXX-XX-XXXX

Updates voor werkgeheugen en agenda

In eerste instantie zijn het werkgeheugen en de agenda van de regelengine leeg. Nadat uw toepassing de feiten over de toepassing en eigenschap heeft toegevoegd, werkt de regelengine het werkgeheugen en de agenda bij, zoals wordt weergegeven:

Werkgeheugen Agenda
-Toepassing
-Eigenschap		 Regel 1

  • De regelengine voegt regel 1 toe aan de agenda, omdat de voorwaarde Application.Income / Property.Price < 0.2, resulteert in waar tijdens de overeenkomstfase.

  • Er bestaat geen CreditRating-feit in het werkgeheugen, dus de voorwaarde voor regel 2 wordt niet geëvalueerd.

  • Regel 1 is de enige regel in de agenda, dus de regel wordt uitgevoerd en verdwijnt vervolgens uit de agenda.

  • Regel 1 definieert één actie die resulteert in een nieuw feit, namelijk het creditratingdocument van de aanvrager dat wordt toegevoegd aan het werkgeheugen.

  • Nadat regel 1 de uitvoering heeft voltooid, keert het besturingselement terug naar de overeenkomstfase.

    Het enige nieuwe object dat moet worden vergeleken, is het creditrating-feit , dus de resultaten van de overeenkomstfase zijn het volgende:

    Werkgeheugen Agenda
    -Toepassing
    -Eigenschap
    - CreditRating    		 Regel 2

  • Regel 2 wordt nu uitgevoerd, waarmee een functie wordt aangeroepen die een goedkeuringsbrief naar de aanvrager verzendt.

  • Nadat regel 2 is voltooid, keert het besturingselement terug naar de overeenkomstfase. Er zijn echter geen nieuwe feiten meer beschikbaar om overeen te komen en de agenda is leeg, dus het doorsturen van ketens wordt beëindigd en de uitvoering van de regelset is voltooid.

Agenda en prioriteit

Als u wilt weten hoe de Azure Logic Apps-regelengine regels evalueert en acties uitvoert, moet u ook meer te weten komen over de concepten van agenda en prioriteit.

Agenda

De agenda van de regelengine is een schema waarmee regels voor uitvoering in de wachtrij worden geplaatst. De agenda bestaat voor een engine-exemplaar en handelt op één regelset, niet op een reeks regelsets. Wanneer aan een feit wordt voldaan en aan de voorwaarden van een regel wordt voldaan, plaatst de engine de regel op de agenda en voert deze regel uit op basis van prioriteit. De engine voert de acties van een regel uit van de hoogste naar de laagste prioriteit en voert vervolgens de acties uit voor de volgende regel op de agenda.

De regelengine behandelt de acties in een regel als een blok, dus alle acties worden uitgevoerd voordat de engine naar de volgende regel gaat. Alle acties in een regelblok worden uitgevoerd, ongeacht andere acties in het blok. Zie Uw regelengine optimaliseren met besturingsfuncties voor meer informatie over assertie.

In het volgende voorbeeld ziet u hoe de agenda werkt:

Regel 1

IF
Fact1 == 1
THEN
Action1
Action2

Regel 2

IF
Fact1 > 0
THEN
Action3
Action4

Wanneer aan het feit 1 , dat een waarde van 1 heeft, in de engine wordt gesteld, voldoen zowel regel 1 als regel 2 aan de voorwaarden. De engine verplaatst dus beide regels naar de agenda om hun acties uit te voeren.

Werkgeheugen Agenda
Feit 1 (waarde=1) Regel 1:
- Actie1
- Actie2

Regel 2:
- Actie3
- Actie4

Prioriteit

Standaard worden alle regels ingesteld op 0 als de prioriteit voor uitvoering. U kunt deze prioriteit echter wijzigen voor elke afzonderlijke regel. De prioriteit kan variëren tot beide zijden van 0, met grotere getallen met een hogere prioriteit. De engine voert acties uit van de hoogste prioriteit tot de laagste prioriteit.

In het volgende voorbeeld ziet u hoe prioriteit van invloed is op de uitvoering van de volgorde voor regels:

Regel 1 (prioriteit = 0)

IF
Fact1 == 1
THEN
Discount = 10%

Regel 2 (prioriteit = 10)

IF
Fact1 > 0
THEN
Discount = 15%

Hoewel aan de voorwaarden voor beide regels wordt voldaan, wordt regel 2 eerst uitgevoerd vanwege de hogere prioriteit. De uiteindelijke korting is 10 procent vanwege het resultaat van de actie die wordt uitgevoerd voor regel 1, zoals wordt weergegeven in de volgende tabel:

Werkgeheugen Agenda
Feit1 (waarde=1) Regel 2:
Korting: 15%

Regel 1:
Korting: 10%

Bijwerkingen van actie

Als de uitvoering van een actie van invloed is op de status van een object of een term die in voorwaarden wordt gebruikt, wordt gezegd dat deze actie een 'neveneffect' heeft op dat object of die term. Deze woordgroep betekent niet dat de actie bijwerkingen heeft, maar dat het object of de term mogelijk wordt beïnvloed door een of meer acties.

Stel dat u de volgende regels hebt:

Regel 1

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

Regel 2

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

In dit voorbeeld heeft OrderForm.UpdateStatus een 'neveneffect' op OrderForm.Status, wat betekent dat OrderForm.Status mogelijk wordt beïnvloed door een of meer acties.

De eigenschap SideEffects voor .NET-klasseleden is ingesteld op true als de standaardwaarde, waardoor de regelengine een lid met bijwerkingen in de cache kan opslaan. In dit voorbeeld slaat de regelengine OrderForm.Status niet in het werkgeheugen op in de cache. In plaats daarvan krijgt de engine de meest recente waarde van OrderForm.Status telkens wanneer de engine regel 1 evalueert. Als de eigenschap SideEffects onwaar is, slaat de regelengine de waarde in de cache op wanneer de engine OrderForm.Status voor de eerste keer evalueert. Voor latere evaluaties in scenario's voor het doorsturen van ketens gebruikt de engine echter de waarde in de cache.

Microsoft Rules Composer biedt momenteel geen manier om de eigenschap SideEffects te wijzigen. U kunt de eigenschapswaarde SideEffects echter programmatisch instellen via het Framework voor bedrijfsregels, een Microsoft. Net-compatibele klassebibliotheek. U stelt deze waarde in bij binding met behulp van de klasse ClassMemberBinding om objectmethoden, eigenschappen en velden op te geven die worden gebruikt in regelvoorwaarden en acties. De klasse ClassMemberBinding heeft een eigenschap SideEffects, die een Booleaanse waarde bevat die aangeeft of de waarde van het lid wordt gewijzigd.

Prestatieoverwegingen

In deze sectie wordt beschreven hoe de Regelengine van Azure Logic Apps in verschillende scenario's en met verschillende waarden voor configuratie- en afstemmingsparameters wordt uitgevoerd.

Feitentypen

De regelengine heeft minder tijd nodig om toegang te krijgen tot .NET-feiten dan toegang te krijgen tot XML-feiten. Als u een keuze hebt tussen het gebruik van .NET-feiten of XML-feiten in een regelset, kunt u overwegen .NET-feiten te gebruiken voor betere prestaties.

Regelprioriteit

De prioriteitsinstelling voor een regel kan variëren tot aan beide zijden van 0 , met grotere getallen met een hogere prioriteit. Acties worden uitgevoerd om te beginnen van de hoogste prioriteit tot de laagste prioriteit. Wanneer de regelset het gedrag van doorstuurketening implementeert met behulp van Assert- of Update-aanroepen, kunt u ketening optimaliseren met behulp van de eigenschap Priority.

Stel dat regel 2 een afhankelijkheid heeft van een waarde die is ingesteld door regel 1. Als regel 1 een hogere prioriteit heeft, wordt regel 2 alleen uitgevoerd nadat regel 1 wordt geactiveerd en de waarde wordt bijgewerkt. Als regel 2 daarentegen een hogere prioriteit heeft, kan de regel eenmaal worden geactiveerd en vervolgens opnieuw worden geactiveerd nadat regel 1 is geactiveerd en het feit wordt bijgewerkt in de voorwaarde voor regel 2. In dit scenario worden de juiste resultaten wel of niet geproduceerd, maar het schieten heeft twee keer invloed op prestaties en slechts één keer.

Zie Regels maken met Behulp van Microsoft Rules Composer voor meer informatie.

Logische OF-operators

De regelengine is geoptimaliseerd voor het uitvoeren van logische AND-operators en reconstrueert de regel die de engine parseert in een disjunctive normale vorm, zodat de logische OF-operator alleen op het hoogste niveau wordt gebruikt.

Als u meer logische OF-operators in voorwaarden gebruikt, maakt de toename meer permutaties die het analysenetwerk van de regelengine uitbreiden. Als gevolg hiervan kan het lang duren voordat de regel wordt genormaliseerd door de regelengine.

De volgende lijst bevat mogelijke tijdelijke oplossingen voor dit probleem:

  • Wijzig de regel in een disjunctive normale vorm, zodat de OPERATOR OR zich alleen op het hoogste niveau bevindt.

    Overweeg de regel programmatisch te maken, omdat u misschien merkt dat het bouwen van een regel in disjunctive normale vorm in de Microsoft Rules Composer lastig kan zijn.

  • Ontwikkel een helperonderdeel dat de OR-bewerkingen uitvoert en retourneert een Booleaanse waarde en gebruik vervolgens het onderdeel in de regel.

  • Splits de regel op in meerdere regels en laat de regels controleren op een vlag die is ingesteld door een eerder uitgevoerde regel, of gebruik een object dat een eerder uitgevoerde regel heeft, bijvoorbeeld:

    • 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 …

Aanroepen bijwerken

De functie Update werkt een feit bij dat bestaat in het werkgeheugen van de regelengine, wat herwaardering veroorzaakt voor alle regels die gebruikmaken van het bijgewerkte feit in voorwaarden. Dit gedrag betekent dat functieaanroepen bijwerken duur kunnen zijn, met name als veel regels herwaardering vereisen vanwege bijgewerkte feiten. In sommige situaties kunt u voorkomen dat u de regels opnieuw moet evalueren.

Denk bijvoorbeeld aan de volgende regels:

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 resterende regels in de regelset gebruiken StatusObj.Flag in hun voorwaarden. Wanneer u de functie Update aanroept op het Object StatusObj , worden alle regels opnieuw geëvalueerd. Wat de waarde ook is in het veld Bedrag , alle regels behalve regel 1 en regel 2 worden tweemaal geëvalueerd: eenmaal vóór de aanroep Update en eenmaal na de aanroep Update .

In plaats daarvan kunt u de waarde Vlag instellen op onwaar voordat u de regelset aanroept en vervolgens alleen regel 1 in de regelset gebruiken om de vlag in te stellen. In dit geval wordt de functie Update alleen aangeroepen als de waarde Amount groter is dan 5. De functie Update wordt niet aangeroepen als het bedrag kleiner is dan of gelijk is aan 5. Op deze manier worden alle regels behalve regel 1 en regel 2 twee keer geëvalueerd als de waarde Bedrag groter is dan 5.

Eigenschapsgedrag SideEffects

In de klassen XmlDocumentFieldBinding en ClassMemberBinding bepaalt de eigenschap SideEffects of de waarde van het afhankelijke veld, lid of kolom in de cache moet worden opgeslagen.

In de klasse XmlDocumentFieldBinding is de standaardwaarde van de eigenschap SideEffects onwaar. In de klasse ClassMemberBinding is de standaardwaarde van de eigenschap SideEffects echter waar.

Dus als de engine voor de tweede keer of later in de regelset toegang heeft tot een veld in een XML-document, haalt de engine de waarde van het veld op uit de cache. Als de engine echter voor de tweede keer of later in de regelset toegang heeft tot een lid van een .NET-object, haalt de engine de waarde op uit het .NET-object, niet uit de cache.

Dit gedrag betekent dat als u de eigenschap SideEffects in een .NET ClassMemberBinding instelt op false, de prestaties kunt verbeteren omdat de engine de waarde van het lid ophaalt uit de cache die begint met de tweede keer en hoger. U kunt de eigenschapswaarde echter alleen programmatisch instellen omdat de eigenschap Microsoft Rules Composer de eigenschap SideEffects niet beschikbaar maakt.

Exemplaren en selectiviteit

De klassen XmlDocumentBinding en ClassBinding hebben elk de volgende eigenschappen, die de regelengine gebruikt om de voorwaardeevaluatie te optimaliseren. Met deze eigenschapswaarden kan de engine eerst de kleinste mogelijke exemplaren gebruiken in voorwaardeevaluaties en vervolgens de resterende exemplaren gebruiken.

  • Exemplaren: het verwachte aantal klasse-exemplaren in het werkgeheugen.

    Als u het aantal objectexemplaren van tevoren weet, kunt u de eigenschap Exemplaren instellen op dit nummer om de prestaties te verbeteren.

  • Selectiviteit: het percentage klasse-exemplaren dat de regelvoorwaarden heeft doorstaan.

    Als u het percentage objectexemplaren weet dat vooraf aan de voorwaarden wordt doorgegeven, kunt u de eigenschap Selectiviteit instellen op dit percentage om de prestaties te verbeteren.

U kunt deze eigenschapswaarden alleen programmatisch instellen omdat deze niet beschikbaar worden gemaakt door Microsoft Rules Composer.

Ondersteuning voor overname van klassen

Overname is de mogelijkheid om alle functionaliteit van een bestaande klasse te gebruiken en deze mogelijkheden uit te breiden zonder de oorspronkelijke klasse te herschrijven, wat een belangrijke functie is in OOP-talen (Object Oriented Programming).

De Azure Logic Apps-regelengine ondersteunt de volgende soorten overname van klassen:

  • Overname van implementatie: de mogelijkheid om de eigenschappen en methoden van een basisklasse te gebruiken zonder andere codering.

  • Overname van interface: de mogelijkheid om alleen eigenschapsnamen en methodenamen te gebruiken, maar de onderliggende klasse moet de implementatie bieden.

Met de regelengine kunt u regels schrijven in termen van een gemeenschappelijke basisklasse, maar de objecten die in de regelengine zijn opgenomen, kunnen afkomstig zijn van afgeleide klassen.

Het volgende voorbeeld heeft een basisklasse met de naam Werknemer, terwijl de afgeleide klassen RegularEmployee en ContractEmployee worden genoemd:

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

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

In dit voorbeeld wordt ervan uitgegaan dat u de volgende regels hebt:

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())

Na de verklaring evalueert de engine alle regels die het type Werknemer of het type ContractEmployee in hun voorwaarden bevatten. Hoewel alleen de afgeleide klasse wordt asserteerd, wordt de basisklasse ook assertieed als regels worden geschreven met behulp van methoden in de basisklasse, in plaats van in de afgeleide klasse.

Gerelateerde inhoud