2010-01-14 9 views
8

Comment résoudre ce problème (en WF4):Chargement persista flux de travail après workflowdefinition a changé WF4

créer un flux de travail en XAML et commencer à plusieurs instances de celui-ci, j'ai un persistancestore et tous les flux de travail persiste sur un signet à mi-chemin de leur flux de travail.

Maintenant j'arrêter l'application

Si je te remets en marche tout application est repris, en bien battant. Mais que se passe-t-il si je veux changer la définition du flux de travail après la persistance des instances en cours d'exécution? la seule façon de charger les flux de travail en cours d'exécution (que j'ai pu trouver) est la manière suivante:

 WorkflowApplication wfapp = new WorkflowApplication(new WorkflowDefinition()); 
     wfapp.InstanceStore = new SqlWorkflowInstanceStore(connStr); 

     wfapp.Load(wfGuid); 

Vous avez donc besoin de la définition de flux de travail, si elle a changé au cours de la persistence, les choses tournent mal.

Quelle est la meilleure façon de résoudre ce problème?

+1

BTW, ce scénario fait l'objet de certains contrats à terme WF4. Découvrez cette présentation de MIX 10: http://channel9.msdn.com/Events/PDC/PDC10/FT08 – Will

Répondre

3

Ce scénario est un peu problématique. Il n'y a aucun moyen de migrer une ancienne définition de workflow vers le nouveau format. J'ai fait quelques tests limités et quelques scénarios avec l'ajout/la suppression d'activités qui ne fonctionnaient pas encore correctement. Mais alors j'ai aussi des scénarios qui vont mal, y compris l'exécution d'une activité déjà terminée. Autant que je sache, il n'y a pas de bon moyen de résoudre le problème autrement qu'en suivant la version du XAML/assembly utilisé pour créer le workflow et en vérifiant que lorsque vous voulez redémarrer un workflow pour déterminer la version du workflow utilisation.

1

Ce n'est pas vraiment un problème avec Windows Workflow car c'est le service de persistance SQL. Vous pouvez créer votre propre service de persistance capable de gérer cette situation, soit en prenant en charge la conversion de l'ancien flux de travail dans le nouveau flux de travail, soit un service de persistance sérialisé en XML/JSON, plus facile à désérialiser. version comme une autre version.

2

De nombreuses versions du même flux de travail doit coexister. Je veux dire, les anciennes instances doivent finir avec l'ancienne version du workflow, et les nouvelles doivent commencer par une nouvelle version du workflow. Dans mon cas, nous avons des services de flux de travail. C'est sur la configuration où un routeur décrit l'ordre dans lequel les instances tentent d'être exécutées. Si une instance ne peut pas commencer à fonctionner avec une version, la suivante est essayée, et ainsi de suite. De même, si votre modification n'implique pas de changements dans les variables de flux de travail, les contrats exposés, etc ... les anciennes et nouvelles versions d'instance de flux de travail peuvent s'exécuter sur la même version de workflow. Vous le saurez, en le testant.

1

Il est possible de charger l'instance wf persistante après avoir changé la définition en WF4 - vous devez analyser et modifier les fichiers xml que le moteur wf stocke. Vous devez créer deux workflows égaux: avec l'ancienne version et la nouvelle version et les comparer afin d'éliminer les différences. Cela doit être fait pour la définition xml et le fichier xml de données complexes utilisé pour stocker l'état du workflow. L'analyser avec LinqToXML vous fera gagner beaucoup de temps et vous devrez vous assurer que vous avez vérifié toutes les différences - s'il reste une différence, le wf ne pourra pas charger. Il y a un élément "ResumeData", que vous pouvez trouver dans l'état wf xml, qui est trop lourd à analyser, mais la bonne nouvelle est que vous pouvez simplement le supprimer.