Pages

Wednesday, May 4, 2016

SugarCRM Troubleshooting: Still Loading...

Some months back I posted an article that spoke to a problem that caused Sugar to get stuck at a "Loading..." message. As discussed in that post, the culprit usually revolves around the rewrite module or its configuration.

In recent months, however, some Sugar customers reported puzzling situations where the Loading... problem could not be resolved through corrections to the rewrite configuration. Adding to the bewilderment was the point that the configuration of these environments seemed to be in order. For example, PHP versions and configuration seemed to line up with recommendations provided by SugarCRM. 

Eventually, after much effort from several folks at SugarCRM, the source of the problem was finally revealed. It turns out that late last year, the JSMin PHP extension was modified and updated to version 2.0.1. The changes in this new version of JSMin introduced an incompatibility for Sugar, which in turn causes the Loading... problem. Note this is usually accompanied by errors in the JavaScript console.

If you are encountering the Loading... issue and have already completed the steps to verify and/or correct the potential rewrite issues, double check your version of the JSMin extension. You can check the version by taking a look at the JSMin section of the output from phpinfo().

Should you have version 2.x of JSMin installed, you can correct the problem by:


  • Downgrading your version of JSMin to 1.1. Please note that if you are installing via PECL, you will need to specify the version you wish to install or it will install the latest version (2.x). To ensure it installs version 1.1, use the following command: pecl install jsmin-1.1.0
  • Disable the JSMin extension. Sugar does not require this extension for proper operation. The JSMin extension is used in a limited capacity as it helps expedite the process that minifies JavaScript code used throughout Sugar. Its absence will not cause that process to fail, only reduce the speed at which it completes, thus, it is perfectly safe to disable it.
Hope this helps.

Friday, February 26, 2016

SugarCRM: Bulk API Explained

Recently I have found myself in various conversations revolving around the topic of the Bulk API and its capabilities. These conversations have helped highlight various misunderstandings relating to its functionality, which I believe are the result of a lack of documentation on the subject. Hopefully this post will help clarify some of the more common themes.

To begin with, let us discuss what the Bulk API is not.

It is not a separate interface to Sugar. It is merely another endpoint of the existing REST v10 API. In short, the moniker Bulk API is a misnomer, as the term is just referring to a component of the REST v10 API, not an alternative to it.

Quite regularly I also hear of attempts to use the Bulk API to perform mass insertions of data. For example, migrating hundreds of thousands of records from another system and into Sugar. While the Bulk API can help expedite the process, it is not specifically designed for that task and its benefits for that type of work are limited. 

What is the purpose of the Bulk API endpoint?

The Bulk API endpoint aims at helping developers reduce the quantity of web requests sent to the REST v10 API. By reducing the number of requests necessary to complete a programmatic task, the time to completion can also be reduced.

The following example helps demonstrate its value quite well.

Monday, August 10, 2015

SugarCRM Quick Hit: SugarBean and JavaScript

Sometimes in the course of customization work we may be performing within Sugar we may have a need to load one or more records from a module. 

For example, we may need to load an entry from the Calls module. Or, as demonstrated in a recent example I posted, we may need a set of records from the Leads module.

The Sidecar framework in Sugar 7 makes this process quite easy via the app.data namespace. Here are a few examples that should help.

To load a single record from a given module:

var myRecord = app.data.createBean('Leads', {id:<record_id>});
myRecord.fetch();

Loading multiple records from a given module:

var myRecords = app.data.createBeanCollection('Leads');
myRecords.fetch();

Note the use of the fetch() method in both examples. It is used to actually instruct Backbone to execute the necessary calls to request the desired data via the Sugar REST v10 API. 

In the case of the first example, the JSON object passed as the second parameter ({id:<record_id>}) allows us to specify the ID of the record we wish to retrieve. However, in the second example, you will notice we are not specifying a similar property. 

When executed, the second example retrieves the first page of the same set of records that would otherwise be displayed to the current user should the user instead access the ListView for the same module. By default, that would be the first 20 records accessible to the current user, ordered by date_modified, descending.

But what if we wanted greater control over which records or fields are retrieved? That brings us back to the fetch() method mentioned earlier.

The fetch() method allows us to specify a number of additional parameters, including: filter, fields, success and others.

Here is an example of where the fields and filter parameters are defined and used to retrieve only the id and status fields for those leads created within the current month.

var leads = app.data.createBeanCollection('Leads');
leads.fetch({
        fields: ['id', 'status'],
        filter:[{'date_entered':{'$dateRange':'this_month'}}],
    });

Hope that helps!