Discussion :

[LeCaméléon]

Re bonjour RDM & co,

Je dois executer un service en lui passant en argument un flux XML (fichier). Ce service est un serveur soap qui, recoit un flux WSDL, apelle un exe, puis rempli une table selon le flux fourni.

Comment créer un client soap via XMLRAD permettant de simuler ce fonctionnement ?

Merci
Nico

[RDM]

j'ai pas bien compris ce que tu voulais faire mais pour faire un client soap il faut que XMLRAD s'appuie sur un WSDL (à partir d'une URL)

[LeCaméléon]

C'est un peu tordu je te l'accorde.

Pour simplifier :

A requeteSOAP => B webserviceXMLRAD => C execution d'un .exe => D remplissage DB

Lorsque B est contacté par A, B apelle C (via delphi) et remplie la DB. Mon pb est que je ne sais pas comment créer une intérrogation A de mon service B en lui passant en argument un flux de données (un fichier XML en dur, à remplir en DB). En effet dans l'écran de création d'une request SOAP, XMLRAD me demande uniquement la location du fichier (serveur) à appeler, et je ne vois pas où je peux lui préciser l'envoie d'arguments ?

Je ne sais pas si j'ai été plus clair ? En tout cas bravo et merci si tu trouves la réponse

[RDM]

je pense surtout qu'il y a un problème de vocabulaire et de qui fait quoi:
A est le client SOAP
B est le serveur SOAP

A et B peuvent être sur la même application XMLRAD , mais je vois pas trop l'intéret alors d'utiliser SOAP.

[LeCaméléon]

B recevait (côté delphi) un flux via le context. Voilà pourquoi j'aurai voulu créer un client A qui contact B et lui envoie en param le flux. j'ai tout changé, désormais B lit un fichier en dur et ca marche aussi bien.

Je vais néanmoins m'attarder sur la nouvelle version d'XMLRAD notamment pour voir les modifs côté asynchrone qui permettrait de décharger significativement notre serveur DB. Sais tu si les allers retour IIS / XMLRAD sont tjs gérés de la même manière (prepare/unprepare gourmant en ressource, notamment lors d'un match, ou requete parent/enfant qui moulinent plus que nécessaire !).

bye
nico

[RDM]

Je vais néanmoins m'attarder sur la nouvelle version d'XMLRAD notamment pour voir les modifs côté asynchrone qui permettrait de décharger significativement notre serveur DB. Sais tu si les allers retour IIS / XMLRAD sont tjs gérés de la même manière (prepare/unprepare gourmant en ressource, notamment lors d'un match, ou requete parent/enfant qui moulinent plus que nécessaire !).

bye
nico

tu peux préciser ta pensée ? je comprend pas bien ce que tu entend par aller/retour XMLRAD IIS en mixant avec les prepare/unprepare...

[LeCaméléon]

Ce n'est sans doute plus le bon endroit dans le forum pour celà, mais j'ai remarqué qu'il est beaucoup plus lent de retourner le resultat d'un requete moulinant x fois sur sa requete parent, que de faire une grosse requete qui ramene toutes les infos (et même trop, d'ailleurs niveau modélisation c'est vraiment pas top de faire celà). Lorsque j'ouvre les stats XMLRAD sur mon service, cette boucle met 2sec, alors que lorsque j'exécute une grosse requete avec jointure qui ramène la même chose, elle s'exécute super vite en passant par l'analyseur de requete. Le gestionnaire de profil m'indique des "exec sp_prepare / unprepare" qui mis les uns à la suite des autres rajoute du temps à l'exécution du service en mode requete parent/enfant. N'y a t'il pas un moyen d'optimiser les réglages de communication entre IIS / XMLRAD et SQLServer ? Je ne sais pas si je suis clair cette fois de plus ...

nico

[RDM]

Tu mixes 2 problèmes.
Le premier c'est le fait de faire des sous DBExtract:
Il sera quasiment toujours plus lent de faire cela plutot qu'une jointure.
Il est d'ailleurs recommandé de faire la jointure (quand cela est possible). pourquoi ?
parce que de faire un Sous DBExtract va demander de rappatrier pour le DBExtract parent les enregistrements coté client et de faire la jointure coté client sur chacun des enregistrement fils que tu auras fetchés.
Cette méthode peut être cependant plus interessante dans certains cas ou le plan de jointure est mauvais et le fait de découper la requête est plus interessant.

Le second problème c'est la repréparation des requête à chaque fois sous ADO qui est un bug du DacADO, mais qui a mon avis n'a que peu dimpact sur les performances comparé aux problèmes ci-dessus.
pour ce second problème le bug est corrigé dans la 2007.

[LeCaméléon]

Ok merci pour tes précisions. Si j'ai le temps dans le 10 jours je testerai la 2007 et proposerai une migration probablement.

A bientôt
Merci

nico