Tutoriel State Workflow en .NET4

Bonjour,

Maintenant sur VS2010 (donc .NET4), j'essaie de me repérer par rapport aux "State Workflow" dans ce nouvel environnement.

J'ai bien sûr téléchargé le SP1 de VS2010 et l'extension pour manipuler ces fameux State Workflow, mais pas mal de choses ont changés entre la v3 et la v4, ne serait-ce que l'approche différente pour les transitions entre états ou le "handleEvent" que je ne retrouve plus (à moins que ce dernier ne fasse encore partie d'une autre extension que j'aurais zappé ...).

Pour faire bref, pourriez-vous m'indiquer des tutoriels pour la manipulation de state workflow en .net4 ?

Même MSDN n'en contient pas (encore je suppose ...), et bien que j'ai trouvé plusieurs infos intéressantes sur un blog, je reste perplexe sur plusieurs domaines :

• Est-il correct de considérer le premier état fourni par défaut lors de la création comme un "état d'initialisation", puisque la transition entre le "Start" et ce "premier état" n'est pas paramétrable ?
• La persistence en tant que webservice reste-t-elle la même ?
• Si l'on veut transformer un stateworkflow en webservice, est-il pertinent de mettre les "Receive" dans les trigger, ou vaut-il mieux les mettre ailleurs ?
• Une nouvelle instance de workflow est-elle créée à chaque fois qu'un trigger avec un "Receive" pouvant créer une instance est appellée ?

En vous remerciant d'avance de votre aide !

Bon, après plusieurs tests, j'ai pu répondre de moi-même sur plusieurs points :

• Oui, le premier état peut être celui d'initialisation, pouvant être confondu avec l'état premier (de départ). Tout dépend ensuite de la modélisation réalisée.
• Non, la persistance semble être plus compliqué : autant on configurait en v3.0 le fichier "web.config" pour définir la définir (avec éventuellement sa persistence personnalisé), autant j'ai l'impression qu'on est obligé de passer par du self-host et avec la classe "WorkflowServiceHost" pour fournir sa persistance personnalisée ... ce qui me parait étrange si ce webservice est fourni à un serveur.
• Oui, enfin tout dépend encore une fois de la modélisation et du comportement attendu. Par exemple, pour passer d'un état à un autre, il faut bien mettre le "Receive" dans le trigger. Par contre, il peut y avoir des "Receive" dans un état lui-même pour plusieurs raisons ; ne serait-ce que dans le premier état pour lier tous les "Receive" du workflow, et ainsi rediriger les requêtes aux bonnes instances de workflow.
• Oui, si "CanCreateInstance" a été coché. A noter qu'il faudra relier (ou corréler) les "Receive" entre eux pour la raison expliqué au-dessus.

En ce qui concerne la persistance par contre, j'ai encore du mal à approcher une persistance pour webservice, qui plus est personnalisé pour une BD Oracle.

Je reviens à la charge en ce qui concerne la persistance :

Elle est prise en compte localement sur le serveur ASP.NET (ou IIS ou autre ...) lorsqu'on coche "PersistBeforeSend" de l'activité "SendReply" associée au "Receive" initial.
Cependant, et bien sûr, si le serveur crash / est relancé, cette persistance locale est perdue.

Je cherche donc à programmer cette persistance par le biais d'un stockage sur BD, Oracle en l’occurrence pour des raisons de contrainte client.

J'ai cru comprendre en farfouillant sur le net qu'on peut facilement associer un fournisseur de persistance (PersistenceProviderFactory) par le fichier web.config :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

<?xml version="1.0" encoding="utf-8"?> <configuration> ... <system.serviceModel> <behaviors> <serviceBehaviors> <behavior> <serviceMetadata httpGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="true"/> <persistenceProvider type="MonProjet.MyPersistenceProviderFactory, DurableServiceFactory, Version=1.0.0.0"/> </behavior> </serviceBehaviors> </behaviors>

---

Par contre, il faut coder derrière la classe "MyPersistenceProviderFactory", et c'est là que je me perds car je n'ai aucun exemple sur lequel prendre appui ... je n'arrive même pas à trouver la classe "SqlPersistenceProviderFactory" qui doit hériter de la classe abstraite "PersistenceProviderFactory".

Si quelqu'un pouvait m'aiguiller sur la bonne voie, j'en serais reconnaissant.

Je suis au point mort avec cette nouvelle version .NET4.

J'ai réussi à m'inspirer de "SqlPersistenceProviderFactory" (merci .NET reflector ...) pour faire ma propre classe.

Lorsque je fournis cette classe au fichier web.config (toujours dans la balise <persistenceProvider>), l'erreur suivante apparait :

Citation:

---

System.ServiceModel.Activities.WorkflowServiceHost is incompatible with System.ServiceModel.Persistence.PersistenceProviderBehavior.
The PersistenceProviderBehavior or derived class, such as SqlPersistenceProviderBehavior, should be removed.
To enable persistence with WorkflowServiceHost, a behavior which installs a System.Runtime.DurableInstancing.InstanceStore should be used instead, such as SqlInstanceStoreBehavior.

---

Soit, je prend pour premier test une classe implémentant "InstanceStore", assez officiel d'ailleurs car il s'agit d'une classe fournit par Microsoft en exemple pour persister sous fichier XML (ce qui pourrait me convenir au final).
Et là ... nouvelle erreur qui m'a fait rire jaune ...

Citation:

---

Unable to cast object of type 'CarInspiredWF_for_WS_persisted.XmlWorkflowInstanceStore' to type 'System.ServiceModel.Persistence.PersistenceProviderFactory'.

---

C'est bien le comble !
J'ai l'impression que Microsoft refuse de considérer la persistence de webservice autrement que par leur produit SQL Server ... Ou alors je me suis royallement planté quelque part, mais la documentation est bien faible ...

Bref, devant le nombre de réponse (extraordinaire :P) obtenu ici, je vais tenter le forum Microsoft, et au pire je reviens en 3.0 ou en 3.5.

Voici le thread du forum Microsoft concernant mon interrogation :

http://social.msdn.microsoft.com/For...2-e25c9d8ed1f0

Je suis passé à d'autres soucis (pour changer :aie:), mais le problème d'implémentation de persistance est résolu.