Comment utiliser un WF DelayActivity dans un flux de travail Web ASP.Net

Question

J'ai une application Web que j'ajoute des fonctionnalités de workflow à l'utilisation de Windows Workflow Foundation. J'ai basé ma solution autour de l'exemple Orders Workflow de K. Scott Allen sur OdeToCode. Au début, je ne me rendais pas compte de l'importance de la mise en garde "si vous utilisez des activités de retard avec et configurez des temporisateurs actifs pour le service de planification manuelle, ces événements se produiront sur un thread d'arrière-plan non associé à une requête HTTP". Je dois maintenant utiliser les activités de Delay et cela ne fonctionne pas comme c'est le cas avec l'architecture de sa solution. Est-ce que quelqu'un a trouvé cela et a trouvé une bonne solution à cela? L'exemple est lié à beaucoup d'endroits, mais je n'ai vu personne d'autre rencontrer ce problème et cela me semble un peu un bouchon de spectacle. Editer: Le problème est que les résultats du workflow sont renvoyés à l'application Web via HttpContext. J'utilise ManualWorkflowSchedulerService avec useActiveTimers et cela fonctionne correctement dans la plupart des cas, car les événements de flux de travail sont déclenchés depuis l'application Web et HttpContext existe toujours lorsque les résultats du workflow sont renvoyés et que l'application Web peut poursuivre le traitement. Lorsqu'une activité de délai est utilisée, le traitement se produit sur un thread d'arrière-plan et lorsqu'il tente de renvoyer des résultats à l'application Web, il n'existe aucun HttpContext valide (car il n'y a pas eu de demande HTTP). C'est-à-dire que la webapp essaye de traiter les résultats du workflow mais qu'il n'y a pas eu de requête http.

Je pense que je dois faire tout le traitement de l'activité Post Delay dans le flux de travail plutôt que de passer à l'application Web.

Cheers.

Answer 1

Vous n'avez pas décrit le problème que vous rencontrez. Mais peut-être que cela aide.

Vous pouvez utiliser ManualWorkflowSchedulerService avec useActiveTimers et le flux de travail continuera sur un autre thread. Normalement, c'est bien parce que votre requête HTTP est déjà terminée et que cela n'a pas vraiment d'importance.

Si toutefois vous avez besoin d'un contrôle total, le runtime du workflow vous permettra de gérer tous les workflows chargés à l'aide de la fonction GetLoadedWorkflows(). Cela retournera une collection d'objets WorkflowInstance. Vous pouvez les utiliser pour appeler le GetWorkflowNextTimerExpiration() afin de vérifier lequel a expiré. Si tel est le cas, vous pouvez le reprendre manuellement. Dans ce cas, vous voulez utiliser ManualWorkflowSchedulerService avec useActiveTimers = false pour pouvoir également contrôler le dernier thread. Cependant, dans la plupart des cas, useActiveTimers = true fonctionne parfaitement.