Workflow Foundation > Articles > Présentation de Workflow Foundation

Cet article à été initialement publié dans le numéro 87 - Juin 2006 du magazine Programmez!. Depuis sa publication, WinFX a été renommé en Framework .NET 3.0 et ne contient plus la brique WinFS.

Présentation de Workflow Foundation

D’ici la fin de l’année, Microsoft mettra à la disposition des développeurs Windows Workflow Foundation, une solution gratuite pour faciliter l’intégration de workflows dans leurs applications .NET.

Windows Workflow Foundation (WF) fait partie intégrante de WinFX, au même titre que Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) et WinFS (le nouveau système de stockage). WinFX est à l’heure actuelle en version Beta, mais sera disponible lors de la sortie d’Office 2007 prévue pour la fin de cette année. Cependant, une licence Go-live permet l’utilisation immédiate de WF et de WCF en environnement de production, et garantit que Microsoft n’apportera plus de gros changements dans les mois qui vieinnent.

Contrairement à un produit comme Biztalk Server, Workflow Foundation se présente comme une brique applicative gratuite venant se greffer directement au cœur de vos applications. A la différence des solutions déja existantes sur le marché, le workflow ne dépend pas d’un produit ou d’un serveur pour fonctionner, , il sera partie intégrante de votre application. Un workflow WF s’exécute donc dans votre application, que ce soit une application console, un service Windows, ou une application web

Pour rappel, un workflow est un ensemble d’actions ou étapes s’exécutant dans un ordre prédéfini. Ces actions peuvent s’enchainer en fonction de conditions, d’interactions avec des processus informatiques ou en fonction d’interactions humaines. Dans Workflow Foundation, ces étapes sont représentées par des composants appelés « activités ». Microsoft en fournit par défaut plus d’une trentaine : exécution de code, boucles et condition, appel de services Web, de workflow ou de méthodes externes, timer, gestion de transactions et d’erreurs… Vous pouvez très facilement compléter cette liste avec vos propres activités, le développement de celles-ci étant globalement similaires au développement de composants .NET : héritage d’une classe de base, et surcharge de méthodes.

Plusieurs modèles de workflow

Workflow Foundation propose deux types de workflow : procédural ou événementiel. Les premiers sont dits séquentiels ou de flux, dans lesquels vous allez décrire votre processus par un enchaînement prédéfini (une logique de navigation de pages Web, une suite d’exécution d’applications externes…). Les worflows événementiels sont des automates à états finis, plus utiles lors d’interactions humaines (comme le suivi d’une commande). Dans un automate à états finis, l’enchaînement des opérations n’est pas déterministe, le workflow est composé de l’ensemble des états possibles ainsi que des règles de transition d’un état à l’autre.

Services additionnels au moteur de Workflow

WF s’exécutant dans vos applications, vous allez devoir guider le moteur de workflow pour qu’il s’adapte à votre mode de fonctionnement. Pour ce faire, vous pouvez remplacer ou ajouter des services techniques dans le moteur de workflow. De manière similaire aux providers d’ASP.NET 2.0, ces services suivent un modèle de développement extensible. Par exemple, pour assurer un suivi complet du cheminement d’exécution de vos workflows, une API est présente dans le SDK. Pour fonctionner, celle-ci a besoin d’un service dit de « tracking », que vous allez devoir activer. Cette activation peut se faire soit de manière impérative dans le code de votre workflow, soit de manière déclarative dans un fichier de configuration. De base, un service de gestion de tracking en base SQL est fourni, mais ce modèle étant complètement extensible, vous allez pouvoir écrire, utiliser et faire évoluer dans le temps vos propres services sans impact direct sur le fonctionnement de votre workflow. Parmi les services les plus utiles, en plus de la gestion de suivi, on retrouve un service de persistance qui permet d’assurer la reprise des workflows en cas d’incident directement à un état préalablement enregistré, et un service de communication utilisé pour permettre à l’application hôte de pouvoir échanger des informations avec vos workflows.

Définition de workflow

Pour pouvoir modéliser un workflow avec Visual Studio 2005, deux pré-requis sont nécessaires : - Avoir WinFX installé sur le poste de développement, - Installer les extensions de Visual Studio 2005 pour Windows Workflow Foundation.

Un exemple de création de workflow

Pour illustrer notre propos, imaginons un workflow de validation de création de compte utilisateur dans lequel un site web comporte une inscription en ligne.

Lors de l’enregistrement d’une personne, celle-ci reçoit un Email de validation contenant un lien, et lorsqu’elle clique sur celui-ci, son compte est validé. Si au bout de 5 jours, elle n’a pas cliqué sur le lien, un Email de notification est re-envoyé et le compte est supprimé.

La nécessité de modéliser un workflow est tout à fait adaptée à ce genre de cas.

Visual Studio 2005 propose plusieurs templates de base : - Sequential Workflow Library, une DLL qui contiendra des workflows qui pourront être exécutés/hébergés par une application tierce (application Windows, service, application Web...). - State Machine Workflow Library, identique à la version séquentielle mais pour des automates à états. - Sequential Workflow Console Application, qui permet de créer une application console qui vous permettra de créer vos workflows et de les héberger. - State Machine Console Application, pour modéliser des workflows en tant que automates à états hébergés dans une application console. - Workflow Activity Library, pour définir vos propres composants. - Empty Workflow Project, un projet vierge permettant de réaliser vos projets selon vos besoins.

Dans notre cas, l’automate à états semble le plus adapté, les différents états étant : « demande de création de compte » >> « compte créé » >> « fin », sachant que pour passer de l’étape « compte créé » à l’étape « fin », le compte utilisateur doit être validé dans un certain intervalle de temps, sous peine d’être supprimé.

Une fois le modèle d’automate à états sélectionné, Visual Studio ouvre un designer permettant de déposer les différentes activités dans le but de définir le cycle d’exécution de notre workflow.

Il est à noter qu’un workflow peut être décrit de plusieurs façons : soit de manière uniquement déclarative dans un fichier XOML, soit de manière mixte déclarative (XOML) / impérative (C#/VB), soit uniquement de façon impérative. Dans notre cas, le workflow est défini uniquement par code et représenté par une classe éclatée dans deux fichiers, un pour le designer et un pour le code utilisateur (comme pour une application winforms).

La première étape est donc, en mode design, de glisser/déposer les différentes activités représentant notre workflow, de la boîte à outils vers le designer.

Chaque étape étant constituée d’un enchaînement d’activités, il est nécessaire de détailler les actions à entreprendre avant, pendant et après leur exécution.

Notre première activité va permettre de démarrer une instance de workflow, c'est-à-dire d’initialiser un cycle d’exécution. Si dix utilisateurs demandent chacun l’exécution de cette activité, nous aurons dix instances de workflow en parallèle en mémoire, ces workflows pouvant être persistés dans une base de données et déchargés de la mémoire via le service de persistance que nous avons abordé précédemment s’ils sont inactifs durant un temps trop important (ceci dans le but de préserver les ressources mémoire de votre serveur).

Il est donc nécessaire, dès le début, de définir la méthode de communication entre le workflow et l’application utilisatrice en définissant un contrat. Deux méthodes sont courantes : - soit en définissant un service d’échange de données représenté par une classe de données et des gestionnaires d’évènements également appelés « handlers » - soit en utilisant des services Web (et dans ce cas en utilisant IIS pour héberger le workflow). - Soit à terme, en utilisant Windows Communication Foundation

Dans notre cas, nous allons utiliser les services Web qui permettent une interaction facile et une communication simplifiée avec tout type d’application.

Il nous faut au préalable définir les méthodes utilisées par notre workflow :

namespace WorkflowLibrary1
{
    public interface ICommunication
    {
      Guid DemandeCreation(string nom, string email);
      bool DemandeValidation(string instance);
    }
}

Notre contrat de communication étant défini, il ne reste plus qu’à l’intégrer dans notre automate à états pour permettre le passage d’une étape à une autre.

Dans chaque étape, nous allons donc rajouter des activités de type « EventDriven » afin de créer / réveiller nos instances de workflow en fonction d’un évènement précis, dans notre cas le fait que le service Web soit appelé par une application. Chaque activité EventDriven est un mini workflow séquentiel commençant par une activité d’écoute et se terminant par une activité de changement d’état.

Par exemple, dans notre EventDriven de demande de création de compte, nous allons obtenir la séquence suivante : • Une activité représentant le service web qui écoute (la signature de celui-ci étant définie dans l’interface précédent, par la méthode « DemandeCréation »), va récupérer le nom et l’Email du demandeur puis les stocker dans des variables de l’instance. • Une activité de code qui va donc exécuter une méthode .NET qui crééra le compte par exemple. • Une activité représentant la réponse du service web, toujours en fonction de sa signature (ici on retourne l’identifiant unique « guid » représentant l’instance en cours). • Et une activité de changement d’état afin de passer à l’étape suivante.

Toutes les étapes d’un automate à états vont ainsi pouvoir être détaillées avec des traitements plus ou moins complexes afin d’obtenir le schéma d’exécution global du workflow.

Une fois la modélisation de l’automate à états terminée, et la DLL de cette dernière compilée, il nous reste à publier et héberger celle-ci.

Etant donné que nous utilisons des services web pour communiquer, il devient évident d’utiliser une application web pour héberger notre workflow. Visual Studio 2005 est d’ailleurs capable de créer automatiquement cette application web, en faisant un clic droit sur la DLL contenant le workflow, et en sélectionnant l’option « Publish as Web Service ». Celle-ci va créer automatiquement l’application web, la préconfigurer (web.config) et créer les différents services web utilisés par notre workflow.

Notre workflow peut ainsi être testé directement depuis un navigateur web en appelant les services web : un premier appel pour créer une instance de workflow en spécifiant un nom et un prénom, et un deuxième appel pour valider la création.

Attention toutefois, une application web ayant une durée de vie limitée, elle peut s’arrêter en cas de non utilisation suivant le paramétrage qui aura été effectué sur le serveur Web. Nos instances de workflow étant chargées en mémoire de la dite application, il est nécessaire de prévoir un système de persistance afin de gérer le chargement / déchargement de nos instances dans une base de données ou un fichier. Par défaut, un service de persistance pour SQL Server est fourni, il ne reste donc plus qu’à l’activer.

Cette activation se déroule en deux étapes : - Préparer une base de données, SQLExpress ou SQLServer 2000/2005 en exécutant les scripts de création de schéma fournis et présents dans le repertoire « C:\Windows\WinFX\3.0\Windows Workflow Foundation\SQL\EN ». - Paramétrer l’application web pour activer la persistance, au niveau du fichier de configuration « Web.config ».

Par exemple, pour une base SQLExpress, le paramétrage sera le suivant :

Nous nous contenterons ici d’activer un service, de type « SqlWorkflowPersistenceService » utilisant une base SQLExpress locale, persistant à chaque fois que le workflow devient inactif (UnloadOnIdle) et se mettant à jour toutes les secondes. Si vous ne possédez pas SQLExpress ou SQL Server, il est possible de créer votre propre service de persistance qui irait écrire l’état des workflow dans une base de données Oracle ou MySql, ou bien sur le système de fichiers du serveur.

A ce niveau notre workflow est défini, hébergé et fourni des services web consommables par tout type d’application. Il ne resterait plus maintenant qu’à écrire l’application qui appelerait notre service Web pour activer notre workflow depuis n’importe où dans le monde.

Conclusion

Windows Workflow Foundation offre donc un modèle de développement de workflows applicatifs rapide à mettre en œuvre et surtout totalement extensible par le développement de vos propres activités ou de vos propres services. Microsoft l’utilisera d’ailleurs dans Office System 2007 et notamment Windows SharePoint Services v3 et Office SharePoint Server 2007 ainsi que dans les prochaines versions de Biztalk Server.

Lorsque vous vous lancez dans la modélisation d’un nouveau workflow avec Workflow Foundation, vous devez avoir en tête deux critères importants: quelle sera la durée de son cycle de vie et quel devra être son niveau de disponibilité.

Florent SANTIN