J'étais parti pour faire un article sur WCF, mais comme tout a déjà été dit, ça attendra un peu.
Cet article est le premier d'une série consacrée à Workflow Foundation (WF). Je vais essayer tout au long de ces articles, d'illustrer quelques une des fonctionnalités de WF, entre autres :
-
les workflows séquentiels
-
les workflows à états
-
les activités parallèles, conditionnelles et les conditions
-
la persistence dans Workflow Foundation
-
le tracking...
On va commencer doucement, avec un premier workflow de type séquentiel. Et pour ça, nous allons partir d'un exemple : Il fait beau dehors et Bob aimerait poser quelques jours de congés. Bob va donc déposer une demande de congés, qui devra être validée par son chef, puis par les ressources humaines. Une fois sa demande acceptée, Bob sera notifié qu'il peut aller profiter du soleil.
Première Etape : Le Workflow
Pour réaliser tout ça, nous allons avoir besoin d'un workflow (de type séquentiel ici, puisque les étapes se déroulent les unes après les autres). Voilà à quoi pourrait ressembler notre workflow
Il est composé de 3 activités de type HandleExternalEvent, et d'une activité CallExternalMethod qui vont permettre de :
-
d'abord réagir à une demande de congés
-
ensuite réagir à la validation par le supérieur de Bob
-
puis celle des ressources humaines
-
et enfin, appeler une méthode qui notifiera Bob de l'état de sa demande.
Deuxième Etape : L'interface
Puisque notre workflow réagit à des événements et qu'il appelle une méthode externe, il nous faut définir ces éléments. Pour cela, nous crééons une interface qui contient les définitions suivantes :
[ExternalDataExchange]
public interface IDemandeCongesService {
event EventHandler<DemandeCongesEventArgs> CongesDemandes;
event EventHandler<DemandeCongesEventArgs> ValidesSuperieur;
event EventHandler<DemandeCongesEventArgs> ValidesRH;
void NotifierDemandeAcceptee(Guid instanceId, DemandeCongesData data);
}
Ce qu'il faut noter dans la définition de cette interface :
-
L'interface est marquée de l'attribut ExternalDataExchange pour indiquer qu'elle sert à communiquer avec un workflow.
-
Les événements sont typés et héritent de la classe ExternalDataEventArgs. Ils sont également marqués de l'attribut Serializable.
-
L'objet DemandeCongesEventArgs contient une propriété de type DemandeCongesData. Cet objet contient les informations propres à notre demande de congés (nom de l'employé, le nombres de jours...), lui aussi marqué de l'attribut Serializable.
Il ne nous reste plus qu'à associer les propriétés de nos activités aux événements et méthodes correspondants.
Troisième Etape : L'implémentation et l'application hôte
Un worfklow dans WF fonctionne un peu de la même façon qu'un service WCF. Il ne peut être démarré tel quel. Il a besoin d'une application hôte pour héberger le runtime de Workflow Foundation, qui se chargera ensuite de charger/créer une instance de notre workflow et de la démarrer.
Pour faire simple, nous regrouperons toute la logique métier dans une application de type Windows (le Web c'est mal 
). Cette application contient une fenêtre principale et une classe qui contient l'implémentation de notre interface IDemandeCongesService. Voici un petit aperçu de notre application finale :
Ceci reste un exemple assez simple de ce qu'on peut faire avec Workflow Foundation. Les autres fonctionnalités de WF seront abordées dans les prochains articles de cette série. Dans le prochain épisode... Le workflow a états. En attendant, vous pouvez télécharger le contenu complet de l'exemple en suivant ce lien : WFpart01.zip (20,96 kb).
Par Dominique Thery,
To be continued...