HandleExternalEvent & CallExternalMethod sous Workflow Foundation

Dimanche 6 août 2006

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

WFPad pour Windows Workflow Foundation Beta 2.2

Mardi 1 août 2006

Dans mon petit post d’introduction à WF, je vous avez parlé et donné le lien de WFPad. Malheuresement, 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

NetFX3 Part I – Windows Workflow Foundation

Lundi 17 juillet 2006

La premiere partie sur de mon introduction au .NET Framework 3 sera consacré à WF (ou WWF :-D ) 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 :

  • Création et edition des articles par un rédacteur
  • Traduction de l’article
  • Mise en page de l’article
  • Validation du redacteur en chef

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 :

  • les workflows de type « Sequential » (workflow séquentiel) utilisés pour les workflows faisant intervenir des applications et dont le fonctionnement est prédictible.
  • les workflows de type « State Machine » (workflow à état) pour les workflows faisant intervenir des personnes et dont le fonctionnement est régi par leur comportement et les actions qu’ils effectuent.

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 :)

Workflow Foundation: la galère des FaultHandler(s)

Vendredi 14 juillet 2006

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 :-D

3ème après Microsoft :-)

Vendredi 14 juillet 2006

A ma grande surprise, j’ai decouvert, et cela dur depuis 3/4 jours, que je suis 3ème apres le site de Microsoft (www.netfx3.com) sur Google.com pour la recherche « netfx3″ (pour framework .net 3.0) :-D

Vive le référencement, et « pourvu que ca dur » :-D

(ps: le petit inconvenient est que je me fais spammer de commentaires sur mes differents posts ^_^)