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.

SugarCRM Troubleshooting: Those Pesky 500 Errors

Many of us have at some point come across the dreaded Internal Server Error 500 message while routinely visiting random web sites. 

For web site visitors, it can be a frustrating experience, especially if the error is occurring on a page one needs to access to obtain important information. For system administrators, this error is even more frustrating as there is no universal solution to the problem.

Given that SugarCRM is also a web based system, it should be no surprise that it is possible to experience similar errors while using it. Before we get into some of the potential sources of this error, let us take a moment to discuss some items you can quickly cross off your list as potential sources:

1. The web browser. When an error 500 is encountered, it will manifest itself in the same manner on all browsers, whether it be Firefox, Chrome, Internet Explorer, etc. This is because it is a server side problem, thus there is no need to test different browsers.

2. The operating system. As described in the previous point, it is a server side problem. As a result, changes in either the browser or operating system at the end user side will not help alleviate the problem.

Now, let us explore some potential causes for this error.