Matt Marum

TethrOn presents their Sugar Integration process

Blog Post created by Matt Marum Employee on Nov 9, 2015

About TethrOn

TethrOn is a mobile field sales and service enablement platform that has a number of different pre-built integrations to back-end systems. The team behind TethrOn recently decided to become a SugarCRM Technology Partner in order to provide connectivity to Sugar with their mobile platform. Their architect gave the experience rave reviews:
Sugar was by far the easiest CRM system to integrate in our experience to date. This is mainly due to the robust set of APIs provided out of the box to support integrations over REST combined with clear documentation on best practices for extending the Sugar v10 REST interface.   In addition, what is provided out of the box is well thought out with respect to useful integration patterns.


TethrOn created a proof of concept in 3 weeks and released their production Sugar connector in just 8 weeks!



If you want to learn more about TethrOn, please visit David Valko from aMind Solutions, the company behind TethrOn, shares the successful pattern they applied for building their integration to Sugar.


Methodology for integrating with Sugar


Integration to our TethrOn platform is achieved through the construction of “connector” module that conforms to a uniform interface that TethrOn understands. That module must implement all data operations supported. Here are the 4 steps we followed for rapidly building the SugarCRM connector for TethrOn.


Step 1: Understand the Integration Points that Sugar provides for you 


Our development team did not have a lot of exposure to SugarCRM, however due to the robust content available on SugarCRM usage, development and integration, our team was able to come up to speed rapidly. We leveraged the many hours worth of recorded online tutorials from Sugar University, as well as online documentation such as the Sugar Developer Guide and other helpful online resources.


Specifically in our case, the v10 REST API was a match to our needs, so after grounding the team in Sugar usage and development, we focused much of our attention on the specification for these APIs to get a complete picture of what capabilities are accessible using this method.


Step 2: Build the sequence of events and validate


To ensure our design was viable, we identified the sequence of API calls that would need to occur to complete each of our integration scenarios. From that we constructed actual calls to the SugarCRM RESTful APIs using a REST client (like cURL or Postman) to ensure our design would function as desired.   These sequences of calls were then translated into actual implementation code and corresponding tests used with our continuous integration environment.


Step 3: Identify any gaps in the Sugar RESTful API and extend the APIs only as necessary


Over 95% of the functionality we needed was already available in the v10 REST API.   Building out the sequence of events as outlined above helped us to identify the remaining 5%. For these cases, we established a SugarCRM deployable package for our product. The package contains the additional web service endpoints we needed to complete our integration scenarios and is now available through Sugar Exchange.


For steps on how to create and modify SugarCRM service endpoints, we followed the instructions for Extending Web Services from the Sugar Developer Guide.


Step 4: When extending Sugar, follow the best practices


The documentation for extending web services describes in a step-by-step way what is needed to create or modify REST endpoints. However, it is also important to keep in mind other constraints in play that could affect the design of your custom endpoints:


In the case of compatibility with Sugar upgrades we took an approach that ensures we make as few assumptions about the current state of Sugar as possible. Specifically we followed these rules:

  • When extending Sugar avoid changing any core code of Sugar
  • Add only the minimal set of new endpoints needed to support the integration scenarios.
  • Given the option of using a “lower level” API or a “higher level” API, choose the “higher level” API. Example: where possible use SugarQuery instead of raw SQL queries to implement your endpoint.


Regarding the restrictions on PHP code in Sugar OnDemand environments, we found the most practical approach was to deploy our package to the SugarCRM On-Demand environment provided to us as a SugarCRM Technology Partner and configure our continuous integration tests to run against that environment.


Additional best practices for SugarCRM Package development can be found at in the Sugar Exchange Package Guidelines.