This is the first of a six post series on Salesforce Connect. Today we focus on how to set up an OData service, configure Salesforce to use it for Salesforce Connect, and configure Relationships between objects.
Introduction
Integrations with backend systems are quite often the most challenging facets of solution development on the Salesforce platform. To seamlessly integrate real-time backend data requires a significant amount of VisualForce, Apex, or Lightning Component development. The alternative approach of running scheduled jobs to replicate data into the platform can result in a stale view of data and can adversely impact the organization’s data usage limits. An often overlooked integration strategy? Salesforce Connect.
Why Salesforce Connect?
Salesforce Connect allows you to expose third party services directly into the Salesforce application and surface the data as External Objects. External Objects are similar to Custom Objects; however, the data is not stored on the platform. Salesforce will issue data requests and queries the underlying service on an as-needed basis to fetch the data in real-time. To the end user, an external object looks no different than any other custom object. It is, therefore, possible to seamlessly integrate ERP, Policy or Claim data in Salesforce without needing to resort to data replication.
See this Trailhead for more information on configuring Salesforce Connect.
The Salesforce side of Salesforce Connect is actually the simplest part. If an appropriate service is available, configuring the Salesforce side of it is relatively easy. The most challenging part of fully leveraging Salesforce Connect involves deploying compliant services that Salesforce Connect can effectively call.
OData
The best way of exposing 3rd party services to be consumed by Salesforce Connect is to expose them as OData compliant endpoints. OData is an open standard that allows object definitions to be published, queried and updated. The OData specification and metadata describes object relationships, simple and complex types, and a query language. Although custom implementations can be built instead of exposing them as OData services, OData has the following advantages:
1. It is an open standard. Salesforce supports OData v2 and v4 endpoints. Other enterprise applications may also support OData, and Middleware tools often include OData connectors. By exposing the endpoint as OData compliant, it can be reused throughout the organization — not just by Salesforce.
2. Java, Javascript and .NET libraries (amongst others) have already been built to support OData. This limits the scope of what needs to be custom built and tested.
3. The spec will continue to evolve. As Salesforce supports new features, developers will be able to leverage them.
An Overview of the Blog Series
This blog series will focus on ground up development of an OData compliant service using the Apache Olingo v4 library written in Java. The process will involve creating a simple application that simulates the integration with a backend insurance system.
The series will be broken down into 6 parts.
Post 1: Set up an OData service, configure Salesforce to use it for Salesforce Connect, and configure Relationships between objects.
Post 2: Add the ability to filter the data and show the impact in Salesforce with related lists that can act on those filters as well as SOQL queries and Reports.
Post 3: Add the ability to write the data to the backend. Configure field level and object security to prevent updates as needed.
Post 4: Add security to the connection and objects to make sure that all data is properly authenticated and highlight the pros and cons of different security options.
Post 5: Packaging of Salesforce Connect as part of your ISV/OEM solution.
Post 6: Considerations, best practices and limitations.
Object Model
The External Data Source has the following object model. The four external objects are indirectly linked to the Salesforce Account and Contact objects.
In addition, two modifications to standard objects are needed:
To have the Accounts and Contacts linked to the external objects, set the following values on selected records:
Video
Summary
Data integrations between different platforms are a key architectural challenge that are a reality for any solution or technical architect. The traditional solutions involved either complex (and often expensive) middleware or brute force, developer driven integrations. Just over a year ago, valuing “clicks not code,” Salesforce Connect was launched to provide a configuration driven method of connecting external databases to Salesforce. This six part series will look at the many aspects of using Salesforce Connect as an enterprise customer as well as a Salesforce ISV needing to package the integration.
No one knows the Salesforce ecosystem as well as CodeScience. As the first PDO Master, we’ve brought 220+ products to market on the AppExchange. We can help you.
Resources
CodeScience is proud to be the first Salesforce Master Navigator PDO. Put our expertise to work for you. Learn more at www.codescience.com/services.
