views:

1225

answers:

7

I'm having an issue with Delphi 2007 when trying to consume a web service I've set up in Java using JAX-WS. The web service can be consumed fine from another Java program and from a C# / ASP.NET 2.0 website. However, when I try to access the same service using the WSDL Importer in Delphi 2007 (17-DEc-2007 patch), the JAX-WS web service doesn't recognise any of the parameters I'm passing it and nulls them.

I've checked the SOAP message that's being passed by Delphi and compared it to the others and they are pretty much identical (with the exception of some negligable namespace decs and a whole lot of view state from the .NET one!)

I've also been around the web (most helpful link was Dr Bob's http://www.bobswart.nl/Weblog/Blog.aspx?RootId=5:798) but no joy.

Has anybody come across this before?

TIA.

+1  A: 

Not the solution for your problem, but I had been in trouble recently with the same environment. I had to change the options many times until find the right way to consume the webservice (writen in C#).

Check:

- THTTPRIO.Converter.Options
- THTTPRIO.HTTPWebNode
- THTTPRIO.HTTPWebNode.InvokeOptions
Cesar Romero
Again, my thanks Cesar! I think you need to give me your speed dial ;)
Urf
Sorry, forgot to mark your answer!
Urf
Good to know it helps you.
Cesar Romero
A: 

Did you solf this issue? - I have the same problem..

Greetings

A: 

Sorry, I'm afraid not. I'm still working my way through options, although this project is not a priority at the moment so not spending much time on it.

As soon as I have an answer though, I'll post it.

Urf
A: 

The saga continues!

After buggering about with the HTTPRIO object to try and get it working I eventually gave up and tried a straight XML transfer over HTTP. Fail.

OK, so I built a simple tester in C# and tried that. Works no problem.

Using Fiddler to see what was being sent backwards and forwards it seemed that the only difference was in the namespaces. I changed the namespaces in the XML send in Delphi and ... it works!

This was a sample of the original XML being generated by the WSDLImporter:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"&gt;
    <SOAP-ENV:Body>
        <version xmlns="http://path.to.service.com/"&gt;
            <input>test</input>
        </version>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

and here is what actually works:

<?xml version="1.0"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"&gt;
    <S:Body>
        <ns2:version xmlns:ns2="http://path.to.service.com/"&gt;
            <input>test</input>
        </ns2:version>
    </S:Body>
</S:Envelope>

So, now that I know this, I do I go about changing the namespace values for the WSDLImporter code? I can't see anything obvious on the HTTPRIO properties.

TIA

Urf
+2  A: 

HA HA IT LIVES!!!

Basically I had to take out the recommended

InvRegistry.RegisterInvokeOptions(TypeInfo(ActivityService), ioDocument);

and force it to use Sec. 5 encoding. Namespaces are generated as required and parameters are passed to the Java web service.

Right, need beer, lots of beer :)

Urf
I can verify that commenting out that line fixes the problem for a JAX-WS web service. I cannot verify the efficacy of lots of beer though ;-)
David Collie
A: 

I banged my head against wall for two days, till I found this post... And Cesars hint to check THTTPRIO.Converter.Options... I tried almost everything, last one was to set soXXXXHdr to true -> then happened something strange, no more nulls to server :O...

I don't know why that setting makes values go through, it just does (at least for me).

Would be great if someone who actually understands whats happening would explain this.

A: 

Removing soSendMultiRefObj from Converter.Options helps

Nikolay Ponomarenko