in reply to Syntax used by SOAP::Lite
in thread Syntax used by SOAP::Lite

I'm still not clear on where SOAP::Lite finds what names/methods are available on the remote server.

Believe it or not -- it doesn't.

It's up to the programmer to know what the methods are. There are structured ways of representing this information, for those people who use code generators, using WSDL (which I consider to be the bane of my existance]

Some SOAP toolkits will return a wsdl if you attempt to GET the proxy URL with a QUERY string of 'wsdl'.... so in your example, you could try pointing a web browser at:

http://services.soaplite.com/hibye.cgi?wsdl

(it won't actually work, though, because SOAP::Lite doesn't support this by default, as it doesn't generate WSDL -- you're left to do that on your own)

Now -- you're probably going to ask how autodispatch works then ... well, it just assumes that if it sees a command that it doesn't know about, then it should try the SOAP service.

Replies are listed 'Best First'.
SOAP::Lite and XML::Parser decoding issues
by smeenz (Sexton) on Jun 04, 2005 at 19:53 UTC
    Yeah that all makes sense now that I've played around with it a bit more, as I realised I can make a call to things that clearly don't exist, and no perl error is generated.. it just quietly populates the soap fault data.

    Changing topics again, the problem I have now is more related to XML parsing. If I look at the actual packets coming back from the server, I can see that it has two occurances of '<lines>' in the data, but after parsing, only the first has made it through.

    I remember from when I was trying to decode the stuff myself using XML::Parser and XML::Twig that there were various options in there that could be used to change how things like that are decoded, but I haven't had a chance yet to see if the XML parser options are visible via the SOAP::Lite object.

    And once again, thanks to everyone for their help here.

[reply]

      SOAP -- and I'm being nice here -- is a pain in the ass.

      It's even worse than dealing with HTML interoperability, because it's cumbersome to set up a range of tests for each toolkit, as it can require setting up a seperate client built from each toolkit.

      There are many, many things that can go wrong when trying to parse the results, but here are a few to start you off:

      • the SOAP::SOM object returned from a method call has a lot more detail than the value returned from $som->result(). The result() method only returns the _first_ value returned, if it was a list.
      • Look into the paramsout() and paramsall() methods to SOAP::SOM
      • You can access values via XPath using the valueof() method to SOAP::SOM.

      Look over the SOAP::Lite documentation ... and as you try more with it, look over it again. It hardly made any sense to me the first time through, over a year ago, but as I use it more, it starts making more and more sense.

      As you start working with it more, you'll find that it makes a whole lot of assumptions, that can make easy cases trivial to implement, but causes a whole lot more work when the assumptions fail ... like if '20040101' is a string, not an integer... or if you're trying to emulate a document/literal webservice as opposed to RPC/encoded.

[reply]
        Thanks. I've already looked at paramsout() and paramsall() and they didn't seem to give me the other instances of <lines>, but I'll have a play with valueof() and see if that gets me anywhere.

        Yep.. just tried it quickly, and valueof('//line') seems to do the trick. I'm not up to speed with xpath syntax yet though, so I'll have to do some reading.

[reply]

In Section Seekers of Perl Wisdom