Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Avec l’arrivée de la machine à états, de nouvelles activités vont faire leurs apparitions. Si vous avez déjà regardé la CTP, vous ne serez pas trop dépaysé.

Bonne nouvelle, on reste dans la philosophie de WF4 : “Tout est activité”; même les transitons entre états (bien quelles ne soient pas visibles dans la toolbox)

On retrouve donc avec l’activité de base de la machine à états : StateMachine. Celle si doit être la première activité à inclure dans vos workflows si vous souhaitez faire usage de la machine à états. Elle peut bien entendu contenir d’autres StateMachine, et peut être contenu dans une autre activité.

Comme pour toute activité de WF4, si l’un des états ou une activité de l’un des états avait des warnings ou une liste d’erreurs, celles-ci remonteraient dans l’entête de la StateMachine.

Note : Pour que votre workflow soit valide, il doit répondre aux quelques règles suivantes :

• Un StaMAchine doit avoir au moins un State.
• Un StaMAchine doit avoir au moins un FinalState.
• Un State doit avoir au moins une transition.
• Une transition doit avoir au moins une activité dans son Trigger.

Comme on peut, le constater, les règles sont simples et peut contraignantes (les conditions dans les triggers peuvent donc être null) et nos scénaris peuvent ressembler à tout ou presque.

Du côté de l’état : State, on reste très simple. Comme le montre l’activité suivante, on a :

• Une activité Entry qui s’exécute à l’activation de l’état.
• Une activité Exit qui s’exécute à la sortie de l’état (donc dès qu’un trigger de sortie est valide).
• Une zone “Transition(s)” (non éditable dans l’activité) qui sert à naviguer entre les activités via les transitons.

Note : Ces deux activités sont aussi représentées dans les états sur la vue précédente par de petites flèches encerclées s’il y a un contenu dans chacune.

Si on double-click sur une transition, on peut l’éditer et choisir :

• Une activité “Trigger”. En général une activité en attente d’un évènement extérieur, ou une temporisation pour limiter la durée d’exécution de l’état précédent.
• Une activité Condition (Actvity<Boolean>) : qui permet de dire si on doit oui ou non passer à l’état suivant. Cette condition est optionnelle. Elle peut donc rester vide. Tout l’intérêt de celle-ci est de déterminer si une variable récupérée ou affectée lors du Trigger est dans une situation requérant un changement d’état. Si cette condition est fausse, on relance le Trigger (génial pour les Trigger complexes).
• Une activité Action qui s’exécutera si la transition est validée et que l’on peut passer à l’état suivant. Très pratique si votre transition est commune à plusieurs états, mais avec des conditions différentes.

Et pour finir, bien évidemment le FinalState. Celui-ci est constitué d’une simple activité Entry. L’état final peut donc exécuter lui aussi une séquence d’activité propre à la fin de vie de votre workflow.

En soit rien de bien compliqué, je dois même dire que je trouve la nouvelle StateMachine très simple à appréhender. C’est bien cela que l’on attend de la machine à état : simplifier des workflows pas toujours évidents à modéliser.

Dans mes prochains articles, je vous démontrerai la facilité d’utilisation du designer et quelques-unes des très bonnes innovations dont regorge la StateMachine….

Attention, il va y avoir “du lourd”!