Hi Paul and others on the list,

I am sorry to bother you but having now been struggling for days with
getting my SOAP::Lite server installation to return MIME attachment I
see no other alternative then to resort to the mailing list.

My problem is that I cannot understand how to specify to the
Apache::SOAP server instance to use the package format
SOAP::Lite::Packager::MIME.

Basically, I want to know how to setup the equivalence of the
following code (that shows how to use attachments within the context
of a CGI script):

#!/usr/bin/perl -w
   use SOAP::Transport::HTTP;
   use MIME::Entity;
   SOAP::Transport::HTTP::CGI
     ->packager(SOAP::Packager::MIME->new)
     ->dispatch_with({'urn:Majordojo:TemperatureService'
=> 'TemperatureService'})
     ->handle;

   BEGIN {
     package TemperatureService;
     use vars qw(@ISA);
     @ISA = qw(Exporter SOAP::Server::Parameters);
     use SOAP::Lite;
     sub c2f {
       my $self = shift;
       my $envelope = pop;
       my $temp = $envelope->dataof("//c2f/temperature");
       use MIME::Entity;
       my $ent = build MIME::Entity
         Type        => "text/plain",
         Path        => "printenv",
         Filename    => "printenv",
         Disposition => "attachment";
       # read
attachments

       foreach my $part (@{$envelope->parts}) {
         print STDERR "soaplite.cgi: attachment found! (".ref($part).")
\n";
         print STDERR "soaplite.cgi: contents => ".$part-
>stringify."\n";
       }
       # send
attachments

       return SOAP::Data->name('convertedTemp' => (((9/5)*($temp-
>value)) + 32)),
         $ent;
     }
   }

… within the context of using attachments with a SOAP::Lite setup
using Apache::SOAP.

I use location bases access in my httpd.conf file:
<Location /ides_soap>
     SetHandler perl-script
     PerlHandler Apache::SOAP
     PerlSetVar
dispatch_to "IDES::new_matter,IDES::get_updated_matters,IDES::update_m
atter,IDES::get_matter_status"
     PerlSetVar options "compress_threshold => 10000"

</Location>

Is it here that I somehow specify to Apache::SOAP to use the package
format SOAP::Lite::Packager::MIME?

Any help would be highly appreciated.

Regards,
Ragnar

On Fri, Sep 5, 2008 at 6:01 PM, Bryan <rdsxfan74@...> wrote:
> I tried to reinstall and skipped the 'nmake test' step and went directly to
> 'nmake install'.  It appeared to install correctly, but when I open the Perl
> Package Manager, SOAP Lite doesn't show up as being an installed module.

When I exclude CGI.t, all tests are successful and the module works
ok. Though I don't use CGI part and compile with dmake.

Hello,

From a soap call I am returning header and data. Header is constructed
as:

$header = SOAP::Header->name(
             "status"=>\SOAP::Header->value(
               SOAP::Header->name("code" => 0),
               SOAP::Header->name("msg" => "Ok")
             )
);

Then there is a data part:

         $data =  SOAP::Data->name(
             "status"=>\SOAP::Data->value(
                 SOAP::Data->name("code" => 0),
                 SOAP::Data->name("msg" => "Ok")
             )
         );

Both will form perfect XML on HTTP transport, but on client via:

$soap->header i get

$VAR1 = {
           'status' => {
                       'msg' => 'Ok',
                       'code' => '0'
                     }
         };

but $soap->result will give me:

$VAR1 = {
           'msg' => 'Ok',
           'code' => '0'
         };

why there is the difference. How do I achieve having "status" in
result of data?

Thank you,
Bohdan

On Tue, Sep 09, 2008 at 05:42:37PM -0000, fistan11 wrote:
> Thomas, can you put any example here? Multithreaded SSL standalone
> server could be MUCH MORE expressive than thousands of doc lines.
> Thank you!

I cannot post the code, as it is part of a commercial product that
is sold by my employer.  In pseudo code, it would look like so
(untested):

use IO::Socket;
use HTTP::Daemon::SSL;
use SOAP::Transport::HTTP;
...

	 # set up HTTP and SSL options
	 my %https_opts = ();
	 $https_opts{LocalPort}       = 443;
	 $https_opts{Proto}           = "tcp";
	 $https_opts{Type}            = SOCK_STREAM;
	 $https_opts{Listen}          = SOMAXCONN;
	 $https_opts{ReuseAddr}       = 1;
	 $https_opts{Timeout}         = 300;
	 $https_opts{SSL_version}     = 'SSLv2/3';
	 $https_opts{SSL_cipher_list} = 'ALL:!LOW:!EXP';
	 $https_opts{SSL_use_cert}    = 1;
	 $https_opts{SSL_key_file}    = "server.key";
	 $https_opts{SSL_cert_file}   = "server.crt";
	 $https_opts{SSL_ca_file}     = "ca-bundle.crt";
	 $https_opts{SSL_ca_path}     = "/path/to/CA/certs";
	 $https_opts{SSL_verify_mode} = 0x01|0x02;
	 $https_opts{SSL_check_crl}   = 0;
	 ...

sub https_daemon {
	 # become a daemon (optional)
	 &make_me_a_daemon();

	 # start HTTPS listener
	 my $server = HTTP::Daemon::SSL->new( %https_opts );

	 # accept loop
	 while (1) {
		 # wait for a client connection
		 my $client = $server->accept();
		 next if (! $client);

		 # start a child process to handle the connection
		 &start_child($server,$client);

		  # parent process closes the connected socket
		 $client->close();
	 }
}

sub start_child {
	 my $server = shift;
	 my $client = shift;

	 my $pid = fork();
	 return if (! defined $pid);

	 if ($pid > 0) {
		 # parent process
		 return;
	 } else {
		 # child process
		 $server->close();

		 # handle the HTTP connection and exit
		 &handle_http_connection($client);
		 $client->close();
		 exit(0);
	 }
}

sub handle_http_connection {
	 my $client = shift;

	 my $soap = new SOAP::Transport::HTTP::Server;
	 $soap->dispatch_to( $SOME_LIST_OF_MODULES );

	 while (1) {
		 # read HTTP request
		 my $req = $client->get_request();
		 last if (! $req);

		 # handle HTTP request and generate HTTP response
		 my $resp = &handle_http_request( $req, $soap );

		 # send HTTP response
		 if ($resp) {
			 $client->send_response( $resp );
		 } else {
			 last;
		 }
	 }
}

sub handle_http_request {
	 my $req = shift;
	 my $soap = shift;

	 # process the SOAP request
	 $soap->request( $req );
	 $soap->handle();

	 # return the SOAP response
	 return $soap->response();
}

Note that error and signal handling have been omitted to save space
and to direct attention to the main concepts.

Also note that this represents a forking server, suitable for a UNIX
type system (eg. Linux).  It is not multi-threaded and it may not
work on Windows.

--
Thomas J. Pinkl


This communication, including any attachments, may contain information that is
confidential and may be privileged and exempt from disclosure under applicable
law. It is intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient, you are hereby notified
that any use, disclosure, dissemination, or copying of this communication is
strictly prohibited. If you have received this communication in error, please
notify the sender. Thank you for your cooperation.

I'm running Perl v5.8.0 built for i386-linux-thread-multi under Linux 2.4.21-57.ELsmp.  Our SOAP::Lite is at v0.710.08.

We're dealing with a picky SOAP client and have set up the following CGI dispatch file (use statements ommitted for brevity):

SOAP::Transport::HTTP::CGI
  ->dispatch_with({'http://echo.nasa.gov/v9/order/fulfillment' =>
    'OrderFulfillmentService'})
  ->handle;

exit 0;

package OrderFulfillmentService;

sub Submit {return (SOAP::Data->name('SubmitResponse')->type('xml')
  ->value(ECHODataOrder::DataOrderRequest(@_)));}

Because of the way the SOAP client calls our Submit service, we have to use the dispatch_with() syntax.  We successfully receive and process their communication and respond with something like this:

<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <SubmitResponse xmlns="http://my.server.com/v7/order/fulfillment">
...

      </SubmitResponse>
   </soap:Body>
</soap:Envelope>

For some reason, SOAP::Lite automatically inserts the xmlns=http://my.server.com/v7/order/fulfillment in the SubmitResponse tag.  In any case, the SOAP client rejects our response.  The authors of the SOAP client believe that we need to modify our SubmitResponse such that a prefix is added like this:

      <order:SubmitResponse xmlns:order="http://my.server.com/v7/order/fulfillment">
...

      </order:SubmitResponse>

I have tried adding various elements to our "{return (SOAP::Data->" statement like "->prefix('order')" and "->attr({prefix=> 'order'}), but everything seems to be ignored.  How can I specify the prefix of my SubmitResponse message/tag?  Many thanks!

(A few of the xmlns values were incorrect.  They have been corrected inline below.)

I'm running Perl v5.8.0 built for i386-linux-thread-multi under Linux 2.4.21-57.ELsmp.  Our SOAP::Lite is at v0.710.08.

We're dealing with a picky SOAP client and have set up the following CGI dispatch file (use statements ommitted for brevity):

SOAP::Transport::HTTP::CGI
  ->dispatch_with({'http://echo.nasa.gov/v9/order/fulfillment' =>
    'OrderFulfillmentService'})
  ->handle;

exit 0;

package OrderFulfillmentService;

sub Submit {return (SOAP::Data->name('SubmitResponse')->type('xml')
  ->value(ECHODataOrder::DataOrderRequest(@_)));}

Because of the way the SOAP client calls our Submit service, we have to use the dispatch_with() syntax.  We successfully receive and process their communication and respond with something like this:

<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <SubmitResponse xmlns="http://echo.nasa.gov/v9/order/fulfillment">
...

      </SubmitResponse>
   </soap:Body>
</soap:Envelope>

For some reason, SOAP::Lite automatically inserts the xmlns=http://my.server.com/v7/order/fulfillment in the SubmitResponse tag.  In any case, the SOAP client rejects our response.  The authors of the SOAP client believe that we need to modify our SubmitResponse such that a prefix is added like this:

      <order:SubmitResponse xmlns:order="http://echo.nasa.gov/v9/order/fulfillment">
...

      </order:SubmitResponse>

I have tried adding various elements to our "{return (SOAP::Data->" statement like "->prefix('order')" and "->attr({prefix=> 'order'}), but everything seems to be ignored.  How can I specify the prefix of my SubmitResponse message/tag?  Many thanks!

Hi,

I have a little script that uses SOAP. I have problems with error
handling. A little example script looks like this (working example):

use SOAP::Lite;
print SOAP::Lite
	 ->service('http://machine.tld:3003/wsdl/all')
	 ->teInput('lala,lulu');

when I run that, I get an error 500 from the SOAP server, which is
expected, because it expects 3 parameters. I want to catch that error in
my script. I used this:

my $result=SOAP::Lite
			 ->service('http://machine.tld:3003/wsdl/all')

->teInput("$barcode_with_num","$soapladestelle");
		 print "Error?: $!\n Result: $result\n";

but I never get anything in either $! or $result. How can I access (and
check of course) if there was an error from the SOAP server? It also
should give an error if the SOAP server isn't available at all (i.e.
server down)

any help?

Lars

Try the following syntax:

$soap = SOAP::Lite
   -> uri("$yourURI")
   -> proxy("$yourProxy");

   eval {$soapReply = $soap->function($soapRequest);};
   if ($@) {
     chomp ($@);
     print "Server Error ->" . $@ . "<-...skipping";
     ++$errors;
     next;
   }
   elsif ($soapReply->fault) {
     print "Fault code   from function ->" .
       $soapReply->faultcode . "<-";
     print "Fault string from function ->" .
       $soapReply->faultstring . "<-...skipping";
     ++$errors;
     next;
   }




--- In soaplite@yahoogroups.com, "Oeschey, Lars (I/ET-83, extern)"
<extern.lars.oeschey@...> wrote:
>
> Hi,
>
> I have a little script that uses SOAP. I have problems with error
> handling. A little example script looks like this (working
example):
>
> use SOAP::Lite;
> print SOAP::Lite
>  ->service('http://machine.tld:3003/wsdl/all')
>  ->teInput('lala,lulu');
>
> when I run that, I get an error 500 from the SOAP server, which is
> expected, because it expects 3 parameters. I want to catch that
error in
> my script. I used this:
>
> my $result=SOAP::Lite
> 		 ->service('http://machine.tld:3003/wsdl/all')
>
> ->teInput("$barcode_with_num","$soapladestelle");
> 	 print "Error?: $!\n Result: $result\n";
>
> but I never get anything in either $! or $result. How can I access
(and
> check of course) if there was an error from the SOAP server? It
also
> should give an error if the SOAP server isn't available at all
(i.e.
> server down)
>
> any help?
>
> Lars
>

> Try the following syntax:

very nice, that works...

another question, I didn't write the server part, but I have a feeling
that it's not correctly implemented.
If I give a wrong set of parameters to the SOAP Server, I'm just getting
the http 500 Error. Though I think, I should get something in
SOAP->faultcode and SOAP->faultstring to give a better Error Message.
When the server is down, I get a http 503 Error, which is OK and should
be the only case I get a http Error. Internally the SOAP Server logs a
correct Error, i.e.

25.09.2008  9:33:27 [ERROR] TIdSoapServer.HandleSoapRequest():
IdSoapRpcXml.TIdSoapReaderXML.GetParameter: Parameter "in2" not found in
list "c-gensym3"

(that means parameter in2 is missing), shouldn't I get something like
this back to the client?

Lars

You will find that the "500 Internal Server Error" is returned for
many cases where there is a problem on the server side like missing
parameters or restrictive file permissions.  The 500 error is what I
would expect for the situation you describe.

It would be nice to get something more descriptive from SOAP.
However, the error condition you describe is not a problem with SOAP
(transport), but a problem with the service/subroutine itself.  If
you have access to the parameter list on the server side before it's
(automatically?) parsed, you should be able to check that list and
return your own SOAP error code and string if parameters are missing
or invalid.

--- In soaplite@yahoogroups.com, "Oeschey, Lars (I/ET-83, extern)"
<extern.lars.oeschey@...> wrote:
>
> > Try the following syntax:
>
> very nice, that works...
>
> another question, I didn't write the server part, but I have a
feeling
> that it's not correctly implemented.
> If I give a wrong set of parameters to the SOAP Server, I'm just
getting
> the http 500 Error. Though I think, I should get something in
> SOAP->faultcode and SOAP->faultstring to give a better Error
Message.
> When the server is down, I get a http 503 Error, which is OK and
should
> be the only case I get a http Error. Internally the SOAP Server
logs a
> correct Error, i.e.
>
> 25.09.2008  9:33:27 [ERROR] TIdSoapServer.HandleSoapRequest():
> IdSoapRpcXml.TIdSoapReaderXML.GetParameter: Parameter "in2" not
found in
> list "c-gensym3"
>
> (that means parameter in2 is missing), shouldn't I get something
like
> this back to the client?
>
> Lars
>

I am using SOAP::Lite 0.60 and upgrade is not an option.

I am using dispatch_with to call the modules that have my logic to
generate the SOAP in them.

Here is a Data::Dumper of the return from a particular method call:

[Sat Sep 27 17:34:13 2008] $VAR1 = bless( {
[Sat Sep 27 17:34:13 2008] null:                  '_value' => [
[Sat Sep 27 17:34:13 2008] null:                                bless( {
[Sat Sep 27 17:34:13 2008] null:
    '_value' => [
[Sat Sep 27 17:34:13 2008] null:
                  3
[Sat Sep 27 17:34:13 2008] null:
                ],
[Sat Sep 27 17:34:13 2008] null:
    '_type' => 'xsd:int',
[Sat Sep 27 17:34:13 2008] null:
    '_signature' => [],
[Sat Sep 27 17:34:13 2008] null:
    '_name' => 'status',
[Sat Sep 27 17:34:13 2008] null:
    '_attr' => {}
[Sat Sep 27 17:34:13 2008] null:
  }, 'SOAP::Data' )
[Sat Sep 27 17:34:13 2008] null:                              ],
[Sat Sep 27 17:34:13 2008] null:                  '_type' =>
'tns1:pointHistoryRequestResponse',
[Sat Sep 27 17:34:13 2008] null:                  '_signature' => [],
[Sat Sep 27 17:34:13 2008] null:                  '_attr' => {
[Sat Sep 27 17:34:13 2008] null:
'xmlns:tns1' => 'http://soap.mysite.com'
[Sat Sep 27 17:34:13 2008] null:                             }
[Sat Sep 27 17:34:13 2008] null:                }, 'SOAP::Data' );


As you can see, I made a SOAP::Data object and forced the namespace to
be "tns1" and made the type of the pointHistoryRequestResponse element
in that namespace.

However, the XML SOAP::Lite generates from that SOAP::Data object is
different...

<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
    <SOAP-ENV:Body>
       <namesp1:pointHistoryRequestResponse
xmlns:namesp1="http://soap.mysite.com">
          <status xsi:type="xsd:int">3</status>
       </namesp1:pointHistoryRequestResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Some reason it decided to completely ignore my tns1 and make up its
own namespace, namesp1. This is causing extremely frustrating issues
for me.

In a more complex response, the tns1 will appear but SOAP::Lite also
decides to make up its own namespace.

If you'd like to see a more complex response, please ask, but that
simple one should be enough to show what I mean when I say that
SOAP::Lite is changing my namespace names.


How can I get around this issue and force SOAP::Lite to use the "tns1"
namespace like I want? I would greatly appreciate any assistance, I am
at wit's end.

> You will find that the "500 Internal Server Error" is returned for
> many cases where there is a problem on the server side like missing
> parameters or restrictive file permissions.  The 500 error is what I
> would expect for the situation you describe.
> It would be nice to get something more descriptive from SOAP.
> However, the error condition you describe is not a problem with SOAP
> (transport), but a problem with the service/subroutine itself.  If
> you have access to the parameter list on the server side before it's
> (automatically?) parsed, you should be able to check that list and
> return your own SOAP error code and string if parameters are missing
> or invalid.

hm, I asked the company that is responsible for the server side of the
SOAP I use. They told me they send a faultcode etc., it looks like this:

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Type: text/xml; charset=utf-8
Content-Length: 561
Server: Indy/9.0.18
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soap:Body>
   <soap:Fault>
    <soap:faultcode>soap:Server</soap:faultcode>
    <soap:faultstring>
     IdSoapRpcXml.TIdSoapReaderXML.GetParameter: Parameter
     "in2" not found in list ""
    </soap:faultstring>
    <detail xsi:type="EIdSoapRequirementFail"></detail>
   </soap:Fault>
  </soap:Body>
</soap:Envelope>

However with your example code

use SOAP::Lite;
$soap= SOAP::Lite
	 ->uri('http://soap.data.inform.com')
	 ->proxy('http://soapserver.tld:3003/soap/');

eval {$soapReply = $soap->teInput("lala,lulu");};
   if ($@) {
     chomp ($@);
     print "Server Error ->" . $@ . "<-...skipping";
   }
   elsif ($soapReply->fault) {
  	 print "Fault code   from function ->" .
  	 $soapReply->faultcode . "<-";
  	 print "Fault string from function ->" .
  	 $soapReply->faultstring . "<-...skipping";
}
else {
	 print $soapReply;
}

I get nothing more than the 500 Server error. I think I should also get
the soap->faultcode etc., something must be still wrong on my side
then...

-------------- Original message from "Oeschey, Lars (I/ET-83, extern)" <extern.lars.oeschey@...>: --------------

> You will find that the "500 Internal Server Error" is returned for
> many cases where there is a problem on the server side like missing
> parameters or restrictive file permissions. The 500 error is what I
> would expect for the situation you describe.
> It would be nice to get something more descriptive from SOAP.
> However, the error condition you describe is not a problem with SOAP
> (transport), but a problem with the service/subroutine itself. If
> you have access to the parameter list on the server side before it's
> (automatically?) parsed, you should be able to check that list and
> return your own SOAP error code and string if parameters are missing
> or invalid.

hm, I asked the company that is responsible for the server side of the
SOAP I use. They told me they send a faultcode etc., it looks like this:

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Type: text/xml; charset=utf-8
Content-Length: 561
Server: Indy/9.0.18
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<soap:Fault>
<soap:faultcode>soap:Server</soap:faultcode>
<soap:faultstring>
IdSoapRpcXml.TIdSoapReaderXML.GetParameter: Parameter
&#34;in2&#34; not found in list &#34;&#34;
</soap:faultstring>
<detail xsi:type="EIdSoapRequirementFail"></detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>

However with your example code

use SOAP::Lite;
$soap= SOAP::Lite
->uri('http://soap.data.inform.com')
->proxy('http://soapserver.tld:3003/soap/');

eval {$soapReply = $soap->teInput("lala,lulu");};
if ($@) {
chomp ($@);
print "Server Error ->" . $@ . "<-...skipping";
}
elsif ($soapReply->fault) {
print "Fault code from function ->" .
$soapReply->faultcode . "<-";
print "Fault string from function ->" .
$soapReply->faultstring . "<-...skipping";
}
else {
print $soapReply;
}

I get nothing more than the 500 Server error. I think I should also get
the soap->faultcode etc., something must be still wrong on my side
then...

> I'm not a great perl person, but doesn't using eval put the fault
string
> out of scope for the block in which you are attempting to print?

I also practically never used eval, so I don't know ;)

> I've always been able to get the error message back - and I
> never use eval
> (i understand that it is handy for trapping errors and not
> crashing the script)

The eval was a workaround, since without using it, I wouldn't get
*anything* back in case of error, the http 500 error wouldn't even come
back to me, and I had no idea if the call was successful.

> also, why are you testing the error path through your code, or do
> you really want to send a single param in your call ?
> (as opposed to teInput("lala", "lulu");)

hm, what do you mean?

Lars

I got a bit further on this, though not very successful. Using the
->trace method of SOAP::Lite, I could see what I'm sending and
receiving:

sent:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.
org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<namesp1:teInput xmlns:namesp1="http://soap.data.inform.com">
<c-gensym3 xsi:type="xsd:string">MAN9999999/1</c-gensym3>
<c-gensym5 xsi:type="xsd:string">LAD1020</c-gensym5>
<c-gensym7 xsi:type="xsd:int">1</c-gensym7>
</namesp1:teInput>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

received:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xs="http://www.
w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<soap:Fault>
<soap:faultcode>soap:Server</soap:faultcode>
<soap:faultstring>IdSoapRpcXml.TIdSoapReaderXML.GetParameter: Parameter
"in2" not found in list
"c-gensym3,c-gensym5,c-gensym7"</soap:faultstring>
<detail xsi:type="EIdSoapRequirementFail"></detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>

looking at the wsdl file, I see that the third parameter should be
string, while I send int (though I didn't do anything, somewhere it gets
autotyped):

<message name="teInput">
<part name="in0" type="xs:string"/>
<part name="in1" type="xs:string"/>
<part name="in2" type="xs:string"/>
</message>

So this is the reason, why it's denied. But: Why don't I get the fault
parameters? With this:

use SOAP::Lite;# +trace => [qw(all)];
my $soap= SOAP::Lite
	 ->uri('http://soap.data.inform.com')
	 ->proxy('http://audiinsa00220.in.audi.vwg:3003/soap/');

my $som=$soap->teInput("MAN9999999/1", "LAD1020", "1");

if ($som->fault) {
	 print $som->faultdetail;
	 print $som->faultcode;
	 print $som->faultstring;
	 print $som->faultactor;
}

I only get:
500 Internal Server Error at soaptest.pl line 6

and: How can I force the parameter to be a string?

Lars

----- Original Message -----

From: Oeschey, Lars (I/ET-83, extern)

To: soaplite@yahoogroups.com

Sent: Wednesday, October 01, 2008 3:28 AM

Subject: RE: [soaplite] Re: How to get errors

> I'm not a great perl person, but doesn't using eval put the fault
string
> out of scope for the block in which you are attempting to print?

I also practically never used eval, so I don't know ;)

> I've always been able to get the error message back - and I
> never use eval
> (i understand that it is handy for trapping errors and not
> crashing the script)

The eval was a workaround, since without using it, I wouldn't get
*anything* back in case of error, the http 500 error wouldn't even come
back to me, and I had no idea if the call was successful.

> also, why are you testing the error path through your code, or do
> you really want to send a single param in your call ?
> (as opposed to teInput("lala", "lulu");)

hm, what do you mean?

Lars

Hi,

I am using SOAP-Lite v 0.710.08.  I am trying to get the result data
from the xml response, but I keep getting error 'Can't call
method "dataof" without a package or object reference at ...'.

Here is the response I am getting back from the webservice request:

<ServiceResponse>
	 <RequestType>CheckListenerStatus</RequestType>
	 <SuccessInd>Y</SuccessInd>
	 <Response>The Listener service is currently running.</Response>
	 <RequestDateTime>10/02/2008 13:12:01</RequestDateTime>
</ServiceResponse>

I then get the error when I make the following call:

my $successInd = $som->dataof('//ServiceResponse/SuccessInd');

How can I fix this?

> the parameter missing error you are receiving is because it
> expects two (3)
> args, and you were only sending one - now, you do need to get your
> error detection working - and i haven't had any problem printing
> the faultcode and strings -
> i recommend you read the wsdl with soap lite that will get
> the type correct.
> in your second response

as you can see from the post after that one (btw, this is the slowest
list I know, not from participants but post speed, i.e. yahoo ;)), I've
been able to trace sent and received stuff. I also managed meanwhile, to
force the third parameter into "string" type, which can be seen with the
trace. I still get the same error from the other side, which I blame on
the server side now, but I still don't get the faultcode/string, and it
definitely is sent (which is also seen in the trace mentioned in the
previous mail)

> faultstring may only contain
> "500 Internal Server Error at soaptest.pl line 6"
> perhaps your server side code is bad?

maybe server-side code is bad... but the 500 Message comes not from
*within* SOAP but is just the transport error (same as with a web
server). I do see the SOAP fault in the trace, and it looks like it
should be captured by SOAP::Lite, but it isn't...

regards, Lars

> I keep getting error 'Can't call
> method "dataof" without a package or object reference at ...'.


> my $successInd = $som->dataof('//ServiceResponse/SuccessInd');

Appears your $som object is an empty string.

--
Radek

> <message name="teInput">
> <part name="in0" type="xs:string"/>
> <part name="in1" type="xs:string"/>
> <part name="in2" type="xs:string"/>
> </message>

First don't input raw values to teInput function. Follow your service
description.
Something like this:

my $som=$soap->teInput(
                                       SOAP::Data->name(in0 => 'MAN9999999/1'),
                                       SOAP::Data->name(in1 => 'LAD1020'),
                                       SOAP::Data->name(in2 =>
1)->type('string'),
                                       );


--
Radek

> > <message name="teInput">
> > <part name="in0" type="xs:string"/>
> > <part name="in1" type="xs:string"/>
> > <part name="in2" type="xs:string"/>
> > </message>
>
> First don't input raw values to teInput function. Follow your service
> description.
> Something like this:
>
> my $som=$soap->teInput(
>                                       SOAP::Data->name(in0 =>
> 'MAN9999999/1'),
>                                       SOAP::Data->name(in1 =>
> 'LAD1020'),
>                                       SOAP::Data->name(in2 =>
> 1)->type('string'),

great, this works! Thanks a lot! Would you mind explaining what the
difference is now? Can I maybe read up somewhere about generic Soap
handling? It seems my fault was just not following "best practice", so
I'd like to know what "best practice" would be ;)

Lars

> First don't input raw values to teInput function. Follow your service
> description.
> Something like this:
>
> my $som=$soap->teInput(
>                                       SOAP::Data->name(in0 =>
> 'MAN9999999/1'),
>                                       SOAP::Data->name(in1 =>
> 'LAD1020'),
>                                       SOAP::Data->name(in2 =>
> 1)->type('string'),

This works good for the positive case (i.e. all values are good). If I
want to get an error, by sending the last value as string, I should get
an error from $som->fault however. I only get a http 500 error. The
trace contains the fault though:

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/s
oap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.
xmlsoap.org/soap/envelope/"><soap:Body><teInput
xmlns="http://soap.data.inform.com"><in0
xsi:type="xsd:string">MAN9999999/1</in0><in1 xsi:type="xsd:st
ring">LAD22010</in1><in2
xsi:type="xsd:int">1</in2></teInput></soap:Body></soap:Envelope>
SOAP::Transport::HTTP::Client::send_receive:
HTTP::Response=HASH(0x1e38270)
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal
Server Error
Cache-Control: proxy-revalidate
Connection: close
Date: Mon, 06 Oct 2008 13:44:41 GMT
Server: Indy/9.0.18
Content-Length: 689
Content-Type: text/xml; charset=utf-8
Client-Date: Mon, 06 Oct 2008 13:44:40 GMT
Client-Peer: 10.250.52.241:8080
Client-Response-Num: 1

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xs="http://www.
w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body><soap:F
ault><soap:faultcode>soap:Server</soap:faultcode><soap:
faultstring>Type Mismatch. For the parameter in2, the type found was
"int" in the namespace
"http://www.w3.org/2001/XMLSchema", which
doesn't match any of the expected values:
{http://www.w3.org/2001/XMLSchema}string</soap:faultstring><detail
xsi:type="EIdSoapRequirementFail"></d
etail></soap:Fault></soap:Body></soap:Envelope>

I'm trying to get the fault like this:

if ($som->fault) {
	 print $som->faultdetail; # returns value of 'detail' element as
                             	 # string or object
	 print $som->faultcode;   #
	 print $som->faultstring; # also available
	 print $som->faultactor;  #
}
else {print "result:$som\n";}

> I'm trying to get the fault like this:
>
> if ($som->fault) {
> print $som->faultdetail; # returns value of 'detail' element as
> # string or object
> print $som->faultcode; #
> print $som->faultstring; # also available
> print $som->faultactor; #
> }
> else {print "result:$som\n";}

You should get the fault this way. You may changed the $som object
before calling a fault method.


--
Radek

> great, this works! Thanks a lot! Would you mind explaining what the
> difference is now? Can I maybe read up somewhere about generic Soap
> handling? It seems my fault was just not following "best practice", so
> I'd like to know what "best practice" would be ;)

A request expects a soap structure which is done by SOAP::Data class.
Check the SOAP::Lite docs.

--
Radek

We have Perl v5.8.0 client code that has always targeted SOAP 1.2
with SOAP::Lite 0.55.  It runs against a remote server with the same
releases.  We recently moved all of the client code to a new Linux
system with Perl 5.8.5 and SOAP::Lite 0.710.08. Now, when
communicating with the remote server we get error: Content-Type must
be 'text/xml' instead of 'application/soap'

I understand SOAP 1.2 uses this new content type over the old v1.1
text/xml, but again, this code has been working for years. The remote
server has not changed! We still have the old client system up and
can do side by side testing.

I tried changing the SOAP version to 1.1 just to send the content-
type that it's expecting, but then other issues come up, like a
hardcoded prefix SOAP-ENC:Array needs to be soapenc:Array.

Can I force the content-type of a v1.2 transaction to text/xml?
What else can be done to remedy this situation?  The people who own
the remote server will certainly not upgrade because of this.

Thanks!

> I tried changing the SOAP version to 1.1 just to send the content-
> type that it's expecting, but then other issues come up, like a
> hardcoded prefix SOAP-ENC:Array needs to be soapenc:Array.
>
> Can I force the content-type of a v1.2 transaction to text/xml?
> What else can be done to remedy this situation? The people who own
> the remote server will certainly not upgrade because of this.

You can change the content-type with

$soap->transport->http_request->header('Content-type' => 'text/xml');

--
Radek

I wrote:
> > I tried changing the SOAP version to 1.1 just to send the content-
> > type that it's expecting, but then other issues come up, like a
> > hardcoded prefix SOAP-ENC:Array needs to be soapenc:Array.
> >
> > Can I force the content-type of a v1.2 transaction to text/xml?
> > What else can be done to remedy this situation? The people who own
> > the remote server will certainly not upgrade because of this.

Radek responded
> You can change the content-type with
>
> $soap->transport->http_request->header('Content-type' => 'text/xml');

Thank you for the suggestion. This does change the header but the
server is now complaining that the client is using the wrong SOAP
version. There is a major difference between the headers sent before
and after the upgrade.

Before upgrade:

<SOAP-ENV:Envelope
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:SOAP-ENC="http://www.w3.org/2001/06/soap-encoding"
   xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   SOAP-ENV:encodingStyle="http://www.w3.org/2001/06/soap-encoding">

After upgrade:

<soap:Envelope
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:soapenc="http://www.w3.org/2003/05/soap-encoding"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
   xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

It looks like the server isn't prepared for the v2003 schemas that come
with SOAP::Lite v0.710 compared to v0.55 - and we cannot change the
server. As mentioned in my original post, SOAP-ENC:Array is hardcoded
into the transaction code and doesn't agree with the newer schema
anyway.

My current recommendation to the client is to downgrade SOAP::Lite and
that probably involves a downgrade of Perl as well, and that may affect
yet other dependencies. Better suggestions are welcome.

I'm hoping for a quick solution here, but my client is willing to pay
to get this resolved quickly if a solution needs to be more involved.
So far I have emailed Paul Kulchenko to request compensated services
but I have not received a response. I welcome emails from qualified
developers with references. You must have a complete understanding of
the situation (I believe my postings here have provided that) and a
ready proposal for a solution, we cannot fund research or education.

Thanks for your time.

Hi Tony,

the namespaces are defined in SOAP::Constants. Unfortunately they cannot
be overridden at run time, because perl's peep-hole optimizer inlines
constants.

However, the constants are not used directly by SOAP::Lite, but through
the following SOAP::Constants variables:

@SUPPORTED_ENCODING_STYLES
%XML_SCHEMAS
%XML_SCHEMA_OF
%SOAP_VERSIONS

To change all occurances, do the following:

BEGIN {
use SOAP::Lite

my $url_enc = "http://www.w3.org/2001/06/soap-encoding";
my $url_env = "http://www.w3.org/2001/06/soap-envelope";

push @SOAP::Constants::SUPPORTED_ENCODING_STYLES, $url_enc;

$SOAP::Constants::SOAP_VERSIONS{'1.2'}->{NS_ENC} = $url_enc;
$SOAP::Constants::SOAP_VERSIONS{'1.2'}->{NS_ENV} = $url_env;

$SOAP::Contants::XML_SCHEMAS{$url_enc} = 'SOAP::XMLSchemaSOAP1_2';
$SOAP::Contants::XML_SCHEMAS_OF{$url_enc} = 'XMLSchemaSOAP1_2';
}

This should change the (new) namespaces back to the old ones throughout
SOAP::Lite (untested...).

Note that SOAP::Constants variables are global - all your SOAP::Lite
instances in the current process will be affected (may be an issue under
mod_perl).

Martin


Am Samstag, den 18.10.2008, 22:57 +0000 schrieb Tony Gravagno:
> ...
> Thank you for the suggestion. This does change the header but the
> server is now complaining that the client is using the wrong SOAP
> version. There is a major difference between the headers sent before
> and after the upgrade.
>
> Before upgrade:
>
> <SOAP-ENV:Envelope
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:SOAP-ENC="http://www.w3.org/2001/06/soap-encoding"
> xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> SOAP-ENV:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
>
> After upgrade:
>
> <soap:Envelope
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:soapenc="http://www.w3.org/2003/05/soap-encoding"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
>
> It looks like the server isn't prepared for the v2003 schemas that
> come
> with SOAP::Lite v0.710 compared to v0.55 - and we cannot change the
> server. As mentioned in my original post, SOAP-ENC:Array is hardcoded
> into the transaction code and doesn't agree with the newer schema
> anyway.
>
> My current recommendation to the client is to downgrade SOAP::Lite
> and
> that probably involves a downgrade of Perl as well, and that may
> affect
> yet other dependencies. Better suggestions are welcome.
>
> I'm hoping for a quick solution here, but my client is willing to pay
> to get this resolved quickly if a solution needs to be more involved.
> So far I have emailed Paul Kulchenko to request compensated services
> but I have not received a response. I welcome emails from qualified
> developers with references. You must have a complete understanding of
> the situation (I believe my postings here have provided that) and a
> ready proposal for a solution, we cannot fund research or education.
>
> Thanks for your time.
>
>
>
>
>