www.infkoffler.com - Site de cours d'informatique

Accueil

Java Standard Edition

Java EE 5

Visual Basic .Net 2005

Cours Javascript - DOM - DHTML

Nouveautés sur le site

Contacts

Accueil > Visual Studio 2008 > Windows Workflow Foundation(WF)

____________________________________________________________________________________________________

Connexion

Windows Workflow Foundation (WF)

6/05/2008

Il existe deux types de workflows sous Windows Workflow Foundation: les Sequential WorkFlow et les State Machine WorkFlow.

Un workflow de WF n’est qu’un type d’application, d’ailleurs on crée un projet de type « Sequential Workflow Console Application » ou « State Machine Workflow Console Application »( ou autre). Ces deux projets sont des applications console.

I)Les projets de type Sequential Workflow Console Application

Commençons par les Sequential Workflow. Il s’agit d’une application, qui peut être écrite sous la forme d’un Workflow séquentiel. Un workflow séquentiel est d’abord un workflow, c'est-à-dire un flux de travail. De plus, l’exécution de ce flux est de type séquentielle, c'est-à-dire que les actions (appelées « activités ») s’enchaînent les unes aux autres. Ce type d’application a une architecture particulière, et commune à toutes les applications de ce type.
WF a modélisé cette architecture, et permet de construire une telle application très facilement. Il suffit de décrire uniquement les caractéristiques du flux séquentiel, c'est-à-dire les activités, comment elles s’enchainent, les conditions, etc. Cette description peut être réalisée de manière très souple et maintenable, avec le designer. On peut aussi décrire le workflow par code (c# par exemple). Le designer transforme notre schéma de workflow en lignes de code (c# ou autre). Nous ne verrons pas ici comment créer le workflow par le designer, cela existe dans d’autres cours, et est intuitif. On suppose ici que vous savez le faire. C’est une explication des lignes autogénérées.

II) Les projets de type State Machine Workflow Console Application

Commençons par cet extrait de MSDN :
"Building State Machines with Windows Workflow Foundation
State Machine workflows represent a different way of visualizing program logic. Rather than flowing from activity to activity like sequential workflows, State Machines transition from state to state. Learn about uses for State machines and see how to design and build a State Machine workflow with Windows Workflow Foundation."

Les State Machine Workflow sont un autre type de workflow, mais constituent toujours un flux de travail. La différence avec les Sequential Workflows est qu’il ne s’agit plus d’un flux séquentiel des activités, mais d’une machine à états (automate) allant d’un état à un autre, le flux étant le changement d’états. C’est une façon différente d’écrire la logique de l’application, qui est plus ou moins bien adaptée que le Sequential Workflow, suivant notre flux de travail. Une fois de plus, c’est une architecture particulière prédéfinie, de même que le Sequential Workflow.

III) Les lignes les plus importantes du main de Program.cs, d’un projet Sequential Workflow Console Application (ces lignes sont autogénérées)

La classe WorkflowRuntime ( espace de noms System.Workflow.Runtime, provenant de la dll du même nom). Elle représente un moteur de workflow, qui sera capable d’exécuter vos workflow.
MSDN nous dit bien “A workflow built on Windows Workflow Foundation is a component that requires an ad hoc runtime environment to function. The workflow runtime environment is represented by the WorkflowRuntime class.”, autrement dit un workflow créé avec Windows Workflow Foundation a besoin d’un environnement d’exécution approprié pour fonctionner; l’environnement d’exécution est représenté par la classe WorkflowRuntime.

Il faut d’abord instancier un objet de cette classe :

WorkflowRuntime workflowRuntime = new WorkflowRuntime( );

Puis on peut créer un objet représentant notre workflow :

WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(monNameSpace.
Workflow1)) ;

Prototype: WorkflowInstance CreateWorkflow( Type workflowType)

Instance est l’objet représentant notre workflow.

Enfin on fait, pour démarrer l’exécution de notre workflow.

instance.Start( ) ;

III.b) Les autres lignes du main.cs

III.b.1) L’instruction using

Expliquons le "

using( WorkFlowRuntime workflowRuntime = new WorkflowRuntime( ) )

{
    // (...)
}

"

Il ne s’agit pas ici de la directive using, mais de l’instruction using. L’objet dans les parenthèses peut être déclaré dans l’instruction, comme ici, ou avant le using.
C'est-à-dire qu’on aurait pu écrire :

WorkFlowRuntime workflowRuntime = new WorkflowRuntime( )
using( workflowRuntime )

{
    // (…)
}

L’objet doit implémenter IDisposable (il aura une méthode Dispose), et l’effet sera qu’après le bloc( ou en cas d’exception), les ressources de l’objet seront libérées.

III.b.2) La classe AutoResetEvent

Espace de nom : System.Threading

«

AutoResetEvent waitHandle = new AutoResetEvent(false) ;

»

Notre objet “waitHandle” est un objet qui servira à “s’occuper de l’attente” (traduction). Le false est l’état initial.

Le « waitHandle.WaitOne( ) » à la fin, permet de boucler jusqu’à ce qu’un signal (évènement) soit émis. Ce signal sera émis par un des deux « waitHandle.Set() ». On fera waitHandle.Set( ), lorsqu’on voudra arrêter notre runtime de workflows (le main se terminant, le runtime se termine).

Aux évènements WorkflowCompleted et WorkflowTerminated du workflowRuntime, on ajoute des méthodes de traitement:

workflowRuntime.WorkflowCompleted += delegate( objet sender, WorkflowCompletedEvent
Args e) {waitHandle.Set( ) ;} ;

WorkflowCompleted est l’évènement qui se produit quand une instance de workflow s’est achevée (dans de bonnes conditions).

Created with colorer-take5 library. Type 'csharp'

workflowRuntime.WorkflowTerminated += delegate(objet sender, WorkflowTerminatedEventArgs e)
{

    Console.Writeline(e.Exception.Message);
waitHandle.Set() ;

};

WorkflowCompleted est l’évènement qui se produit quand une instance de workflow s’est terminée à cause d’une exception non traitée.

IV) La classe SequentialWorkflowActivity d’un projet Sequential Workflow Console Application (ces lignes sont autogénérées)

IV.A) La déclaration de la classe

public sealed partial class Workflow1 : SequentialWorkflowActivity

La classe SequentialWorkflowActivity (namespace System.Workflow.Activities) représente un workflow qui exécute des activités séquentiellement.

sealed (« scellé, fermé » en anglais) est un mot clé qui indique qu’on ne pourra pas hériter de cette classe (cela ne signifie pas qu’il s’agit forcément d’une classe de base).

« partial » car la classe est déclarée dans plusieurs fichiers, la deuxième partie figure dans Workflow1.designer.cs

IV.A.2) Le contenu de la classe Workflow1

La classe contient un constructeur sans paramètres, qui appelle la méthode InitializeComponent, qui se trouve dans le fichier Workflow1.designer.cs .

Elle contient également un certain nombre de méthodes, qui sont les méthodes-conditions, et les code activities.

IV.A.3) Le contenu de la partie de la classe Workflow1, qui figure dans Workflow1. designer.cs

On y trouve la déclaration des attributs privés comme les CodeActivity (namespace System.Workflow.Activities), les IfElseBranchActivity (namespace System.Workflow. Activities).

On trouve également la méthode InitializeComponent( ). Elle contient l’instanciation des objets du workflow (CodeActivity, IfElseBranchActivity, IfElseActivity,…), ainsi que l’initialisation de leurs propriétés.

La classe Workflow1 (SequentialWorkflowActivity) possède une propriété Activities de type ActivityCollection (namespace System.Workflow.ComponentModel). On ajoute les activity avec la méthode Add (CodeActivity, IfElseActivity, etc). La propriété name contient le nom du Workflow1. Avant de modifier la propriété Activities, il est nécessaire de positionner la propriété booléenne CanModifyActivities à true (et elle est remise ensuite à false).

On remarque qu’on aurait pu tout écrire par code, en se passant du designer.

V) Les objets du Workflow1 en détail

V.A) La classe CodeActivity

Classe CodeActivity (namespace System.Workflow.Activities).

Propriété Name, le nom de l’activité.
Propriété Description, une string décrivant l’activité.
Evènement ExecuteCode, de type EventHandler. On y rajoute les méthodes à appeler s’il se produit, en procédant comme d’habitude. Procédure de la forme :

Private void maProc_ExecuteCode( object sender, EventArgs e){ /*(...)*/ }

V.B) La classe IfElseActivity

Classe IfElseActivity (namespace System.Workflow.Activities). Elle démarre, conditionnellement, une des deux(ou plus ) activités. On peut voir un objet IfElseActivity comme une activity (qui sera l’une ou l’autre selon la condition), ce n’est alors pas étonnant que la classe soit dans le namespace System.Workflow. Activities.

Il y a une propriété Activities (ActivityCollection), qui contient toutes les activités qu’on veut voir exécuter. On y rajoute des IfElseBranchActivity, qui représente une branche d’un IfElseActivity, mais qu’on peut voir aussi comme une activity, qui s’exécute si la condition est remplie.
Les branches vont être évaluées de la gauche (du design) vers la droite, d’où le « else » du « IfElseBranchActivity ».

La propriété name est présente.

V.B.1) La classe IfElseBranchActivity

Classe IfElseBranchActivity (namespace System.Workflow.Activities).
Sert à créer des objets qu’on ajoute à la propriété Activities d’un objet IfElseActivity.

Représente une activité conditionnelle, ou encore une branche d’un IfElseActivity.

Propriété Activities (ActivityCollection) qui contient les activités enfants. C’est dans le cas où on veut exécuter plusieurs activités à la suite, dans le cas où la condition est remplie (la collection a un ordre).

Propriété Name.

Propriété Condition (ActivityCondition, namespace System.Workflow.ComponentModel). On y met un objet par exemple CodeCondition, classe qui hérite de ActivityCondition, et qui représente une condition implémentée sous forme de code.
L’objet CodeCondition est d’abord instancié avec son constructeur sans paramètres. Il contient un évènement Condition, et c’est à cette propriété qu’on ajoute la méthode à appeler pour évaluer la condition. L’évènement a lieu quand la condition est évaluée. La programmation évènementielle apporte ici une souplesse dans l’implémentation des conditions.
On peut noter que le EventHandler est générique :

System.EventHandler<System.Workflow.Activities.ConditionalEventArgs>

, ce qui implique que les méthodes liées seront des void meth( object sender, ConditionalEventArgs e).

La valeur de retour d’une CodeCondition est à mettre dans e.Result.

RETOUR HAUT