Introduction to the Windows Workflow Foundation Rules Engine

 

Jurgen Willis
Microsoft Corporation

Febbraio 2006

Si applica a:
   Windows Workflow Foundation (WF) Beta 2
   Visual Studio 2005

Riepilogo: Questo articolo offre una panoramica delle funzionalità del motore regole in Windows Workflow Foundation (WF). Descrive come vengono usate le condizioni e i RuleSet in WF e illustra il comportamento delle raccolte di regole, tra cui la concatenamento e la traccia in avanti. (18 pagine stampate)

Nota Questo articolo è stato scritto usando beta 2 e in futuro alcune modifiche potrebbero essere necessarie per ottenere questa operazione per lavorare sulle versioni successive di Windows Workflow Foundation.

Contenuto

Introduzione
Panoramica delle regole in Windows Workflow Foundation
Valutazione delle regole
Catena di inoltro
Controllo del concatenamento diretto
Discussione sulla modellazione aggiuntiva
Rilevamento e traccia
Conclusione
Ulteriori informazioni

Introduzione

Con la disponibilità di Windows Workflow Foundation (WF), Microsoft introduce nuove funzionalità delle regole alla piattaforma per sviluppatori WinFX. Queste funzionalità si estendono da condizioni semplici che guidano il comportamento di esecuzione dell'attività fino a set di regole complesse eseguite da un motore regole di concatenamento completo.

La funzionalità delle regole consente la modellazione dichiarativa delle unità di logica dell'applicazione nell'ambito di un processo aziendale complessivo. Gli scenari di esempio per la tecnologia del motore regole sono convalida degli ordini, calcolo dei prezzi, applicazione della promozione, gestione dei processi di eccezione e valutazione delle attestazioni e gestione.

Un obiettivo fondamentale nello sviluppo di questa tecnologia era quello di offrire un'esperienza di flusso di lavoro e regole veramente integrata. In tutto il settore, le regole e il flusso di lavoro sono in genere state tecnologie abbastanza distinte, in genere fornite da diversi fornitori. I motori delle regole di terze parti sono spesso incorporati o integrati dai provider di gestione dei processi aziendali e del flusso di lavoro, ma l'esperienza di sviluppo e amministrazione non è chiaramente una soluzione semplice.

Con WF, Microsoft è stato molto incentrato sulla fornitura di un'esperienza di sviluppo semplice tra la modellazione del flusso di lavoro e delle regole, in modo da consentire agli sviluppatori di incorporare facilmente le regole in qualsiasi punto del flusso di lavoro. Gli sviluppatori sono in grado di stabilire se modellare la logica nel modello di flusso di lavoro, nelle regole o nel codice senza dover preoccuparsi delle implicazioni di integrazione di tali decisioni. Ciò è stato raggiunto, tuttavia, senza sacrificare la possibilità di eseguire regole all'esterno dell'ambito di un flusso di lavoro.

Un secondo obiettivo chiave è stato quello di fornire un modello semplice per gli sviluppatori da usare per definire le regole. La tecnologia delle regole è stata spesso una tecnologia di nicchia, usata da un gruppo di regole altamente specializzato. Anche se i miglioramenti apportati agli strumenti hanno ampliato il set di singoli utenti che usano regole, i modelli hanno spesso richiesto agli utenti di essere troppo distribuiti nella meccanica di implementazione del motore sottostante. Per fornire le funzionalità delle regole nella piattaforma, è stato scelto un modello che sarà raggiungibile dall'ampia community per sviluppatori .NET e infine non sviluppatori. Anche se ci sarà sempre un certo livello di competenza del dominio, come per qualsiasi tecnologia, l'obiettivo è che tutti gli sviluppatori .NET possano aumentare rapidamente il modello di regole e incorporarlo facilmente nelle proprie applicazioni.

Oltre a fornire un modello avvicinabile, WF offre anche un potente motore di valutazione per supportare scenari di regole complesse, una valutazione concatenamento impegnativa e un controllo di valutazione preciso. Ciò viene fornito in modo che fornisca numerosi punti di estendibilità, consentendo agli sviluppatori di compilare le funzionalità della piattaforma e offrire funzionalità di supporto di un'ampia gamma di scenari.

Questo documento fornisce un'introduzione tecnica alle funzionalità delle regole fornite in WF e una panoramica delle funzionalità disponibili e dell'uso. Alla fine di questo documento è un elenco di risorse aggiuntive che possono essere usate per informazioni sulle funzionalità delle regole in WF.

Panoramica delle regole in Windows Workflow Foundation

La tecnologia regole viene esposta in due modi chiave in WF, come condizioni sulle attività e come set di regole di concatenamento inoltrato nell'attività Criteri. La catena di inoltro verrà illustrata più avanti nel documento; brevemente messo, si riferisce alla possibilità di eseguire le azioni di una regola per causare la rivalutazione di altre regole dipendenti.

Condizioni attività

Le condizioni vengono usate dalle quattro attività seguenti che vengono fornite con WF:

• IfElseBranch
• While
• Replicator
• ConditionedActivityGroup (CAG)

Le condizioni vengono usate per guidare il comportamento di esecuzione di queste attività, ad esempio determinando se un determinato ifElseBranch verrà eseguito. Le condizioni possono essere specificate come CodeConditions, che avranno un gestore configurato nel codice accanto o come RuleConditionReference. Una regolaConditionReference punta a una definizione RuleCondition in un file con estensione rules associato al flusso di lavoro nel progetto del flusso di lavoro. L'esperienza in Visual Studio è illustrata nella figura 1.

Figura 1. Creazione di regole WF

Aggiunta di una condizione di regola

Questi sono i passaggi coinvolti nell'aggiunta di una condizione di regola a un'attività IfElseBranch che si trova all'interno dell'attività IfElse:

1. Quando viene selezionata un'attività con una condizione (come con l'attività IfElseBranch illustrata) viene visualizzata una proprietà Condition nella griglia Proprietà.
2. Un elenco a discesa per la proprietà Condition consente all'utente di selezionare codeCondition o RuleConditionReference.
3. Se RuleConditionReference è selezionato, la proprietà Condition può essere espansa per visualizzare le proprietà ConditionName ed Expression.
4. Dopo aver specificato un nome di condizione, i puntini di sospensione nella proprietà Expression vengono selezionati per avviare l'Editor condizione regola. Questo editor consente allo sviluppatore di digitare nella condizione nel formato di testo, con supporto intellisense simile. Il testo viene analizzato nella rappresentazione del modello a oggetti associata della RegolaCondition.
5. Dopo aver selezionato OK, la definizione RuleCondition viene serializzata in un <file WorkflowName.rules> aggiunto al progetto.

Per fare riferimento a campi o proprietà nel flusso di lavoro, è possibile digitare questa proprietà nell'editor. Dopo aver digitato il punto, viene visualizzato un menu simile a intellisense che consente di selezionare i membri nel flusso di lavoro (è anche possibile digitare direttamente il membro). Le chiamate annidate possono essere eseguite anche; ad esempio , this.order.Total. I metodi statici possono essere chiamati sui tipi a cui si fa riferimento digitando il nome della classe seguito dal nome del metodo, come si farebbe nel codice.

Le espressioni sono supportate con gli operatori relazionali seguenti:

• Uguale ("==" o "=")
• Maggiore di (">")
• Maggiore o uguale (">=")
• Minore di ("<")
• Minore o uguale ("<=")

È inoltre possibile usare gli operatori aritmetici seguenti:

• Aggiungi ("+")
• Sottrazione ("-")
• Moltiplica ("*")
• Divide ("/")
• Modulo ("MOD")

Le espressioni possono essere combinate/negate usando gli operatori seguenti:

• AND ("AND", "&&")
• OR ("OR", "||")
• NOT ("NOT", "!")
• Bit per bit e ("&")
• Bit per bit o ("|")

Il motivo principale per cui uno sviluppatore usa una condizione regola anziché una condizione di codice è che le condizioni della regola diventano parte del modello e possono essere aggiornate dinamicamente in fase di esecuzione nelle istanze del flusso di lavoro. Un vantaggio secondario delle condizioni delle regole è che, come parte del modello, è possibile creare strumenti più sofisticati sopra il modello per offrire esperienze di creazione aggiuntive, gestione delle dipendenze, analisi tra condizioni e così via.

Attività dei criteri

L'attività Criteri incapsula la definizione e l'esecuzione di un RuleSet. RuleSet è una raccolta di regole con un set di semantiche di esecuzione. Le regole sono, a sua volta, espressioni If-Then-Else che operano sui membri del flusso di lavoro. L'esperienza è illustrata nella figura 2 ed è simile a quella vista con le condizioni della regola.

Figura 2. Creazione di WF RuleSet

Aggiunta di un'attività di criteri

Per configurare un set di regole per l'attività dei criteri, seguire questa procedura:

1. Trascinare l'attività dei criteri dalla casella degli strumenti nella finestra di progettazione del flusso di lavoro.
2. In RuleSetReference viene fornito un nome per il RuleSet.
3. Se si selezionano i puntini di sospensione nel campo Definizione del set di regole, viene avviato l'editor del set di regole.
4. L'editor mostra una raccolta di regole in una casella di riepilogo.
5. Se si seleziona una determinata regola, vengono visualizzate le relative azioni Condition, Then actions, Else actions e un set di proprietà aggiuntive.
6. Come nell'Editor condizione delle regole, le azioni Condition, Then e Else vengono immesse come testo e analizzate nella rappresentazione del modello a oggetti associata; le regole vengono compilate in base ai membri del flusso di lavoro.
7. Se si seleziona OK , il set di regole viene serializzato nel file con estensione rules associato al flusso di lavoro.

Si noti che la selezione dei puntini di sospensione nella proprietà RuleSetReference avvierà l'editor che consente all'utente di selezionare un RuleSet esistente o aggiungere/rinominare/rimuovere RuleSet, come illustrato nella figura 3.

Figura 3. WF RuleSet Browser

Valutazione delle regole

Ogni regola in un RuleSet ha un valore di priorità con un valore predefinito pari a 0. Le regole in un RuleSet possono essere considerate una raccolta ordinata, ordinata in base ai valori di priorità. L'analizzatore regole WF valuta le regole singolarmente ed esegue le azioni della regola in base ai risultati della valutazione della condizione della regola.

Il meccanismo di valutazione può essere descritto concettualmente con la procedura seguente:

1. Iniziare dall'elenco delle regole attive.
2. Ricercare la regola avente la priorità più elevata.
3. Valutare la regola ed eseguirne le azioni Then/Else appropriate.
4. Se le azioni di una regola aggiornano un campo o una proprietà usata da una regola precedente nell'elenco (una con priorità più alta), rivalutare la regola precedente ed eseguire le relative azioni in base alle esigenze. Si noti che vengono rivalutate solo le regole con una dipendenza specifica.
5. Continuare il processo fino a quando non vengono valutate tutte le regole nel RuleSet.

Si osservi l'esempio seguente. Si supponga di avere il ruleset seguente, in cui A, B e così via, rappresentano i dati nel flusso di lavoro.

Regola4 (priorità = 4)

IF A = 15
THEN B = 5

Rule3 (P=3)

IF C = 5
THEN B = 10

Regola2 (P=2)

IF D = 2
THEN A = 15

Rule1 (P=1)

IF B = 5
THEN E = 7

Si supponga che i dati di input siano:

• A = 0
• B = 0
• C = 5
• D = 2
• E = 0

La valutazione procede come segue:

• La regola4 viene valutata; restituisce false e poiché non ha azioni Else , non viene eseguita alcuna azione.
• Rule3 restituisce true e viene eseguita l'azione, impostando B = 10. Rule4 non dipende dal valore di B, quindi la valutazione procede a Rule2.
• Rule2 restituisce true e viene eseguita l'azione, impostando A = 15.
• Poiché Rule4 usa il valore di A nelle sue condizioni, viene rivalutato. Restituisce true e la relativa azione viene eseguita, impostando B = 5; Rule3 e Rule2 non vengono rivalutati perché le relative condizioni non si basano sul valore di A. Nessuna regola precedente dipende dal valore di B, quindi la valutazione procede a Rule1.
• Rule1 restituisce true e la relativa azione viene eseguita, impostando E = 7.

Il set di dati risultante sarà ora:

• A = 15
• B = 5
• C = 5
• D = 2
• E = 7

Concatenamento di inoltro

Come illustrato in precedenza, il concatenamento si basa sulle dipendenze identificate tra le regole; in particolare, le dipendenze tra le azioni di una regola e le condizioni di altre regole. Queste dipendenze possono essere identificate o dichiarare in uno di tre modi:

• Implicita
• Basato su attributi
• Esplicita

Implicita

Le dipendenze implicite vengono identificate automaticamente dal motore. Quando un RuleSet viene eseguito per la prima volta, ogni regola viene analizzata per valutare i campi o le proprietà letti nella condizione e scrive in nelle azioni. A tale scopo, l'espressione viene eseguita nella condizione e nelle istruzioni nelle azioni. Si supponga, ad esempio, le regole seguenti.

Regola 1

IF this.subtotal > 10000
THEN this.discount = .05

Regola 2

IF this.discount > 0
THEN this.total = (1-this.discount) * this.subtotal

Il motore valuta le regole e identifica che la regola 1 legge il campo subtotale e scrive nel campo sconto. La regola 2 legge i campi sconto e subtotale e scrive nel campo totale. Pertanto, la regola 2 ha una dipendenza dalla regola 1; il risultato è che il motore garantirà che la regola 2 venga valutata/rivalutata ogni volta che la regola 1 esegue l'azione Then .

Si noti che le dipendenze vengono identificate a livello di nodo foglia. Prendere il set di regole seguente.

Regola 1

IF this.order.Subtotal > 10000
THEN this.order.Discount= .05

Regola 2

IF this.order.Discount > 0
THEN this.order.Total = (1-this.order.Discount) * this.order.Subtotal

Regola 3

IF this.order.CustomerType = "Residential"
THEN ...

Una dipendenza viene comunque identificata tra le regole 1 e 2. Tuttavia, la regola 3 non avrebbe una dipendenza dalla regola 1 o 2, poiché né aggiorna la proprietà CustomerType . In altre parole, la dipendenza viene identificata al livello della proprietà CustomerType , non all'oggetto Order stesso.

Tramite il concatenamento implicito, WF esegue la maggior parte del concatenamento necessario per l'utente, in modo che l'utente non debba modellare in modo esplicito gli aggiornamenti e può, di fatto, non essere a conoscenza del concatenamento o della necessità, nella maggior parte dei casi. Ci aspettiamo che questo renderà più semplice la modellazione di ruleset complessi per la maggior parte degli utenti e rendere la nozione di concatenamento di un potente, ma per lo più nascosto, funzionalità del motore. Tuttavia, i due altri meccanismi per guidare il concatenamento, basato su attributi ed espliciti, vengono forniti per scenari più complessi e specifici.

Basato su attributi

Per chiamate al metodo all'interno di una regola, diventa più difficile valutare in modo deterministico le letture/scritture che si verificano. Per risolvere questo problema, WF fornisce tre attributi che possono essere applicati a un metodo per indicare le relative azioni:

• RuleRead
• RuleWrite
• RuleInvoke

L'attribuzione di un metodo con l'attributo RuleRead indica che legge la proprietà indicata. Analogamente, l'attributo RuleWrite può essere usato per indicare che un metodo aggiorna un determinato campo o proprietà. Si supponga che le prime due regole nella sezione implicita siano state riscritte come indicato di seguito.

Regola 1

IF this.subtotal > 10000
THEN this.SetDiscount(.05)

Regola 2

IF this.discount > 0
THEN this.total = (1-this.discount) * this.subtotal

Il metodo SetDiscount può quindi essere attribuito come indicato di seguito, consentendo al motore di identificare che la regola 2 dipende dalla regola 1 a causa dell'uso del campo sconto.

[RuleWrite("discount")] 
void SetDiscount(double requestedDiscount)
{
     ...//some code that updates the discount field
}

L'attributo RuleInvoke può essere usato per dettare le dipendenze a causa di chiamate al metodo collegato. Si supponga, ad esempio, la modifica seguente alle regole e ai metodi.

Regola 1

IF this.subtotal > 10000
THEN this.SetDiscountWrapper(.05)

Regola 2

IF this.discount > 0
THEN this.total = (1-this.discount) * this.subtotal

[RuleInvoke("SetDiscount")]
void SetDiscountWrapper(double requestedDiscount)
{
     ...
     SetDiscount(requestedDiscount);
     ...
}

[RuleWrite("discount")] 
void SetDiscount(double requestedDiscount)
{
}

La condizione della regola 2 chiama SetDiscountWrapper, che a sua volta chiama SetDiscount, che scrive nel campo sconto. L'attributo RuleInvoke consente di dichiarare e rilevare questa scrittura indiretta dal motore.

È importante riconoscere che il campo o la proprietà a cui si fa riferimento nel percorso dell'attributo fa riferimento a un campo o a una proprietà nella stessa classe del metodo, che non è necessariamente l'oggetto radice passato al RuleSet per l'esecuzione. Ad esempio, è possibile attribuire la classe Order come indicato di seguito.

public class Order
{
     private double discount;

     public double Discount
     {
     get { return discount;}
     set { discount = value;}
     }

     [RuleWrite("Discount")] 
     void CalculateDiscount(double requestedDiscount, double weighting)
     {
...//some code that updates the discount field
     }
}

È quindi possibile usare un'istanza di questa classe in un flusso di lavoro come indicato di seguito.

public class Workflow1 :  SequentialWorkflowActivity
{
     private Order discount;

     ...
}

L'esecuzione della regola 2 provocherebbe la rivalutazione della regola 1.

Regola 1

IF this.order.Discount > 5
THEN ...

Regola 2

IF ...
THEN this.order.CalculateDiscount( 5.0, .7)

Alcuni punti aggiuntivi sull'uso degli attributi:

• Gli attributi puntano alle proprietà/campi nella classe Owner , non ai parametri di una chiamata al metodo.
• I caratteri jolly possono essere usati anche negli attributi della regola. Ad esempio, RuleWrite("order/*") può essere usato per indicare che tutti i campi dell'oggetto a cui fa riferimento il campo "order" vengono modificati dal metodo (in questo esempio il metodo si trova nel flusso di lavoro stesso, non nella classe Order ). Il carattere jolly può essere usato solo alla fine del percorso, anche se; un attributo come RuleWrite("*/Discount") non è valido.
• Un attributo come RuleWrite("order") può essere usato con i tipi di riferimento per indicare che il riferimento è cambiato, ad esempio per indicare che la variabile punta ora a un'istanza di Order diversa. Tutte le regole che usano un campo/proprietà nella variabile verranno considerate interessate, oltre a tutte le regole che testano il riferimento all'istanza stessa, ad esempio IF this.order == this.order2.
• Il comportamento predefinito se non vengono specificati attributi di metodo è che si presuppone che una chiamata al metodo venga letti tutti i campi/proprietà nell'oggetto di destinazione (l'oggetto in cui viene richiamato il metodo), ma scrive in nessuno di essi. Si presuppone inoltre che un metodo venga letto dai parametri passati a esso, ma si presuppone che non venga scritto in nessuno di essi. I parametri out e ref vengono considerati scritti in quando vengono usati nelle azioni delle regole.

Esplicita

Il meccanismo finale per indicare le dipendenze di campo/proprietà è tramite l'uso dell'istruzione Update . L'istruzione Update accetta come argomento una stringa che rappresenta il percorso di un campo o di una proprietà o un'espressione che rappresenta un accesso a un campo/proprietà. Ad esempio, una delle due istruzioni seguenti può essere digitata nell'editor RuleSet per creare un'istruzione Update sulla proprietà Name di un'istanza del cliente nel flusso di lavoro.

Update("this/customer/Name") 

OR

Update(this.customer.Name)

L'istruzione Update indica che la regola scrive nel campo/proprietà indicato. Ciò avrà lo stesso effetto di un set diretto della proprietà/campo nella regola o la chiamata di un metodo con un attributo RuleWrite per il campo/proprietà.

Il comando Update supporta anche l'uso di caratteri jolly. Ad esempio, è possibile aggiungere il comando Update seguente a una regola.

Update("this/customer/*")

In questo modo, tutte le regole che usano qualsiasi proprietà nell'istanza del cliente devono essere rivalutate. In altre parole, ognuna delle due regole seguenti verrebbe rivalutata.

IF this.customer.ZipCode == 98052
THEN ...

IF this.customer.CreditScore < 600
THEN ...

In genere, non è previsto che gli utenti dovranno modellare istruzioni di aggiornamento esplicite nella maggior parte degli scenari. Il concatenamento implicito deve fornire l'analisi delle dipendenze e il comportamento di concatenamento necessari nella maggior parte degli scenari. L'attributo del metodo deve supportare gli scenari più diffusi in cui il concatenamento implicito non può identificare le dipendenze. In generale, l'assegnazione del metodo è il metodo preferito per indicare le dipendenze sull'uso dell'istruzione Update , poiché la dipendenza può essere identificata una volta sul metodo e sfruttata tra molte regole diverse che usano tale metodo. Inoltre, negli scenari in cui il writer delle regole e l'implementazione del metodo sono diversi individui (o il lavoro viene eseguito in momenti diversi), l'attributo del metodo consente al writer del metodo, che conosce meglio il codice, di identificare le dipendenze del metodo.

Tuttavia, ci saranno alcuni scenari in cui l'istruzione Update sarà la soluzione appropriata, ad esempio quando un campo/proprietà viene passato a un metodo su una classe che il writer del flusso di lavoro non controlla e pertanto non può attributo, come nel codice seguente.

IF ...
THEN this.customer.UpdateCreditScore(this.currentCreditScore)
     Update(this.currentCreditScore)

Controllo del concatenamento diretto

Il concatenamento in avanti è una nozione molto potente che consente l'assemblaggio di regole atomiche in RuleSet senza la definizione di, o necessariamente anche la conoscenza delle dipendenze tra le regole.

Tuttavia, in alcuni scenari, il writer di regole potrebbe voler fornire maggiore controllo sul comportamento di concatenamento, in particolare la possibilità di limitare la concatenazione che si verifica. Ciò consente al modello di regola di:

• Limitare l'esecuzione ripetitiva di regole in grado di comportare risultati non corretti.
• Migliorare le prestazioni.
• Impedire cicli runaway.

Questo livello di controllo è facilitato nelle regole WF da queste due proprietà:

• Proprietà Comportamento concatenamento nel RuleSet.
• Proprietà Comportamento di rivalutazione in ogni regola.

Entrambi questi valori possono essere impostati nell'editor RuleSet.

Comportamento concatenamento, proprietà

La proprietà Chaining Behavior in RuleSet ha tre valori possibili:

• Concatenamento completo
• Concatenamento esplicito
• Sequenziale

L'opzione Full Chaining è l'impostazione predefinita e fornisce il comportamento descritto fino a questo punto. L'opzione Concatenamento esplicito disattiva il concatenamento implicito e basato su attributi e specifica che il concatenamento deve verificarsi solo per istruzioni di aggiornamento esplicite. Ciò consente al writer di regole di controllare completamente le regole che causano la rivalutazione. In genere, questa operazione viene usata per evitare dipendenze cicliche che causano un'esecuzione eccessiva (o anche runaway) della regola o per migliorare le prestazioni eliminando la rivalutazione della regola superflua non necessaria per fornire completezza funzionale del RuleSet.

L'opzione finale è Sequenziale. Questa opzione causerà al motore di valutare le regole in modo rigorosamente lineare. Ogni regola verrà valutata una sola volta e una sola volta e nell'ordine di priorità. Le regole con priorità più elevata potrebbero influire sulle regole con priorità inferiori, ma l'inverso non sarebbe vero perché non si verificherebbe alcuna concatenazione. Pertanto, questa opzione si utilizza quando le priorità vengono assegnate esplicitamente, a meno che fra le regole non esista alcuna dipendenza.

Reevaluation Behavior, proprietà

Il comportamento di rivalutazione nella regola ha due valori possibili:

• Sempre
• Mai

Sempre è il valore predefinito e fornisce il comportamento illustrato in precedenza, ovvero che la regola verrà sempre rivalutata in base alla concatenamento a causa delle azioni di altre regole. Mai, come implica il nome, disattiva questa rivalutazione. La regola verrà valutata una sola volta, ma non verrà rivalutata se è stata eseguita in precedenza qualsiasi azione. In altre parole, se la regola è stata valutata in precedenza ed è stata eseguita le azioni Then o Else , non verrà rivalutata. L'esecuzione di un insieme di azioni vuote nelle azioni Then o Else non contrassegnerà una regola come eseguita, anche se.

In genere, questa proprietà verrà usata, a livello di regola, per evitare un ciclo infinito a causa delle dipendenze che la regola ha, sia sulle proprie azioni che su altre regole. Ad esempio, la regola seguente creerebbe il proprio ciclo infinito e la rivalutazione non è necessaria per soddisfare i requisiti funzionali della regola.

IF this.shippingCharge < 2.5 AND this.orderValue > 100
THEN this.shippingCharge = 0

In alternativa, se la regola è destinata a essere rivalutata, ma solo se il campo OrderValue viene modificato, l'utente può impostare il comportamento di concatenamento sul RuleSet solo su catena su istruzioni di aggiornamento esplicite (e quindi aggiungere tali istruzioni update alle azioni di regola pertinenti). Naturalmente, l'utente potrebbe aver aggiunto un predicato aggiuntivo a questa regola che verifica che il valore di ShippingCost non sia già 0, ma i controlli di concatenamento rimuoveno la necessità per gli utenti di definire le loro regole in base ai dettagli di valutazione, anziché ai loro requisiti aziendali.

Funzione Halt

Come controllo finale, una funzione Stop può essere aggiunta come azione regola (digitare semplicemente " Arresta " nelle caselle di azione Then o Else nell'editor). Questo arresterà immediatamente l'esecuzione di RuleSet e restituirà il controllo al codice chiamante. Naturalmente, l'utilità di questa funzione non si limita necessariamente agli scenari di controlli di concatenamento. Un RuleSet con un obiettivo funzionale specifico, ad esempio, può usare una funzione Stop per l'esecuzione a corto circuito dopo aver raggiunto l'obiettivo.

Discussione sulla modellazione aggiuntiva

Esecuzione basata su priorità

Come accennato in una sezione precedente, se gli utenti desiderano una determinata sequenza di esecuzione per RuleSet o un subset di regole in tale RuleSet, possono definire esattamente questa sequenza usando il campo di priorità in una regola. In questo modo spesso rimuove il requisito per la concatenazione e gli utenti possono anche disattivare la concatenazione in questi scenari. È stato rilevato che in molti casi le dipendenze delle regole possono essere soddisfatte semplicemente fornendo sequenziamento esplicito dell'esecuzione.

È importante notare, tuttavia, che il meccanismo di esecuzione in avanti in WF offre una funzionalità per gli utenti per definire una sequenza di esecuzione, ma non richiede di farlo. Nella maggior parte dei casi, il comportamento di concatenamento in avanti rende l'assegnazione delle priorità delle regole non necessarie per ottenere il risultato ruleSet corretto, poiché le relazioni vengono gestite automaticamente dal motore per garantire che vengano soddisfatte le dipendenze delle regole.

Prendere le regole seguenti.

Regola 1

IF this.Weather.Temperature < 50
THEN this.Drink.Style = "Latte"

Regola 2

IF this.Drink.Style == "Latte"
THEN this.Snack.Style = "Scone"
ELSE this.Snack.Style = "Muffin"

In WF è possibile fornire una priorità più alta sulla regola 1 in modo che venga eseguita prima. Ciò garantisce che Drink.Style sia impostato prima della valutazione della regola 2.

La sequenziazione non è tuttavia necessaria per ottenere i risultati desiderati. Si supponga che la regola 2 sia stata valutata prima. In questo caso, l'oggetto Drink.Style può essere null o potrebbe essere un altro stile. Ciò comporta l'impostazione Snack.Style su Muffin. Tuttavia, dopo l'esecuzione della regola 1 e l'impostazione di Drink.Style su Latte, la regola 2 verrà rivalutata e imposta lo Snack.Style su Scone. Essenzialmente, l'utente ha l'opzione di dettatura della sequenza, ma in molti casi non è necessario farlo.

Elaborazione raccolta

In alcuni scenari potrebbe essere necessario valutare le regole su tutti gli elementi singolarmente in una raccolta. L'iterazione sulla raccolta può essere eseguita in diversi modi, ma un modo è con un modello di regola, ad esempio questo:

Regola 1 (priorità = 2)

//always execute this rule once to create the enumerator
IF 1==1 
THEN this.enumerator = this.myCollection.GetEnumerator()

Regola 2 (priorità = 1)

IF this.enumerator.MoveNext()
THEN this.currentInstance = this.enumerator.Current

Regole 3-N (priorità = 0)

.... //additional rules written against this.currentInstance

Regola N+1 (priorità = -1)

// can be any condition as long as it is evaluated every time;
// this.currentInstance will be evaluated each time 
//this.currentInstance changes, whereas 
// "1==1" would only be evaluated once
IF this.currentInstance == this.currentInstance  
                                                                           
THEN ...
         Update("this/enumerator") //this will cause Rule 2 to be reevaluated
ELSE ...
          Update("this/enumerator")

Rilevamento e traccia

Rilevamento

Quando viene eseguito un RuleSet, gli eventi di rilevamento vengono inviati ai servizi di rilevamento configurati negli host che hanno registrato per questi eventi aggiungendo un Oggetto UserTrackPoint al profilo di rilevamento. Viene inviato RuleActionTrackingEvent , che fornisce il nome della regola valutata, nonché il risultato della valutazione della condizione (true/false). Per un esempio, vedere l'esempio RuleActionTrackingEvent in SDK.

I risultati della valutazione delle condizioni delle regole possono essere rilevati in modo implicito durante l'esecuzione dell'attività di rilevamento.

Traccia

Altre informazioni di valutazione di RuleSet possono essere inviate a un file di log aggiungendo quanto segue a un file di configurazione dell'applicazione.

<configuration>
   <system.diagnostics>
      <switches>
           <add name="Rules" value="Information"/>
      </switches>
   </system.diagnostics>
</configuration>

Le informazioni seguenti verranno inviate al file di log:

• Informazioni sulle dipendenze delle condizioni:
  • Esempio: Dipendenza della regola "ReturnNumberOfStops": "this/currentFlight/OutboundFlight/NumberOfStops/"
• Informazioni sull'effetto collaterale dell'azione:
  • Esempio: Regola "ReturnNumberOfStops" QUINDI effetto collaterale: "this/currentFlight/Score/"
• Relazione di concatenamento:
  • Esempio: Regola "ReturnNumberOfStops" regola di trigger delle azioni THEN "ApprovedFlights"
• Esecuzione ruleSet:
  • Esempio: Regole: "Esecuzione di RuleSet FlightRuleSet"
• Valutazione delle condizioni:
  • Esempio: Regole: Valutazione della condizione sulla regola "SetDefaultScore"
• Risultato della valutazione delle condizioni:
  • Esempio: Regole: condizione valutata su True
• Esecuzione dell'azione:
  • Esempio: Regole: Azioni di valutazione THEN per la regola "SetDefaultScore"

Tutti i messaggi di traccia sono attualmente definiti a livello di "Informazioni", quindi è necessario specificare un livello di informazioni o verbose nel file di configurazione per visualizzare la traccia delle regole.

Conclusione

WF offre una funzionalità di regole flessibili che possono essere sfruttate in molti modi diversi per supportare un'ampia gamma di scenari. Dalle semplici condizioni di attività ai set di regole di inoltro sofisticate, la tecnologia consente di integrare facilmente le regole di supporto nei flussi di lavoro. Inoltre, il motore regole può anche essere sfruttato all'esterno dei flussi di lavoro per fornire funzionalità delle regole a qualsiasi applicazione .NET.

Il set di funzionalità consente ai nuovi sviluppatori di incorporare facilmente regole semplici nei flussi di lavoro, fornendo comunque la ricchezza e l'estendibilità per supportare scenari RuleSet e applicazioni molto più avanzati. Questo documento, combinato con le risorse menzionate nella sezione successiva, dovrebbe aiutare gli sviluppatori a scoprire le regole WF sulla tecnologia e diventare rapidamente produttivi con il relativo uso.

Ulteriori informazioni

• Sito del flusso di lavoro MSDN

  Numerosi documenti e collegamenti ai webcast e ai lab.

• Esempi di sito della community

  • External RuleSet Toolkit: fornisce un esempio di come esternare le regole dagli assembly del flusso di lavoro.
  • Analisi RuleSet: uno strumento per analizzare RuleSet per le relazioni tra regole e tra regole e dati.
  • Regole in Excel: fornisce un esempio di come usare regole autonome, all'esterno di un flusso di lavoro. Viene anche illustrato come creare regole a livello di codice create tramite una tabella decisionale in Excel.

• Esempi di SDK

  • IfElseWithRules: mostra l'uso di una RegolaCondition in un'attività IfElse (in \Technologies\RulesAndConditions).
  • DynamicUpdateChangingRules: illustra l'uso delle API di aggiornamento dinamico per modificare una RegolaCondition in un'istanza del flusso di lavoro in esecuzione (\Technologies\RulesAndConditions).
  • SimplePolicy: illustra l'uso delle API per definire una semplice attività RuleSet e criteri (\Technologies\Activity\Policy).
  • AdvancedPolicy: definisce un RuleSet più complesso (\Technologies\Activities\Policy).
  • RuleActionTrackingEventSample: illustra come acquisire i risultati della valutazione delle regole in un provider di rilevamento (\Technologies\Tracking).

• Forum del flusso di lavoro MSDN

  • Per domande correlate a Regole WF o WF in generale, visitare questo forum di discussione.

 

Informazioni sull'autore

Jurgen Willis è un Program Manager nel team di Windows Workflow Foundation con responsabilità della tecnologia del motore regole e delle attività guidate dalle regole. Prima di partecipare a Microsoft, Jurgen ha progettato e implementato soluzioni di integrazione e gestione dei processi per le aziende Fortune 500.