Optimering för körning av Azure Logic Apps-regelmotor (förhandsversion)
Gäller för: Azure Logic Apps (Standard)
Viktigt!
Den här funktionen är i förhandsversion och omfattas av kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.
Azure Logic Apps Rules Engine tillhandahåller körningskontexten för en regeluppsättning som du kan skapa med Microsoft Rules Composer. Den här guiden beskriver huvudbegreppen kring hur regelmotorn fungerar och ger optimeringsrekommendationer för åtgärder och körning.
Kärnkomponenter
Regeluppsättningsexekutor
Den här komponenten implementerar algoritmen som ansvarar för utvärdering av regelvillkor och åtgärdskörning. Standardexekutor för regeluppsättningar är en nätverksbaserad, framåtlänkningsmotor som är utformad för att optimera minnesintern drift.
Regeluppsättningsöversättare
Den här komponenten tar ett RuleSet-objekt som indata och skapar en körbar representation av regeluppsättningen. Standardöversättaren i minnet skapar ett kompilerat diskrimineringsnätverk från regeluppsättningsdefinitionen.
Regeluppsättningsspårningsavlyssnare
Den här komponenten tar emot utdata från regeluppsättningens exekutor och vidarebefordrar utdata till regeluppsättningens spårnings- och övervakningsverktyg.
Villkorsutvärdering och åtgärdskörning
Regelmotorn för Azure Logic Apps är en mycket effektiv slutsatsdragningsmotor som kan länka regler till .NET-objekt eller XML-dokument. Regelmotorn använder en trestegsalgoritm för regeluppsättningskörning med följande steg:
Tändsticka
I matchningssteget matchar regelmotorn fakta mot predikaten som använder faktatypen, som är objektreferenser som underhålls i regelmotorns arbetsminne, med hjälp av predikaten som definieras i regelvillkoren. För effektivitet sker mönstermatchning för alla regler i regeluppsättningen, och villkor som delas mellan regler matchas bara en gång. regelmotorn kan lagra partiella villkorsmatchningar i arbetsminnet för att påskynda efterföljande mönstermatchningsåtgärder. Utdata från mönstermatchningsfasen innehåller uppdateringar av regelmotorns agenda.
Konfliktlösning
I konfliktlösningssteget undersöker regelmotorn regler som är kandidater för körning för att fastställa nästa uppsättning regelåtgärder som ska köras, baserat på ett förutbestämt lösningsschema. regelmotorn lägger till alla kandidatregler som hittas under matchningsfasen i regelmotorns dagordning.
Standardkonfliktlösningsschemat baseras på regelprioriteringar i en regeluppsättning. Prioriteten är en regelegenskap som du kan konfigurera i Microsoft Rules Composer. Ju större tal, desto högre prioritet. Om flera regler utlöses kör regelmotorn åtgärderna med högre prioritet först.
Åtgärd
I åtgärdsfasen kör regelmotorn åtgärderna i den lösta regeln. Regelåtgärder kan bekräfta nya fakta i regelmotorn, vilket gör att cykeln fortsätter och även kallas för framåtlänkning.
Viktigt!
Algoritmen föregriper aldrig den regel som körs. Regelmotorn kör alla åtgärder i regeln som körs innan matchningsfasen upprepas. Andra regler på regelmotorns agenda körs dock inte innan matchningsfasen börjar igen. Matchningsfasen kan leda till att regelmotorn tar bort dessa regler från dagordningen innan de körs.
Exempel
I följande exempel visas hur trestegsalgoritmen för matchning, konfliktlösning och åtgärd fungerar:
Regel 1: Utvärdera intäkter
Deklarativ representation
Erhålla en sökandes kreditvärdighet endast om sökandens inkomst-till-lån-förhållande är mindre än 0,2.
IF – SEDAN representation med hjälp av affärsobjekt
IF Application.Income / Property.Price < 0.2 THEN Assert new CreditRating( Application)
Regel 2: Utvärdera kreditvärdighet
Deklarativ representation
Godkänn endast en sökande om sökandens kreditvärdighet är mer än 725.
IF – SEDAN Representation med hjälp av affärsobjekt:
IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725 THEN SendApprovalLetter(Application)
I följande tabell sammanfattas fakta:
| Fakta | beskrivning | Fält |
|---|---|---|
| Program | Ett XML-dokument som representerar ett hemlåneprogram. | - Inkomst: $65,000 - SSN: XXX-XX-XXXX |
| Property | Ett XML-dokument som representerar den egenskap som ska köpas. | - Pris: $225,000 |
| CreditRating | Ett XML-dokument som innehåller lånesökandens kreditvärdighet. | - Värde: 0-800 - SSN: XXX-XX-XXXX |
Uppdateringar av arbetsminne och agenda
Till en början är regelmotorns arbetsminne och agenda tom. När programmet har lagt till fakta om program och egenskaper uppdaterar regelmotorns arbetsminne och agenda enligt följande:
| Arbetsminne | Agenda |
|---|---|
| -Tillämpning -Egenskap |
Regel 1 |
Regelmotorn lägger till regel 1 i sin agenda eftersom villkoret Application.Income /Property.Price < 0.2 utvärderas till true under matchningsfasen.
Det finns inget CreditRating-faktum i arbetsminnet, så villkoret för regel 2 utvärderas inte.
Regel 1 är den enda regeln på dagordningen, så regeln verkställs och försvinner sedan från dagordningen.
Regel 1 definierar en enskild åtgärd som resulterar i ett nytt faktum, vilket är sökandens CreditRating-dokument som läggs till i arbetsminnet.
När regel 1 har slutfört körningen återgår kontrollen till matchningsfasen.
Det enda nya objektet som ska matchas är CreditRating-faktumet , så resultatet av matchningsfasen är följande:
Arbetsminne Agenda -Tillämpning
-Egenskap
- CreditRatingRegel 2 Regel 2 körs nu, vilket anropar en funktion som skickar ett godkännandebrev till den sökande.
När regel 2 har slutförts återgår kontrollen till matchningsfasen. Det finns dock inga nya fakta att matcha, och agendan är tom, så framåtlänkningen avslutas och regeluppsättningens körning är klar.
Agenda och prioritet
För att förstå hur Azure Logic Apps-regelmotorn utvärderar regler och utför åtgärder måste du också lära dig mer om begreppen agenda och prioritet.
Agenda
Regelmotorns agenda är ett schema som köar regler för körning. Agendan finns för en motorinstans och agerar på en enda regeluppsättning, inte en serie regeluppsättningar. När ett faktum bekräftas i arbetsminnet och en regels villkor uppfylls placerar motorn regeln på dagordningen och kör den regeln baserat på prioritet. Motorn kör en regels åtgärder uppifrån och ned och kör sedan åtgärderna för nästa regel på dagordningen.
Regelmotorn behandlar åtgärderna i en regel som ett block, så alla åtgärder körs innan motorn flyttas till nästa regel. Alla åtgärder i ett regelblock körs oavsett andra åtgärder i blocket. Mer information om försäkran finns i Optimera regelmotorn med kontrollfunktioner .
I följande exempel visas hur agendan fungerar:
Regel 1
IF
Fact1 == 1
THEN
Action1
Action2
Regel 2
IF
Fact1 > 0
THEN
Action3
Action4
När fakta 1, som har värdet 1, bekräftas i motorn, har både regel 1 och regel 2 sina villkor uppfyllda. Så motorn flyttar båda reglerna till dagordningen för att utföra sina åtgärder.
| Arbetsminne | Agenda |
|---|---|
| Fakta 1 (värde=1) | Regel 1: - Åtgärd 1 - Åtgärd 2 Regel 2: – Åtgärd 3 - Åtgärd 4 |
Prioritet
Som standard är alla regler inställda på 0 som prioritet för körning. Du kan dock ändra den här prioriteten för varje enskild regel. Prioriteten kan variera till endera sidan av 0 med större tal med högre prioritet. Motorn kör åtgärder från högsta prioritet till lägsta prioritet.
I följande exempel visas hur prioritet påverkar orderkörningen för regler:
Regel 1 (prioritet = 0)
IF
Fact1 == 1
THEN
Discount = 10%
Regel 2 (prioritet = 10)
IF
Fact1 > 0
THEN
Discount = 15%
Även om villkoren för båda reglerna är uppfyllda körs regel 2 först på grund av dess högre prioritet. Den slutliga rabatten är 10 procent på grund av resultatet från åtgärden som körs för regel 1 enligt följande tabell:
| Arbetsminne | Agenda |
|---|---|
| Fact1 (värde=1) | Regel 2: Rabatt: 15 % Regel 1: Rabatt: 10 % |
Biverkningar för åtgärd
Om en åtgärds körning påverkar ett objekts tillstånd eller en term som används under villkor, sägs den här åtgärden ha en "bieffekt" på objektet eller termen. Den här frasen betyder inte att åtgärden har biverkningar, utan snarare att objektet eller termen kan påverkas av en eller flera åtgärder.
Anta till exempel att du har följande regler:
Regel 1
IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"
Regel 2
IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")
I det här exemplet har OrderForm.UpdateStatus en "sidoeffekt" på OrderForm.Status, vilket innebär att OrderForm.Status kan påverkas av en eller flera åtgärder.
Egenskapen SideEffects för .NET-klassmedlemmar är inställd på true som standardvärde, vilket förhindrar att regelmotorn cachelagrar en medlem med biverkningar. I det här exemplet cachelagras inte OrderForm.Status i arbetsminnet av regelmotorn. I stället får motorn det senaste värdet för OrderForm.Status varje gång motorn utvärderar regel 1. Om egenskapsvärdet SideEffects är falskt cachelagrar regelmotorn värdet när motorn utvärderar OrderForm.Status för första gången. För senare utvärderingar i scenarier med framåtlänkning använder motorn dock det cachelagrade värdet.
Microsoft Rules Composer tillhandahåller för närvarande inte något sätt för dig att ändra egenskapsvärdet SideEffects . Du kan dock programmatiskt ange egenskapsvärdet SideEffects via Business Rules Framework, som är en Microsoft . NET-kompatibelt klassbibliotek. Du anger det här värdet som bindning med klassen ClassMemberBinding för att ange objektmetoder, egenskaper och fält som används i regelvillkor och -åtgärder. Klassen ClassMemberBinding har en egenskap med namnet SideEffects, som innehåller ett booleskt värde som anger om åtkomst till medlemmen ändrar dess värde.
Prestandaöverväganden
I det här avsnittet beskrivs hur Regelmotorn för Azure Logic Apps fungerar i olika scenarier och med olika värden för konfigurations- och justeringsparametrar.
Faktatyper
Regelmotorn tar mindre tid att komma åt .NET-fakta än att komma åt XML-fakta. Om du har ett val mellan att använda .NET-fakta eller XML-fakta i en regeluppsättning bör du överväga att använda .NET-fakta för bättre prestanda.
Regelprioritet
Prioritetsinställningen för en regel kan variera till endera sidan av 0 med större tal med högre prioritet. Åtgärder körs i ordning från högsta prioritet till lägsta prioritet. När regeluppsättningen implementerar framåtlänkningsbeteende med hjälp av Assert - eller Update-anrop kan du optimera länkningen med hjälp av egenskapen Prioritet .
Anta till exempel att regel 2 har ett beroende av ett värde som anges av regel 1. Om regel 1 har högre prioritet körs regel 2 först när regel 1 utlöses och uppdaterar värdet. Om regel 2 däremot har högre prioritet kan regeln utlösas en gång och sedan utlösas igen efter att regel 1 utlöses och uppdaterar faktumet i villkoret för regel 2. Det här scenariot kanske eller kanske inte ger rätt resultat, men det är uppenbart att avfyrning två gånger påverkar prestanda jämfört med att bara starta en gång.
Mer information finns i Skapa regler med Microsoft Rules Composer.
Logiska OR-operatorer
Regelmotorn är optimerad för att köra logiska AND-operatorer och rekonstruerar regeln som motorn parsade till en disjunctive normal form så att den logiska OR-operatorn endast används på den översta nivån.
Om du använder fler logiska OR-operatorer under förhållanden skapar ökningen fler permutationer som expanderar regelmotorns analysnätverk. Därför kan det ta lång tid för regelmotorn att normalisera regeln.
Följande lista innehåller möjliga lösningar på det här problemet:
Ändra regeln till ett disjunctive normal form så att OR-operatorn bara är på den översta nivån.
Överväg att skapa regeln programmatiskt eftersom det kan vara svårt att skapa en regel i disjunctive normal form i Microsoft Rules Composer.
Utveckla en hjälpkomponent som utför OR-åtgärderna och returnerar ett booleskt värde och sedan använder komponenten i regeln.
Dela upp regeln i flera regler och låt reglerna söka efter en flagga som angetts av en tidigare körd regel, eller använd ett objekt som en tidigare utförd regel har hävdat, till exempel:
Regel 1:
IF (a == 1 OR a == 3) THEN b = trueRegel 2:
IF (b == true) THEN …Regel 1:
IF (a == 1 OR a == 3) THEN Assert(new c())Regel 2:
IF (c.flag == true) THEN …
Uppdatera anrop
Funktionen Uppdatera uppdaterar ett faktum som finns i regelmotorns arbetsminne, vilket orsakar omvärdering för alla regler som använder det uppdaterade faktumet under förhållanden. Det här beteendet innebär att uppdateringsfunktionsanrop kan vara dyra, särskilt om många regler kräver omvärdering på grund av uppdaterade fakta. I vissa situationer kan du undvika att behöva omvärdera reglerna.
Tänk till exempel på följande regler:
Regel 1
IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)
Regel 2
IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)
Alla återstående regler i regeluppsättningen använder StatusObj.Flag i sina villkor. När du anropar funktionen Uppdatera i Objektet StatusObj utvärderas alla regler på nytt. Oavsett vilket värde som finns i fältet Belopp utvärderas alla regler utom regel 1 och regel 2 två gånger: en gång före uppdateringsanropet och en gång efter uppdateringsanropet.
I stället kan du ange värdet Flagga till false innan du anropar regeluppsättningen och sedan endast använda regel 1 i regeluppsättningen för att ange flaggan. I det här fallet anropas funktionen Uppdatera endast om värdet Belopp är större än 5. Funktionen Uppdatera anropas inte om mängden är mindre än eller lika med 5. På så sätt utvärderas alla regler utom regel 1 och regel 2 endast två gånger om värdet Belopp är större än 5.
SideEffects egenskapsbeteende
I klasserna XmlDocumentFieldBinding och ClassMemberBinding avgör egenskapen SideEffects om värdet för det bundna fältet, medlemmen eller kolumnen ska cachelagras.
I klassen XmlDocumentFieldBinding är egenskapen SideEffects standardvärde falskt. Men i klassen ClassMemberBinding är egenskapen SideEffects standardvärde sant.
Om motorn använder ett fält i ett XML-dokument för andra gången eller senare i regeluppsättningen hämtar motorn fältets värde från cacheminnet. Men om motorn får åtkomst till en medlem i ett .NET-objekt för andra gången eller senare i regeluppsättningen hämtar motorn värdet från .NET-objektet, inte från cacheminnet.
Det här beteendet innebär att om du anger egenskapen SideEffects i en .NET ClassMemberBinding till false kan du förbättra prestandan eftersom motorn hämtar medlemmens värde från cacheminnet från och med andra gången och framåt. Du kan dock bara programmatiskt ange egenskapsvärdet eftersom Microsoft Rules Composer inte exponerar egenskapen SideEffects .
Instanser och selektivitet
Klasserna XmlDocumentBinding och ClassBinding har följande egenskaper, som regelmotorn använder sina värden för att optimera villkorsutvärderingen. Med de här egenskapsvärdena kan motorn använda minst möjliga instanser först i villkorsutvärderingar och sedan använda de återstående instanserna.
Instanser: Det förväntade antalet klassinstanser i arbetsminnet.
Om du känner till antalet objektinstanser i förväg kan du ange egenskapen Instances till det här talet för att förbättra prestandan.
Selektivitet: Procentandelen klassinstanser som klarar regelvillkoren.
Om du känner till procentandelen objektinstanser som uppfyller villkoren i förväg kan du ange egenskapen Selectivity till den här procentandelen för att förbättra prestandan.
Du kan bara programmatiskt ange dessa egenskapsvärden eftersom Microsoft Rules Composer inte exponerar dem.
Stöd för klassarv
Arv är möjligheten att använda alla funktioner från en befintlig klass och utöka dessa funktioner utan att skriva om den ursprungliga klassen, vilket är en viktig funktion i OOP-språk (Object Oriented Programming).
Azure Logic Apps-regelmotorn stöder följande typer av klassarv:
Implementeringsarv: Möjligheten att använda basklassens egenskaper och metoder utan någon annan kodning.
Gränssnittsarv: Möjligheten att endast använda egenskapsnamn och metodnamn, men den underordnade klassen måste tillhandahålla implementeringen.
Med regelmotorn kan du skriva regler i termer av en gemensam basklass, men objekten som anges i regelmotorn kan komma från härledda klasser.
I följande exempel finns en basklass med namnet Employee, medan de härledda klasserna heter RegularEmployee och ContractEmployee:
class Employee
{
public string Status()
{
// member definition
}
public string TimeInMonths()
{
// member definition
}
}
class ContractEmployee : Employee
{
// class definition
}
class RegularEmployee : Employee
{
// class definition
}
Anta att du har följande regler i det här exemplet:
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())
Efter försäkran omvärderar motorn alla regler som innehåller typen Anställd eller ContractEmployee i deras villkor. Även om endast den härledda klassen är bekräftad, bekräftas även basklassen om regler skrivs med metoder i basklassen i stället för i den härledda klassen.