With the introduction of Salesforce Connect customers can de-risk integrations with external systems. However, in order to make use of this feature your data source must be OData compliant. In this post we discuss what the options are when your external system is NOT OData compliant.

What is OData

OData (Open Data Protocol) is a standard that defines best practices for defining and consuming RESTful APIs. The goal of OData is to free up data by providing a consistent metadata description of your data model. Using this machine readable metadata, other clients/systems/apps can perform CRUD operations against data held in a database.

OData uses mature web technologies for maximum interoperability. It uses HTTP, JSON/Atom and URI. For more information check out odata.org

Custom OData Services

Whilst some of the large Enterprise Applications (SAP and MS Sharepoint) expose OData services its quite rare for a legacy application to be OData complaint without some extra component. Even Salesforce, which provides the ability to consume data via OData using Salesforce Connect doesn't exposes CRM data natively as OData complaint (there is however great API support using either the REST API or SOAP API - the available Salesforce Connect Adapter for connecting to other Salesforce orgs uses the REST API).

Salesforce Connect is the product feature that enables you to consume OData services inside Salesforce. What this essentially means is that your users can perform CRUD operations on data that resides outside of salesforce natively from within the salesforce ui. This is very powerful if you think about it for a second, it means in order to integrate with an external system all you have to do from a salesforce point of view is configuration, no complicated integrations to build. But what if your data source is not OData complaint and you would still like to integrate it with your Salesforce org. You have two options;

  • Build the integration using custom code or some sort of middleware tool.
  • Create custom OData web services which expose your legacy data.

You may ask what the benefit of option 2 is when it involves custom development anyway. The simple answer is interoperability. Moving your legacy data to OData complaint services ensures that any other future applications can use this data with little development effort.

If your data is not OData complaint however you would like to make use of Salesforce connect you have two options:

  • Build a Custom Adapter using Apex - this type of implementation will mean that only Salesforce will be the only system which can access the data source using OData standards.
  • Use a middleware tool to expose your data source in an OData complaint format.

In the next post we will discuss in more detail how we can use Mulesoft to expose our legacy data to so that we can make use of Salesforce Connect.