Pages

Tuesday, February 24, 2015

One of the ideas that I regularly try to convey when talking about the customization capabilities of the Sugar 7 framework relates to leveraging JavaScript wherever possible. This is especially true for projects where our objective is to upgrade heavily customized versions of Sugar up to version 7.x.

In the pre-7.x world, some customizations that can now be implemented natively via the Sugar 7.x framework used to require the use of SugarLogic functionality or inclusion of third party JavaScript libraries. The case of SugarLogic can be particularly problematic if one utilizes a large number of such customizations, as it might imply the execution of additional server side code. The greater the number of these type of customizations and the greater the potential to introduce performance problems. This is also true for logic hooks. For example, a hook that automatically converts the last name field to upper case upon a record being saved.

If we step back and analyze these customizations, we would likely find that some could be implemented via JavaScript. Doing so would in turn offload some of the server load to the client -- likely helping correct performance problems. The latter example of the logic hook upper casing the last name field is a good case in point.

Suppose we wanted to convert such a customization to implement it through JavaScript instead of using a logic hook. How would we do that?

The general idea would be to use a standard onBlur() event, tied to the last_name field of a module such as Contacts and then automatically updating the content of that same field when focus is lost.

As it turns out, the Sugar 7.x framework makes this a very easy task. The code for making such a customization is found below:

Thursday, November 13, 2014

A few weeks ago we looked at an example of a very basic topography one can use to deploy Sugar 7. Along the way we also looked at the advantages and disadvantages of such configurations. Today we will look at a slightly more complicated setup.The diagram below illustrates a deployment implemented across multiple servers. While there are many variations to this concept, the one illustrated in this diagram is the most basic.

Sugar 7.x Multiserver Deployment

You will notice there are three different servers in use by this model. Despite this fact, all SugarCRM users only directly access one of those servers, the web server.

This is an important point, as it directly affects the security of the system. Using a multiserver configuration similar to that depicted in the image above allows us to limit access to the Elasticsearch and MySQL servers to only the web server. Those restrictions can be easily implemented through firewall rules.