Drupal talking to SugarCRM.. Which language?

I've decided to include versions 1 and 2 of Web Service definition using SOAP and RESTful protocols in SugarOnDrupal module. This would definitively improve the level of integration with existing Drupal or SugarCRM life applications. The same API call answer different results in V1 and V2 methods, and the format type could be different using RESTful or SOAP protocols, but this is not important, it can be handled programatically. The bad part is (what is this blog post about): what are the technological requirements to do so?

Let's begin with Drupal requirements:

  • Recommended: PHP 5.2.x
  • Required: PHP version 4.3.5 or higher
  • PHP 5.3 is not yet supported for Drupal 6
  • PHP 5.2 or higher will be a requirement for Drupal 7.

About RESTful client, as (for now) it's going to be built internally for SugarOnDrupal module, these would be the requirements:

  • Using serialized content (worse performance): It's included since PHP 4, there should not be any problem..
  • JSON: As of PHP 5.2.0, the JSON extension is bundled and compiled into PHP by default.
  • Using PHP4, the PECL JSON extension requires PHP Version: PHP 4.3.0 or newer. Probably there will be other JSON implementations, but I would not cover that.

    The transport part is a little bit more complicated, because it may be based in libCURL:

  • Drupal already has an HTTP client capable to support GET/POST/PUT request, using fsockopen, included since PHP4.
  • if using libCURL: PHP requires that you use libcurl 7.0.2-beta or higher. In PHP 4.2.3, you will need libcurl version 7.9.0 or higher. From PHP 4.3.0, you will need a libcurl version that's 7.9.8 or higher. PHP 5.0.0 requires a libcurl version 7.10.5 or greater.

Now, about SOAP interface.. This is quite complicated..

According to SugarCRM wiki, internally on the server side, the SOAP interface is implemented with nuSoap, a PHP SOAP library. In fact, they recommend to use nuSOAP because other implementation may have issues as complaining with SOAP protocols, including PHP5 SOAP. In any case, lets develop this a little bit:

  • PHP5 SOAP is only bundled since PHP 5.0.0 or greater.
  • There's a pear SOAP package that works with PHP Version: PHP 4.3 or newer
  • nuSOAP latest version (0.7.3) is dated on 2007/11/06. I haven't seen any issue of nuSOAP regarding PHP version 4.3.5 or lower, therefore I guess this should work with current Drupal requirements.

The bad part is about what SOAP interface can web use.. PHP SOAP or nuSOAP. SugarCRM recommends nuSOAP because PHP5 SOAP doesn't complain well with WSDL request types, but this could be fixed using non-wsdl mode.

I should also consider that PHP json interface may behaviour differently in each PHP version..

The last part: SugarCRM Version (because of the supported protocols)

Ok, now we know more or less the requirements for each interface.

  • We can have a Drupal 6 running in PHP 4.3.5, talking to SugarCRM 5.5 using the REST interface in serialized mode, and we don't need to install additional modules or dependencies. Pretty good! But what if the SugarCRM version is 5.2? only version 1 and only SOAP interface is available..
  • But, we can also have a Drupal 6 running in PHP 5.2.3, but we have to modify and install nuSOAP or remove the PHP5 SOAP extension to be able to ask to SugarCRM 5.2.

Conclusions?

To make things easier for the module user, I'm refusing the idea of having to install other dependencies (e.g. nuSOAP). Having nuSOAP as recommended interface for SugarCRM webservices, I've to consider that it may get into conflict if PHP5 SOAP is enabled, because both uses the same class function names, therefore nuSOAP should have to be modified to work with PHP5 SOAP enabled in the PHP side. I'm not sure how could this be avoided with a PHP 4 version, because it has no any kind of soap interaction. Should the user install nuSOAP as a requirement?

The last idea comming to my mind is about writting a simple to_soap() funciton able to build the queries that SugarCRM nuSOAP server would expect, as the WebServices part will be static enough to not need adaptability or changes.. I don't know..