Traiter les processus longs dans ASP.NET

Question

J'aimerais connaître la meilleure façon de gérer les processus longs lancés à la demande à partir d'une page Web ASP.NET. Le processus peut consister en différentes étapes (comme le téléchargement de fichiers sur le serveur, l'exécution de packages SSIS, l'exécution de procédures stockées, etc.) et parfois le processus peut prendre jusqu'à deux heures pour se terminer. Si j'opte pour une exécution asynchrone à l'aide d'un service WCF, que se passe-t-il si l'utilisateur ferme le navigateur pendant que le processus est en cours, comment le résultat du processus ou de l'échec doit être affiché à l'utilisateur? Pour résoudre ce problème, je choisis les appels de service WCF unidirectionnels, mais le problème est que je dois créer une table de processus et stocker le résultat (et les messages d'erreur en cas d'échec des étapes et des étapes réussies) dans cette table qui est un surcoût supplémentaire parce qu'il y a beaucoup de tels processus avec différentes étapes que l'utilisateur peut invoquer de la page Web et l'utilisateur doit être informé de la progression (dans le cas le plus simple, le statut peut être "xyz de processus") et une fois cela fait, la sortie doit être affichée à l'utilisateur (par exemple en exécutant une procédure stockée).

Quelle est la meilleure façon de concevoir la solution pour cela?

Answer 1

Comme je le vois, vous avez trois options

1. Avoir une page longue course où l'usager attend pour la réponse. Si c'est plusieurs heures, vous allez avoir beaucoup de problèmes d'utilisabilité, donc je ne l'envisagerais même pas.
2. Créez une table de processus pour stocker les résultats des opérations. Exécutez les fonctions de service de manière asynchrone et déléguez la consignation des résultats dans le service. Il peut y avoir une page que l'utilisateur actualise qui obtient les derniers résultats de cette table.
3. Si vous ne voulez vraiment pas créer de table, stockez tous les détails du processus en cours dans l'état de session des utilisateurs et disposez d'une page de processus en cours comme ci-dessus. Vous avez le problème possible que la session peut expirer, ou l'application Web peut redémarrer et vous perdrez tout cela.

Je ne peux pas voir que le numéro 2 est une telle difficulté.Vous pourriez rendre la table assez générique pour englober tous les types de processus: les détails du processus pourraient simplement être encodés en binaire ou en xml et interprétés par l'application web. Vous avez alors la solution la plus robuste.

Answer 2

Je ne peux pas dire quelle serait la meilleure solution, mais l'utilisation de Windows Workflow Foundation pour des processus aussi longs est certainement une façon de s'y prendre.

Vous pouvez faire le suivi du processus pour voir ce stade, il est à, persister même si vous avez des étapes où il est en attente d'entrée utilisateur, etc.

WF fournit beaucoup de fonctionnalités hors de la boîte (en particulier si votre support de stockage est SQL Server) et peut être une bonne option à considérer.

http://www.codeproject.com/KB/WF/WF4Extensions.aspx pourrait vous aider à mieux comprendre la situation.

Answer 3

Je pense que vous êtes sur la bonne voie. Vous devez exécuter le processus de manière asynchrone, stocker l'exécution quelque part (une table) et conserver l'état du processus en cours d'exécution.

Votre nom d'utilisateur doit voir un en attente étiquette d'affichage alors que le processus est en cours d'exécution, et une étiquette fini avec le résultat lorsque le processus terminé. Si l'utilisateur a fermé le navigateur, elle verra le résultat de son processus en cours d'exécution prochaine fois qu'elle se connecte.