Discussion :

[rastali]

Bonjour à tous,

J'ai un gros souci sur l'application que je développe (VS 2005, ASP.NET 2.0 C#).
J'effectue le traitement de données suivant:
- lecture d'un fichier xml
- affichage des informations à l'écran
- saisie d'informations complémentaires par l'utilisateur
- insertion des données en base.

C'est lors de l'étape d'insertion des données en base qu'il y a un problème. Je dois insérer parfois jusqu'à 30000 enregistrements. Le traitement dure entre 2h et 2h30 suivant la quantité d'info contenue dans les fichiers xml.

Au début je faisais un simple appel de ma procédure stockée d'insertion dans une boucle, la barre de progression de IE progressé pour finalement arriver sur la page d'erreur d'IE (impossible d'afficher la page) et le traitement n'etait pas terminé.

Après quelque recherche, j'ai ajouté un UpdatePanel et un UpdateProgress. Au bout d'un moment (environ 30 minutes) le message affiché dans le ProgressTemplate de l'UpdateProgress disparaissait, puis un pop-up d'erreur s'affichait avec le code erreur suivant : "Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was : 500" et j'ai déjà eu le meme message d'erreur avec le code erreur 12152.
Après un click sur le bouton OK de la pop up, quand le code erreur est 500, la fonction qui appelle la proc stock me renvoie : Le thread a été abandonné. et le traitement ne se termine pas.
Après un click sur le bouton OK de la pop up, quand le code erreur est 12152, le traitement continue de façon transparente jusqu'à la fin, et je peux naviguer sur mon application, mais cette pop up est tout de meme derangeante, sans compter que je préférerai que le message de l'Update Progress reste affiché.

Dernière solution testée, j'ai essayé d'effectuer ces multiples insertions a l'intérieur d'un thread. Donc la j'ai directement la main sur l'appli, je peux donc changer de page, mais du coup je ne peux pas savoir quand le thread est fini. Mais le gros problème, c'est que ca fini par planter avec l'erreur : le thread a été abandonné, et donc l'insertion des données n'est pas complète.

Est-ce que quelqu'un à une solution à mon problème ?

[Kaidan]

ASP.NET pour effectuer un traitement qui dure 2h30 n'est tout simplement pas la bonne solution.

[SaumonAgile]

Je dirais même que lancer des imports à distance sur des gros volumes de données est en soit une mauvaise approche. Je ferais plutot tourner un service sur le serveur qui doit effectuer le traitement, et je déposerais le fichier à importer dans un répertoire surveillé par le service (avec un FileSystemWatcher par exemple).

[rastali]

Bonjour,

et merci de vos réponses.

Est-il possible d'appeler une fonction d'un service (je n'y connais rien en service) via une appli asp.net ? Ou alors la solution serait que l'appli asp.net déplace les fichiers, et que le service traite le fichier puis le déplace a son tour afin de ne pas boucler dessus?

Est-ce que l'utilisation d'un webservice auquel je passerai la liste de données en paramètre serait efficace?

[SaumonAgile]

Il vaudrait mieux utiliser un service windows. Sinon tu auras le même problème avec un web service.
Effectivement, tu peux créer une page web qui te permet d'uploader un fichier sur le serveur dans le répertoire surveillé par le service windows.
Et oui, tu peux déplacer le fichier dans un autre répertoire après le traitement et même pourquoi pas envoyer un mail pour dire que le traitement est fini.

Exemple de hierarchie pour les dossiers
- IN : répertoire surveillé par le service dans lequel sont uploadés les fichiers
- OUT : répertoire de destination pour les fichiers traités par le service.
- ERR : répertoire pour les fichiers n'ayant pas pu être traités correctement par le service.

[Bluedeep]

Il vaudrait mieux utiliser un service windows. Sinon tu auras le même problème avec un web service.

D'autant que pour causer ".Net à .Net" on ne voit pas bien l'intérêt d'un webservice dans ce cas.

[SaumonAgile]

D'autant que pour causer ".Net à .Net" on ne voit pas bien l'intérêt d'un webservice dans ce cas.

Un service ne sert pas à pouvoir utiliser des plateformes différentes, ça sert à séparer/découpler des systèmes et à fournir une interface standard d'interoperabilité (principalement). Peu importe que ce soit du .NET, Java, ou autre chose.

[Bluedeep]

Un service ne sert pas à pouvoir utiliser des plateformes différentes, ça sert à séparer/découpler des systèmes et à fournir une interface standard d'interoperabilité (principalement). Peu importe que ce soit du .NET, Java, ou autre chose.

Tu m'as visiblement mal lu.

Je reprends donc.

Un des intérêts du webservice est qu'il expose de manière standardisée des ressources; on sait donc qu'il est opérable quelque soit la nature technique du client. Néanmoins cet interopérabilité se paye (SOAP est assez limité).

Ici, on a pas à s'assurer d'une quelconque interopérabilité, donc un service windows suffit et n'impose pas les limitations d'un webservice.

C'est plus clair ?

[SaumonAgile]

Je ne répondais pas spécialement dans le contexte présent mais plutôt dans le contexte général. C'est le ".NET à .NET" dans ton affirmation qui m'a fait réagir.

Ton affirmation "si c'est pour faire communiquer système en .NET avec un autre système en .NET, pas besoin de web service" ne me semble pas correcte.
Tu peux utiliser des interfaces standards (comme les webservices) pour faire communiquer des systèmes (même tous écrits en .NET) pour la simple raison qu'il s'agit justement d'un standard, et que cela permet de ne pas limiter l'évolution du système à une unique technologie (problème que tu aurais en utilisant le remoting à la place du ws).

[Bluedeep]

J
Tu peux utiliser des interfaces standards (comme les webservices) pour faire communiquer des systèmes (même tous écrits en .NET) pour la simple raison qu'il s'agit justement d'un standard,

C'est une évidence (je dirais presque un truisme) mais dans ce cas tu dois t'interroger sur l'utilité et le rapport cout/bénéfice d'utiliser un standard. Comme tu le dis :

et que cela permet de ne pas limiter l'évolution du système à une unique technologie (problème que tu aurais en utilisant le remoting à la place du ws).

Oui, mais là encore, c'est, toutes proportions gardées, la même idée que de se dire : dois je concevoir un code portable ou non ?

[SaumonAgile]

C'est une évidence (je dirais presque un truisme) mais dans ce cas tu dois t'interroger sur l'utilité et le rapport cout/bénéfice d'utiliser un standard.

Je suis absolument d'accord avec toi. Je serais tenté de dire que :
- dans un environnement hétérogène à la base, on préfèrera les standards;
- dans un environnement très centré sur une techno, on réservera la plupart du temps les standards pour les systèmes interfaces avec l'extérieur.

Ensuite il faut aussi prendre en compte, le cout d'un "technology miss" (comme pour les "cache miss/hit"), si le passage à un standard etait trop couteux pour un système, on préférera peut-être le développer dès le début dans un standard.

Tout ce que je viens de dire n'étant que mon avis, pas une affirmation.