Pages

Thursday, February 7, 2019

SugarCRM DevOps: Compression

Question: Which would download faster, a 3.5 MB sized file or one approximately 500 KB in size?

It is not a trick question. Without a doubt, our expectation would be that the smaller sized file would download faster, regardless of the speed of our network connection to the server. But how can we reduce the size of payload if we cannot trim the actual contents? A quick and easy way to reduce the size would be to compress the content to be sent in the response.


If we apply this principle to Sugar, the compression of payloads sent from the web server to the browser would result in a snappier user experience, due to faster retrieval of data and other necessary components. As a general rule of thumb, we should always implement a compression methodology in order to help us achieve the best experience possible.


But how can one determine if compression is enabled and being utilized by the web server hosting a Sugar instance?

The image in Figure 1.1 helps us answer that question.


Figure 1.1: Example ListView response

To answer our question we must examine the web requests exchanged between our web browser and the web server. This can be easily accomplished within Chrome by accessing the Developer Tools and reviewing the contents of the Network tab, as illustrated in Figure 1.1.

Wednesday, May 23, 2018

SugarCRM: More Customization Tips

In a previous post on the subject of customizations we explored some general tips and advice that help us avoid a variety of problems. We will continue this discussion, but this time around we will focus on JavaScript. More specifically, we will focus on the manner in which one can handle responses to requests made to the Sugar REST v10 API.

One may have a need to send such a request to:
  • Read an existing record
  • Update a record
  • Load a collection 
The Sidecar framework provides mechanisms for performing all of the above, such as beanObject.fetch(). However, the process for handling responses these methods generate is not readily obvious. Quite often, there is a tendency to rely on raw JavaScript to address such needs, for example, interacting with the xhr object as such:

object.xhr.done()

Rather than using raw JavaScript, one should leverage the parameters that can be defined as part of the method. In the case of .fetch(), it would look similar to the following:


As illustrated in the code, an anonymous function is defined for the success: parameter. This is the code that will be automatically executed upon a response being received and is capable of interacting with the JSON response -- found in the data variable. 

Note that a similar approach can also be used to define an error anonymous. 

Wednesday, November 22, 2017

SugarCRM: Related Data Interactions

Often times a customization we are working on requires us to interact with related data, usually records that are children of another. For example, a customization might require us to determine if a given Account record has 1 or more related Contacts. Or for that matter, we may need the collection of ID values that represent all the Calls linked to a Contact.

In either example, the path most often followed could be described with the following pseudo-code:

1. Instantiate the parent SugarBean object (e.g. Account/Contact record object)
2. Load the corresponding relationship to access the related data objects
3. Retrieve the related SugarBean objects representing the related objects

See below for a PHP snippet illustrating the above:



Line 12 in the above example would effectively create an array of SugarBean objects representing the linked Contacts. From that point forward, determining whether or not the Account has any linked Contacts becomes a simple matter of checking the size of the array. 

For the linked Calls example, the code would be very similar, except we would load the 'calls' relationship and the ID values we want would be in the SugarBean object array that results from executing the getBeans() method.

Now, all of the above would function just fine, but let us consider a few things about this approach.