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?