# Dotnet > Gnral Dotnet > Windows Workflow Foundation >  Tutoriel State Workflow en .NET4

## vampirella

Bonjour,

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

J'ai bien sr tlcharg le SP1 de VS2010 et l'extension pour manipuler ces fameux State Workflow, mais pas mal de choses ont changs entre la v3 et la v4, ne serait-ce que l'approche diffrente 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 ?

Mme MSDN n'en contient pas (encore je suppose ...), et bien que j'ai trouv plusieurs infos intressantes sur un blog, je reste perplexe sur plusieurs domaines :
Est-il correct de considrer le premier tat fourni par dfaut lors de la cration comme un "tat d'initialisation", puisque la transition entre le "Start" et ce "premier tat" n'est pas paramtrable ?La persistence en tant que webservice reste-t-elle la mme ?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 cre  chaque fois qu'un trigger avec un "Receive" pouvant crer une instance est appelle ?

En vous remerciant d'avance de votre aide !

----------


## vampirella

Bon, aprs plusieurs tests, j'ai pu rpondre de moi-mme sur plusieurs points :

Oui, le premier tat peut tre celui d'initialisation, pouvant tre confondu avec l'tat premier (de dpart). Tout dpend ensuite de la modlisation ralise.Non, la persistance semble tre plus compliqu : autant on configurait en v3.0 le fichier "web.config" pour dfinir la dfinir (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 personnalise ... ce qui me parait trange si ce webservice est fourni  un serveur.Oui, enfin tout dpend encore une fois de la modlisation 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-mme pour plusieurs raisons ; ne serait-ce que dans le premier tat pour lier tous les "Receive" du workflow, et ainsi rediriger les requtes aux bonnes instances de workflow.Oui, si "CanCreateInstance" a t coch. A noter qu'il faudra relier (ou corrler) 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.

----------


## vampirella

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" associe au "Receive" initial.
Cependant, et bien sr, 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 loccurrence 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 :



```

```

Par contre, il faut coder derrire la classe "MyPersistenceProviderFactory", et c'est l que je me perds car je n'ai aucun exemple sur lequel prendre appui ... je n'arrive mme pas  trouver la classe "SqlPersistenceProviderFactory" qui doit hriter de la classe abstraite "PersistenceProviderFactory".

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

----------


## vampirella

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

J'ai russi  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 :



> 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 implmentant "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 ...



> 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 considrer 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 rponse (extraordinaire  ::P: ) obtenu ici, je vais tenter le forum Microsoft, et au pire je reviens en 3.0 ou en 3.5.

----------


## vampirella

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 problme d'implmentation de persistance est rsolu.

----------

