Considerazioni sulle prestazioni da tener presente quando si utilizza il Motore regole di business

In questo argomento vengono descritte le prestazioni del Motore regole di business in diversi scenari e con valori differenti per i parametri di configurazione/regolazione.

Tipi di fact

Il Motore regole di business impiega meno tempo ad accedere ai fact .NET rispetto ai fact XML e di database. Se è possibile scegliere tra fact .NET, XML o di database per un criterio, è consigliabile utilizzare i fact .NET per ottenere prestazioni migliori.

Confronto tra binding di tabelle dati e connessioni dati

Quando le dimensioni del set di dati sono ridotte (meno di circa 10 righe), l'associazione TypedDataTable offre prestazioni migliori rispetto all'associazione DataConnection . Quando il set di dati è di grandi dimensioni (maggiore o uguale a circa 10 righe), l'associazione DataConnection offre prestazioni migliori rispetto all'associazione TypedDataTable . È pertanto necessario decidere se utilizzare l'associazione DataConnection o l'associazione TypedDataTable in base alle dimensioni stimate del set di dati.

Funzioni di recupero di fact

È possibile scrivere un retriever dei fatti, ovvero un oggetto che implementa metodi standard e li usa in genere per fornire fatti a lungo termine e modificare lentamente i fatti al motore delle regole prima dell'esecuzione dei criteri. Il motore memorizza questi fact nella cache e li utilizza su più cicli di esecuzione. Anziché inviare un fact statico o abbastanza statico ogni volta che si richiama il Motore regole di business, è consigliabile creare una funzione recupero fact che invii il fact la prima volta e ne esegua quindi l'aggiornamento nella memoria solo quando necessario.

Priorità delle regole

L'impostazione di priorità per una regola può variare su entrambi i lati di 0, con numeri più grandi con priorità più alta. Le azioni vengono eseguite nell'ordine dalla priorità più alta alla priorità più bassa. Quando il criterio implementa il comportamento di forward chaining tramite chiamate Assert/Update , il concatenamento può essere ottimizzato usando l'impostazione di priorità. Si supponga, ad esempio, che Rule2 abbia una dipendenza da un valore impostato da Rule1. Assegnando a Rule1 una priorità più alta significa che Rule2 verrà eseguito solo dopo l'attivazione di Rule1 e l'aggiornamento del valore. Viceversa, se Rule2 ha una priorità più alta, può essere attivato una sola volta e quindi generato nuovamente dopo l'attivazione di Rule1 e aggiorna il fatto che Rule2 stia usando in una condizione. I risultati prodotti possono o meno essere corretti, ma è chiaro che una doppia attivazione ha delle conseguenze in termini di prestazioni rispetto alla singola attivazione.

Chiamate di aggiornamento

La funzione Update aggiorna un fatto presente nella memoria di lavoro del motore regole e fa sì che tutte le regole che usano il fatto aggiornato nelle condizioni vengano rivalutate. Le chiamate di funzione di aggiornamento possono essere costose, soprattutto se molte regole devono essere rivalutate a causa dell'aggiornamento dei fatti. In alcune situazioni è tuttavia possibile evitare di rivalutare le regole. Si considerino, ad esempio, le regole seguenti:

Regola1:

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

Regola2:

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

Tutte le regole rimanenti del criterio usano StatusObj.Flag nelle relative condizioni. Pertanto, quando Update viene chiamato sull'oggetto StatusObj , tutte le regole verranno rivalutate. Indipendentemente dal valore del campo Amount , tutte le regole ad eccezione di Rule1 e Rule2 vengono valutate due volte, una volta prima della chiamata Di aggiornamento e una volta dopo la chiamata Di aggiornamento .

È invece possibile impostare il valore del campo flagsu false prima di richiamare il criterio e quindi usare solo Rule1 nel criterio per impostare il flag. In questo caso, update viene chiamato solo se il valore del campo Amount è maggiore di 5 e Update non viene chiamato se l'importo è minore o uguale a 5. Pertanto, tutte le regole ad eccezione di Rule1 e Rule2 vengono valutate due volte solo se il valore del campo Amount è maggiore di 5.

Utilizzo degli operatori logici OR

Il motore regole è ottimizzato per l'esecuzione di operatori AND logici e ricostruisce la regola analizzata in forma normale disgiuntiva in modo che l'operatore OR venga usato solo al livello superiore. L'uso di un numero crescente di operatori OR logici in condizioni crea ulteriori permutazioni che espandono la rete di analisi del motore regole e potrebbe richiedere molto tempo per normalizzare la regola. Nell'elenco che segue sono riportate possibili soluzioni al problema.

• Modificare la regola in modo che sia in forma normale disgiuntiva in modo che l'operatore OR sia solo al livello superiore. Tenere presente che lo sviluppo di una regola in forma normale disgiuntiva in Creazione regole di business può risultare complesso. Può essere preferibile creare la regola a livello di codice.

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

• Provare a suddividere la regola in più regole e fare in modo che queste verifichino la presenza di un flag impostato da una regola eseguita in precedenza oppure utilizzino un oggetto dichiarato da una regola eseguita in precedenza, come mostrato negli esempi seguenti:

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

    Regola 2: se (b == true) THEN ...

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

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

Memorizzazione delle impostazioni nella cache

Il Motore regole di business utilizza due cache, la prima si trova nel servizio di aggiornamento mentre la seconda è presente in ogni processo BizTalk. La prima volta che si utilizza un criterio, il processo BizTalk richiede le informazioni sul criterio dal servizio di aggiornamento. Il servizio di aggiornamento recupera tali informazioni dal database del Motore regole di business, le memorizza nella cache e le restituisce al processo BizTalk. Il processo BizTalk crea un oggetto criterio basato su tali informazioni e lo memorizza in una cache quando l'istanza del Motore regole di business associata completa l'esecuzione del criterio. Quando lo stesso criterio viene richiamato di nuovo, il processo BizTalk riutilizza l'oggetto criterio presente nella cache, se disponibile.

Analogamente, se il processo BizTalk richiede le informazioni su un criterio dal servizio di aggiornamento, tale servizio ne esegue una ricerca nella propria cache. Ogni 60 secondi (1 minuto) il servizio di aggiornamento verifica inoltre l'eventuale presenza di aggiornamenti del criterio nel database. Se tali aggiornamenti sono disponibili, li recupera e aggiorna la cache con le informazioni più recenti.

Esistono tre parametri di ottimizzazione per il motore regole correlati a queste cache: CacheEntries, CacheTimeout e PollingInterval. I valori di tali parametri possono essere specificati nel Registro di sistema o in un file di configurazione.

Il valore di CacheEntries è il numero massimo di voci nella cache. Il valore predefinito di CacheEntries è 32. È possibile aumentare il valore del parametro CacheEntries per migliorare le prestazioni in alcuni casi. Si supponga, ad esempio, di utilizzare 40 criteri in modo ripetuto. In questo caso, è possibile aumentare il valore di CacheEntries a 40 per migliorare le prestazioni. Il servizio di aggiornamento sarà pertanto in grado di memorizzare nella cache i dettagli relativi a 40 criteri (al massimo) e il servizio BizTalk potrà memorizzare nella cache fino a 40 istanze di criteri. Nella cache del servizio BizTalk possono essere contenute più istanze di un criterio.

Il valore di CacheTimeout è il tempo , espresso in secondi, per le voci che escono dalla cache del servizio di aggiornamento. In altre parole, il valore CacheTimeout indica per quanto tempo una voce della cache per un criterio viene mantenuta nella cache se non sono presenti riferimenti. Il valore predefinito di CacheTimeout è 3600 secondi (un'ora). Questo significa che, se non viene fatto alcun riferimento alla voce nella cache per un'ora, tale voce viene eliminata. In alcuni casi, è possibile aumentare il valore CacheTimeout per migliorare le prestazioni. Si supponga, ad esempio, che il criterio venga richiamato ogni due ore. È possibile migliorare le prestazioni dell'esecuzione dei criteri aumentando il valore del parametro CacheTimeout a un valore maggiore di due ore.

Il parametro PollingInterval per il motore regole definisce il tempo in secondi per l'intervallo in cui il servizio di aggiornamento controlla la presenza di aggiornamenti nel database del motore di regole. Il valore predefinito per il parametro PollingInterval è 60 secondi (un minuto). Se è noto che i criteri non vengono aggiornati affatto o vengono aggiornati solo raramente, è possibile aumentare tale valore allo scopo di migliorare le prestazioni.

Proprietà SideEffects

Le classi ClassMemberBinding, DatabaseColumnBinding e XmlDocumentFieldBinding hanno una proprietà denominata SideEffects. Tale proprietà determina se il valore del campo, del membro o della colonna associata viene memorizzato nella cache. Il valore predefinito della proprietà SideEffects nelle classi DatabaseColumnBinding e XmlDocumentFieldBinding è false. Il valore predefinito della proprietà SideEffects nella classe ClassMemberBinding è true. Quando si accede a un campo di un documento XML o di una colonna di una tabella di database per la seconda volta o successivamente all'interno del criterio, il relativo valore viene pertanto recuperato dalla cache. Se, tuttavia, si accede a un membro di un oggetto .NET per la seconda volta o successivamente, il valore viene recuperato dall'oggetto .NET e non dalla cache. L'impostazione della proprietà SideEffects di una classe .NETMemberBinding su false migliorerà le prestazioni perché il valore del campo viene recuperato dalla cache dalla seconda volta in poi. È possibile eseguire questa operazione solo a livello di codice. Lo strumento Business Rule Composer non espone la proprietà SideEffects .

Proprietà Instances e Selectivity

Le classi XmlDocumentBinding, ClassBinding e DatabaseBinding hanno due proprietà: Instances e Selectivity. Il valore di Instances è il numero previsto di istanze della classe nella memoria di lavoro. Il valore di Selectivity è la percentuale delle istanze della classe che passeranno correttamente le condizioni della regola. Il Motore regole di business utilizza tali valori per ottimizzare la valutazione delle condizioni in modo che venga utilizzato prima il numero di istanze minore possibile, per poi passare alle istanze rimanenti. Se si conosce in precedenza il numero di istanze dell'oggetto, l'impostazione della proprietà Instances su tale valore migliorerebbe le prestazioni. Analogamente, se si conosce in precedenza la percentuale di questi oggetti che passano le condizioni, l'impostazione della proprietà Selectivity su tale valore migliorerebbe le prestazioni. È possibile impostare i valori di questi parametri solo a livello di codice. Lo strumento Creazione regole di business non li espone.