kdwsdl2cpp doesn't generate necessary headers about kdsoap HOT 9 OPEN

The API to use is rather something along the lines of

  KDSoapMessageAddressingProperties addressing;
  addressing.setDestination("http://example.com/onvif/event_service?idx=4");
  message.setMessageAddressingProperties(addressing);

but the question is indeed why kdwsdl2cpp doesn't generate that.

Maybe bindingService.clientInterface()->setSendSoapActionInWsAddressingHeader(true); is enough to fix it?

It sounds like WS/Addressing support isn't fully integrated with kdwsdl2cpp indeed, please let me know if this helps, then we can take a look at improving this integration. The first step will be to extend unittests/ws_addressing_support ...

from kdsoap.

Hi,
sorry for the delay on the answer, but I lost access to the service and couldn't test your suggestions.
I just tested adding bindingService.clientInterface()->setSendSoapActionInWsAddressingHeader(true); but it is not working yet.
By checking the message sent using wireshark I can see that this adds a new evement to the header:

<wsa:Action>
    http://www.onvif.org/ver10/events/wsdl/PullPointSubscription/PullMessagesRequest
    </wsa:Action>

However, that's not the element I needed to add.

So, maybe I need to implement a manual call using the API directly instead of using the automatically generated files? Or is there any other solution?

Thanks a lot

from kdsoap.

Please update to latest master, and do

  KDSoapMessageAddressingProperties addressing;
  addressing.setDestination("http://example.com/onvif/event_service?idx=4");
  bindingService.clientInterface()->setMessageAddressingProperties(addressing);

I suppose that the WSDL files contain all the information necessary for kdwsdl2cpp to generate the message addressing properties automatically, but I don't know enough about ws-addressing to implement that (someone else implemented the current support for WS-addressing). Meanwhile, this new method at least allows to set WS-addressing properties manually on WSDL-generated messages.

Please let me know how this works for you.

from kdsoap.

I've been trying to use the method you propose, but although I've updated to master and build new headers and sources files which contains that method, it does nothing. The sent soap header is empty, there is no addressing information added to it

from kdsoap.

That is surprising, given that the unittest I wrote as part of that commit, shows that the addressing information is sent correctly. There must be a difference somewhere.

Ah, I found it, after writing a testcase based on the onvif WSDL. The code required a SOAP action to be set in order to write addressing properties. I removed that check now, I hope that's correct (no time to read the WS-Addressing spec).

Please git pull and try again.

from kdsoap.

It's working now! Thanks a lot!
By the way, this service may return an error when some of the request's parameters are not right. When using gsoap, a class with the error information was available by calling response.GetFaultObject().
Is there any way of getting that same information using KDSoap? Even if I have to parse it myself from the XML. As far as I know, the only way of getting some information is by calling the lastError and lastFault methods of the service, but there is no way of getting the complete fault error, am i wrong?

from kdsoap.

If you use the blocking API (bindingService.pullMessages(...)), then indeed you're limited to lastError/lastFault.
If you use the job API instead -- which is recommended anyhow in the GUI thread, then you can get the full response message.

Something like:

  TEV__PullMessages in;
  // ...
  auto job = new PullMessagesJob(&bindingService);
  job->setParameters(in);
  QObject::connect(job, &KDSoapJob::finished, nullptr, [job]() {
    if (job->reply().isFault()) {
      qDebug() << job->reply().arguments();
    } else {
      qDebug() << "success";
      // use job->resultParameters();
    }
  });
  job->start();

from kdsoap.

I suppose we could add a method KDSoapMessage lastReply(); to KDSoapClientInterface though, much like lastResponseHeaders(), for the case of blocking calls.

from kdsoap.

Ok, so I'll use jobs for now, but u think it would be useful to have the lastReply() method you mentioned
Thanks a lot for all your help!

from kdsoap.