Les modèles de workflow de Windows Workflow
Foundation
Dans le monde des workflows, tout le monde n'a pas forcément
les mêmes besoins que son voisin notamment sur la manière dont sera conçu et sur
la manière dont fonctionnera son workflow. En effet, si l'on souhaite créer ce
qu'on appelle un workflow technique ou si l'on souhaite créer un workflow avec
intervention des utilisateurs (également appelé workflow humain), ce sont deux
approches radicalement différentes auxquelles nous serons confrontés et par
conséquent, il serait intéressant que Windows Workflow Foundation nous
aide à concevoir des workflows spécifiques à ce que nous souhaitons faire.
Comme vous pouvez le constater sur l'image ci-dessus qui
correspond à l'écran de création de projets de Visual Studio 2005, il
existe six nouveaux types de projets qui sont installés par les extensions
Visual Studio pour Workflow Foundation qui sont téléchargeables gratuitement
sur le site de Microsoft (voir la section
téléchargements). Chacun de ces
types de projets possède ses spécificités mais comme vous pouvez le voir, tous
ces types de projets tournent autour de deux grandes familles :
-
Sequential Workflow
-
State Machine Workflow
Les workflows séquentiels (Sequential Workflow)
Le
modèle de projet Sequential Workflow est généralement utilisé pour
réaliser ce qu'on appelle des workflows techniques.
Un workflow technique consiste en une suite d'opérations,
appelées activités dans la terminologie Workflow Foundation, réalisant
chacune un traitement bien précis (calcul, écriture dans une base de données,
envoi d'un message électronique...) et ceci sans qu'une intervention de
l'utilisateur ne soit nécessaire durant l'exécution de toute la chaîne
d'opérations. Dans cette suite d'opération, il est possible de diriger le chemin
d'exécution du workflow en fonction de critères que l'on appelle dans la
terminologie Workflow Foundation des règles.
Sur l'image ci-contre, vous pouvez visualiser un exemple de
workflow séquentiel qui commence par une étape d'exécution de code (codeActivity)
puis qui enchaîne sur une prise de décision (ifElseActivity) en fonction d'une
règle définie par le concepteur du workflow. En fonction de l'évaluation de la
règle, soit le flux d'exécution partira sur la gauche ou sur la droite de la
branche de décision, chaque branche réalisant une opération différente
(exécution de code pour la partie gauche et attente d'un laps de temps déterminé
sur la partie droite). Le workflow se termine ensuite et le programme ayant
déclenché le workflow peut récupérer d'éventuels résultats fournis par
l'exécution du workflow.
Les workflows à états (State Machine Workflow)
Le modèle de projet State Machine Workflow est
généralement utilisé pour réaliser ce qu'on appelle des workflows humains.
Un workflow humain consiste à attendre une intervention d'un
utilisateur, réel ou bien simulé par une application, qui va déclencher un
évènement permettant de prévenir le workflow qu'il doit poursuivre son exécution
en prenant éventuellement en compte les valeurs fournies par l'utilisateur
durant le déclenchement de l'évènement.
Des exemples classiques de workflows humains sont les
systèmes de prises de commande ou de demande de congés, qui sont initialement
déclenchés par un utilisateur (la personne qui passe une commande ou qui émet
une demande de congés) mais qui nécessitent des interventions humaines durant
les étapes ultérieures pour valider certaines étapes du workflow (validation
d'une remise accordée sur la commande, validation de la demande de congés par le
responsable puis le service des ressources humaines...).
Comme vous pouvez le constater sur l'image ci-contre, un
workflow humain est réalisé sous la forme d'une machine à états, c'est à dire
que chaque étape du workflow attendra un évènement déclenché par un utilisateur
ou une application représenté ici l'activité eventDriven. Chaque étape
déroulant ensuite sa logique métier puis enchaînant éventuellement sur un autre
état attendant lui même une nouvelle intervention humaine pour continuer son
exécution. Une étape de workflow représenté ici par les éléments
stateActivity, consiste une fois qu'elle a reçu l'évènement correct, en un
workflow séquentiel comme décrit précédemment.
Quel modèle de projet en fonction de mon besoin
?
La question qui se posera un jour à toute personne voulant
réaliser un workflow en utilisant Windows Workflow Foundation est : Quel type
de projet dois je prendre en rapport à mon besoin ?
Il n'existe pas de réponse valable dans 100% des cas mais
sachez que ce qui a été dit précédemment sur le fait que les workflow techniques
soient réalisés sous la forme de workflows séquentiels et que les workflows
humains soient réalisés sous la forme de machine à états ne sont que des
généralités par rapport à ce qui est généralement constaté dans les modes
d'implémentation des workflows.
En effet, vous pourriez très bien rencontrer le cas d'avoir
un workflow technique dans lequel une intervention humaine est nécessaire à un
moment donné. Dans ce cas, quel type de projet choisir puisque nous aurions
besoin des deux types de projets : séquentiel pour la partie technique et
machine à états pour la partie humaine. Pour cet exemple mais c'est valable
quasiment dans tous les cas, sachez qu'il est possible d'introduire des
interventions humaines dans des workflows techniques en insérant l'activité qui
va bien (ex : EventDriven) dans la chaîne d'exécution du workflow. De
même, il est possible de réaliser des workflows techniques avec des machines à
états.
Conclusion
Comme nous venons de l'expliquer, il est possible de réaliser
avec Windows Workflow Foundation tous les types de workflows possibles et
imaginables avec les outils fournis en standard par ce socle de développement
fourni par Microsoft. Que vous ayez besoin de réaliser des workflows simples ou
compliqué, avec ou sans intervention humaine, toutes les briques nécessaires à
la réalisation de vos workflows existent et seule la manière dont seront
utilisées ces briques fera que le résultat final sera à la hauteur du besoin
exprimé initialement.