Skip to main content

Everything you wanted to know about Salesforce Lighting Connect (External Objects)



The world runs of Data. Having correct data can determine if your business succeeds or fails. Since the emergence of Cloud Computing, Data escaped its normal prison of sitting on servers and became relevant. But the most important aspect about cloud was data was not interchangeable. I.e., It escaped the prison but was trapped in a zoo. In a large organisation if there was a need for using more than one system to manage data, it became a development nightmare. Not to mention maintaining multiple connections and data consistency between two systems, middle-wares (if any) and still keeping it under the governor limits.

Salesforce Lighting connect lets you overcome this limitation by using the (soon to be) global standard OData protocol. With external objects you can connect to an external data source like SAP or any other database that uses OData protocol or a simple URL. What this means is you can have orders in SAP and customer Data in Salesforce. Both will be connected together and you can use it with very less or no effort.

oData - New Page (1).png


What is OData Protocol?
OData was first proposed by Microsoft and was released in March 2014 by OASIS (Organisation for the advancement of structured information Standards). In very basic terms OData is the common language in which the web will talk to each other. This is possible even today by using REST API and SOAP but these API are for processing information, having a separate protocol for only Data exchange helps in many ways. First, it is easy, as easy as creating your own object in Salesforce. Second, it is auto-synced between the two system.

How does Salesforce use this OData?
Salesforce has introduced a new concept called External Objects. Earlier we had external ID field that stored ID for external databases. This was very useful when loading Data but with External objects the data will be accessed from the external system and displayed in form of Salesforce. Thus keeping it in Sync. The following diagram illustrates the entire process.
oData diagram


What do we need to access external data?
Before we learn how to create an external object, let us look at what the external database should provide in order to make this connect happen.
There are two fundamental things we need to access the data. They are
Data should be in open format like oData.
It should be accessible via the internet (i.e., via cloud)
For security, it should support OAuth.

Do external object support SOQL and SOSL?
One of the most obvious feature of external object is ability to search them. We can use the standard SELECT, WHERE, LIMIT and OFFSET clause we are familiar with for SOQL with the external objects. Obviously it is limited to the external data service to provide accurate data.
For SOSL, the external objects support FIND, IN, RETURNING, WHERE, LIMIT and OFFSET clauses.

Does it support Relationships?
Where would we be without relationships? Yes, External objects support a limited type of lookup relationships like Basic Lookup, External Lookup and indirect Lookup.

Lookups:
The standard lookups that we currently used are extended on the external objects. The lookup to an external object do not support cascade delete or lookup filters.

External Lookups:
External lookups are created on Standard, Custom or external objects using the External ID field (and not the standard Salesforce ID)

Indirect Lookups
Indirect lookup are external objects that are child to Standard Salesforce objects using a unique External ID field.

However, a point to note that child records of external object will load depending on external database and network speed.

This is everything you need to know about external objects. In the next post we will actually create few objects and show seamless integration between two system. What do you think of lighting connect, have more questions? Post them in comments below.

Popular posts from this blog

The curious case of the custom redirection on Salesforce Console

Every developer worth their salt knows that the easiest way of redirection from a page to another is by using everyone's favorite function

public PageReference redirect() { PageReference pageRef = page.peskyProblemRedirection; pageRef.setRedirect(true); return pageRef; }
And the method is called by adding it to the Action attribute of the CommandButton or link, which works like charm and the user is redirected to the page after completion of the action.
So why am I going back to the basics? Because this way of redirection causes a pesky little problem in using the Service Cloud or Sales Cloud console.

Let's illustrate the problem, let's say you have a visualforce page as follows:

<apex:page sidebar="false" showHeader="false" controller="myExampleController"> <apex:form > <apex:pageBlock > <apex:pageBlockButtons > <apex:commandButton action="{!Redirect}&qu…

Some PDF tricks on Visualforce: Landscape, A4, page number and more

The beauty of Visualforce is simplicity. Remember the shock you received when you were told the entire page renders as PDF if you just add renderAs=PDF to the Page tag.

For those who thought I spoke alien language right now, here is the trick, to render a page as PDF, we add a simple attribute to the <apex: page> tag

<apex: page renderAs='pdf'> This will render the entire page as PDF.

Now, say we need to add some extra features to the PDF. Like a page number in the footer or we need to render the page in landscape mode. Faced with this problem, I put on my Indiana Jones hat and went hunting for it in the vast hay-sack of the internet (read: googled extensively). Imagine my happiness when i found a big big page with many big big examples to solve the problem. The document I am referring to is from W3C, paged Box media.

Long story short, I now possess the ultimate secret of rendering the page in any format I want. So here are few tricks I learned from the page. To p…

Cache me if you can: What you should know before daring to set URL parameter on visualforce

If someone gave me a pence for every time there was an SOQL query in an APEX Class without using Limit or a condition during a code review, I could afford a Lamborgini this month. Sigh. If only. We make it a habit of going digging for data, at the very moment we need it. The crux of this problem happens when you have chain classes which are independent of each other. Each class needs the reference from a single record and we have to query for that record every single time.

While we don't see it, every SOQL query has a cost to it, and it does not go in my Lamborghini fund, however, it should. In a recent project, we had to construct an Account 360 page that could fetch information from different integration points. The page was also called using a live telephony integration, which could pass the phone number for the account. This required an ability to keep in context the Account that was on call.

Passing the Account id in URL parameter was a valid option, however, any manipulatio…