La disponibilité de la Beta 2 de Visual Studio 2010 et du .NET Framework 4.0 a été annoncé par Jason Zander, General Manager de Visual Studio ce lundi (19/10/2009) suivi de l’annonce de Scott Guthrie, General Manager de la division .Net chez MS Corp que j’ai eu la chance de rencontrer en Mars dernier à l’occasion du MIX09 à Las Vegas.
Parcourons ensemble ces nouvelles versions !
Windows Workflow Foundation propose deux services fort utile qui sont le Tracking et la Persistance.
La persistance va permettre d’enregistrer l’instance d’un workflow en dur dans un serveur SQL. On va pouvoir grace a cela, demarrer une instance de workflow depuis une application host, la quitter, puis la reprendre a tout moment. La persistance devient alors très utile, imaginez un workflow de gestion d’article qui demarre au moment où un article serait posté et attendrait la validation des admins pour etre publié. Il serait alors fort utile de pouvoir enregistrer et reprendre le workflow quand on le souhaite pour que les admins puissent donner leur reponse à tout moment.
La persistance sous WF est très simple a mettre en oeuvre :
Il faut d’abord préparer la base de données en executant les scripts SQL qui se trouvent dans C:\WINDOWS\WinFX\v3.0\Windows Workflow Foundation\SQL\EN. Il y a 4fichiers : 2 pour les schémas et 2 pour la logique pour la persistance et le tracking. Executez les schémas en 1er biensûr 🙂
Ensuite pour activer la persistance dans votre workflow, ajoutez le service SqlWorkflowPersistenceService à votre runtime. ex:
1 | Dim persistance As New SqlWorkflowPersistenceService(CONNSTRING, True, New TimeSpan(0, 0, 5), New TimeSpan(0, 0, 5) runtime.AddService(persistance) |
A tout moment vous allez pouvoir recuperer les instances persistées par le code :
1 | Dim instances As IEnumerable(Of SqlPersistenceWorkflowInstanceDescription) = persistance.GetAllWorkflows() |
Vous recuperez une collection de SqlPersistenceWorkflowInstanceDescription où vous allez pouvoir recuperer des informations comme son status, son ID d’instance, etc…
Enfin pour récupérer une instance :
1 | Dim instance as WorkflowInstance = runtime.GetWorkflow(_instanceID) |
où _instanceID est un Guid qui correspond à l’ID de l’instance à resumer.
Le Tracking quant à lui, permet de « traquer » un workflow en enregistrant des tas de parametres sur son déroulement. Pour le mettre en place, c’est aussi facile que pour la persistance. Assurez-vous d’avoir bien créé les tables (scripts Tracking_Logic et Tracking_Shema). Ensuite tout comme la persistance, il faudra ajouter le service tracking à la runtime par le code :
1 | Dim tracking As New SqlTrackingService(CONNSTRING) runtime.AddService(tracking) |
Vous pourrez ensuite recuperer un tas de parametres pour toutes les instances par le code :
1 2 | Dim stq As New SqlTrackingQuery(CONNSTRING) Return stq.GetWorkflows(New SqlTrackingQueryOptions()) |
Ce code vous retournera une List(Of SqlTrackingWorkflowInstance) (autopub: explication des List ici) :))
L’objet SqlTrackingQueryOptions permet quant à lui, d’imposer des conditions de recherche. L’exemple ci-dessous permet de recuperer seulement les instances en cours (running) :
1 2 3 4 | Dim stq As New SqlTrackingQuery(CONNSTRING) Dim opt As New SqlTrackingQueryOptions() opt.WorkflowStatus = WorkflowStatus.Running Return stq.GetWorkflows(opt) |
L’objet SqlTrackingWorkflowInstance contient toutes les informations sur une instance de Workflow. On y trouve les propriètés ActivityEvents (evenement des Activity), Status, UserEvents (evenement des utilisateurs comme par exemple les traces laissées par les TrackData dans le workflow), WorkflowInstanceId, etc…
Toutes les specs du SqlTrackingWorkflowInstance : http://windowssdk.msdn.microsoft.com/en-us/lib…
Conclusion : ca devient un vrai jeu d’enfant, sous WF, de persister et tracer un workflow. Moi j’adore 🙂
Les Activity HandleExternalEvent & CallExternalMethod, sont tout deux indispensable dans le developpement de workflow. Ce sont en quelque sorte les entrées-sorties entre le workflow et le programme host.
Le HandleExternalEventActivity va pemettre de marquer une pause dans le deroulement d’un workflow en attendant le déclement d’un evenement. Le CallExternalMethodActivity va quand à lui effectuer en quelque sorte l’opération inverse, à savoir, déclencher l’appel d’une methode externe au workflow.
Les methodes et evenement vont devoir etre défini dans une interface marquée par l’attribut ExternalDataExchange. Le programme host, lui, devra ajouter le service ExternalDataExchangeService
Mission 1 : Création du projet DTO pour les objets communs
1) Créons donc un nouveau projet de type Class Library en VB.net. Nous allons commencer tout d’abord par ajouter une référence au Workflow Foundation qui est : System.Workflow.Activities
2) Ensuite créons une classe nommé MyEventArgs qui nous pemettra de passer des arguments dans notre evenement. Nous allons, dans cette classe, stocker un petit message, il faudra donc créer un champ et une propriété de type String nommé Message.
Cette classe doit être Serializable et doit hériter de la classe System.Workflow.Activities.ExternalDataEventArgs. Il faudra donc dans le code du constructeur ajouter un MyBase.New(instanceId) avec comme instanceId, l’instance de notre workflow en Guid pour que l’evenement puisse etre mappé sur la bonne instance de workflow.
Notre classe pourrait ressembler à cela :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | <Serializable()> _ Public Class MyEventArgs Inherits System.Workflow.Activities.ExternalDataEventArgs Private m_Message As String Public Property Message() As String Get Return m_Message End Get Set(ByVal value As String) m_Message = value End Set End Property Sub New(ByVal instanceId As Guid, message as String) MyBase.New(instanceId) m_Message = message End Sub End Class |
3) Créons maintenant notre Interface de communication que l’on nommera dans notre exemple : ICommunication.
L’interface doit être marquée par l’attribut System.Workflow.Activities.ExternalDataExchange().
Nous allons définir une methode nomme MaMethode qui prendra en argument un message en string et un evenement nommé MonEvenement de type MyEventArgs créé juste avant :). Le code pourrait être :
1 2 3 4 5 | <System.Workflow.Activities.ExternalDataExchange()> _ Public Interface ICommunication Sub MaMethode(ByVal message As String) Event MonEvenement As EventHandler(Of MyEventArgs) End Interface |
4) Pour finir, compiler votre projet DTO et passons à la création du workflow
Mission 2 : Création du workflow
1) Commencons par créer un nouveau projet dans notre solution de type Sequential Workflow Library et ajouter la référence au projet DTO.
Notre workflow va ressembler à ca :
Au démarrage, il attend l’evenement MonEvenement (Activity HandleExternalEvent) qui contient un message via la classe MyEventArgs , puis quand l’evenement est recu, appel MaMethode (Activity CallExternalMethod) en passant en parametre le message contenu dans notre evenement.
Plutot qu’un long baratin, la démo en video :
Mission 3 : Création de la couche service
Il ne vous plus qu’a créer la couche service qui s’occupera de démarrer le runtime et les instances de votre workflow. C’est elle aussi qui implémentra l’interface ICommunication.
Ici, notre couche service sera tres simple. Elle disposera des methodes StartRuntime et StartInstance pour demarrer le runtime du WF et l’instance de notre workflow. La methode DeclencherEvent s’occupera de declencher l’evenement. De plus, elle implementra notre interface ICommunication (methode MaMethode et evenement MonEvenement). A noter que lors de la creation de notre runtime, nous avons ajouter le service ExternalDataExchangeService pour pouvoir communiquer avec notre workflow via notre Interface.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | Public Class Service Implements DTO.ICommunication Dim runtime As Workflow.Runtime.WorkflowRuntime Dim instance As Workflow.Runtime.WorkflowInstance Sub StartRuntime() runtime = New Workflow.Runtime.WorkflowRuntime() Dim eds As New Workflow.Activities.ExternalDataExchangeService() runtime.AddService(eds) eds.AddService(Me) runtime.StartRuntime() End Sub Sub StartInstance() instance = runtime.CreateWorkflow(GetType(WorkflowDemo2.Workflow1)) instance.Start() Console.WriteLine("InstanceId {0} demarrée", instance.InstanceId.ToString()) End Sub Sub DeclencherEvent(ByVal message As String) RaiseEvent MonEvenement(Nothing, New DTO.MyEventArgs(instance.InstanceId, message)) End Sub Public Sub MaMethode(ByVal message As String) Implements DTO.ICommunication.MaMethode Console.WriteLine("MaMethode appelée. Le message est : {0}", message) End Sub Public Event MonEvenement(ByVal sender As Object, ByVal e As DTO.MyEventArgs) _ Implements DTO.ICommunication.MonEvenement End Class |
Mission 4 : Création de la GUI
Ici dans notre projet notre GUI sera en mode console. Elle doit juste faire reference à notre couche service et l’instancier. Le code peut être :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Module Module1 Sub Main() 'Instanciation de la couche service Dim service As New Service() ' Demarrage du Runtime WF service.StartRuntime() ' Demarrage d'une instance de notre Workflow service.StartInstance() ' Declenchement de l'evenement Console.Write("Message a passer dans l'evenement ? ") service.DeclencherEvent(Console.ReadLine()) ' Fin Console.Read() End Sub End Module |
Ce qui donne à l’ecran :
Conclusion
C’est certe un exemple très simple et qui ne sert a rien, mais j’espere avoir pu vous donner quelques tips pour l’utilisation des HandleExternalEvent & CallExternalMethod au sein d’un workflow sous Worfkflow Foundation.
**UPDATE** : les sources du projet ICI
Dans mon petit post d’introduction à WF, je vous avais parlé et donné le lien de WFPad. Malheureusement, la version de ce soft ne marche pas avec la Beta 2 de WF.
Je vous mets donc à disposition, la nouvelle release de WFPad que j’ai un peu modifé (commenté une ligne qui posait problème) : DOWNLOAD HERE
Pour rappel, WFPad est un projet opensource ecrit en C# qui permet la visualisation et l’édition en mode graphique de code XOML (…de Workflow) 🙂
Le post officiel avec les sources de Mark Schmidt’s : CLICK HERE
La premiere partie sur de mon introduction au .NET Framework 3 sera consacré à WF (ou WWF 😀 ) pour Windows Workflow Foundation.
Revenons d’abord au Workflow
Qu’est qu’un workflow ? Comme je le citais dans mon 1er post sur Netfx3, un workflow est la modélisation et la gestion informatique de l’ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d’un processus métier. Le terme de « workflow » pourrait donc être traduit en français par « gestion électronique des processus métier ». (source Wikipedia).
Un processus métier représente les interactions sous forme d’échange d’informations entre divers acteurs tels que :des humains, des applications ou services, des processus tiers… Il fournit en outre, à chacun des acteurs, les informations nécessaires pour la réalisation de sa tâche. Pour un processus de publication en ligne par exemple, il s’agit de la modélisation des tâches de l’ensemble de la chaîne éditoriale, de la proposition du rédacteur à la validation par le responsable de publication. (Source CommentCaMarche.net)
En quelque sorte le workflow est la logique de votre programme. C’est une série d’étapes décrivant les activités des différentes personnes et applications impliquées dans le processus. Toutes les applications pourraient être modélisées dans un workflow. Pour un processus de publication en ligne par exemple, nous pourrions le modeliser en 4 étapes :
Windows Workflow Foundation
WF est une plateforme de developpement de workflow qui vient se greffer au dessus du framework .NET 2.0. On parle bien de « plateforme de developpement » et non d’un produit permettant la conception de workflow comme BizTalk.
Le Workflow Foundation définit deux types de workflows :
WF offre la possibilité de developper des workflows sur technologie .NET de manière très simple et incroyablement rapide par l’integration d’un designer à Visual Studio 2005 (et bientôt Orcas, le successeur de VS2005).
Les workflows ne peuvent être executés directement. Ils sont compilés dans une DLL (Assembly .NET), c’est pourquoi nous avons besoin d’une application « host » en web, win, console ou autre pour heberger et executer notre workflow.
Avec WF nous avons une notion d’Activity. Un workflow est consistué d’Activity qui ont tous une tache à accomplir (Test IfElse, boucle While, Execution de code, invoquation de webservice, etc..). Workflow Foundation propose plus d’un vingtaine d’Activity de base, mais vous avez la possibilité de developper vos propres Activity et/ou d’en télécharger sur Internet (ex: l’activity SendMail).
Les workflows sont soit decrit en XML que l’on appelle le XOML* (à ne pas confondre avec le XAML de WPF), soit dans du code ou soit en mixte (XOML + Code). Un projet open-source nommé WFPad permet de visualiser graphiquement et d’editer le code XOML d’un workflow totalement independament de VisualStudio. On pourrait penser à un DRH qui viendrait modifier en drag&drop à chaud, sans aucune connaissance en informatique, le workflow d’un processus d’une application de demande de congés des employés par exemple.
WF offre donc une plateforme de developpement de workflow simple, puissante et totalement extensible. La difficulté n’est pas plus dans le developpement mais dans la modélisation.
*: D’après certaines sources, le nom XOML devrait disparaître pour être appellé XAML. Le XAML servirai donc pour la réalisation des IU sous WPF et pour la conception des workflows sous WF.
Comment demarrer ?
Installation
Premierement, il est indispensable de posséder le framework .NET 2.0 car la technologie .NET 3.0 n’est qu’une surcouche du .net 2.0 et Visual Studio 2005 pour pouvoir developper vos workflows.
Ensuite, téléchargez et installer Microsoft Pre-Release Software Microsoft .NET Framework 3.0 – June 2006 CTP
Pour finir, il vous faudra installer les extentions pour VS2005 : Microsoft® Visual Studio® 2005 Extensions for Windows® Workflow Foundation Release Candidate 2
Ressources
Site NETFX3 :
Article sur SUPINFO Project
Article sur TechHeadBrothers
Workflow-Foundation.com
Je publirai en debut de semaine mon (1er) Webcast sur le Workflow Foundation.
En esperant avoir été bien compris, n’hesitez pas à me laisser des commentaires ou m’envoyer un mail pour toutes suggestions, questions ou critiques. Prochaine partie : le Windows Communication Foundation 🙂
Ca fait un peu plus d’une petite semaine que je me suis lancé dans le Windows Workflow Foundation (WF et non WWF ^^), qui est pour moi, ma 1er partie de ma decouverte de .NET 3.0 🙂
Je suis entrain de terminer mon article ainsi qu’un Webcast sur une introduction à WF qui devrait être finalisé ce weekend…
En préparant mon Webcast je me suis heurté à un problème avec l’Activity FaultHandler ! Cette activité permet de recupérer les exceptions survenu dans l’execution de votre workflow…
Mon workflow possédait un CodeActivity qui été sensé travailler avec un XmlDocument representant la response d’un Webservice. Mais voila que dans certains cas mon code pouvait lever l’exception XmlException..
J’ai donc placé dans le « Fault View » du designer, un FaultHandler qui checké l’exception XmlException pour executer un CodeActivity qui ecrivait un petit message « Bug :-))) » ^_^
Mais lorsque je provoquais volontairement l’exception lors de l’execution de mon workflow, celle ci n’etait pas du tout géré par mon FaultHandler et on me renvoyait dans mon code sous VS2005 avec un petit message « XmlException was unhandled by user code » 🙁
A partir de là, grosse perte de temps à chercher dans tous les sens sur les peu de sites qui parle de WF…. La solution est en fait toute bête ^^
En effet, VisualStudio est prioritaire sur les FaultHandlers.. C’est à dire que quand votre Workflow est executé en mode debug sous VS2005, en cas d’exception ce n’est pas le FaultHandler qui repondra mais VS2005. Si maintenant vous executez votre application hors contexte VS2005, là vous aurez bien le FaultHandler qui prendra la main 🙂
Chose dîte, je retourne sur mon Webcast : Que du bonheur 😀
