Skip to main content

Les fondamentaux du service de workflow

Téléchargez dès à présent le document en format pdf

Article par Jérémy Jeanson (MVP Connected System Developer)

Développant avec .net depuis 2001, j’ai vécu les différentes évolutions du Framework, des premières Beta de la version 1.0 à aujourd’hui. Je surfe donc sur la vague .net depuis ses débuts, et j’adore cela.

À force de pratiques et d’expériences personnelles, je me suis spécialisé dans les architectures n-tiers exploitant Windows Communication Foundation, Windows Workflow Foundation et plus généralement l’interopérabilité des services.

Sommaire de l'article

Introduction

L'objectif de cet article est d'expliquer pourquoi les services de workflow (WS pour Workflow Services) existent et de clarifier enfin, ces « petits plus » qu'apport Windows Workflow Foundation (WF) à Windows Communication Foundation (WCF). Les architectes et développeurs qui utilisent déjà WS le savent bien, l'utilisation de l'expression « petit plus » est purement ironique. Nombre de fonctionnalité de WF sont uniques et sont utilisables « out of the box » sans la moindre adaptation.

 

Haut de page | Haut de page

La perception initiale de services de Workflow Foundation

Au premier abord, le développeur et/ou l'architecte ne voient que la partie immergée de l'iceberg : Workflow Services permet d'avoir :

  • Un service dont l'enchainement d'opérations est régi par un designer.
  • On ne peut pas utiliser une méthode du service si le workflow ne l’a pas atteinte.
  • Plusieurs points d'entrées dans un workflow, qui sont actifs en fonction de l'état d'avancement d'un workflow.
  • Un processus robuste pour interagir avec plusieurs flux, sources de données, etc.

Cette vision synthétique peut être représentée par le graphique suivant :

 

Haut de page | Haut de page

L’erreur à ne pas commettre

Celle-ci ne prend malheureusement pas en compte de toute la puissance des services de Workflow Foundation. Il est alors facile de penser que WCF seul est en mesure de remplir le même rôle. Cette réflexion est légitime à partir du moment où l'on commet l'erreur ultime : parler workflow, et uniquement workflow.

Je m'explique : de manière générale, quand on parle POO, on différentie la notion de classe / structure et d'instance. Qui ne s'est jamais fait rabattre le caquet par un développeur se voulant plus « instruit » que les autres en disant :  « Non ce n'est pas un objet, c'est une classe. Ce sera un objet quand on l'aura instancié! »

Le workflow Xaml ou Xamlx est une classe. Pourquoi alors, ne pas parler d'instance de workflow? Nombre de développeurs se cassent justement les dents sur WCF et WF, car ils oublient la notion d'instance. À partir du moment où l'on utilise un service, on a une instance. Pour WCF, on a une instance de la classe exposée par le service. Pour WF, on a une instance de workflow.

C'est ensuite la configuration de WCF qui fait que l'on autorise ou non une ou plusieurs instances simultanées. Par défaut, WCF permet d'avoir plusieurs instances. Généralement, ceci ne pose pas de soucis avec un service classiques, car on se demande rarement, si les appels successifs à des méthodes différentes d'un même service utilisent la même instance. Avec WF, les choses sont différentes. L'appel à une première méthode va faire évoluer une instance de workflow. L'appel à la méthode suivante (dans l'ordre de déroulement du workflow) va faire évoluer l'instance de workflow au stade suivant et ainsi de suite jusqu'à la fin du workflow.

 

Haut de page | Haut de page

La corrélation

Le schéma suivant représente la problématique imposée par le fait d’avoir plusieurs instances de workflows : un message doit atteindre une instance précise du workflow.

Afin de répondre à cette problématique, WF et son hôte de services disposent d'un mécanisme tout intégré appelé « Corrélation ». Ce mécanisme presque « magique » permet à un message d'atteindre une instance de workflow précise, et dans le cas où aucune instance n'existe, d'en instancier une nouvelle. Pour fonctionner, la corrélation a besoin d'un ou plusieurs éléments communs aux échanges (ex: un ID ou un nom d'utilisateur). Cet élément, ou ces éléments permettront de distinguer une instance de workflow d'une autre.

Par exemple, pour un workflow de demande de congés :

  1. Un utilisateur fait une demande de congés.
  2. Un workflow est instancié
  3. Un id de demande est retourné à l'utilisateur
  4. L'utilisateur emploi ensuite cet id pour le reste de ces échanges avec l'instance de workflow.
  5. La personne en charge d'accepter ou de refuser la demande de l'utilisateur emploiera le même id afin de faire évoluer l'instance de workflow (en général, cet id est communiqué à l'utilisateur par mail ou via une base des données).

Dans cet exemple, l'instance de workflow fournit une information qui va permettre la corrélation. On dit alors que le workflow est l'émetteur des données de corrélation. Il est tout à fait envisageable d'inverser ce mécanisme et que ce soit le client du service qui soit émetteur de cette information.

Avec Workflow Foundation 4, la corrélation peut se baser sur une donnée présente dans :

  • Le contenu du message (arguments de la méthode appelée).
  • Le contexte WCF (possible si le Binding WCF utilisé permet d'utiliser un contexte).

 

Haut de page | Haut de page

La persistance

Plusieurs problèmes peuvent ensuite se poser :

  • Chaque instance de workflow consomme des ressources (principalement de la RAM). On ne peut donc pas garder toutes les instances actives en même temps.
  • Le serveur qui héberge le service peut être éteint, ou avoir un dysfonctionnement alors qu'une ou plusieurs instances de workflows sont en attente.
  • Un workflow peut durer plusieurs jours, mois ou années. Plus le processus d'interactions avec le workflow est long et plus on a de chances d'être confronté à l'un des deux cas ci-dessus.

Afin de répondre à cette nouvelle problématique, WF dispose d'un mécanisme appelé « persistance ». Celui-ci permet de stocker les informations relatives à une instance de workflow dès que l'instance est en attente. Dès qu'une instance est à nouveau utile, elle est extraite de ce stockage et ravivée pour répondre au client du service de workflow. Le dispositif de stockage est appelé magasin de persistance.

Le schéma suivant représente trois cycles possibles d'interactions avec un service de workflow qui utilise un magasin de persistance basé sur SQL serveur.

 

Haut de page | Haut de page

Le versioning

Le versioning est un problème qui se pose avec des workflows, à partir de l’instant où l’on a une ou plusieurs instances de workflows qui sont en cours d’exécution (ou qui sont persistées) et que l’on met veut mettre à jour la définition du workflow. On se trouve alors fasse à plusieurs difficultés :

  • Quelle définition va utiliser une instance qui doit être ravivée ?
  • Comment savoir, quelle définition du workflow est utilisée par telle ou telle instance ?
  • Comment mettre à jour les instances persistées avant qu’elles n’aient besoin d’être ravivées ?
  • … etc…

Avec l’arrivée de Windows Workflow Foundation 4.5, les différentes variantes d’un workflow peuvent être identifiées par leur « identité ». Cette identité s’appuie sur deux informations différentes : le nom et le numéro de version du workflow.

WF 4.5 est aussi en mesure de conserver côte à côte plusieurs versions d’un même workflow. Ceci permet de raviver des instances de workflow persistées, alors qu’elles ont été créées avec un workflow de version antérieure.

Bien entendu, dans le monde de WF, rien n’est rigide. WF 4.5 intègre donc aussi la possibilité de mettre à jour les instances de workflow persistées afin qu’elles utilisent la toute dernière version d’un workflow.

Exemple :

  1. Durant une durée D1, on utilise des workflows d’identité X que l’on persiste.
  2. À un instant T1, on applique une « carte d’évolution» (ensemble de différences entre l’identité X et l’identité Y d’un même workflow)
  3. Après cet instant T1, les instances seront ravivées avec des workflows d’identité Y.

 

Haut de page | Haut de page

« Happy End »

Voici qui termine notre voyage initiatique avec les services de workflows. J'espère que celui-ci est assez clair pour vous permettre une bonne visibilité de WF.

 

Haut de page | Haut de page