Las propiedades en un objeto de respuesta después de una llamada al servicio web son nulas

Question

Puedo ver el objeto en Fiddler pero el objeto no está deserializando en mi extremo. ¿Alguien ha visto esto antes?

Answer 1

La única razón por la que puedo pensar es en una falta de coincidencia de contrato. Aunque es extraño que no se genere ningún error de validación. ¿Estás utilizando un cliente generado a partir del WSDL correcto? ¿Es un cliente de WCF o uno de SOAP? El primero hace la validación, estoy seguro, pero los desajustes del esquema pueden pasar por el segundo.

Answer 2

"La respuesta es nula" o "La respuesta contiene nulos" o "La solicitud es nula" o "La solicitud contiene nulo" casi siempre significa que tiene una discrepancia en el espacio de nombres. Por ejemplo, la respuesta puede contener:

<response xmlns="http://foo.com"/> 

pero debe ser, de hecho

<response xmlns="http://bar.com"/> 

En este caso, null serán recibidos.

Answer 3

Cada vez que esto me sucede a mí, es porque necesito actualizar mis referencias de servicio. Pruébalo y cuéntame qué sucede :)

Answer 4

Lo resolvió ... o al menos tiene una solución alternativa. En el código de Java, @XmlElementRefs y @XmlElementRef deberían haber sido @XmlElements y @XmlElement respectivamente (además del atributo "type", necesitaba un atributo "name").

Supongo que si hubiera publicado esto como una nueva pregunta con una etiqueta Java, así como C# y servicios web, algunos Stack-Eyed Stalowoverflower habrían detectado este error de colegial.

Answer 5

Tuve un problema similar que resolví comprobando el valor del pedido en Reference.cs. [System.Xml.Serialization.XmlElementAttribute (Order = 0)]

El orden de los parámetros de devolución ha cambiado, pero al actualizar mi referencia de servicio en Visual Studio no cambié el valor de "Orden".

Compruebe que los parámetros devueltos en Fiddler/SoapUI sean los mismos que en su clase generada por proxy.

Answer 6

Tuve un caso similar en el que creé un cliente a través de SVCUTIL/Service Reference de VS. La respuesta se recibió con éxito con los datos correctos (confirmados mediante el método IClientMessageInspector.AfterReceiveReply), sin embargo, los valores en el nivel del objeto no se completaron. No hubo errores de-serialización (confirmados mediante la salida system.diagnostics)

El problema era doble:

1) Ciertos objetos fueron nombrados exactamente como sus tipos, pero tenían diferentes espacios de nombres de sus tipos. Esto parece haber confundido al generador de proxy al asignar el parámetro de espacio de nombres (en la anotación System.Xml.Serialization.XmlElementAttribute) de la clase al del objeto

2) El parámetro order (en System.Xml. Serialization.XmlElementAttribute anotación) de las propiedades no era necesario y también el parámetro de espacio de nombres faltaba

así a partir de: [System.Xml.Serialization.XmlElementAttribute (IsNullable = true, Orden = 0)]

a: [ System.Xml.Serialization.XmlElementAttribute (IsNullable = true, Namespace = "http: //www.whathevernamespaceiscorrect.com ")]

Básicamente, en el proxy generado necesité corregir el espacio de nombres de la clase al especificado en el tipo, y reemplazar el parámetro de orden con el parámetro de espacio de nombres configurándolo en el espacio de nombres correcto según el WSDL

Answer 7

yo tenía el mismo problema, y ​​como sugiere el problema de espacio de nombres fue el cause.However raíz, mi clase de proxy ha anidado clases y larga cadena de espacio de nombres anidados.

era confuso para identificar el espacio de nombres correcto aplicar en el código Cs para la clase de proxy. Aquí, describo cómo averiguar el espacio de nombres que se requiere para ser actualizado en el proxy del cliente.

Lo que hice fue interceptar la solicitud en la clase ClientMessageInspector, método AfterReceiveReply (permite la inspección o modificación de un mensaje después de que se recibe un mensaje de respuesta pero antes de volverlo a la aplicación cliente). Verificó el espacio de nombres del objeto que devuelve nulo en Response utilizando XMLDocument. Actualicé la clase de proxy con el espacio de nombres recuperado de XML. Después de hacer los cambios, los objetos no fueron nulos en respuesta.

public class MyMessageInspector : IClientMessageInspector 
{ 
    public void AfterReceiveReply(ref System.ServiceModel.Channels.Message request, object correlationState) 
    { 

     MemoryStream ms = new MemoryStream(); 
     XmlWriter writer = XmlWriter.Create(ms); 
     request.WriteMessage(writer); 

     writer.Flush(); 
     ms.Position = 0; 
     XmlDocument xmlDoc = new XmlDocument(); 
     xmlDoc.Load(ms); 
     this.ReadMessage(xmlDoc); 


     ms = new MemoryStream(); 
     xmlDoc.Save(ms); 
     ms.Position = 0; 
     XmlReader reader = XmlReader.Create(ms); 
     Message newMessage = Message.CreateMessage(reader, int.MaxValue, request.Version); 
     newMessage.Properties.CopyProperties(request.Properties); 
     request = newMessage; 

    } 

    private void ReadMessage(XmlDocument xmlDoc) 
    { 
     XmlNode v1 = xmlDoc.GetElementsByTagName("XPAth"); 
     //Actual Namespace in XML, which should be used in Proxy Class 
     string namespaceURIForObjectInXML = v1.NamespaceURI; 
    } 

    public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel) 
    { 

    } 



} 

Answer 8

Asegúrese de que la definición/especificación coincida con la salida. Compare el WSDL (en el navegador) y la respuesta (en SOAP-UI, Fiddler), p.

• WSDL utiliza caso camello (lastName) y la respuesta
• utiliza guiones (last_name).