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.

SugarCRM 101: Elasticsearch

I recently found myself doing an extensive amount of work relating to Elasticsearch. While doing so, the usefulness of the O'Reilly Elasticsearch book came to mind, along with the thought: it would be useful to have a list of helpful commands handy. 

So here it is, a list of commands that will hopefully help answer some of your questions on the manner in which Elasticsearch interacts with Sugar.

Before proceeding, there are some important notes to bear in mind. 

First, where referenced, replace localhost:9200 with the IP/address and port number for your Elasticsearch server. Secondly, the provided examples utilize the curl command line utility. Lastly, the name of the Elasticsearch index is derived from the unique_key value stored in the config.php file of your Sugar instance, thus [index_name] = unique_key. 

SugarCRM Diagram: Single Server Deployment

Technical concepts are often times easier to convey through images. One such concept that is more easily communicated in images relates to the idea of deployment topologies for SugarCRM.

Changes to the underlying server elements required for Sugar 7 have generated a number of questions in relation to Sugar deployments. This and other posts to follow will hopefully help answer some of these questions, as well as discuss some common pros and cons for each scenario.

For our first example, we will discuss the simplest deployment scenario, using a single server.

Sugar 7.x Single Server Deployment

In this diagram we see a single server being used to host the SugarCRM application. It is assumed that the hardware on that server would be adequate to support the load.

What are the pros and cons of such a deployment? Let us first take a look at the pros.

SugarCRM Customization: Dynamic RecordView

Recently the need to explore the topic of applying user specific fields to a Sugar 7 view made its way to my desk. With past versions of Sugar, this type of customization could be implemented by creating the user specific metadata definitions, a custom view with the logic that drove the selection of the metadata and some logic that flushed out the cache so as to force the new metadata to be displayed upon the view being rendered. Given my history with the topic, I was curious to see how different the process would be in Sugar 7.

For those of you that are new to Sugar 7, it is worth noting that the metadata for a given view is stored in a JSON object accessible through the namespace this.meta. Said object can be easily manipulated through the controller relating to that view, thus we can leverage this.meta to adjust the metadata for a given view.

In our example we will assume we have two different users that should be viewing different fields on the RecordView. User 1 is the default admin user, identified by the ID value of "1" within the database, and User 2 is the user Jim, identified by the ID value of "seed_jim_id" within the database. Our goal will be to modify the default RecordView on the Contacts module such that User 1 automatically receives the default set of fields upon accessing the RecordView, but User 2 receives a modified version of that view, i.e. a different set of fields, with some overlap.

How do we go about applying this customization?

SugarCRM 101: Email Delivery

Sometimes I find myself discussing topics relating to Sugar that are difficult to explain without leveraging visual aids. One of those topics happens to be that of the mechanics involved in the delivery of email messages.

In general, the ability to send email, whether ad-hoc messages or those sent through an email campaign, requires the interaction between Sugar and other systems. Because those other systems are not actually within the control of the Sugar application, broader questions pertaining to the delivery of email are sometimes not easily answered, or in some cases, cannot be answered, without leveraging information only available on the other systems. This is often a point of confusion as many folks often assume that all the relevant information is stored somewhere within Sugar, which is not the case.

This short video will discuss this topic in greater detail and hopefully help answer some of your questions pertaining to Sugar and its email delivery mechanics.

Enjoy!

Let Us Continue...

Last week we took a peek under the hood of Sugar 7 to learn about the location of some of its un-minified JavaScript code. Today, we will continue that discussion, except we will focus on core components of the Sidecar technology that makes up the new MVC client in Sugar 7.

Before we proceed, it is worth noting that Sidecar is a combination of open source JavaScript libraries, including jQuery, Backbone and Underscore, among others. Thus, when we talk about Sidecar, what we are really talking about is the consolidated result of these technologies. 

Bearing that in mind, the article referenced at the top of this post speaks to code relating to customizations that we can apply to change a portion of the MVC client. Another portion of that same client adds some magic behind the scenes to tie together the actions occurring on the interface with the backend.

Although we would not be modifying this code, it is worth studying it as it provides us some really good insights into the manner in which the Sidecar technology implements the Sugar object model and framework. But as with the previous post, this task is far easier to accomplish if we have access to the un-minified sources.

Below is a listing of files you should find helpful in your continued learning about Sugar 7 and Sidecar:

Sugar Object	Un-minified Source Folder
ACL, Controller, Metadata, User	/sidecar/src/core/
SugarBean, Validations	/sidecar/src/data/
Data Formatting, Logger	/sidecar/src/utils/
Handlebars Helpers, Views, Alerts	/sidecar/src/view/

Give those folders a look and share any gems you find within the comments.

The Issue of Legibility

Those of you that have been working with Sugar 7 have likely already noted that much of the JavaScript code utilized is minified. While that is a nifty trick to squeeze out some more performance, it makes code very difficult to read, such as the snippet inserted below:

({inlineEditMode:false,createMode:false,plugins:['SugarLogic','ErrorDecoration','GridBuilder','Editable','Audit','FindDuplicates','ToggleMoreLess'],enableHeaderButtons:true,enableHeaderPane:true,events:{'click .record-edit-link-wrapper':'handleEdit','click a[name=cancel_button]':'cancelClicked','click [data-action=scroll]':'paginateRecord','click .record-panel-header':'togglePanel','click .tab a':'setActiveTab'},buttons:null...

From the standpoint of a consultant, and one in charge of applying code level modifications to a given Sugar instance, having to unravel code like this in order to work on a customization is a bit of a nightmare. One is also put in a situation in which one has to rely on the use of JavaScript beautifiers and similar tools to display the code in a more legible manner. 

No need to worry, however. Legible versions of the JavaScript code that Sugar utilizes and in turn, minifies, are easily accessible, thus simplifying our work. The table below gives us a listing of the various file locations that might be of interest to developers:

Minified Files	Un-minified Source
/clients/base/views/	/jssource/src_files/clients/base/views/
/clients/base/layouts/	/jssource/src_files/clients/base/layouts/
/clients/base/fields/	/jssource/src_files/clients/base/fields/
/modules/<Module>/clients/base/	/jssource/src_files/modules/<Module>/clients/base/

In future posts we will take a closer look at other aspects of the file system that are equally important.

Have fun exploring!

SugarCRM Cookbook: Retrieving User Roles

One of the challenges relating to the adoption of any new technology is understanding the manner in which one accomplishes equivalent tasks based on our experience with previous versions of the same technology. Sugar 7 is no exception to this rule, and this challenge is perhaps its biggest within the development community.

With that in mind, lets talk about a recent situation I came across that very much speaks to this point. In short, in the course of talking about the 7.x technology, the question arose of how one would go about retrieving a list of Roles assigned to a given user. Because we have to do this through a JavaScript based controller, techniques we might have used in the past are no longer applicable.

For the purposes of our example we will assume that we wish to retrieve the list of Roles assigned to the currently logged in user, in turn allowing us to see some details about the manner in which we interact with the current user, also a common need and one that also differs greatly. 

The following Gist will allow us to retrieve the Roles:

NOTE: Roles are only accessible to Admin level users and as such, the above code would only function if executed by a user with Admin privileges. In turn, it would also be best to specify a particular user ID rather than relying on the current user. 

SugarCRM Troubleshooting: SugarCRM 7 Installs

Wow! - That was my initial reaction when I first saw early versions of SugarCRM 7.0 (Sugar 7) a little over a year ago. It reminded me of how impressed I was the first time I saw Sugar in its 3.0 days.

Fast forward to today and a lot of folks have had a chance to experience the same. New customers utilizing the SugarCRM OnDemand environment have had access to 7.0 for a few months. More recently, new on-premise customers utilizing classic LAMP stacks have also been able to take advantage of all the great new features in 7.0. 

As the with any new software release, as it gets exposed to greater quantity of users, certain patterns emerge relating to common problems users encounter. Sugar 7 is no exception. 

Perhaps the most common issue in the 7.0 world today is one where the install procedure completes without error, but after completion, the Sugar login page never displays. In its place, users will see the following:

It would seem Sugar never stops loading because the message never goes away. This is actually not far from the truth, but fortunately, there is a very simple fix to this problem. Before we look at the solution, it is worth briefly discussing the nature of the problem, as it is directly related to an important change that has been introduced into the Sugar architecture.