Qu'est ce qu'un workflow ?

Pour répondre à cette question, je vais faire l'analogie avec le code d'un développeur. Lorsque l'on développe, on définit le plus souvent une suite d'opérations ou de tâches. Cela peut être une insertion dans un journal d'événements ou dans une base de données. Ensuite, on ordonne ces opérations avec des instructions qui contrôlent le flux de notre programme. Par exemple, on utilise l'instruction :

If (condition)
{Liste d'opération 1}
else {Liste d'opération 2}

ou un bloc :

While (Condition)
{Liste d'opérations}

pour traiter des données en boucle.

Chaque décision dans le code, que ce soit en C#, Java, C/C++, Javascript etc ..., est matérialisée par des conditions. Tout code source possède 3 types d'instruction:

• Les instructions d'exécution qui peuvent être une écriture dans une base de données ou encore dans un journal d'évènements, l'envoi d'un mail, ou plus généralement toute instruction qui exécute une action.
• Les instructions définissant le flux d'exécution comme le bloc if (condition) {instructions} else {instructions}. Ce sont toutes les instructions qui ont une influence sur le flux d'exécution du programme.
• Les règles qui définissent les conditions dans les flux d'exécution.

Voici un exemple montrant les 3 types les 3 types d'instruction:

Les concepteurs de Workflow Foundation ont identifié ces 3 concepts et les ont intégrés dans Workflow Foundation. Un workflow n'est rien d'autre qu'une suite d'instructions d'exécution représentée par des activités (Custom Activity, Code Activity, InvokeWebService, etc…). Ces instructions d'exécution ou activités sont elles-mêmes comprises dans des activités définissant le flux d'exécution du programme (IfElseActivity, WhileActivity, ParallelActivity, ReplicatorActivity, etc…). Pour définir les conditions dans les activités définissant le flux d'exécution, on met en place des règles (rules en anglais). Pour illustrer cela, voici un workflow reprenant la même logique que l'exemple précédent :

Premièrement, le workflow est représenté de manière graphique. Les deux exemples réalisent exactement la même chose. Cependant, dans le premier exemple, tout a été défini avec un langage textuel qui est le C# alors que dans le deuxième, tout a été quasiment définit de manière graphique en utilisant le drag'n drop et la fenêtre de propriété de Visual Studio 2008.
Aujourd'hui, c'est dans l'air du temps d'utiliser ce que l'on appelle des langages graphiques ou des DSL (Domain Specific Language). Le plus célèbre d'entre eux est le designer de classes intégré dans toutes les éditions de Visual Studio. Workflow Foundation propose ainsi de définir votre propre langage graphique pour définir les workflows. Pour cela, nous avons à notre disposition un ensemble d'activités que l'on peut glisser et déplacer dans la fenêtre définissant le workflow. Voici un aperçu de la Toolbox regroupant les différentes activités fournies par WF :

Il est aussi possible de définir un workflow par le code, en instanciant les bons objets, ou avec du XAML (rebaptisé XOML dans WF, pour le différencier du XAML de WPF). Le XAML est un langage basé sur XML permettant d'instancier et de paramétrer des objets.
Lorsqu'on crée un nouveau workflow, nous avons le choix avec 2 implémentations de workflow :

• Workflow basé sur du code uniquement
• Workflow basé sur du XAML avec un fichier de code associé

Théoriquement, il est aussi possible définir un workflow basé uniquement sur du XAML en supprimant le fichier de code associé, Visual Studio 2005 ou 2008 ne propose pas ce template. L'intérêt principal d'un workflow définit uniquement en XAML, est que l'on peut le modifier à la main ou via un éditeur spécialisé sans avoir besoin de recompiler l'application. Cela laisse penser qu'il est possible développer des applications avec des workflows, et que votre client pourra via un éditeur de workflow, modifier par la suite le comportement de son programme en éditant lui-même ses workflows. Bien sûr, il devra avoir une connaissance du vocabulaire métier défini dans le workflow, mais comme celui-ci est la matérialisation d'un processus de l'entreprise, cela devrait lui être familier. Dans tous les cas, c'est beaucoup plus simple et plus réaliste que de modifier du code et de le recompiler.
Une autre différence fondamentale lorsqu'on utilise WF est que la logique définissant ce que l'on fait est séparée de la logique qui définit quand on le fait. C'est-à-dire que l'on peut changer toute la logique de séquencement ou d'ordonnancement d'un workflow sans affecter les instructions d'exécution. Pour cela, on sélectionne la ou les activités voulues et on les déplace à l'endroit souhaité dans le workflow. Avec un langage textuel, cela se résumerai à un ensemble de couper/coller quelque peu hasardeux et pas toujours très simple à réaliser.
Comme la logique d'ordonnancement est définie de manière déclarative et qu'en fait chaque activité correspond à une classe, il est tout à fait possible de modifier à l'exécution, c'est-à-dire dynamiquement, un workflow. Par exemple, on peut rajouter de nouvelles instructions d'exécution ou des instructions définissant le flux d'exécution à un endroit donné. Il suffit simplement d'instancier les activités voulues, de les paramétrer et de les insérer là où on le souhaite. Comparé à un langage textuel, cela pourrait être synonyme d'injection de code (via de la POA par exemple), ce qui est quand même bien plus complexe à réaliser.