I have a Drupal 7 site that needs to update the contents of a number of nodes once a day, pulling new data from a SOAP service running on an IIS server. And there is what appears to me to be a very strange problem with it.

I have a test script, that does not run inside of Drupal, that connects to the SOAP service like this:

  $wsdl = 'http://foo.state.us/SpecService.WS/SpecServiceDA.asmx?WSDL';
  $soap_client = new SoapClient($wsdl);

This script works fine. Inside my Drupal module, I have code that connects to the same service like this:

  $wsdl = variable_get_value('spec_service_url');
  $soap_client = new SoapClient($wsdl);

This code generates a 405 error, with the IIS server log reporting:

Exception information: 
    Exception type: HttpException 
    Exception message: Request format is unrecognized. 

Both the test script and the Drupal site are running on the same server, under the same virtual host. I've checked the value of $wsdl and it matches that in the text script. I've also tried simply using the string, with the same result.

Now for the very strange part:

If I run the test script once, the module code then works fine for a time ranging from a few hours to a few weeks.

Eventually, I will start getting 405 errors again. I rerun the test script, and the module resumes functioning until the next failure.

I'm about ready to start pulling out hair. Anyone have any theories what might be going on here?


Jaypan’s picture

Not sure, but nothing suggests your problem has anything to suggest your problem is a Drupal one, and rather appears to be a problem with the soap library you are using.

wrd’s picture

It's very much a shot in the dark. It's the same library (SoapClient: http://php.net/manual/en/class.soapclient.php) in both pieces of code. It's essentially the same code (and I've tested it with exactly the same code, since the only difference is how the WSDL string gets fed to the function). The only difference I can think of is that the test script, which works every time, is being run "directly", while the module code, which sometimes fails, is being executed as a hook_menu() callback or a hook_action_info() callback (the latter as a scheduled job, the former when I need to execute it on-demand).