Sdílet prostřednictvím


Optimalizace efektivity pro engine pravidel Azure Logic Apps

Platí pro: Azure Logic Apps (Standard)

Tato příručka popisuje základní koncepty, které vysvětlují, jak modul pravidel Azure Logic Apps funguje při vyhodnocování podmínek, provádění akcí a řešení konfliktů mezi pravidly. Modul pravidel Azure Logic Apps poskytuje kontext spuštění sady pravidel, kterou vytvoříte pomocí nástroje Microsoft Rules Composer.

Dozvíte se o třífázovém algoritmu spouštění modulu, o tom, jak program a systém priority určují pořadí provádění pravidel a jak vedlejší účinky ovlivňují chování ukládání do mezipaměti. Tato příručka také poskytuje strategie optimalizace výkonu, včetně tipů pro správu typů faktů, logických operátorů, aktualizačních volání a podpory dědičnosti tříd, takže můžete vytvářet sady pravidel, které běží efektivně.

Základní součásti

  • Exekutor sady pravidel

    Tato komponenta implementuje algoritmus zodpovědný za vyhodnocení podmínky pravidla a provádění akce. Výchozí výkonný stroj sady pravidel je odvozovací stroj založený na diskriminační síti, který je navržen tak, aby optimalizoval provoz v paměti.

  • Překladač pravidel

    Tato komponenta přebírá jako vstup objekt RuleSet a vytváří spustitelný soubor sady pravidel. Výchozí překladač v paměti vytvoří z definice sady pravidel kompilovanou síť diskriminace.

  • Zachytávání sady pravidel

    Tato komponenta přijímá výstup z exekutoru sady pravidel a předává tento výstup do nástrojů pro sledování a monitorování sady pravidel.

Vyhodnocení podmínky a spuštění akce

Modul pravidel Azure Logic Apps je vysoce efektivní modul pro odvozování, který dokáže propojit pravidla s objekty .NET nebo dokumenty XML. Modul pravidel používá pro spouštění sady pravidel třífázový algoritmus s následujícími fázemi:

  • Utkání

    Stroj pravidel ve fázi shody porovnává fakta s predikáty, které využívají typ faktu, což jsou odkazy na objekty udržované v pracovní paměti stroje pravidel, a to pomocí predikátů definovaných v podmínkách pravidla. Pro efektivitu dochází k porovnávání vzorů napříč všemi pravidly v pravidlové sadě a podmínky sdílené mezi pravidly jsou porovnány pouze jednou. Modul pravidel může ukládat částečné shody podmínek v pracovní paměti, aby se urychlily následné operace porovnávání vzorů. Výstup z fáze porovnávání vzorů obsahuje aktualizace v agendě modulu pravidel.

  • Řešení konfliktů

    Ve fázi řešení konfliktů modul pravidel zkoumá pravidla, která jsou kandidáty na spuštění, a určí další sadu akcí pravidel, které se mají spustit, na základě předem určeného schématu řešení. pravidlový stroj přidá všechna kandidátská pravidla nalezená během fáze porovnávání do svého seznamu.

    Výchozí schéma řešení konfliktů je založené na prioritách pravidel v rámci sady pravidel. Priorita je vlastnost pravidla, kterou můžete nakonfigurovat v nástroji Microsoft Rules Composer. Čím větší je číslo, tím vyšší je priorita. Pokud se aktivuje více pravidel, modul pravidel nejprve spustí akce s vyšší prioritou.

  • Akce

    Ve fázi akce modul pravidel provádí akce ve vyřešeném pravidle. Akce pravidel můžou v modulu pravidel uplatnit nová fakta, což způsobí, že cyklus bude pokračovat a označuje se také jako řetězení vpřed.

    Důležité

    Algoritmus nikdy nepřeruší aktuálně spuštěné pravidlo. Pravidlový engine provede všechny akce v aktuálně spuštěném pravidle před opakováním fáze porovnání. Jiná pravidla v pravidlovém modulu se ale nespustí, dokud se fáze shody znovu neaktivuje. Fáze shody může způsobit, že pravidlový systém tato pravidla odebere z programu ještě před jejich spuštěním.

Příklad

Následující příklad ukazuje, jak funguje třífázový algoritmus shody, řešení konfliktů a akce:

Pravidlo 1: Vyhodnocení příjmů

  • Deklarativní reprezentace

    Získat rating žadatele pouze v případě, že poměr příjmů k půjčkě žadatele je menší než 0,2.

  • Jestliže – reprezentace pomocí obchodních objektů

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

Pravidlo 2: Vyhodnocení úvěrového hodnocení

  • Deklarativní reprezentace

    Schválit žadatele pouze v případě, že rating žadatele je větší než 725.

  • Pokud: reprezentace pomocí podnikových objektů

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

Následující tabulka shrnuje fakta:

Fakt Popis Pole
Aplikace Dokument XML, který představuje aplikaci domácí půjčky. - Příjem: 65 000 Kč
- SSN: XXX-XX-XXXX
Vlastnost Dokument XML, který představuje atribut určený ke koupi. - Cena: 225 000 Kč
CreditRating Dokument XML, který obsahuje rating žadatele o úvěr. - Hodnota: 0-800
- SSN: XXX-XX-XXXX

Aktualizace pracovní paměti a programu

Na začátku jsou pracovní paměť a agenda stroje pravidel prázdná. Jakmile vaše aplikace přidá fakta Application a Property, modul pravidel aktualizuje svou pracovní paměť a agendu, jak je znázorněno:

Pracovní paměť Program jednání
-Aplikace
-Vlastnost
Pravidlo 1
  • Pravidlový systém přidá pravidlo 1 do svého seznamu úkolů, protože podmínka Application.Income / Property.Price < 0.2 se vyhodnotí jako pravda během fáze shody.

  • V pracovní paměti neexistuje žádná skutečnost CreditRating , takže podmínka pravidla 2 se nevyhodnocuje.

  • Pravidlo 1 je jediné pravidlo programu, takže pravidlo se provede a pak zmizí z programu.

  • Pravidlo 1 definuje jedinou akci, která má za následek novou skutečnost, což je dokument CreditRating žadatele, který je přidán do pracovní paměti.

  • Po dokončení provádění pravidla 1 se řízení vrátí do fáze porovnání.

    Jediným novým objektem, který se má shodovat, je CreditRating, takže výsledky fáze shody jsou následující:

    Pracovní paměť Program jednání
    -Aplikace
    -Vlastnost
    - Kreditní hodnocení
    Pravidlo 2
  • Pravidlo 2 se nyní provede a zavolá funkci, která odešle schvalovací dopis žadateli.

  • Po dokončení pravidla 2 se řízení vrátí do fáze párování. Nejsou však k dispozici žádná nová fakta, která by se měla shodovat, a agenda je prázdná, takže se ukončí dopředné řetězení a provedení sady pravidel je dokončeno.

Agenda a priorita

Abyste pochopili, jak modul pravidel Azure Logic Apps vyhodnocuje pravidla a provádí akce, musíte se také seznámit s koncepty agendy a priority.

Program jednání

Agenda modulu pravidel je plán, který zařazuje pravidla do fronty pro provedení. Agenda existuje pro instance motoru a používá jednu sadu pravidel, nikoli řadu sad pravidel. Když je fakt vložen do pracovní paměti a jsou splněny podmínky pravidla, motor umístí pravidlo do agendy a vykoná toto pravidlo na základě priority. Modul provede akce pravidla od nejvyšší po nejnižší prioritu a pak provede akce pro další pravidlo v programu.

Modul pravidel zachází s akcemi v pravidle jako s blokem, takže všechny akce se spouštějí před tím, než se modul přesune na další pravidlo. Všechny akce v bloku pravidla se spustí bez ohledu na ostatní akce v bloku. Další informace o asercích naleznete v tématu Optimalizace modulu pravidel pomocí řídicích funkcí.

Následující příklad ukazuje, jak program funguje:

Pravidlo 1

IF
Fact1 == 1
THEN
Action1
Action2

Pravidlo 2

IF
Fact1 > 0
THEN
Action3
Action4

Když je fakt Fact1, který má hodnotu 1, vložen do jádra, jsou splněny podmínky pro pravidlo 1 a pravidlo 2. Takže modul přesune obě pravidla do programu, aby provedl své akce.

Pracovní paměť Agenda
Fakt 1 (hodnota=1) Pravidlo 1:
- Akce 1
- Akce2

Pravidlo 2:
- Akce 3
- Akce4

Priorita

Ve výchozím nastavení jsou všechna pravidla nastavená na hodnotu 0 jako priorita pro provádění. Tuto prioritu ale můžete změnit u jednotlivých pravidel. Priorita může mít hodnotu na obou stranách nuly, přičemž větší čísla mají vyšší prioritu. Modul provádí akce od nejvyšší priority po nejnižší prioritu.

Následující příklad ukazuje, jak priorita ovlivňuje plnění pravidel:

Pravidlo 1 (priorita = 0)

IF
Fact1 == 1
THEN
Discount = 10%

Pravidlo 2 (priorita = 10)

IF
Fact1 > 0
THEN
Discount = 15%

I když jsou splněny podmínky obou pravidel, pravidlo 2 se spustí jako první kvůli vyšší prioritě. Konečná sleva je 10 procent z důvodu výsledku provedené akce pro pravidlo 1, jak je znázorněno v následující tabulce:

Pracovní paměť Program jednání
Fakt1 (hodnota=1) Pravidlo 2:
Sleva: 15 %

Pravidlo 1:
Sleva: 10 %

Vedlejší účinky akce a chování při ukládání do mezipaměti

Pokud provádění akce ovlivňuje stav objektu nebo termín použitý v podmínkách, znamená to, že tato akce má na daný objekt nebo termín "vedlejší účinek". Tato fráze neznamená, že akce má vedlejší účinky, ale spíše je objekt nebo termín potenciálně ovlivněn jednou nebo více akcemi.

Předpokládejme například, že máte následující pravidla:

Pravidlo 1

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

Pravidlo 2

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

V tomto příkladu má OrderForm.UpdateStatus vedlejší účinek na OrderForm.Status, což znamená, že OrderForm.Status je potenciálně ovlivněna jednou nebo více akcemi.

Vlastnost SideEffects pro členy třídy .NET je nastavena na hodnotu true jako výchozí hodnota, která brání modulu pravidel v ukládání člena do mezipaměti se vedlejšími účinky. V tomto příkladu modul pravidel neukládá OrderForm.Status do mezipaměti v pracovní paměti. Místo toho modul získá nejnovější hodnotu OrderForm.Status pokaždé, když modul vyhodnotí pravidlo 1. Pokud hodnota vlastnosti SideEffects je false, modul pravidel ukládá hodnotu do mezipaměti, když modul vyhodnotí OrderForm.Status poprvé. Pro pozdější vyhodnocení ve scénářích řetězení dopředu ale modul použije hodnotu uloženou v mezipaměti.

Nástroj Microsoft Rules Composer v současné době neposkytuje způsob, jak upravit hodnotu vlastnosti SideEffects . Hodnotu vlastnosti SideEffects však můžete nastavit programově prostřednictvím rozhraní Business Rules Framework, což je knihovna tříd kompatibilní s Microsoft .NET. Tuto hodnotu nastavíte na vazbu pomocí ClassMemberBinding třídy k určení metod objektů, vlastností a polí použitých v podmínkách a akcích pravidla. ClassMemberBinding třída má vlastnost s názvem SideEffects, která obsahuje logickou hodnotu, která označuje, zda přístup k členu změní jeho hodnotu.

Důležité informace o výkonu

Tato část popisuje, jak modul pravidel Azure Logic Apps funguje v různých scénářích a s různými hodnotami pro parametry konfigurace a ladění.

Typy faktů

Pro přístup k faktům .NET trvá modul pravidel méně času, než přístup k faktům XML. Pokud máte v sadě pravidel možnost použít fakta .NET nebo fakta XML, zvažte použití faktů .NET k lepšímu výkonu.

Priorita pravidla

Nastavení priority pravidla může být v rozsahu na obou stranách 0 , přičemž větší čísla mají vyšší prioritu. Akce se spouštějí v pořadí od nejvyšší priority po nejnižší prioritu. Když sada pravidel implementuje chování dopředného řetězení pomocí Assert nebo Update volání, můžete optimalizovat řetězení pomocí vlastnosti Priority.

Předpokládejme například, že pravidlo 2 má závislost na hodnotě nastavené pravidlem 1. Pokud má pravidlo 1 vyšší prioritu, pravidlo 2 se spustí jenom po vyvolání pravidla 1 a aktualizaci hodnoty. Naopak pokud má pravidlo 2 vyšší prioritu, pravidlo se může aktivovat jednou a potom znovu spustit po spuštění pravidla 1 a aktualizovat fakt v podmínce pro pravidlo 2. Tento scénář může nebo nemusí vést ke správným výsledkům, ale jasně platí, že dvakrát spouštění má vliv na výkon ve srovnání s jedním spouštěním.

Další informace naleznete v tématu Vytváření pravidel pomocí nástroje Microsoft Rules Composer.

Logické operátory OR

Modul pravidel je optimalizovaný tak, aby spustil logické operátory A a přepracoval pravidlo, které modul zpracoval do disjunktivního normálního tvaru tak, aby logický operátor NEBO byl použit pouze na nejvyšší úrovni.

Pokud v podmínkách použijete více logických operátorů OR , toto zvýšení vytvoří více permutací, které rozšíří síť analýzy stroje pravidel. V důsledku toho může modul pravidel trvat dlouhou dobu, než pravidlo normalizuje.

Následující seznam obsahuje možná alternativní řešení tohoto problému:

  • Změňte pravidlo na disjunktivní normální formulář tak, aby operátor OR byl pouze na nejvyšší úrovni.

    Zvažte vytvoření pravidla prostřednictvím kódu programu, protože můžete zjistit, že vytvoření pravidla v nesousedivé normální podobě v nástroji Microsoft Rules Composer může být složité.

  • Vyvíjejte pomocnou komponentu, která provádí operace OR , a vrací logickou hodnotu a pak tuto komponentu použijte v pravidle.

  • Rozdělte pravidlo na několik pravidel a nechte tato pravidla kontrolovat příznak nastavený pravidlem, které bylo spuštěno dříve, nebo použijte objekt, který pravidlo, jež bylo spuštěno dříve, prosadilo, například:

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

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

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

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

Aktualizace volání

Funkce Update aktualizuje skutečnost, která existuje v pracovní paměti modulu pravidel, což způsobuje opětovné hodnocení pro všechna pravidla, která používají aktualizované skutečnosti v podmínkách. Toto chování znamená, že volání funkce Update můžou být nákladná, zejména pokud řada pravidel vyžaduje opětovné hodnocení kvůli aktualizovaným faktům. V některých situacích se můžete vyhnout nutnosti znovu posuzovat pravidla.

Představte si například následující pravidla:

Pravidlo 1

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

Pravidlo 2

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

Všechna zbývající pravidla v sadě pravidel ve svých podmínkách používají StatusObj.Flag . Když zavoláte funkci Update u objektu StatusObj , všechna pravidla se znovu zhodnotí. Bez ohledu na hodnotu v poli Částka se všechna pravidla s výjimkou pravidla 1 a pravidla 2 vyhodnocují dvakrát: jednou před voláním aktualizace a jednou po volání aktualizace.

Místo toho můžete nastavit hodnotu příznaku na false před vyvolání sady pravidel a pak použít pouze pravidlo 1 v sadě pravidel k nastavení příznaku. V tomto případě je funkce Update volána pouze v případě, že je hodnota Amount větší než 5. Funkce Update se nevolá, pokud je částka menší nebo rovna 5. Tímto způsobem se vyhodnocují všechna pravidla kromě pravidla 1 a pravidla 2 dvakrát, pouze pokud je hodnota Částka větší než 5.

Chování vlastnosti SideEffects a chování cache

V třídách XmlDocumentFieldBinding a ClassMemberBinding vlastnost SideEffects určuje, zda se má hodnotu vázaného pole, člena nebo sloupce ukládat do mezipaměti.

Ve třídě XmlDocumentFieldBinding je výchozí hodnota vlastnosti SideEffectsfalse. Nicméně třída ClassMemberBinding, jejíž vlastnost SideEffects má výchozí hodnotu true.

Takže pokud modul přistupuje k poli v dokumentu XML podruhé nebo později v sadě pravidel, získá modul hodnotu pole z mezipaměti. Pokud však modul přistupuje k členu objektu .NET podruhé nebo později v sadě pravidel, získá modul hodnotu z objektu .NET, nikoli z mezipaměti.

Toto chování znamená, že pokud nastavíte vlastnost SideEffects v .NET ClassMemberBinding na false, můžete zvýšit výkon, protože engine získá hodnotu člena z mezipaměti počínaje druhým použitím a nadále. Hodnotu vlastnosti však můžete nastavit pouze prostřednictvím kódu programu, protože Nástroj Microsoft Rules Composer nezpřístupňuje vlastnost SideEffects .

Instance a selektivita

Třídy XmlDocumentBinding a ClassBinding mají následující vlastnosti, které modul pravidel používá jejich hodnoty k optimalizaci vyhodnocení podmínky. Tyto hodnoty vlastností umožňují modulu použít v vyhodnocení podmínek co nejmenší možné instance a pak použít zbývající instance.

  • Instance: Očekávaný počet instancí třídy v pracovní paměti.

    Pokud znáte počet instancí objektů předem, můžete vlastnost Instances nastavit na toto číslo, aby se zlepšil výkon.

  • Selektivita: Procento instancí třídy, které úspěšně projdou podmínkami pravidla.

    Pokud znáte procento instancí objektů, které předávají podmínky předem, můžete vlastnost Selectivity nastavit na toto procento, aby se zlepšil výkon.

Tyto hodnoty vlastností můžete nastavit pouze prostřednictvím kódu programu, protože nástroj Microsoft Rules Composer je nezpřístupňuje.

Podpora dědičnosti tříd

Dědičnost je schopnost používat všechny funkce z existující třídy a rozšířit tyto schopnosti bez přepsání původní třídy, což je klíčovou funkcí v jazycích OOP (Object Oriented Programming).

Modul pravidel Azure Logic Apps podporuje následující druhy dědičnosti tříd:

  • Dědičnost implementace: Schopnost používat vlastnosti a metody základní třídy bez jiného kódování.

  • Dědičnost rozhraní: Schopnost používat pouze názvy vlastností a názvy metod, ale podřízená třída musí poskytnout implementaci.

Pomocí modulu pravidel můžete psát pravidla z hlediska společné základní třídy, ale objekty vytříděné do modulu pravidel mohou pocházet z odvozených tříd.

Následující příklad má základní třídu s názvem Employee, zatímco odvozené třídy jsou pojmenovány RegularEmployee a ContractEmployee:

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

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

V tomto příkladu předpokládejme, že máte následující pravidla:

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

Po kontrolním výrazu modul znovu vyhodnocuje všechna pravidla, která obsahují typ Zaměstnanec nebo typ Smluvní zaměstnanec ve svých podmínkách. I když je uplatněna pouze odvozená třída, základní třída je také odvozena, pokud jsou pravidla zapsána pomocí metod v základní třídě, nikoli v odvozené třídě.