SOAP::Lite misbehavior or bug?

McMahon has asked for the wisdom of the Perl Monks concerning the following question:

I have a Perl SOAP client that insists on sending

<ConfirmUnsubscribes xsi:type="xsd:int">0</ConfirmUnsubscribes>
[download]

which is rejected by the server with an error

Fault: Validation constraint violation: data type mismatch xsd:int in
element <ConfirmUnsubscribes>
[download]

However, I have a Ruby SOAP client that is behaving exactly correctly when it interprets the WSDL and sends data that looks like:

<ConfirmUnsubscribes
xsi:type="n2:ConfirmUnsubEnum">0</ConfirmUnsubscribes>
[download]

That is: the data type for "ConfirmUnsubscribes" is in fact a member of an array "ConfirmUnsubEnum" and is not necessarily an int (even though, ok, it's an int at heart)

Can anyone suggest a way to either make the server less strict, or else to improve the WSDL-reading capability of the Perl SOAP client in SOAP::Lite?

Comment on SOAP::Lite misbehavior or bug? Select or Download Code

Replies are listed 'Best First'.
Re: SOAP::Lite misbehavior or bug? by duckyd (Hermit) on Jun 08, 2006 at 23:20 UTC
SOAP::Lite doesn't have much WSDL support. You can either set the type manually as suggested above, or consider using SOAP::WSDL which should set the types correctly in the request based on the WSDL.	[reply]
Re: SOAP::Lite misbehavior or bug? by jhourcle (Prior) on Jun 09, 2006 at 14:23 UTC
Can anyone suggest a way to either make the server less strict, or else to improve the WSDL-reading capability of the Perl SOAP client in SOAP::Lite? To make the server 'less strict', the only way that I know of is to change it to use document/literal encoding, which doesn't require the clients to send a type for each element, and so it's 'less strict' in that there's no type to match against. However, I have no idea what it would require to change your server to do this. For better WSDL support, I know there exists SOAP::WSDL, but I've never used it. My problem is the opposite -- supporting strict clients w/ a SOAP::Lite server. For that, I use a replacement serializer, which doesn't examine the value of the element to determine the type, but looks at the element's name (I either pull the name from the hash key, or bless items into a class).	[reply]
Re: SOAP::Lite misbehavior or bug? by Anonymous Monk on Jun 08, 2006 at 19:40 UTC
It's possible to override most of SOAP::Lite's element generation, but it would be helpful to know what the WSDL is so we can find out what's wrong and improve it.	[reply]
Re^2: SOAP::Lite misbehavior or bug? by McMahon (Chaplain) on Jun 08, 2006 at 19:43 UTC
The WSDL itself is gigantic, but the appropriate part is `<simpleType name="ConfirmUnsubEnum"> − <restriction base="xsd:string"> <enumeration value="0"/> <enumeration value="1"/> <enumeration value="2"/> </restriction> </simpleType>` [download]	[reply] [d/l]
Re^3: SOAP::Lite misbehavior or bug? by Anonymous Monk on Jun 08, 2006 at 20:17 UTC
Well, I can offer a suggestion for manually encoding your element, which ignores both the WSDL and the broken SOAP::Lite serializer: `my $confirm = SOAP::Data->new; $confirm->name("{http://the.target.namespace/here}ConfirmUnsubscribes" +); $confirm->type("{http://the.schema.namespace/here}ConfirmUnsubEnum");` [download]	[reply] [d/l]


Perl: the Markov chain saw
	PerlMonks