Discussion :

[Synack31]

Bonjour,

Je dois développer un serveur de Web Service SOAP à partir de WinDev mais j'ai actuellement un problème de performance de temps entre l’émission d'une requête sollicitant un service et la réponse du dit service.
En effet la réponse attendu renvoie un nombre important de ressources (environ 50 000) qui mettent du temps à être généré par le serveur ainsi qu'a être formatées en XML par WinDev

Etant donné mon problème j'ai pensé renvoyer non pas une seul réponse mais plusieurs de taille plus raisonnable qui serai envoyé petit à petit. Mon problème est que je ne vois rien dans WinDev qui permet de renvoyer plusieurs réponse lors de la sollicitation d'un service. Le fonctionnement normal a l'air d’être une seule réponse par requête sur le Web Service.

J'ai également pensé à un fonctionnement asynchrone avec un service qui prépare la réponse et un autre qui la renvoie mais WinDev ne génère le XML de retour qu'au moment de retourner la réponse donc le XML ne sera généré qu'a l'appel du second service.

Du coup voici les questions :

Existe-t-il un moyen de renvoyer plusieurs réponses lors de la sollicitation d'un service WinDev?
Peut-on pré-générer la réponse d'un Web Service dans son format final (XML) et du coup comment utilisé cette réponse lors de la sollicitation d'un second service ?


Merci.

[Invité]

Bonjour,

Tu sais, faire plusieurs A/R avec le serveur (que cela soit du HTTP ou du SQL ou quoi que ce soit d'autre) n'a aucune chance d'être plus performant qu'un seul...
En revanche, cela te permettrait de gérer une jauge et c'est pas mal pour patienter.

Si tu "maîtrises" le serveur, les sockets pourraient être une solution
Un SocketEcrit depuis le client pour déclencher le traitement sur le serveur.
Puis une boucle avec des SocketLit lancées dans un thread parallèle sur le client.
Le serveur pourrait te renvoyer un "#END#" à la fin ce qui te permettrait de - sortir de ta boucle - fermer ta jauge - afficher le résultat - ...

Bon courage.

[Synack31]

Merci pour ta réponse.

Je me suis mal exprimé concernant le problème de performance, je ne cherche pas à améliorer les perfs mais a traiter les problèmes qui en découle càd une temps de réponse client-serveur débouchant la plupart du temps sur un timeout et donc la fin de la transaction. L'idée des sockets est une solution intéressante que je vais étudier mais j'ai peur de perdre la flexibilité qu'un Web Service propose. L'idéal est de traiter se problème uniquement du coté serveur pour que le WSDL suffise à la mise en place d'une application cliente.

[Lo²]

Bonjour,

Est-ce que l'utilisation d'un webservice pour renvoyer plus de 50000 infos est le bon choix ?
Je verrai éventuellement un webservice qui va te renvoyer le nom du fichier XML généré, puis ce fichier est mis à dispo sur un serveur FTP, qui sera récupéré/traité par le client.

[tunizar]

Merci pour ta réponse.

Je me suis mal exprimé concernant le problème de performance, je ne cherche pas à améliorer les perfs mais a traiter les problèmes qui en découle càd une temps de réponse client-serveur débouchant la plupart du temps sur un timeout et donc la fin de la transaction. L'idée des sockets est une solution intéressante que je vais étudier mais j'ai peur de perdre la flexibilité qu'un Web Service propose. L'idéal est de traiter se problème uniquement du coté serveur pour que le WSDL suffise à la mise en place d'une application cliente.

Bonjour,
Il faut découper le traitement fonctionnel du Web Service, autrement dit la logique métier en plusieurs fragments, ensuite faire appel
aux tâches parallèles
Par exemple : un Web Service qui récupère le client et ses factures mais il prend trop de temps avec un time out, il faut le découper en deux Web service un pour la récupération du client et l'autre pour la récupération des factures avec un lancement basé sur ces tâches parallèles

[hpascal]

Bonjour

D'accord avec Lo2 pour séparer la récupération des données du WebService
Le WebService te renverrait le nom du fichier ou éventuellement l'ID d'une file d'attente où trouver le nom du fichier
Je préfère le gestion d'une file d'attente plus souple et performante pour gérer les reprises sur incident
Ensuite la récupération se ferait par ftp ou http

Après téléchargement tu supprimes le fichier ou tu mets à jour la file d'attente (qui serait épurée par le serveur)
La file d'attente peut être gérée par ton WebService ou par celui de PCSOFT (SQLConnecteWS)

D'ailleurs pour améliorer le temps de récupération il ne faudrait pas que ce fichier soit en XML, bien trop verbeux. Quand c'est possible il vaut mieux un format à plat (csv ...)

[tunizar]

Bonjour


D'ailleurs pour améliorer le temps de récupération il ne faudrait pas que ce fichier soit en XML, bien trop verbeux. Quand c'est possible il vaut mieux un format à plat (csv ...)

Bonjour,
Le compresser éventuellement ?

[hpascal]

Bonjour,
Le compresser éventuellement ?

Encore mieux

[Synack31]

Merci pour votre aide,

Est-ce que l'utilisation d'un webservice pour renvoyer plus de 50000 infos est le bon choix ?

Hélas je n'ai pas vraiment le choix. A vrai dire le cas de renvoie de 50000 infos est un cas rare mais que je ne peux pas ignorer.

Je verrai éventuellement un webservice qui va te renvoyer le nom du fichier XML généré, puis ce fichier est mis à dispo sur un serveur FTP, qui sera récupéré/traité par le client.

C'est une solution que je vais surement utiliser si je n'en trouve pas d'autres qui n'utilisent que des services.

Il faut découper le traitement fonctionnel du Web Service, autrement dit la logique métier en plusieurs fragments, ensuite faire appel
aux tâches parallèles
Par exemple : un Web Service qui récupère le client et ses factures mais il prend trop de temps avec un time out, il faut le découper en deux Web service un pour la récupération du client et l'autre pour la récupération des factures avec un lancement basé sur ces tâches parallèles

Le souci c'est que je ne vois pas dans Windev comment renvoyer deux réponses à partir d'une seul requête client. De plus la logique métier est déjà pas mal découpé car je suis dans un contexte où je renvoi simplement des informations liées à un usager càd nom, prénom, adresse, etc.. et je voudrai éviter de la charcuter encore plus d'autant que ce n'est pas ce qui est attendu dans les specs.


A la limite j'avais pensé proposer un service qui retournerai des informations sur quantité de données à récupérer et un second service paramétré qui proposera de récupérer une partie de ces données.
Par exemple le premier service retourne l'information comme quoi il y a 50 000 infos à transmettre et un second service limité au transfère de 1000 infos qui aurai comme paramètre un offset sur ces 50 000 infos.

Quoi qu'il en soit merci pour votre aide ça me donne pas mal d'idées

[tunizar]

[QUOTE=Synack31;8671959]

A la limite j'avais pensé proposer un service qui retournerai des informations sur quantité de données à récupérer et un second service paramétré qui proposera de récupérer une partie de ces données.
Par exemple le premier service retourne l'information comme quoi il y a 50 000 infos à transmettre et un second service limité au transfère de 1000 infos qui aurai comme paramètre un offset sur ces 50 000 infos.

QUOTE]

ça est déjà un découpage

[Synack31]

A la limite j'avais pensé proposer un service qui retournerai des informations sur quantité de données à récupérer et un second service paramétré qui proposera de récupérer une partie de ces données.
Par exemple le premier service retourne l'information comme quoi il y a 50 000 infos à transmettre et un second service limité au transfère de 1000 infos qui aurai comme paramètre un offset sur ces 50 000 infos.

ça est déjà un découpage

C'est vrai mais la coupe n'est pas dans le même "sens" puisque on récupère l'ensemble des informations liés à une ressources au lieu de la disperser dans plusieurs réponses ce que je veux éviter car ça oblige un traitement supplémentairement pour trouver quelle infos va avec telle autre.

[yoshi570]

Bonjour

D'accord avec Lo2 pour séparer la récupération des données du WebService
Le WebService te renverrait le nom du fichier ou éventuellement l'ID d'une file d'attente où trouver le nom du fichier
Je préfère le gestion d'une file d'attente plus souple et performante pour gérer les reprises sur incident
Ensuite la récupération se ferait par ftp ou http

Après téléchargement tu supprimes le fichier ou tu mets à jour la file d'attente (qui serait épurée par le serveur)
La file d'attente peut être gérée par ton WebService ou par celui de PCSOFT (SQLConnecteWS)

D'ailleurs pour améliorer le temps de récupération il ne faudrait pas que ce fichier soit en XML, bien trop verbeux. Quand c'est possible il vaut mieux un format à plat (csv ...)

Et bien je ne suis pas d'accord sur ce point.
L’intérêt d'un webservice et d'avoir accès a un service / des infos via un moyen de communication unique.
Donc, pour moi, il ne faudrait pas multiplié les protocoles...
Et comme tu le souligne, lève d'autre problèmes comme que faire des ces fichiera ensuite, quid de la sécurité et de l´accès a ces données ...
Bref un rajout de complexité inutile je trouve.

Le souci c'est que je ne vois pas dans Windev comment renvoyer deux réponses à partir d'une seul requête client. De plus la logique métier est déjà pas mal découpé car je suis dans un contexte où je renvoi simplement des informations liées à un usager càd nom, prénom, adresse, etc.. et je voudrai éviter de la charcuter encore plus d'autant que ce n'est pas ce qui est attendu dans les specs.


A la limite j'avais pensé proposer un service qui retournerai des informations sur quantité de données à récupérer et un second service paramétré qui proposera de récupérer une partie de ces données.
Par exemple le premier service retourne l'information comme quoi il y a 50 000 infos à transmettre et un second service limité au transfère de 1000 infos qui aurai comme paramètre un offset sur ces 50 000 infos.

Quoi qu'il en soit merci pour votre aide ça me donne pas mal d'idées

Pour le renvoi de plusieurs réponses, je crois que, justement, ce n'est pas possible. Sinon cela deviendrait un WebSocket ...
En revanche, tu as presque l'idée.
Pour un service asynchrone,

1. l'utilisateur fait la demande
2. Le serveur renvoie un ticket
3. Le serveur traitre la demande (sauvegarde de la réponse en local)
4. l'utilisateur demande la reponse de son ticket
5. Le serveur renvoie la réponse (Status='En cours';Réponse='' ou Status='OK';Réponse='blabla')

[Synack31]

Merci yoshi570 pour ton aide. Effectivement je pense que c'est le mieux à faire pour un fonctionnement asynchrone mais j'aurai toujours le problème lié à Windev qui encode la réponse en XML au dernier moment sans que je puisse lui dire de le faire plus tôt (ici, lors de la première requête).

Quoi qu'il en soit j'ai décidé de reprendre le fonctionnement d'une de nos entreprises partenaires qui propose un système de page. A l'appel du service le serveur renvoie un certain nombre de réponse qui correspond à une page et signal qu'il reste par exemple 5 autres pages. Avec la gestion d'un contexte je fais en sorte qu'un nouvel appel au même service renvoie la page suivante. Cette solution est plutôt bien adapté à ma situation même si au final je contourne les problèmes posés plutôt que de les résoudre. D’ailleurs, bien que je vais passé en résolu ce post, je suis toujours intéressé de savoir si on peut ne serait-se que préparer la réponse XML en avance pour faire de l’asynchrone.

Merci à tous pour votre aide.

[yoshi570]

Merci yoshi570 pour ton aide. Effectivement je pense que c'est le mieux à faire pour un fonctionnement asynchrone mais j'aurai toujours le problème lié à Windev qui encode la réponse en XML au dernier moment sans que je puisse lui dire de le faire plus tôt (ici, lors de la première requête).

Quoi qu'il en soit j'ai décidé de reprendre le fonctionnement d'une de nos entreprises partenaires qui propose un système de page. A l'appel du service le serveur renvoie un certain nombre de réponse qui correspond à une page et signal qu'il reste par exemple 5 autres pages. Avec la gestion d'un contexte je fais en sorte qu'un nouvel appel au même service renvoie la page suivante. Cette solution est plutôt bien adapté à ma situation même si au final je contourne les problèmes posés plutôt que de les résoudre. D’ailleurs, bien que je vais passé en résolu ce post, je suis toujours intéressé de savoir si on peut ne serait-se que préparer la réponse XML en avance pour faire de l’asynchrone.

Merci à tous pour votre aide.

Je sais que windev est assez lent pour gérer les fichiers xml. Bien que certaines fonctions et/ou variable améliorent la chose. (il existe plein de topic sur ce sujet)
En revanche, tu parle de windev génère un XML pour le renvoie de la réponse. La réponse du webservice est enveloppée dans un XML. ceci, seul, ne devrait pas être trop consommateur de temps, non?
Quel forme a les données que tu renvois ?

[hpascal]

Et bien je ne suis pas d'accord sur ce point.
L’intérêt d'un webservice et d'avoir accès a un service / des infos via un moyen de communication unique.
Donc, pour moi, il ne faudrait pas multiplié les protocoles...
Et comme tu le souligne, lève d'autre problèmes comme que faire des ces fichiera ensuite, quid de la sécurité et de l´accès a ces données ...
Bref un rajout de complexité inutile je trouve.

Tu as tout à fait raison
Je parle seulement d'un cas où le volume de données serait beaucoup trop important pour un WebService
Dans ce cas, récupérer les données en une seule fois par le WS n'est pas adapté, il faut envisager d'autres solutions qui ne posent pas de problème au niveau de l'intégrité des données

[Synack31]

Je sais que windev est assez lent pour gérer les fichiers xml. Bien que certaines fonctions et/ou variable améliorent la chose. (il existe plein de topic sur ce sujet)
En revanche, tu parle de windev génère un XML pour le renvoie de la réponse. La réponse du webservice est enveloppée dans un XML. ceci, seul, ne devrait pas être trop consommateur de temps, non?
Quel forme a les données que tu renvois ?

Les données sont des classes d'une vingtaine d'attributs de type simple (chaîne, entier,...) stockées dans un tableau . Avec 50 000 ressources la génération du XML prend environ 2 minutes. De ce que je comprends de ton message il y a moyen de formater mon tableau de données en XML puis de renvoyer ce résultat plus tard par l'appel du second service qui va envelopper l'XML généré c'est ça ? Je vais me renseigné mais n'y a t'il pas un risque que le WSDL généré ne prenne plus en compte la structure des données puisque pour lui il ne s'agit que de texte XML ?

[yoshi570]

OK, donc tu renvois en gros un très gris tableau. C'est typiquement le cas ou windev va patiner pour augmenter l'arborescence du XML a chaque nouveau élément du tableau qu'il trouve.

Essaie donc de renvoyer ta classe sérialiser. Et tu la de-sérialise a la réception. Comme tu n'a que des types simple, il ne devrais y avoir aucun soucis. Ainsi, windev, n'aura que un (gros) élément texte a mettre dans le XML et être beaucoup plus rapide.

[Synack31]

Essaie donc de renvoyer ta classe sérialiser. Et tu la de-sérialise a la réception. Comme tu n'a que des types simple, il ne devrais y avoir aucun soucis. Ainsi, windev, n'aura que un (gros) élément texte a mettre dans le XML et être beaucoup plus rapide.

J'ai fait le test et en effet il est très rapide d'envelopper les infos sérialisés en XML.
Par contre, je le redoutais, le WSDL indique juste que la réponse contient un texte et bien que j'imagine qu'il suffit de désérialiser le contenu avec un simple déserialiseur XML, la réponse du service devient tout de même moins clair et on fait bosser l'appli cliente. A cela s'ajoute le fait que si l'on veut un Web Service cohérent ça oblige plus ou moins à faire fonctionner tous les services de cette manière (quoi que l'on peut se limiter aux services asynchrones).
Quoi qu'il en soit il faut avouer que ça marche plutôt bien et que ça peut vraiment être utile pour de l’asynchrone surtout si on a la main sur le développement du code client.

[yoshi570]

J'ai fait le test et en effet il est très rapide d'envelopper les infos sérialisés en XML.
Par contre, je le redoutais, le WSDL indique juste que la réponse contient un texte et bien que j'imagine qu'il suffit de désérialiser le contenu avec un simple déserialiseur XML, la réponse du service devient tout de même moins clair et on fait bosser l'appli cliente. A cela s'ajoute le fait que si l'on veut un Web Service cohérent ça oblige plus ou moins à faire fonctionner tous les services de cette manière (quoi que l'on peut se limiter aux services asynchrones).
Quoi qu'il en soit il faut avouer que ça marche plutôt bien et que ça peut vraiment être utile pour de l’asynchrone surtout si on a la main sur le développement du code client.

Bonne nouvelle!
Mais avec la de/serialisation, tu ne perds pas (vraiment) la structure.
De plus, si tu a la main sur le développement du client tu peux deserialiser directement dans ton même objet classe et garder la faciliter de développement. non ?

[Synack31]

Mais avec la de/serialisation, tu ne perds pas (vraiment) la structure

Disons que l'on perd la description de la structure. On peut la retrouver mais pour ça il faut un minimum étudier la réponse du Web Service (ou lire la doc )

De plus, si tu a la main sur le développement du client tu peux deserialiser directement dans ton même objet classe et garder la faciliter de développement. non ?

Tout à fait mais ce n'est pas le cas dans mon projet actuel :p

De toute façon comme je l'ai indiqué plus haut je suis partie sur une distribution par lots du résultat car ça a d'autres avantages mais au moins maintenant j'ai une solution si un problème nécessitant un service asynchrone se présente.
Bon, avec WinDev il faut un peu faire avec ce qu'il nous propose et on obtient rarement la solution parfaite mais tant que ça fonctionne correctement...

Merci pour ton aide.