SOAPRPC response is garbled

We have a soap service written in perl in a remote server, which returns a hash table of some query result.
From webMethods IS we are calling the above soap service using pub.client:SOAPPRC, and able to get result back.
But when very long text is entered, the response for that field is corrupted, the data type shall be string, but response I got is base64binary as below:
QkFHSERBRCAtI…

Please suggest how to tackle this problem.

Thanks in advance for help.

Tamal

Interesting. My guess is that the pub.client:soapRPC service is treating the long string as something that needs to be interpreted as base64Binary. There could even be a part of the soap spec that was behind that behavior or maybe its just a plain ole bug.

At any rate, interoperability issues like this one are one of the big reasons that the rpc/encoded style of soap messaging is not recommended by many. I read a post on the SOAP::Lite (perl Soap toolkit) website seeking volunteers for an open source project to re-write the toolkit to better support the document/literal style and the WS-* standards that have caught on.

I would submit an SR to webMethods with adequate examples to reproduce this behavior.

Let us know what you learn.

A possible workaround is to build the soap rpc/encoded message manually (using document types or just plain ole string maniuplation) and then post that to your perl service using pub.client:http. You would then be able to convert the resulting XML string into a node and parse out the troublesome description string.

Mark

My guess is that the web service being called is doing that intentionally. I don’t know if I’d consider the field “corrupted” or “garbled.” Have you tried simply decoding it?

Rob,

Good point. The service provider could be intentionally encoding the large string response as base64Binary. However, if the WSDL describing the service indicated that a string would be returned, then this would technically be a violation of that “contract”, albeit not a major one.

The soap message in its “wire format” should match what is described in the WSDL. The consuming client still has to map that wire format to its internal repesentations which is an area of interoperability issues for soap rpc/encoded.

Mark