Discussion :

[Jérôme Lambert]

Salut à tous,

J'ai quelques soucis avec les workflows combiné au versioning d'assembly et à la persistance.
Pour aller droit au but : Comment peut-on maintenir des workflows dont l'assembly d'origine a changé ?

Imaginons que j'ai dans mon assembly Core un modèle de workflow de type State Machine. Mon projet client a un WorkflowRuntime afin de lancer des instances de mon Workflow provenant de l'assembly Core. J'ai ajouté le service de persistance afin que mes workflows soient sauvegardés dans une base de données.

Je lance donc l'application avec mon assembly en version 1.1, je crée une instance de workflow et j'arrête l'application pour que le workflow soit sérialisé en base de données. Ensuite, je change le numéro de version de mon assembly Core (ça fonctionne aussi si je change le schéma de mon workflow) et je relance mon application avec la nouvelle version de l'assembly Core. Et là BOUM, impossible de récupérer mon workflow vu que l'assembly n'est plus la même, logique.

Alors sur MSDN, je trouve la réponse pour gérer ce problème : http://msdn2.microsoft.com/en-us/lib...75(vs.85).aspx

If you want to use the V1 version of the workflow for the V1 persisted instances, you can use an assembly resolver to help you handle this situation.

Ok, je veux bien créer un assembly resolver... Donc j'imagine que c'est une classe qui pourra nous donner un objet Assembly. Exemple, je dis :

• Je veux mon assembly Core en version 1.1
• Maintenant, je veux mon assembly Core en version 1.2

Est-ce que je me trompe ?

Ensuite, j'ai mon objet Assembly, mais comment est-ce que je peux relier cet objet à la récupération d'une instance d'un workflow qui se trouve en base de données ?

Comme vous voyez, il me manque quelques briques que je n'arrive pas à trouver sur google

[Bluedeep]

Et en effectuant une persistance binaire de ton wf, plutôt que d'utiliser la persistance de SqlWorkflowPersistanceService, ça donne quoi ?

J'ai un problème un peu similaire, mais je l'ai résolu "bourrin" :

- une assembly ne contient qu'un workflow.

- tout lancement d'un workflow par un autre passe par mon "WorkflowNodesManager" qui , en gros, interroge la charge des différents noeuds disponibles et l'envoie sur celui a priori le moins chargé. (j'ai donc une activity d'enchainement spécifique).

- si une modification est faite a un workflow elle n'est déployée que quand la dernière instance de ce type a fini son job.

[Jérôme Lambert]

Et en effectuant une persistance binaire de ton wf, plutôt que d'utiliser la persistance de SqlWorkflowPersistanceService, ça donne quoi ?

Tu parles de faire persister mes workflow sur fichier ? Tu penses que ça pourrait prouver quoi si je faisais ça ?

- une assembly ne contient qu'un workflow.

Pas bète.

- si une modification est faite a un workflow elle n'est déployée que quand la dernière instance de ce type a fini son job.

Cette solution n'est pas envisageable pour ma part car le projet contiendra des workflows qui pourront vivre pendant des semaines.


Ce qui me pose vraiment problème, c'est la solution que propose Microsoft. Je ne vois pas comment relier tout ce que j'ai.

Dans me base de données, deux workflows :

• WorkflowType1 avec ID1 et créé avec l'assembly Core 1.1
• WorkflowType1 avec ID2 et créé avec l'assembly Core 1.2

Du côté de mon application courante (au niveau du client), j'ai un workflow runtime qui permet de récupérer un workflow en base de données. Mais comment faire pour désérialiser le workflow :

• ID1, en prenant en compte l'assembly Core 1.1
• ID2, en prenant en compte l'assembly Core 1.2

Je ne sais ni quoi utiliser (fichier de config avec AssemblyBinding ou la classe Assembly ou encore la classe AppDomain avec l'utilisation d'un proxy apparement), ni comment utiliser chaque proposition.