Le proxy de WCF a généré de WSDL, la méthode de proxy retourne null.

Question

J'ai généré un proxy WCF à partir d'un fichier WSDL, mais maintenant quand j'appelle les méthodes du proxy, elles renvoient null. J'ai activé l'enregistrement des messages et je peux voir que les messages du serveur sont correctement renvoyés.

J'ai vérifié la réponse de este Mais dans mon cas, le nom de l'objet renvoyé était le même dans le message et dans le WSDL. Je pense toujours que le problème est lié au fichier WSDL, puisqu'il n'est pas récupéré de la manière habituelle via l'URL "?wsdl" (il s'agit d'un service Web tiers), mais qu'il a été fourni séparément.

Le type de retour de la méthode est simplement une chaîne de caractères.

Quelqu'un d'autre a-t-il eu des problèmes similaires, et quelle a été la solution correspondante, le cas échéant ? Quelle est la source la plus probable du problème ?

Re-edit :

Il s'agit d'un service web RPC/Encodé. Comme écrit, je peux voir la réponse SOAP par l'enregistrement de message, mais WCF semble ne pas pouvoir analyser l'information.

La partie message de la réponse du service ressemble à ceci :

<ns1:ServiceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace">
    <ns1:ReturnValue xsi:type="xsd:string">

Cependant, en inspectant le message sortant de mon client, c'est différent :

<ns1:ServiceRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace">
    <RequestValue xsi:type="xsd:string" xmlns="">

Il se peut donc que le mandataire s'attende à ce que la réponse ait la même structure d'espace de noms et qu'il ne parvienne pas à l'analyser.

J'ai essayé de changer le type de l'attribut element dans les définitions de messages wsdl, et l'ajout de quelques nouveaux éléments dans le fichier types de la définition wsdl, mais ensuite le svcutil s'arrête lors de la génération du proxy, se plaignant qu'il y a un conflit entre le document de style inféré et le style rpc spécifié.

De la Spécification WSDL , section 3.5 :

Si l'utilisation est encodé chaque partie de message fait référence à un type abstrait en utilisant l'attribut type attribut.

Mais alors, je suis un peu confus, puisque cela ne semble pas avoir été un problème dans ce pregunta . Que faudrait-il faire pour apporter une modification similaire, avec la restriction qu'il s'agit d'un service RPC/encodé ?

Answer 1

Vous devrez donner des détails sur le service Java afin de résoudre ce problème. Cependant, je soupçonne que le service Java utilise des parties de message définies avec l'attribut type attribut. Ces messages ne sont pas conformes au WS-I Basic Profile 1 car il existe une ambiguïté quant à l'espace de noms à utiliser pour les éléments du message. Certains services utiliseront l'espace de noms du type, tandis que d'autres utiliseront (correctement) l'espace de noms du service web lui-même.

Utilisation de la element lève l'ambiguïté et est donc préférable.

Veuillez poster un extrait de la WSDL contenant l'un des messages qui vous posent problème. Si vous comparez ensuite la définition du message avec ce que vous voyez sur le fil, puis avec les détails de la classe proxy censée consommer le message, je pense que vous comprendrez ce que je veux dire. La classe proxy s'attend à un espace de noms, mais sur le fil, un espace de noms différent est utilisé.

Answer 2

Nous avons eu quelque chose de similaire en utilisant un client WCF contre un WSDL d'un service web Java.

Notre problème était que nous ne pouvions pas voir les données qui revenaient du service, il semblait que les données étaient manquantes.

Cependant, quand nous avons regardé ce qui passait par le câble, les données étaient là.

Le problème est que le WSDL comporte de nombreux types qui héritent d'autres types. Par défaut, nous ne pouvions voir que les informations contenues dans le type de base.

La solution a été d'attribuer à l'objet le type que nous attendions, puis tous les champs sont apparus.