The power of the Salesforce Sales Cloud Connector in Open Connectors

In this blog you will learn about what makes the Salesforce Sales Cloud Connector in Open Connectors so unique and powerful, and how it will save you a lot of custom integration work when integrating to Salesforce.

You’d think that a cloud based company like Salesforce would set the standard with respect to their API specification – and in may ways they do – but like every other cloud application, Salesforce has its own set of API nuances.

What’s unique about the Salesforce Sales Cloud Connector?

First: All of the Connectors within OCN standardize “GET” resources to GET /<resourceName> with the response being the full set of fields for that object returned in the JSON payload. This standardization makes GET /<resourceName> consistent and predictable across every Connector in OCN.

So, for the Salesforce Connector, a few examples of the available GET resources are:

And the expectation is that when those resources are called, ALL (non-null) fields associated with the object are returned in the response JSON payload.

However, the native Salesforce API specification requires that the set of fields that you want returned for a given object be specified in their GET /sobject resource call. 

Issue1: The Salesforce native API does not allow for a GET /contacts where all the fields for a contact are eligible to be returned.

Issue2: The Salesforce native API does not allow for an open query like select * from contact; the specific fields names are required as part of the select request.

Thus, the Salesforce Sales Cloud Connector has to accommodate and automatically determine the full set of fields to return from a GET call.

To solve this, Open Connectors, via the Salesforce Connector, automatically introspects the metadata for the desired <objectName> and thus gets the full list of fields available for that object – including any associated custom fields. The Connector assembles the query based on the Salesforce standard – specifying the full set of field names – and thus can return the full set of possible fields from a GET /<objectName> request.

What the Connector does:

1. The Salesforce Sales Cloud Connector automatically makes two requests for every GET /<objectName> request to Salesforce – standardizing so that the developer using the Open Connectors API doesn’t have to code this uniquely to support a Salesforce Sales Cloud integration.
2. If there is a custom field added to an object, the GET resources for the Connector will return those automatically, eliminating code changes that are normally required to return those when integrating directly using the native Salesforce Sales Cloud API.

Example of GET /contacts in Open Connectors:

GET /contacts returns the full payload of native fields directly from Salesforce. The Connector is actually making two calls in order to standardize the GET /contacts call, and return all possible fields as JSON (that have values):

Second: The bulk data resources in the Salesforce Sales Cloud Connector makes up for file size limits imposed by Salesforce – removing the burden of “chunking” large bulk files in your integrations.

This is a really handy feature that saves time and puts the onus of securely managing large files on Open Connectors.

Issue: The Salesforce Sales Cloud API specification requires when using their native bulk (aka batch) API resources, that the upload is done in batches of <= 10,000 records. Thus, if an integration requires batches of greater than this amount the developer will need to put the required code in place to split the data into chunks of <= 10,000 records and batch load each chunk individually. This can get complex requiring multithreading, handling errors, and so forth.

What the Connector Does:

1. To solve this, Open Connectors automatically splits the file and handles the multiple batch requests via the Salesforce API resources. For example, if the bulk upload request is for 100,000 records, Open Connectors will chunk it into sets of 10,000 records, multithreading each as separate requests to the Salesforce batch API resources.

Handling large bulk uploads via the Salesforce Sales Cloud Connector eliminates the need for a developer to compensate and code a framework to handle the required file splitting based on the limits imposed by the native Salesforce Sales Cloud native APIs.

Using the standardized Open Connectors Bulk API resources also enforces encryption and meets data compliance requirements as the chunked file records are encrypted and are auto-deleted when the request is completed (treated as transient data).

Tech Hints for using the Salesforce Connector’s /bulk resources:

1. Consider using the Bulk API if you are managing over 2000 records.
2. The Salesforce bulk chunking mechanism allows you to use bulk on large data sets without limitations. If you use an orderBy clause, chunking is disabled. If chunking is enabled, it may take longer to get all the data. Also, be aware that Salesforce has daily upload and download limits.
3. If you encounter record lock issues when performing bulk uploads, you can try serial mode instead of the default parallel node. See the Salesforce documentation topic General Guidelines for Data Loads for more information about parallel and serial modes. To switch to serial mode pass “concurrency”:”serial” in the request metadata.

Third: If you are using the Salesforce Connector to retrieve events from Salesforce, you have two options: 1) Use Salesforce’s webhooks or 2) Use the Connector’s polling framework to query for changes to objects in Salesforce.

Issue: To enable events in Salesforce, your Customer’s Salesforce Admin will need to add in Apex code to generate the webhooks. That is not always an option depending on your customer’s security restrictions, but regardless, it does require code “intervention” and is not automated.

What the Connector does:

1. The Salesforce Sales Cloud Connector provides a choice – use Salesforce’s webhooks or use the polling framework that it has built in, and which will also generate a webhook back to your application.

Thus, if automation is critical for your use case and you’ll be creating Salesforce Connector instances using Open Connectors’ APIs, then using the poller capability is nice option.

Note that when the poller queries and if finds changes to the requested objects since it last polled, it will send a webhook to the URL of your choice! So, in a way, the Connector “webhookifies” the Salesforce API without the hassle of coding APEX into your customer’s Salesforce account instance. Handy!

In closing, the Salesforce Sales Cloud Connector in Open Connectors adds value over and above the native Salesforce API specifications. Depending on your use case, it will save you time vs. writing custom code directly to Salesforce’s API specification AND it will be consistent with how the other 150+ connectors in Open Connectors work.

More blogs coming soon! Next, I’ll step you through how to build your own Connectors in OCN, complete with videos.