Implémentation de GoTo dans WF 4

Question

Étant donné qu'un service de flux de travail .NET 4 Windows Workflow Foundation (WF) persistant dans SQL Server est déployé sous AppFabric, comment puis-je "passer" le service d'une activité à une autre? Le flux de travail peut être séquentiel ou organigramme.

Le cas d'utilisation est administratif. Un flux de travail de longue durée est inactif lors de l'activité de réception A. Certains clients appellent le service par erreur, l'acheminant vers l'activité de réception B. Le flux de travail (qui peut être incorporé dans un flux de travail plus important) n'a aucun chemin vers A. Le client appelle le support desk et demande que le flux de travail soit remis à A.

Nous avons vu ce cas se produire fréquemment en production. Notre système BPM actuel prend en charge un appel "goto". Comment cela peut-il être accompli dans WF 4? Si ce qui précède n'est pas pratique, qu'est-ce qu'un bon modèle de conception pour mettre en œuvre une activité «échouée» hors du «chemin heureux» qui peut se ramifier à un nombre limité d'activités antérieures connues (redémarrage d'ici) basé sur une variable? L'objectif est d'éviter de créer un flux de travail illisible avec une multitude de lignes.

EDIT 2: Nous avons décidé de ne pas suivre cette voie, mais il y a un nouveau MSDN article pour ce faire.

EDIT 3: Nous avons encore changé d'avis et allons avec la solution de Leon Welicki de l'article MSDN lié ci-dessus. :)

Answer 1

Cela ne peut pas être fait hors de la boîte. Si cela peut être fait, cela signifierait l'ouverture de l'état du workflow, stocké dans 4 colonnes binaires et le passage à l'état précédent en sachant que n'importe quel nombre d'activités aurait pu être exécuté et toutes les variables auraient pu être changées ou même abandonné parce qu'ils ne sont plus dans la portée. Supposons que j'allais essayer ceci. J'essayerais de copier l'état de la base de données SQL à chaque fois qu'un flux de travail serait inactif afin d'obtenir une sorte de pile avec tous les états inactifs précédents d'un flux de travail. Ensuite, à un moment ultérieur, lorsque le flux de travail est inactif et qu'il n'est pas en mémoire, vous pouvez remplacer l'état actuel par un état antérieur et recharger le flux de travail. Je ne l'ai jamais essayé donc je ne sais pas si cela fonctionnera et je verrai pas mal de problèmes potentiels, je pense que la transaction DB a été en concurrence ou que des emails ont été envoyés mais exécutés une seconde fois.