One Way To Index ElasticSearch In Sugar 7

Edit (8/20/14): As Cédric Mourizard mentioned in the comments, if you have access to CLI you can simply run the following command to trigger an indexing of ElasticSearch. The method explained in this article is geared toward triggering an indexing via the API in scenarios where you may not have access to the CLI.

$ php silentFTSIndex.php

Like many, I’m comfortable with the ETL tools that I have been using in Sugar for years now. While many ETL tools support Sugar’s SOAP API (and a couple support the new REST API), I often prefer working directly with the database as it’s a much quicker way to move large amounts of data due to bypassing business logic such as workflow rules and logic hooks.

Things changed in 7. With ElasticSearch now being a requirement of Sugar, doing database work can have some undesired effects in regards to search and activity stream functionality. They simply do not work if data has been imported directly to the database.

One way I have found to update ElasticSearch after doing an import directly to the database is to interact with the bean within Sugar or using the API.

I think it’s safe to assume that our goal as Sugar developers is to automate tedious tasks so that users (and us developers) can work more efficiently. Indexing ElasticSearch is certainly one of those tasks.

That said, I find writing a script using the Sugar 7 Rest Client to be a quick and easy way to index ElasticSearch after performing Sugar 7 database work.

Here is a quick example of using the Sugar 7 Rest Client to do just that.

Have a better idea? Please let me know in the comments below!

Sugar 7 API Wrapper Class Updates

Previously, the wrapper class was… well… just that, a class. Working with custom endpoints was awkward and felt hacky. The more I dived in to Sugar 7 customization the more I realized I needed something more flexible and future proof.

That something is, at the time of this writing, the latest push to github.

Now the wrapper class is now a facade to a more powerful rest client. The reason for going this route was to keep the class intuitive but also allow a developer more flexibility. Prior to this latest push to github, in order to support a new endpoint a new method in the wrapper class had to be coded. Now, with a simplified rest client and improved facade you can easily work with custom endpoints and endpoints that have not been defined in the wrapper class.

Does this mean new features? Of course!

There have been 4 new methods added to the wrapper class. Those 4 methods allow you to interact with any endpoint that is not covered by the wrapper class. This includes both custom and stock endpoints.

Examples of these endpoints are:

$sugar = new \Spinegar\Sugar7Wrapper\Rest();

/* Get Endpoint*/
$arguments = array();
$result = $sugar->getEndpoint('MyCompany/MyAddon/MyGetEndpoint', $arguments);

/* Post Endpoint*/
$arguments = array();
$result = $sugar->postEndpoint('MyCompany/MyAddon/MyPostEndpoint', $arguments);

/* Put Endpoint*/
$arguments = array();
$result = $sugar->putEndpoint('MyCompany/MyAddon/MyPutEndpoint', $arguments);

/* Delete Endpoint*/
$arguments = array();
$result = $sugar->deleteEndpoint('MyCompany/MyAddon/MyCustomDeleteEndpoint', $arguments);

Nifty, right? Enjoy!

Introduction to the Sugar 7 API Wrapper Class

In a previous post I showed you how to use Guzzle to interact with the new SugarCRM v10 API. Today, I would like to introduce you to an even easier way to utilize the new API, the SugarCRM REST API Wrapper Class.

Installation and Instantiation

Installation of this package is handled with Composer. Start by updating composer.json with the following information.

Next, install the package via Composer.

With the SugarCRM REST API Wrapper installed and auto loaded, we can now instantiate the class and authenticate against our SugarCRM instance.


Common Usage Examples

1. Searching for an account by Name.

2. Alternatively, we can retrieve an account by ID.

3. Retrieving a list of cases associated to an account.

4. Create a case and relate the case to an account.

5. Listing notes associated to a case.

6. Listing documents associated to the account. (Compare to using Guzzle without the wrapper class)



There you have it. Using this new wrapper class is very simple and involves much less code than using cURL or even Guzzle to interact with the new API. That said, the wrapper class requires Guzzle and will install it via composer for you.

Are there any other examples you would like to see? If so, please comment and I’ll update this post accordingly.