.NET Web Service Client Issues***UPDATED, PARTIALLY SOLVED*** - Forum - Technology Partner - Progress Community

.NET Web Service Client Issues***UPDATED, PARTIALLY SOLVED***


.NET Web Service Client Issues***UPDATED, PARTIALLY SOLVED***

  • I am running ESB 7.01 on Windows.

    I have a Web Service hosted on the ESB, and I am able to call it using a client generated in a Java IDE. However, when I try to call the web service with a .NET client, NULL is returned and the response message from the ESB ends up in the dead message queue.

    Anyone had issues with this before?

    BTW, I created all the schemas and WSDL by hand, so there shouldn't be any interop issues along those lines.


  • I checked the Dead Message Queue, and the return message that the .NET client is expecting is placed in the DMQ with a reasonundeliuvered code of 4, which means UNDELIVERED_ROUTING_INVALID_DESTINATION.

    It seems that Sonic MQ cannot find the temp queue/topic that is supposed to be created to handle the return message.

    Has anyone been able to call an ESB Web Service from a .NET client?

  • I haven't personally done this, so I can't help you directly, but if you haven't already started talking to Tech Support about this, it would be a good idea to do so.

  • Hi Jamie,

    Thanks for your reply. I contacted support about two weeks ago, and I have not heard anything from them. Hopefully they will get back to me soon. This is a brick wall for me.



  • So I used Fiddler to debug the HTTP session created by the .NET client. A few things are happening.

    1) The XML was being returned to the .NET client. I noticed that .NET added empty default namespaces to the XML tags. (Example: ) So it appears that .NET cannot marshal the XML to C# objects correctly.

    2) The XML response was still getting thrown in the DMQ.

    So I modified the Web Service to return XML with a Namespace, and .NET was able to marshal the XML to C# objects. So.... it appears that .NET requires Web Services to return XML with a Namespace.

    However, the message is still getting thrown in the DMQ. Sonic Support is still looking into this issue.

    Sonic must think that the .NET client did not get the message, and therefore is throwing it in the DMQ. Strangely enough, I unchecked the Preserve Undelivered option in the SOAP acceptor, and Sonic is still throwing the message in the DMQ.