in

DotNetSide

Dot Net South Italy Developers User Group

Articoli

Articoli pubblicati dagli iscritti a .netSide

Activities integrate in Workflow Foundation 4 – Parte 1

di Raffaele Fanizzi

Nel precedente articolo ho effettuato un’introduzione a Windows Workflow Foundation 4, mostrando senza scendere nei particolari come è possibile definire un workflow sia programmaticamente, che dichiarativamente utilizzando il designer.

E’ obiettivo di questo articolo iniziare ad esplorare tutte le attività integrate in WF4 al fine di comprendere le potenzialità messe a disposizione da quest’API per modellare la logica applicativa senza scrivere neanche una riga di codice.

Quando apriamo il designer di WF4 sulla toolbox di Visual Studio 2010 compaiono nove diverse tab contenenti le possibili attività utilizzabili per la realizzazione di un workflow:

  • Primitives: integra una serie di attività utili all’esecuzione di operazioni comuni
  • Collection: integra una serie di attività utili alla manipolazione di collezioni di oggetti
  • Control Flow: integra una serie di attività utili all’implementazione del flusso di esecuzione del workflow
  • Flowchart: integra una serie di attività utili all’implementazione del flusso di esecuzione del workflow utilizzando il paradigma dei diagrammi di flusso
  • Runtime: integra una serie di attività utili a manipolare il runtime di WF4
  • Transactions: integra una serie di attività utili alla gestione delle transazioni e della compensazione all’interno del workflow
  • Error Handling: integra una serie di attività utili alla gestione delle eccezioni
  • Messaging: integra una serie di attività utili alla gestione della comunicazione del workflow mediante servizi WCF
  • Migration: integra una serie di attività utili all’uso di attività sviluppate per WF3 in workflow definiti mediante WF4

In questo primo articolo verranno presentate le attività disponibili nelle tab Control Flow e Flowchart. Ulteriori articoli seguiranno per le restanti attività.

Quando si realizza un workflow con Windows Workflow Foundation 4, le due attività che più comunemente utilizzerete come root activity, cioè come attività padre di tutte le altre, saranno Sequence e Flowchart che potete trovare rispettivamente nelle tab Control Flow e Flowchart.

 

Sequence workflow

Sequence è un’attività che consente di porre in sequenza l’esecuzione di due o più attività. Una volta trascinata sul designer del vostro workflow, sarà possibile aggiungere al suo interno ogni tipo di attività necessaria posizionandola sopra o sotto altre attività.

Sequence

 

Sequence fa parte della tab Control Flow all’interno della quale troviamo tutte le altre attività che consentono di definire il flusso di esecuzione del workflow. Alcune di queste riprendono strettamente costrutti tipici della programmazione: If, While, DoWhile, Switch<T> e ForEach<T>.

 

image

L’attività If implementa un punto di decisione basato su un’espressione booleana. La condizione valutata non è altro che un’espressione VB e pertanto sarà elaborata a runtime sulla base del codice Visual Basic .NET inserito. Naturalmente, esattamente come visto nel precedente articolo, nella definizione dell’espressione VB sarà possibile far riferimento agli argomenti in input/output al workflow, così come alle variabili del workflow, a patto che queste ultime siano definite nello scope a cui l’attività If fa riferimento.

L’attività If presenta due branch che vengono eseguite in maniera esclusiva: Then e Else. All’interno di queste branch possono essere inserite altre attività di qualsiasi tipo.

image

 

image

Le attività While e DoWhile rispecchiano gli equivalenti costrutti disponibili in .NET. Esattamente come per l’attività If, anche in questo caso la condizione booleana è definita mediante un’espressione Visual Basic valutata a runtime. Oltre alla condizione, While e DoWhile consentono di definire anche un Body, cioè essenzialmente l’attività da eseguire nel corso dell’iterazione.

image

 

L’attività Switch<T> implementa il classico meccanismo di switch…case tipico dei linguaggi di programmazione .NET. Come si intuisce dal suo nome, si tratta di un’attività generica, cioè di un’attività che richiede la definizione del tipo di oggetto sul quale verrà effettuato lo switch. Trascinandola sul designer dalla toolbox comparirà automaticamente una popup che vi consentirà di scegliere il tipo .NET. Esattamente come per le variabili e i parametri in input, la scelta è possibile tra tutti i tipi visibili al workflow, cioè essenzialmente tutti quelli inclusi nell’elenco dei namespace che potete vedere e modificare cliccando in basso nella finestra del designer sulla voce “Imports”.

Definito il tipo, l’attività Switch<T> vi consentirà di specificare l’espressione Visual Basic che verrà valutata per effettuare lo switching e, per ogni caso che si vorrà gestire, le attività da eseguire. Di default l’attività Switch<T> genera il caso default, tipico delle istruzioni switch…case per indicare le attività da eseguire se il valore risultante dall’espressione Visual Basic non ricade in nessuno dei casi gestiti.

 

image

Analogamente a Switch<T>, anche l’attività ForEach<T> è generica e richiede in input il tipo della collezione enumerabile sulla quale sarà eseguita l’iterazione. Il tipo è uno dei parametri in input all’attività, insieme al nome della variabile che sarà utilizzata per l’elemento corrente all’interno di una iterazione ed alla collezione che dovrà essere di tipo IEnumerable<T>. Nel body sarà quindi possibile inserire le attività da eseguire all’interno dell’iterazione, accedendo alla variabile (che sarà di tipo T) che immagazzina l’elemento corrente della collezione.

Parallel e ParallelForEach<T> possono essere considerate le versioni parallele rispettivamente delle attività Sequence e ForEach<T>. Come i nomi potrebbero far immaginare, queste due attività hanno l’obiettivo di eseguire una serie di attività in parallelo. Tuttavia non bisogna confondere l’esecuzione in parallelo delle attività con la loro esecuzione in multithread. Un’istanza di workflow, infatti, è sempre eseguita utilizzando un unico thread. Questo significa che le Parallel e ParallelForEach<T> eseguono asincronamente tutte le sotto-attività, ma queste sono schedulate comunque in maniera sequenziale. Il vantaggio nell’uso di questi costrutti si rende evidente nel momento in cui le attività che devono eseguire sono potenzialmente costose e, pertanto, vengono implementate in modo asincrono. In quest’ultimo caso, Parallel e ParallelForEach<T> proseguono con le restanti attività mentre l’attività asincrona è in esecuzione. Quando le attività da eseguire non sono asincrone, Parallel e ParallelForEach<T> si comportano rispettivamente in maniera analoga alle attività Sequence e ForEach<T>. Come creare un’attività asincrona sarà oggetto di un altro articolo e pertanto non entro adesso nel merito di questo argomento.

Parallel e ParallelForEach<T>, inoltre, hanno tra i loro parametri di input una CompletionCondition, cioè un’espressione booleana che viene valutata prima di ogni esecuzione delle loro sotto-attività. Quando tale condizione è vera, il ciclo di esecuzione in parallelo si interrompe ed il flusso del workflow riprende dall’attività successiva a quella parallela.

Completiamo questa panoramica sulle attività della tab Control Flow con l’attività Pick. Quest’ultima risulterà molto utile soprattutto quando il workflow dovrà essere messo in attesa di uno o più eventi scatenati dall’host del workflow.

image

 

L’attività Pick si compone di una o più attività PickBranch. Ognuna di essa è composta da un’attività Trigger ed un’attività Action. Quando il flusso di esecuzione del workflow arriva ad un’attività Pick, il runtime valuta simultaneamente tutte le attività Trigger. La prima che è completata, comporta la cancellazione di tutte le altre e l’esecuzione dell’attività Action corrispondente.

Supponiamo di dover modellare un processo secondo il quale il workflow deve restare in attesa di un input da parte dell’utente per un periodo di tempo massimo definito. Con l’attività Pick è possibile modellare tale problematica con una Pick activity che integra due branch. La prima avrà come attività trigger l’input da parte dell’utente, la seconda un’attività Delay (disponibile nella toolbox sotto la tab Primitives) che essenzialmente attende un tot periodo di tempo definito mediante un TimeSpan prima di far proseguire il flusso di esecuzione.

Quando si utilizza l’attività Pick è molto importante considerare che il completamento dell’esecuzione dell’attività Trigger di una branch comporta la cancellazione dell’esecuzione delle attività Trigger delle restanti branch. Questo può comportare problemi se si inserisce all’interno delle attività Trigger molta logica al punto che potrebbe essere stata eseguita un’attività Trigger per metà quando un’altra viene completata e portare a risultati inattesi. Per risolvere questo problema è fondamentale inserire all’interno delle attività Trigger solo ed esclusivamente le attività che servono per definire l’evento che il workflow deve attendere (timer, input da parte dell’utente, chiamata di un web service, ecc…) e delegare all’attività Action l’esecuzione della logica applicativa corrispondente.

 

image

Nell’immagine sopraesposta c’è un esempio di workflow realizzato utilizzando alcune attività del Control Flow che simula il processo di autorizzazione all’acquisto di un oggetto. Naturalmente questo esempio fa un uso un po’ forzato dei vari costrutti al fine di mostrarne il funzionamento e non perché siano realmente necessari in questo specifico caso.

Flowchart workflow

image

Windows Workflow Foundation 4 introduce un nuovo paradigma per la realizzazione di workflow basato sui diagrammi di flusso. Molto spesso quanto un analista deve definire il processo di business di un’applicazione, si avvale dei diagrammi di flusso come formalismo. L’idea alla base del Flowchart di WF 4 è quella di consentire una realizzazione dei workflow più user friendly rispetto all’uso costrutti tipici della programmazione che abbiamo visto con le attività presenti nella tab Control Flow.

Supponiamo di dover definire un workflow in cui, dipendentemente dall’input dell’utente recuperato mediante un’attività, il workflow debba tornare indietro e riprendere l’esecuzione da un’attività già eseguita. Per modellare questo tipo di problematiche utilizzando le attività Control Flow dovremmo affidarci ad artifici come un ciclo While o DoWhile che cicla fino a quando l’input non consente il proseguimento del workflow. Utilizzando il Flowchart, invece, è possibile definire attività e collegarle tra loro mediante una serie di frecce che definiscono il flusso del diagramma. Pertanto non c’è alcun problema nel riprendere l’esecuzione da uno step precedentemente eseguito: è sufficiente collegare un’attività ad una precedente sulla base della valutazione di un’espressione.

All’interno di un diagramma di flusso o Flowchart possono essere presenti dei punti di scelta, che in WF 4 sono rappresentati dalle attività FlowDecision e FlowSwitch<T>. Queste due attività sono simili rispettivamente alle attività If e Switch<T>, ma il loro uso è possibile solo all’interno di un’attività Flowchart.

FlowDecision consente, sulla base di un’espressione Visual Basic booleana, di far proseguire il flusso di esecuzione verso le attività collegate al ramo destro o sinistro. FlowSwitch<T>, invece, rappresenta un punto di scelta esclusivo che valuta un valore e consente di definire per ogni ramo in output il caso che rappresenta, compreso il default.

E’ molto importante chiarire che all’interno di un Flowchart può essere utilizzato qualsiasi tipo di attività (anche quelle appartenenti alla tab Control Flow), ma questa sarà eseguita solo se raggiunta da almeno una freccia. Le attività isolate, cioè non collegate al diagramma di flusso, saranno ignorate.

image

 

 

L’immagine sopraesposta ripropone il precedente workflow realizzato però con un Flowchart.

 

Macchine a stati

Coloro che conoscono Windows Workflow Foundation 3 sicuramente si staranno chiedendo dove sono le macchine a stati, cioè uno dei formalismi attraverso i quali è possibile definire workflow in WF3. In WF4 le macchine a stati non esistono, cioè non esiste un formalismo integrato nella libreria per utilizzarle esplicitamente. Tuttavia esistono due possibilità per coloro i quali vogliono realizzare workflow di questo tipo in WF4:

  • Utilizzare i Flowchart che consentono di definire liberamente il flusso di esecuzione del workflow per simulare il comportamento di una macchina a stati
  • Affidarsi al progetto Workflow Foundation su Codeplex che propone alcune attività custom per implementare esplicitamente macchine a stati
Only published comments... Nov 07 2010, 04:00 PM by VitoA
Attachment: Code.zip
Powered by Community Server (Commercial Edition), by Telligent Systems