Organizations of all scales are stepping into the digital age. It is but natural that they would need to compete and get their share of pie of business. Today’s consumer is constantly searching for information across channels. For example, to buy an electronics people visit stores, compare brands and check their prices online in marketplaces. Customer’s review, product specifications and associated multi-media play an important role in buying decisions.
Check out why our SugarCRM developers are rated so high.
It can be noted that a single software cannot meet ever-growing, ever-changing needs of today’s organizations. Hence best of breed applications in each sphere are leveraged and integrating them becomes an absolute necessity. In this article we will explore how a custom SugarCRM API can be written for a specific business need.
Read how we integrated open-source CRM application with SAP one of the most complicated ERP system and saved our customer with thousands of dollars literally.
Understanding SugarCRM integration / API evolution and architecture
SugarCRM being a web application supported both SOAP and REST API, but citing security feature upgrades provided by REST API, with the release of SugarCRM 7.0 support for SOAP API has been deprecated and now only REST API is being supported.
SugarCRM implements Extension Framework to handle multiple levels and multiple types of APIs. Such implementation extends the validation over the API generically, providing blanket cover for ACL control over all the modules requested over the API, ensuring role and access control for all scenarios.
Types of API within SugarCRM
For the scope of the article we will differentiate API by the target for the API. The target for an API in the SugarCRM can be the instance application itself or a module in the instance.
Basically an application targeted API interacts with the other application at the overall application level, for example application / instance login and logout; where as a module targeted API work at the module level, like create / read / update / delete.
In this article we will see both kinds of APIs, and some basic code reference to implement them. This will help you gain a good confidence in both these varieties.
Application level API
At application level, an API is created if it is independent of any module level action i.e the external application doesn’t need to have direct access to manipulate the data in any of the modules, a possible scenario is, if the external application needs to access the functionality of a SugarCRM vendor.
For example, if a credit card number validation is implemented in SugarCRM and the external application (let’s say a client portal) needs to access the feature, then the API should be maintained as an application targeted API. The code for the same can be something as the following:-
File path : <>/custom/clients/base/api/<filename>.php
<?php
if (!defined('sugarEntry') || !sugarEntry)
die('Not A Valid Entry Point');
class CC extends SugarApi {
public function registerApiRest() {
$api_list = array();
$api_list['check_cc'] = array(
'reqType' => 'POST',
'noLoginRequired' => TRUE,
'path' => array('CCUTILS', 'check', '?'),
'pathVars' => array('', 'util_activity', 'card_number'),
'method' => 'check_cc',
'shortHelp' => 'check the cc number provided to be valid',
'longHelp' => ''
);
return $api_list;
}
public function check_cc($api, $args) {
#code to business logic...
}
}
Module level API
Complementary to application level API, all module specific actions / functionality will be implemented in a module level API. For example, a file in SugarCRM’s document module needs to be sent for e-signature to a third party website, in such a scenario the API needs to be provided at the module level and not at the application level, however a work around is always possible to implement the same logic as an application level API, the code for this would be as follows
File path: <>/custom/modules/Documents/clients/base/api/PostEsignDocuments.php
<?php
if (!defined('sugarEntry') || !sugarEntry)
die('Not A Valid Entry Point');
require_once("clients/base/api/ModuleApi.php");
class PostEsignDocuments extends ModuleApi {
public function registerApiRest() {
$api_list = array();
$api_list['link_modules'] = array(
'reqType' => 'POST',
'noLoginRequired' => FALSE,
'path' => array('Documents', '?', 'esign'),
'pathVars' => array('module', 'record_id', 'action'),
'method' => 'relate_documents',
'shortHelp' => 'send the file related to document record_id to 3rd party esign',
'longHelp' => ''
);
return $api_list;
}
public function relate_documents($api, $args) {
#custom business logic ...
}
}
Conclusion
With APIs in play, the organization comfortably can grow their needed network of apps to support their business, without compromising on the integrity of the business logic already implemented and still leaving enough scope to introduce new apps to the network for the upcoming future
Evaluating SugarCRM for your business – We can help
Reach out to us so that we can assess and plan a road-map for your CRM implementation. Let’s build a system, which you will use for years to come.
