Skip navigation
All Places > Developer > Blog > 2019 > August
2019

Hi, my name is Julian Haresco and I am a Software Engineering Intern at SugarCRM. I am going to be a rising senior at Purdue University majoring in Computer Science with a focus in Machine Learning and Software Engineering. This summer, I was given the opportunity to integrate Amazon’s Beta EventBridge API with Sugar for SugarCRM to become one of Amazon's ten launch partners for the EventBridge.

 

What is Amazon EventBridge?

In case you haven’t heard, Amazon released a new product for its cloud services called Amazon EventBridge. This service is a new addition to the vast array of services offered within Amazon Web Services (AWS) but comes with a very special feature that I believe makes it stand out from other products offered by Amazon’s cloud service. EventBridge is unique as it allows you to utilize a third-party SaaS system to send CloudWatch Events to AWS. The biggest benefit of this product is the freedom it offers to customers. Since the Event Buses and sources are customizable based on region, they can view the events in their desired location and then have them interact with other AWS resources easily. Furthermore, prior to EventBridge, all AWS CloudWatch Events could only be triggered by another resource within AWS. So allowing them to connect to an external SaaS system simply allows for AWS to be more usable than ever before with data external to AWS.

 

Amazon has partnered with various SaaS companies to set-up what they are calling Partner Event Sources. These are SaaS systems with EventBridge Partner Event Sources integrated into their systems already for customer use. SugarCRM Inc. is one of the ten initial AWS EventBridge launch partners including Symantec, Zendesk, and SignalFx. For Sugar, this pre-installed integration builds a timeline within AWS based on the modules and logic hooks the developer desires. Empowering customers with a real-time log about how the records and relationships within their system are changing with every event sent.

 

Here’s how I did it

To meet these needs, a new administration module that is installed via a module loadable package was created named EventBridge Logic Hooks. Within this module, Sugar will automatically connect, or create, the internal “Partner event source” based on how the customer fills out the fields when creating a new record for this module. However, the values within the fields will need to meet the requirements outlined in our support documentation for Amazon EventBridge. This module then automatically creates a Sugar logic hook that will send an event to EventBridge using the Partner Event Source to the AWS account they provided once the specified module triggers the logic hook.

 

 

On the Amazon side, the EventBridge Console will automatically display the “Partner event source” with the same name displayed on the record created with Sugar. These event sources can then be attached to an Event Bridge by following Amazon’s instructions. Now our customers can attach the event source to the Event Bus. This allows them to target resources that best suit their needs.

 

 

How do developers get involved?

Developers who want to experiment with Sugar’s integration of EventBridge can download the module loadable package from SugarExchange and follow the instructions outlined with our support documentation for Amazon EventBridge to install the module. From there, developers should be able to effectively create and set-up Partner Event Sources and connect them to an EventBus within their AWS account. 

 

NOTE: This is a beta version so there are improvements that could be made. For example: The operations to Event Bridge are synchronous which may cause additional latency in save operations for enabled modules.

 

What has been our experience?

Amazon EventBridge has been incredibly easy to use in terms of creating, editing, and setting up the Partner event source within Sugar. As a developer, the documentation is clearly laid out and extremely helpful in finding the answers to any questions about configuring EventBridge within a SaaS system like Sugar. Furthermore, the EventBridge Console makes a clear distinction between a Partner event source and one I create on my own. This set-up is incredibly  intuitive and easy to use, providing a seamless set-up process from within Sugar to the AWS EventBridge Console on the customer’s side.

 

This project was just the beginning. AWS EventBridge opens up great possibilities for integration. I'll continue using it and looking for new ways to leverage this system. I hope you will too. So, please, take a look at AWS EventBridge. Connect it with Sugar. Then, tell us about your experiences in the comments.

We recently held a webinar on How to write code for SugarCloud. At the end, we gave a summary of some of the Dos and Don'ts for working with SugarCloud.

 

With more and more customers utilizing SugarCloud products, I thought it would be a good idea to expand on some of the basic best practices when developing for SugarCloud. As Sugar's cloud-based product line evolves, I will add more items to this list.

 

When developing for SugarCloud:
Don't

use custom code when configuration will do just fine.

The ability to write custom code for Sugar is a huge benefit. It isn't, however, the best solution for all situations. Very often your problem can be alleviated by simply using the configuration tools that Sugar provides in its admin console. Manipulating a configuration in the system is typically a safer choice as there is no concern with upgrade compatibility.

Don't

have direct filesystem or DB access.

SugarCloud is a shared environment. Any changes made to the filesystem could impact other customers.

Don't

use blacklisted classes, functions, or file types.

In order to maintain the integrity of the standard Sugar functionality when we upgrade a customer instance and limit any negative impact our upgrade has on the customer's modifications, all instances hosted on Sugar's cloud service have package scanner enabled. Here is a blacklist of cases that will cause the package scanner to fail.

Don't

perform load or pen testing without permission of Sugar Support.

SugarCloud is a shared environment. An unscheduled load test may cause performance issues with other customers' instances. You must obtain Sugar Support's permission so that they may make the proper adjustments to ensure no other instances are affected by your tests.

Don't

introduce performance or security issues with your code.

For the safety and security of your users, it is never wise to introduce performance or security issues into your code. This is especially true when working in a shared environment so as not to affect other customers' user experiences.

Don't

disable or circumvent package scanner.

Package scanner is enabled on all cloud instances to ensure no security violations are introduced.

Don't

allow an outbound HTTP connection to last longer than 1 second.

SugarCloud is a shared environment. Long connections can have a performance impact on your users as well as the users of other customers.

Don't

abuse the job queue with a multitude of long running jobs.

SugarCloud is a shared environment. Long running can have a performance impact on your users as well as the users of other customers. If you load the queue with too many long running jobs, the rest of the jobs awaiting their turn will be affected

Don't

abuse the REST API with more than 20 requests per second.

SugarCloud is a shared environment. Too many requests can have a performance impact on your users as well as the users of other customers.

Do

upgrade to every new release.

Sugar Sell and Sugar Serve operate on a quarterly update cycle while Sugar Market is updated approximately every two weeks. Each update will include new improvements or fixes from the previous version. It is important to keep up-to-date on these upgrades to minimize the number of things that will need to be tested. 

Do

test before you deploy!

It is always better to find any issues in a test environment prior to deploying live. If there are issues or incompatibilities after a change, these should be caught and addressed before a user runs into a problem.

 

Want to learn more? Don't miss the webinar recording.

In response to the recent evolution of the SugarCRM product line, we’ve compiled a list of answers to some common questions that we have received from the developer community about our new products. This FAQ will be a living document, so please post any additional questions in the comments section and we will do our best to address them here.

Sugar Professional and Enterprise customers: 

If you are an existing customer of Sugar Professional or Sugar Enterprise then nothing has changed for you. If you are in our cloud, you will still get new features on a quarterly basis. If you are on-premise, you will still get new features on an annual basis.

    
QuestionSugar MarketSugar SellSugar Serve
Will it be available On-Premise?No. Sugar Market, Sugar Sell, and Sugar Serve are available via cloud only and are not available for on-site deployment.
Can we write code customizations for it?The Sugar Market platform does not support direct code customizations. It does, however, have REST APIs and other tools to enhance your development.

Yes, Sugar Sell and Sugar Serve are based on the Sugar Enterprise platform which supports code customizations. You can use Module Loader to install code customizations for Sugar Serve and Sell. Since Serve and Sell are built on Sugar Enterprise, use the ENT flavor in your package manifests.

How can we download instance backups for local development and test?No, Sugar Market is a multi-tenant application. There is no concept of local development.Yes using Backups module.
Can we get data backup?Yes, by exporting a report.Yes using Backups module.
Can we access development builds?We are working toward a solution for this.There is a Developer Builds space in the SugarCRM Developers community. We will post development builds here for each release.
Will Sell/Serve/Market use the same platform as Sugar Enterprise?Sugar Market is a unique platform.Sugar Sell and Sugar Serve are built on the Sugar Enterprise platform.
Will Sell/Serve/Market be connected to the same database, or will they be separate instances connected via API?At this time, Sugar Market utilizes an independent database. Sugar Market integrates with Sugar Sell/Ent/Pro out of the box.A single SugarCloud instance and database can have both users of Sugar Sell and Sugar Serve using it at the same time.
Where can I find more specific info about the divergence between Sugar products?The differences between the SugarCRM License Types are outlined in the User Management section of the Sugar Enterprise 9.1 Administration Guide.
What resources are available if I have more questions?Sugar Market DocumentationSugar Sell DocumentationSugar Serve Documentation
How often will Sugar products be updated?

Sugar Market operates on a continuous update cycle, with releases approximately every two weeks.

Sugar Sell and Sugar Serve operate on a quarterly release cycle (every three months).