Tuesday, February 24, 2015

SugarCRM Customization: Custom Blur Event

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:

I hope you find it helpful!

Tuesday, January 27, 2015

MS-SQL Quick Hit: Listing Field Definitions

Some months back I wrote about some important performance gotchas pertaining to using SugarCRM on Microsoft SQL Server (MS-SQL). More recently I had a need to analyze a system to uncover the source of similar issues. 

While doing so, I came up with an SQL query that helped me quickly view all  the column names and their definitions, simplifying the process of identifying potentially problematic entries.

I share this query below in hopes it will help you at some point:

select,,, c.max_length, c.precision, c.scale, c.collation_name 
from sys.columns c
join sys.types t
on c.user_type_id = t.user_type_id
join sys.tables ta
on c.object_id = ta.object_id

Note that with some minor modifications you can get the query to list out the columns of a specific data type.

Thursday, November 13, 2014

SugarCRM Diagram: Multiple Server Deployment (Basic)

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.