SugarCRM 101: Multiple Businesses Continued

Recently I found myself reviewing a behavioral issue in SugarCRM that coincidentally had affected another user a few months prior.

While reviewing the matter, it became evident it fit in nicely with the list of reasons it is generally not a good idea to use a single install of SugarCRM for multiple businesses, commonly referred to as a multi-tenant implementation.

This time around, the issue revolved around email and the manner in which messages link themselves to records in SugarCRM. In general, SugarCRM utilizes the email addresses associated with a record to determine which records should be linked to the message. Thus, the FROM, TO, CC and BCC addresses on a message are all relevant because if the address is associated with a record in SugarCRM -- be it an account, contact, or other -- the email message will automatically associate itself with that record. Said message would, for example, appear on the History subpanel of the contact with the matching TO address, as well as that of the contact with the matching CC address. Herein lies the potential problem. 

Within an implementation intended to conform with multi-tenancy standards, the record with the TO address may not be accessible to a user that does have access to the record with the CC address. Perhaps the records represent individuals in different territories or serviced by different business units, etc. Whatever the reason, it is possible that a given user of the system does not have access to both records that correspond with the two email addresses. 

Regardless, the email message is linked to both records and History information could be exposed to unintended users. Take note that security issues of this type often times cannot be addressed as they are a direct result of the architecture of SugarCRM. 

Thus, once again, one should heed the warning that problems may arise (sometimes not readily apparent), if one chooses to use the system in a multi-tenant manner. 

SugarCRM: SOAP API Performance

It is not uncommon for discussions that revolve around the SOAP API in SugarCRM to include some measure of criticism, but how much of that criticism is actually warranted?

SOAP --the protocol-- has always been critiqued for not being an optimal method for communication between distributed systems, in short, poor performance. Thus, it is no surprise that some of that criticism should find its way into conversations about the SugarCRM SOAP API.

Some folks in the broader web development world have altogether given up on SOAP, favoring RESTful web services. True to the trends in the general web development community, many SugarCRM developers have also tossed aside any notions of using the SOAP API, and SugarCRM addresses this trend by also providing a REST API. However, this growing resentment towards all things SOAP makes me question whether it is justified, and if so, what can be done about it?

Before we go any further I should state I do not discount the point that test results can prove REST to be faster than SOAP, but I do think many performance problems attributed to the SugarCRM SOAP API can be overcome with some fine tuning of code. 

In my experience, the most common source of performance problems has come from the use of the set_relationship() method. Said method is used to create a relationship between records, for example, link an opportunity to a contact. All efforts should be made to reduce the number of times this method is called within your code.

SugarCRM Troubleshooting: SOAP API Login Problems

One of the oddest technical issues that I have run into dates back a couple of years. In short, attempts to login to the SugarCRM SOAP API failed, but only if the connecting client was a .NET application. That is to say, a PHP script attempting to do the same worked flawlessly.

There was an obvious disconnect there, as the SOAP API should fail for all clients, not just .NET clients. The eventual solution left me puzzled, as it too did not seem to make much sense. As a result, a true solution to the problem seemed to evade me.

By chance, a very similar problem recently found its way to my desk. However, this time around, additional conditions within the environment provided other clues not readily obvious the first time I encountered the problem. 

Not unlike the previous scenario, attempting to execute the login() method of the SOAP API via PHP succeed, i.e. it returned a valid session, but doing the same via .NET failed, returning a SOAP error. 

With the new clues in hand, a definitive solution and explanation finally emerged.

As it turns out, the commonality between the two systems is that both were using self signed SSL certificates. Were we to attempt to access said SugarCRM instance via our browser, it would give us a warning similar to the following image:

The image will vary depending on the browser you use, but the message it is trying to communicate to us is the same: the SSL certificate for the site cannot be trusted.

While our browser permits us to continue on by means of a click, .NET does not. Herein is the root cause of the login() problem for the SugarCRM SOAP API.

To solve the problem, one of two solutions must be applied:

1. Replace the self signed certificate with one validated by a Certificate Authority

or

2. Add the self signed certificate to the list of trusted certificates on the system where the .NET code attempting to connect to SugarCRM is being executed.