[WF4] Bon usage du Pick

mercredi 10 novembre 2010 15:43 JeremyJeanson

[WF4] Bon usage du Pick

L'activité Pick de Workflow Foundation 4 semble présenter un grand défi à relever pour les développeurs. J'ai déjà eu quelque retours que l'on pourrait résumer en : " Le Pick ne parche pas ! "... Si, si le Pick fonctionne bien, mais son usage n'est pas toujours évident. Afin d'en clarifier l'usage, je vais tenter ici de résumer ce que le Pick sait faire et ce que l'on doit faire pour l'utiliser correctement.

Voici donc un petit résumé type FAQ, qui je l'espère, sera utile.

1) De quoi le Pick est-il constitué et quelle est sa fonction ?

Le Pick est une activité constituée de plusieurs branches dont il a la responsabilité de l'exécution (PickBranch). Chaque PickBranch contient deux éléments très importants : le Trigger et l'Action. On peut glisser autant de branches qu'on le souhaite dans un Pick.

2) Que se passet il quand le Pick s'exécute ?

Quand un Pick s'exécute, la première opération qu'il va effectuer consiste à programmer l'exécution des activités Trigger des PickBranch. Dès que l'une des activités Trigger a fini de s'exécuter, les autres activités Triggers sont annulées. Le Pick programme alors l'exécution de l'activité Action de la PickBranch correspondant au Tigger exécuté complètement.

Comme je le dis souvent : " Le Pick est une course entre Tigger pour au final n'exécuter qu'une seule Action ". Mais cette course a des règles bien précises.

3) Quelles sont les règles ?

Microsoft n'a pas fixé de règles concernant l'usage des Pick et des PickBranch, mais si vous voulez utiliser efficacement ceux ci, il vaut mieu respectée ces deux petites règles :

• Les Triggers doivent contenir au moins une activité asynchrone.
• Les Triggers doivent contenir des activités annulables.

4) Pourquoi de telles règles ?

Si on reprend les mots exacts que j'ai utilisés dans mon 1), les Triggers ont leur exécution " programmée " par le Pick. Le début de " l'exécution " de chaque Trigger ne peut donc avoir lieu que si le précèdent Trigger dans l'ordre de création des branches permet à une autre activité de s'exécuter. Voilà pourquoi le Trigger doit contenir une opération asynchrone.

Dans le cas contraire : le Trigger de la première branche s'exécutera et arrivera à son terme avant même d'avoir permis l'exécution du Triggers suivant (et donc de ceux qui suivent). Il s'agit là du même fonctionnement que celui que l'on constate avec l'activité Parallel. Et donc dans le cas d'un Pick, l'Action de la première branche sera toujours celle qui sera exécutée.

Arrive ensuite le souci de l'annulation. Si les activités que vous avez utilisées dans vos Trigger n'acceptent pas l'annulation, elles s'exécuteront quoiqu'il arrive, et l'Action programmée ne sera exécutée qu'après. Vos Trigger refusant l'annulation, chaque Trigger arrivera à sa fin.

Voilà pourquoi, si vous créez des activités custom pour les Trigger de vos PickBranch, il faut impérativement que celles-ci soient basées sur les AsyncCodeActivity ou qu'elles programment l'exécution d'activités qui en héritent. Il faut aussi penser à réécrire la méthode Cancel de ses activités pour annuler les traitements en cours dans l'activité.

Pour plus d'information sur le type de code utilisable : Coder une activité d'attente non bloquante sans bookmark