Condividi tramite

Ottimizzazione per l'esecuzione del motore regole di App per la logica di Azure (anteprima)

  • Articolo

Si applica: App per la logica di Azure (Standard)

Importante

Questa funzionalità è in anteprima ed è soggetta alle Condizioni supplementari per l'utilizzo per le anteprime di Microsoft Azure.

Il motore regole di App per la logica di Azure fornisce il contesto di esecuzione per un set di regole, che è possibile creare con Microsoft Rules Composer. Questa guida illustra i concetti di base relativi al funzionamento del motore regole e fornisce raccomandazioni di ottimizzazione per operazioni ed esecuzione.

Componenti principali

  • Executor ruleset

    Questo componente implementa l'algoritmo responsabile della valutazione della condizione della regola e dell'esecuzione dell'azione. L'executor del set di regole predefinito è un motore di inferenza di concatenamento di rete basato sulla rete progettato per ottimizzare l'operazione in memoria.

  • Traduttore del set di regole

    Questo componente accetta un oggetto RuleSet come input e produce una rappresentazione eseguibile del set di regole. Il traduttore in memoria predefinito crea una rete di discriminazione compilata dalla definizione del set di regole.

  • Intercettore di rilevamento del set di regole

    Questo componente riceve l'output dall'executor del set di regole e inoltra tale output agli strumenti di rilevamento e monitoraggio del set di regole.

Valutazione delle condizioni ed esecuzione di azioni

Il motore regole di App per la logica di Azure è un motore di inferenza altamente efficiente che può collegare regole a oggetti .NET o documenti XML. Il motore regole usa un algoritmo a tre fasi per l'esecuzione del set di regole con le fasi seguenti:

  • Fiammifero

    Nella fase di corrispondenza, il motore regole corrisponde ai fatti rispetto ai predicati che usano il tipo di fatto, che sono riferimenti a oggetti mantenuti nella memoria di lavoro del motore regole, usando i predicati definiti nelle condizioni della regola. Per un'efficienza, i criteri di ricerca si verificano in tutte le regole nel set di regole e le condizioni condivise tra le regole vengono confrontate una sola volta. Il motore regole potrebbe archiviare le corrispondenze di condizione parziale nella memoria di lavoro per accelerare le operazioni successive di corrispondenza dei criteri. L'output della fase di corrispondenza dei criteri contiene aggiornamenti dell'agenda del motore regole.

  • Risoluzione dei conflitti

    Nella fase di risoluzione dei conflitti, il motore regole esamina le regole candidate per l'esecuzione per determinare il set successivo di azioni delle regole da eseguire, in base a uno schema di risoluzione predeterminato. il motore regole aggiunge tutte le regole candidate trovate durante la fase di corrispondenza all'agenda del motore regole.

    Lo schema di risoluzione dei conflitti predefinito si basa sulle priorità delle regole all'interno di un set di regole. La priorità è una proprietà della regola che è possibile configurare in Microsoft Rules Composer. Maggiore è il numero, maggiore è la priorità. Se vengono attivate più regole, il motore regole esegue prima le azioni con priorità più alta.

  • Azione

    Nella fase di azione il motore regole esegue le azioni nella regola risolta. Le azioni delle regole possono asserire nuovi fatti nel motore delle regole, che fa sì che il ciclo continui ed è noto anche come concatenamento in avanti.

    Importante

    L'algoritmo non precede mai la regola attualmente in esecuzione. Il motore regole esegue tutte le azioni nella regola attualmente in esecuzione prima che la fase di corrispondenza si ripeta. Tuttavia, altre regole sull'agenda del motore regole non verranno eseguite prima che la fase di corrispondenza inizi di nuovo. La fase di corrispondenza potrebbe causare la rimozione delle regole dal motore regole dall'ordine del giorno prima dell'esecuzione.

Esempio

L'esempio seguente illustra il funzionamento dell'algoritmo a tre fasi di corrispondenza, risoluzione dei conflitti e azione:

Regola 1: Valutare il reddito

  • Rappresentazione dichiarativa

    Ottenere il rating di credito di un richiedente solo se il rapporto reddito-prestito del richiedente è minore di 0,2.

  • IF: rappresentazione THEN tramite oggetti business

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

Regola 2: Valutare la valutazione della valutazione del credito

  • Rappresentazione dichiarativa

    Approvare un richiedente solo se il rating di credito del richiedente è superiore a 725.

  • IF— THEN Rappresentazione tramite oggetti business:

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

La tabella seguente riepiloga i fatti:

Fatto Descrizione Campi
Applicazione Documento XML che rappresenta un'applicazione di prestito a domicilio. - Reddito: $ 65.000
- SSN: XXX-XX-XXXX
Proprietà Documento XML che rappresenta la proprietà da acquistare. - Prezzo: $ 225.000
CreditRating Documento XML contenente il rating di credito del richiedente del prestito. - Valore: 0-800
- SSN: XXX-XX-XXXX

Aggiornamenti alla memoria e all'agenda di lavoro

Inizialmente, la memoria e l'agenda del motore regole sono vuote. Dopo che l'applicazione aggiunge i fatti dell'applicazione e della proprietà , il motore regole aggiorna la memoria di lavoro e l'agenda, come illustrato di seguito:

Memoria di lavoro Agenda
-Applicazione
-Proprietà		 Regola 1

  • Il motore regole aggiunge la regola 1 all'agenda perché la condizione Application.Income / Property.Price < 0.2 restituisce true durante la fase di corrispondenza.

  • Non esiste alcun fatto creditRating nella memoria di lavoro, quindi la condizione per la regola 2 non viene valutata.

  • La regola 1 è l'unica regola dell'ordine del giorno, quindi la regola viene eseguita e quindi scompare dall'ordine del giorno.

  • La regola 1 definisce una singola azione che comporta un nuovo fatto, ovvero il documento CreditRating del richiedente che viene aggiunto alla memoria di lavoro.

  • Al termine dell'esecuzione della regola 1, il controllo torna alla fase di corrispondenza.

    L'unico nuovo oggetto che corrisponde è il fatto CreditRating , quindi i risultati della fase di corrispondenza sono i seguenti:

    Memoria di lavoro Agenda
    -Applicazione
    -Proprietà
    - CreditRating    		 Regola 2

  • La regola 2 viene ora eseguita, che chiama una funzione che invia una lettera di approvazione al richiedente.

  • Al termine della regola 2, il controllo torna alla fase di corrispondenza. Tuttavia, non sono disponibili altri nuovi fatti per la corrispondenza e l'agenda è vuota, quindi il concatenamento in avanti termina e l'esecuzione del set di regole è completa.

Agenda e priorità

Per comprendere come il motore regole di App per la logica di Azure valuta le regole ed esegue le azioni, è necessario conoscere anche i concetti dell'agenda e della priorità.

Agenda

L'agenda del motore regole è una pianificazione che accoda le regole per l'esecuzione. L'agenda esiste per un'istanza del motore e agisce su un singolo set di regole, non su una serie di set di regole. Quando un fatto viene asserito nella memoria di lavoro e vengono soddisfatte le condizioni di una regola, il motore inserisce la regola nell'agenda ed esegue tale regola in base alla priorità. Il motore esegue le azioni di una regola dall'alto verso il basso e quindi esegue le azioni per la regola successiva nell'agenda.

Il motore regole considera le azioni in una regola come blocco, quindi tutte le azioni vengono eseguite prima che il motore passi alla regola successiva. Tutte le azioni in un blocco di regole vengono eseguite indipendentemente dalle altre azioni nel blocco. Per altre informazioni sull'asserzione, vedere Ottimizzare il motore regole con funzioni di controllo .

Nell'esempio seguente viene illustrato il funzionamento dell'agenda:

Regola 1

IF
Fact1 == 1
THEN
Action1
Action2

Regola 2

IF
Fact1 > 0
THEN
Action3
Action4

Quando il fatto Fact1 , che ha un valore pari a 1, viene asserito nel motore, entrambe le condizioni della regola 1 e della regola 2 sono soddisfatte. Quindi, il motore sposta entrambe le regole nell'agenda per eseguire le azioni.

Memoria di lavoro Agenda
Fact 1 (value=1) Regola 1:
- Azione1
- Azione2

Regola 2:
- Azione3
- Azione4

Priorità

Per impostazione predefinita, tutte le regole sono impostate su 0 come priorità per l'esecuzione. Tuttavia, è possibile modificare questa priorità per ogni singola regola. La priorità può variare su entrambi i lati di 0 con numeri più grandi con priorità più alta. Il motore esegue azioni dalla priorità più alta alla priorità più bassa.

Nell'esempio seguente viene illustrato come la priorità influisce sull'esecuzione dell'ordine per le regole:

Regola 1 (priorità = 0)

IF
Fact1 == 1
THEN
Discount = 10%

Regola 2 (priorità = 10)

IF
Fact1 > 0
THEN
Discount = 15%

Anche se vengono soddisfatte le condizioni per entrambe le regole, la regola 2 viene eseguita per prima a causa della priorità più alta. Lo sconto finale è del 10% a causa del risultato dell'azione eseguita per la regola 1, come illustrato nella tabella seguente:

Memoria di lavoro Agenda
Fact1 (value=1) Regola 2:
Sconto: 15%

Regola 1:
Sconto: 10%

Effetti collaterali azione

Se l'esecuzione di un'azione influisce sullo stato di un oggetto o su un termine usato in condizioni, questa azione viene detta "effetto collaterale" su tale oggetto o termine. Questa frase non significa che l'azione ha effetti collaterali, ma piuttosto l'oggetto o il termine è potenzialmente influenzato da una o più azioni.

Si supponga, ad esempio, di avere le regole seguenti:

Regola 1

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

Regola 2

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

In questo esempio OrderForm.UpdateStatus ha un effetto collaterale su OrderForm.Status, ovvero OrderForm.Status è potenzialmente interessato da una o più azioni.

La proprietà SideEffects per i membri della classe .NET è impostata su true come valore predefinito, che impedisce al motore regole di memorizzare nella cache un membro con effetti collaterali. In questo esempio il motore regole non memorizza nella cache OrderForm.Status nella memoria di lavoro. Al contrario, il motore ottiene il valore più recente di OrderForm.Status ogni volta che il motore valuta la regola 1. Se il valore della proprietà SideEffects è false, il motore regole memorizza nella cache il valore quando il motore valuta OrderForm.Status per la prima volta. Tuttavia, per le valutazioni successive negli scenari di concatenamento in avanti, il motore usa il valore memorizzato nella cache.

Microsoft Rules Composer attualmente non consente di modificare il valore della proprietà SideEffects . Tuttavia, è possibile impostare a livello di codice il valore della proprietà SideEffects tramite Business Rules Framework, ovvero microsoft . Libreria di classi conforme a NET. Per impostare questo valore in corrispondenza dell'associazione, utilizzare la classe ClassMemberBinding per specificare metodi, proprietà e campi oggetto utilizzati nelle condizioni e nelle azioni delle regole. La classe ClassMemberBinding ha una proprietà denominata SideEffects, che contiene un valore booleano che indica se l'accesso al membro modifica il relativo valore.

Considerazioni sulle prestazioni

Questa sezione illustra le prestazioni del motore regole di App per la logica di Azure in vari scenari e con valori diversi per i parametri di configurazione e ottimizzazione.

Tipi di fatti

Il motore regole richiede meno tempo per accedere ai fatti .NET rispetto all'accesso ai fatti XML. Se si ha una scelta tra l'uso di fatti .NET o fatti XML in un set di regole, è consigliabile usare fatti .NET per ottenere prestazioni migliori.

Priorità delle regole

L'impostazione di priorità per una regola può essere impostata su entrambi i lati di 0 con un numero maggiore con priorità più alta. Le azioni sono eseguite in ordine a partire dalla priorità più alta alla priorità più bassa. Quando il set di regole implementa il comportamento di forward chaining tramite le chiamate Assert o Update , è possibile ottimizzare il concatenamento tramite la proprietà Priority .

Si supponga, ad esempio, che la regola 2 abbia una dipendenza da un valore impostato dalla regola 1. Se la regola 1 ha priorità più alta, la regola 2 viene eseguita solo dopo che la regola 1 viene attivata e aggiorna il valore. Viceversa, se la regola 2 ha una priorità più alta, la regola può essere attivata una sola volta e quindi viene nuovamente attivata dopo che la regola 1 viene attivata e aggiorna il fatto nella condizione per la regola 2. Questo scenario potrebbe o non produrre i risultati corretti, ma chiaramente l'attivazione due volte ha un impatto sulle prestazioni rispetto all'attivazione una sola volta.

Per altre informazioni, vedere Creare regole con Microsoft Rules Composer.

Operatori OR logici

Il motore regole è ottimizzato per eseguire operatori AND logici e ricostruisce la regola analizzata dal motore in una forma normale disgiuntiva in modo che l'operatore OR logico venga usato solo al livello superiore.

Se si usano più operatori OR logici in condizioni, l'aumento crea più permutazioni che espandono la rete di analisi del motore regole. Di conseguenza, il motore regole potrebbe richiedere molto tempo per normalizzare la regola.

L'elenco seguente offre possibili soluzioni alternative per questo problema:

  • Modificare la regola in un formato normale disgiuntivo in modo che l'operatore OR sia solo al livello superiore.

    Prendere in considerazione la creazione della regola a livello di codice, perché potrebbe risultare difficile creare una regola in forma normale disgiuntivo in Microsoft Rules Composer.

  • Sviluppare un componente helper che esegue le operazioni OR e restituisce un valore booleano e quindi usare il componente nella regola.

  • Suddividere la regola in più regole e verificare la presenza di un flag impostato da una regola eseguita in precedenza oppure usare un oggetto asserzionato da una regola eseguita in precedenza, ad esempio:

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

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

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

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

Aggiornare le chiamate

La funzione Update aggiorna un fatto presente nella memoria di lavoro del motore regole, che causa la rivalutazione per tutte le regole che usano il fatto aggiornato in condizioni. Questo comportamento significa che le chiamate di funzione di aggiornamento possono essere costose, soprattutto se molte regole richiedono una rivalutazione a causa di fatti aggiornati. In alcune situazioni, è possibile evitare di dover rivalutare le regole.

Si considerino ad esempio le regole seguenti:

Regola 1

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

Regola 2

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

Tutte le regole rimanenti nel set di regole usano StatusObj.Flag nelle relative condizioni. Quando si chiama la funzione Update nell'oggetto StatusObj , tutte le regole vengono rivalutate. Indipendentemente dal valore nel campo Amount, tutte le regole ad eccezione della regola 1 e della regola 2 vengono valutate due volte: una volta prima della chiamata di aggiornamento e una volta dopo la chiamata di aggiornamento.

È invece possibile impostare il valore Flag su false prima di richiamare il set di regole e quindi usare solo la regola 1 nel set di regole per impostare il flag. In questo caso, la funzione Update viene chiamata solo se il valore Amount è maggiore di 5. La funzione Update non viene chiamata se la quantità è minore o uguale a 5. In questo modo, tutte le regole ad eccezione della regola 1 e della regola 2 vengono valutate due volte solo se il valore Amount è maggiore di 5.

Comportamento della proprietà SideEffects

Nelle classi XmlDocumentFieldBinding e ClassMemberBinding la proprietà SideEffects determina se memorizzare nella cache il valore del campo associato, del membro o della colonna.

Nella classe XmlDocumentFieldBinding il valore predefinito della proprietà SideEffects è false. Tuttavia, nella classe ClassMemberBinding il valore predefinito della proprietà SideEffects è true.

Pertanto, se il motore accede a un campo in un documento XML per la seconda volta o successiva all'interno del set di regole, il motore ottiene il valore del campo dalla cache. Tuttavia, se il motore accede a un membro di un oggetto .NET per la seconda volta o versione successiva all'interno del set di regole, il motore ottiene il valore dall'oggetto .NET, non dalla cache.

Questo comportamento significa che se si imposta la proprietà SideEffects in una classe .NETMemberBinding su false, è possibile migliorare le prestazioni perché il motore ottiene il valore del membro dalla cache a partire dalla seconda volta e versioni successive. Tuttavia, è possibile impostare il valore della proprietà solo a livello di codice perché Microsoft Rules Composer non espone la proprietà SideEffects .

Istanze e selettività

Le classi XmlDocumentBinding e ClassBinding hanno ognuna le proprietà seguenti, che il motore regole usa i relativi valori per ottimizzare la valutazione delle condizioni. Questi valori delle proprietà consentono al motore di usare prima le istanze più poche possibili nelle valutazioni delle condizioni e quindi di usare le istanze rimanenti.

  • Istanze: numero previsto di istanze di classe nella memoria di lavoro.

    Se si conosce in anticipo il numero di istanze dell'oggetto, è possibile impostare la proprietà Instances su questo numero per migliorare le prestazioni.

  • Selettività: percentuale di istanze di classe che superano correttamente le condizioni della regola.

    Se si conosce la percentuale di istanze dell'oggetto che superano le condizioni in anticipo, è possibile impostare la proprietà Selectivity su questa percentuale per migliorare le prestazioni.

È possibile impostare questi valori di proprietà solo a livello di codice perché Microsoft Rules Composer non li espone.

Supporto per l'ereditarietà delle classi

L'ereditarietà è la possibilità di usare tutte le funzionalità di una classe esistente ed estendere tali funzionalità senza riscrivere la classe originale, che è una funzionalità chiave nei linguaggi OOP (Object Oriented Programming).

Il motore regole di App per la logica di Azure supporta i tipi di ereditarietà delle classi seguenti:

  • Ereditarietà dell'implementazione: possibilità di usare le proprietà e i metodi di una classe di base senza altro codice.

  • Ereditarietà dell'interfaccia: la possibilità di usare solo nomi di proprietà e nomi di metodo, ma la classe figlio deve fornire l'implementazione.

Con il motore regole, è possibile scrivere regole in termini di classe base comune, ma gli oggetti asserti nel motore regole possono provenire da classi derivate.

Nell'esempio seguente è presente una classe base denominata Employee, mentre le classi derivate sono denominate RegularEmployee e ContractEmployee:

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

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

Per questo esempio, si supponga di avere le regole seguenti:

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

Dopo l'asserzione, il motore rivaluta tutte le regole che contengono il tipo Employee o il tipo ContractEmployee nelle relative condizioni. Anche se viene asserta solo la classe derivata, anche la classe base viene asserta se le regole vengono scritte usando metodi nella classe base, anziché nella classe derivata.

Contenuto correlato