Child pages
  • Sakai web service gotchas
Skip to end of metadata
Go to start of metadata

Sakai web service gotchas

The following are a few tricks I've picked up - I spent ages trying to figure these out and must have gotten a few extra grey hairs along the way. Hoefully these will save your sanity (wink)

HTTP vs HTTPS in Using Web Services

I was having difficulties connecting to the SakaiLogin.jws?wsdl file. I was trying to connect through Perl and using the SOAP::Lite module.

This simple fragment of code should have worked:

But I was getting a 500 Connect failed: connect: Connection refused; error.

At first I thought it might have been the self-signed certificate that we are using whilst we integrate, so we put in the certificate environment variables into the script as per the SOAP::Lite documentation so that the certificate and key could be found:

but still no luck. Same error.

Note re adding the environment variables

Since we are writing a script to connect to a web service, there is the possibility of having the script on a different machine altogether, but this would be restricted by having the environment variables hard coded into your script, so you should use a more flexible method of connecting over HTTPS to the web service provider.

Also, the certificate and key must be readable by the user executing the script that requires them otherwise you will get an errr saying they cannot be read. Allowing read access to the certificate and key might be an issue of security for you.

We then disabled SSL on the server and tried again, this time with the URL being HTTP instead of HTTPS, but this time I get a 404 Not Found error! The file clearly exists, I can browse to it and get the WSDL XML displayed on screen.

That got me thinking and finally I came up with...

The solution

We have our server setup so that Apache hands off the requests to Tomcat that it needs to, with Apache running on the standard port 80 and Tomcat running on port 8080. When browsing via the web, I access Sakai through port 80, but under the hood, Apache is handing off the requests to Tomcat and connecting through port 8080. Because I wasn't going through Apache with this Perl script, I needed to add the port to the URL to connect directly through Tomcat so the URL becomes: http://myserver:8080/sakai-axis/SakaiLogin.jws?wsdl

After I did that, the requests went through fine.

From Seth Theriault:
All my conns to Tomcat are fronted by Apache. I am using a Perl script with these URIs:

my $loginURI = "https://my.sakai.server/sakai-axis/SakaiLogin.jws?wsdl";
my $scriptURI = "https://my.sakai.server/sakai-axis/SakaiScript.jws?wsdl";

and see no problems.

Thanks Seth. Maybe it was just the UNE server setup that was presenting difficulties for me?!

A caveat with Perl and Web Services

Some of the web services (which are written in Java and implemented through Apache Axis) require boolean data types to be passed to them. However, Perl has no pure boolean datatypes. Sure, there are ways within Perl to signal a true or false value, but this does NOT extend outside of Perl. So the problem arises when you need to pass a boolean data type to a web service written in Java.

The solution is in Perl's SOAP::Lite module, which allows you to create boolean data types:

This sets up some boolean typed parameters which can now be securely passed to a function requiring booleans!

1 Comment

  1. I'd like to post a couple 'ActivePerl on Windows' Gotchas.  These may also apply to Linux / Mac - I have no idea.

    Now that I've found the SOAP calls, I love them and write scripts to manage Sakai all the time from my desktop machine.  We have Sakai on Linux, but my desktop is Windows with ActivePerl installed and I've run into some interesting things that may be related to newbie-isms, but I'll share them in hopes they help someone else.

    Getting (the right) Return Results

    When you perform a SOAP call in PERL using the ActivePerl  SOAP::Lite module you need to know that if the SOAP call is successful, it will return a 1If the SOAP call fails, it will return a 1. This can be misleading / confusing / frustrating :

    1. if you're expecting a result from a SOAP call and continue to get a 1 only. 
    2. and nothing is happening in Sakai (the function call is actually failing or not getting called at all)

    This 1 is simply the fact that PERL called soap and the call was executed period. It is NOT the result of the function call that Sakai is sending back.

    When you want a result from a webservice SOAP call you need to add ->result to the end of the call and set a variable for it like this :

    Now you can print that to the screen or use it later in your script like this :


    Proper SOAP Parameters

    If you execute your script and are seeing this error -

     Use of uninitialized value in string eq at scriptname.pl line 74.

    This can be an incredibly frustrating error - because it doesn't tell you how you screwed up. When seeing this error, check your SOAP function call.  Compare the number (and type) of parameters you're sending to that listed in your SakaiScript.jws file (located in src_dir/webservices/axis/src/webapp).  This is a text file that holds the JAVA code for the SOAP functions -most of which you can find on Steve's page

    Make sure - if there are 3 parameters in SakaiScript.jws that you're sending 3.  If they're strings, or boolean, make sure you're sending a string or a boolean. Also make sure the values of the variables you're using are what you think they are. Print them to the screen if you have to.  If you mistype a variable name or cut and paste someone else's code, variable names may be similar but wrong (and undefined - ie. $session / $sessionid )

    The bottom line with this error is that you have something wrong in your code, even though it may look correct at first glance.