Simple SOAP client with wsdl2php using WSDL

Nusoap used to be my favourite php toolkit for SOAP communication. But I was struggling a lot with it to make a simple client from the wsdl file. I really liked the way .NET SOAP modules parse the wsdl in a second and give you classes that you can use in your code. So why not having the same thing in php?

Luckily for me somebody thought of it first. Enter wsdl2php. It is simple, lightweight and easy to use. It parses the wsdl file and creates ready to use php classes. It is really handy for tackling those complex data types that you might have on your web services. It can be used both on Linux and Windows from the php command line.

So go ahead and download the latest version from sourceforge. If you are on a Linux distribution you can use the pear installer to install it from the .tgz file:

sudo pear install wsdl2php-0.2.1-pear.tgz

and then use it as a command line app with:

wsdl2php http://yoursoapserver/Service.wsdl

If you are on Windows, no worries, you can also extract the tgz and call the wsdl2php.php file from the command line with the URL to the WSDL as an argument. Something like:

C:\PHP5\php.exe -f "C:\wsdl2php\wsdl2php.php" --  "http://yoursoapserver/Service.wsdl"

There are also more info how to use php cli under windows on the php manual pages.

The script should generate a php file in the working directory with all the classes and data types that are found on the WSDL. The generated client class extends php's SoapClient class, which shold come with the php core. You just have to include it in your php app, and you are ready to go:

require_once 'YourWebService.php';
$client = new yourWebService();
$input = "Your Input"; # check the generated classes to find out
                       # what the required input should be. 

try{
   echo $client->someFunction($input);
}
catch (Exception $e){
   echo $e->getMessage();
}

If you are dealing with complex data types, be sure to check the generated classes to determine what your input variables should look like.

If you learn to use this tool, it should make your work with SOAP and WSDL a lot easier.

However if you are struggling to hard and still can not make a soap client work with a wsdl file and generate the desired XML output read my blog post about posting raw XML with nusoap to a SOAP Web Service

Multiple table delete: Cascade delete vs Join Delete

There is this really old php/mysql project that I maintain and every know and than there are some problems with data integrity, orphaned records and constraint violations.

After some debugging I found out that the main problem is that related data is deleted in separate delete statements, and some of them throw exceptions and don't get executed.

I immediately thought of making a CASCADE DELETE on the constraints, but as I started reading on google about cascades I found out that many people are against it. Personally I have had at least 2 or 3 bad experiences with accidentally deleting some data and then reflecting that on the cascaded data. Probably that is why I try to avoid cascading.

The other option is to make an inner join on the delete statement.

Let's say that we have such a model: User 1:N Service 1:N Service_Parameter

The query would look something like this:

delete user.*, service.*, service_parameters.* 
from user 
inner join service on service.user_id = user.id 
inner join service_parameter on service_parameter.service_id = service.id 
where user.id = $id

People seem to be against this idea as you would have to remember the data relation and execute such a query whenever you are deleting data. However if your application code is written properly you would usually have a delete method where this query would be written, and then execute this method (or stored procedure) whenever you want to delete something.

If you delete something manually from the DB, accidentally or intentionally, you would not delete the cascaded data. This might be a pro or a con whichever way you want to look at it.

Perssonally I would like to have to make more separate deletes or a stored procedure with the above query rather than using the dreaded CASCADE DELETE and not having an explicit control of what am I deleting.