Quel est le meilleur moyen de transférer un grand ensemble de données sur un service Web ASMX?

Question

J'ai hérité d'une application C# .NET qui parle à un service Web et le service Web parle à une base de données Oracle. J'ai besoin d'ajouter une fonction d'exportation à l'interface utilisateur pour produire une feuille de calcul Excel de certaines données.

J'ai créé une fonction de service Web pour exécuter une requête de base de données, charger les données dans un DataTable, puis les renvoyer, ce qui fonctionne correctement pour un petit nombre de lignes. Cependant, il y a suffisamment de données dans l'exécution complète pour que l'application cliente se verrouille pendant quelques minutes, puis renvoie une erreur de délai d'attente. Évidemment, ce n'est pas la meilleure façon de récupérer un tel ensemble de données. Avant d'aller de l'avant et de trouver une façon douteuse de diviser l'appel, je me demande s'il y a déjà quelque chose en place qui peut gérer cela. En ce moment, je pense à une fonction startExport appelant ensuite une fonction next50Rows jusqu'à ce qu'il n'y ait plus de données, mais comme les services web sont sans état, cela signifie que je vais devoir garder une sorte de numéro d'identification et gérer le autorisations associées. Cela voudrait dire que je n'ai pas besoin de charger l'intégralité de l'ensemble de données dans la mémoire du serveur web, ce qui est une bonne chose.

Donc, si quelqu'un connaît un meilleur moyen de récupérer une grande quantité de données (dans un format de table) sur un service Web ASNM, s'il vous plaît faites le moi savoir!

Answer 1

Je suppose que vous voulez simplement appeler le service Web de manière asynchrone, afin que votre application ne bloque pas sur l'interface utilisateur pendant que tout se passe. Jetez un oeil à http://msdn.microsoft.com/en-us/library/ms233842.aspx et voir si cela aide.

Answer 2

Je vous recommande de décharger la tâche sur SSRS, qui gère les requêtes de longue durée sans problème. Vous pouvez créer un rapport avec votre générateur de rapports, puis utiliser votre application .NET pour appeler les services Web SSRS et exécuter votre rapport, puis exporter les résultats au format Excel (en tant que tableau d'octets). Voir this page pour l'exemple de code à l'aide du service .asmx et this page pour l'appel de SSRS avec WCF.

Vous devez également appeler votre service Web dans un thread distinct pour éviter de bloquer votre interface utilisateur.

Answer 3

Nous avions ce scénario d'entreprise exact il y a quelques années, et je vais vous dire ce que nous avons fait.

1. Essayez de limiter la quantité de données transférées
2. Si vous transférez n tables, les diviser en n datatables et le transfert d'un datatable à la fois.
3. Compressez votre jeu de données/datatable avant de transférer. Cela fait un énorme (énorme énorme) impact. De l'autre côté, décompressez le flux d'octets dans un dataset/datatable. N'utilisez pas non plus la compression intégrée de .NET - utilisez SharpZipLib. Cela donne de bien meilleurs résultats.
4. En outre, vous pouvez effectuer le transfert de manière asynchrone pour empêcher le client de se bloquer.

Nos clients utilisent la solution ci-dessus, sans problème, depuis des années.

Answer 4

Voir "Large Data and Streaming" dans la bibliothèque MSDN. N'utilisez pas les services Web ASMX si vous souhaitez effectuer des transferts de données volumineux.

Answer 5

Le problème est commun: vous avez beaucoup de données à retourner à l'utilisateur.

Si vous avez de la chance, vous pouvez vous en sortir en augmentant le délai d'expiration du service Web.Dans le cas contraire, une solution consistant à renvoyer à l'utilisateur des données comportant des pages à la fois répondrait-elle à vos besoins? Dans cette conception, l'appelant serait responsable de spécifier la page de démarrage, et combien de lignes de données par page à votre service Web.

Voir Pagination Queries et Pagination tips

Si toutefois, vous n'êtes pas limité à l'utilisation webservice comme une solution, alors vous pourriez enquêtions offrir des services d'information à vos utilisateurs. Vraiment vaut la peine d'examiner cette option alternative :)

Answer 6

Je recommande WCF Data Services (ou peu importe comment il s'appelle maintenant). Vous pouvez exposer un point de terminaison oData qui (si vous avez .NET des deux côtés du service web) vous donne une limitation de requête transparente (le serveur limite le nombre de réponses dans un seul appel et le client effectue automatiquement des requêtes supplémentaires). Il vous donne également une interface de type IQueryable extrêmement flexible.