sugarondrupal.drtsg.net

I've reviewed and discussed this issue too many times with several customers. I don't want to say that SugarCRM Self service Portal is bad, I don't think so, but I agree with them in that it's not as flexible as they need. Everytime I try to argue that the purpose of that portal is heavily defined and it works as it should, they answer me that "it doesn't work as they want". This flexibility is going to be a requirement also in SugaronDrupal project.

I'm currently working on this feature, as it is one of the requirements to have a Drupal installation profile for a Customer self service portal. The sugarondrupal_cases module (not yet available) is a "interface" module. Now it is possible to list cases in a Drupal site, view them and also create them. there's a lot of work to be done in 'design' and functionality, but it's working as the pictures attached can confirm..

I've commited several changes to the SugaronDrupal module a few days ago. Currently, it also supports SOAP if the Soap Client module is enabled. The only reason why is this module a requirement to using SOAP is that it has included a switch and some nuSOAP manipulation so it can use nuSOAP style and code base even if PHP SOAP is enabled.

While I was introducing the SOAP support for the module I had remember some differences between the SOAP and RESTful protocols in Version 1 and 2 of the web services. The following list show different responses for the same call using different protocols.

With the goal of provide support for versions 1 and 2 of the SugarCRM WebServices, I had to do a triage of 'functionality' to be provided by them. I've listed and sorted the API functions included in SugarCRM 5.2 and 5.5 versions, for the versions 1 and 2 of the Web Services. There are a lot of missing methods (they where documented as deprecated, or superseed by another), and there are new ones.

I've included two pics with the results:

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?

As I'm refactoring the main part of the SugaronDrupal module, I need to test how reliable the REST (SugarCRM WebServices V2) interface is. As I have already commented, I've joined the SugarCRM testFest to do exhaustive Web Services testing. Although TestFest has not started yet, I've already been testing on my own, in an attempt to get some advantage to the little timewindow available for testing and fixing before the 5.5 version gets released. The following content are the results of my own tests.

SugarCRM includes the RESTful services in the 5.5 version. The API set is quite similar to the SOAP implementation, but somethings are missing right now. The documentation is still in DRAFT state, and the services also has some issues to be resolved. This is one of the reason why I decided to join the SugarCRM TestFest. In any case, this will be a short introduction about RESTful services and how to call them. Please, note that these are results from SugarCRM 5.5.Beta1.

As I said, the module is currently under heavy redesign. The most important part is the connector itself, the main SugarOnDrupal module. This will be the responsible of linking Drupal with SugarCRM. For this task, anticipating the release of the SugarCRM 5.5 version, I've decided to include the REST and SOAP V2 interfaces. There are a lot of differences between V1 and V2 Web Service specifications, but all of them will be consolidated under SugarOnDrupal module, to be able to link SugarCRM flavors from CE (Community) to Proffesional or Enterprise editions.

Lets begin, it's time to start a serious development. This is why this post, the first post, should clarify where is the focus of this development right now. I'll be involved in the SugarCRM TestFest, thanks to the effort of Matt Heitzenroder. Clearly it's a good chance to collaborate, and I'll be doing so.