Lightning Connect is, like much of the lightning suite, actually a group of closely related tools used to accomplish a singular goal. In the case of Lightning Connect, the goal is to surface data residing in external data stores inside Salesforce. This is accomplished by securely exposing data through the oData protocol. The oData protocol is an OASIS standard for REST APIs and data interchange. Through oData endpoints, data can be exposed from common database systems, data science tools, and software libraries. Implementations exist for Microsoft SQL server, PostgreSQL, MySQL, SAP and many other common business systems. Additionally, many common development platforms can also act as oData providers with libraries existing for Rails, Django, and .Net.
Once the data store is oData enabled, administrators can establish external objects. These external objects provide on-the-fly access to your data via oData. From a user perspective, they're virtually identical to standard custom objects with a few restrictions. Unlike standard custom objects, they end not in __c but __x. As you can imagine, certain features of the Salesforce platform are not available with external objects. Most of these stem from the external objects' read-only nature. Features such as sharing, triggers, field history tracking, and processes are not available to external objects. Unintuitively, however, things like merge fields, validation rules, and actions are also not available. While you're not able to create master detail relationships between external objects, you can create lookup relationships to external objects. These are identified as
external lookups and are set when you create the external object. Often, Salesforce automatically generates these relationships when you establish the oData link. In addition to the external lookups between external objects, you can establish an indirect lookup between standard or custom sObjects and external objects. This means you can display related external objects on, say, the account detail page.
Combined together, oData providers and external objects allow you to access data from external stores without having to import that data into Salesforce. Using this data access allows you to report on and combine on-premises data with salesforce data seamlessly. This can be done not only with built-in reporting tools but also with SOQL. Accessing external objects in SOQL is as simple as querying the __x representation of the object. SELECT ExternalID FROM orders__x, for instance, is a perfectly valid query. Running this query causes Salesforce to access the remote data store via oData. This does result in a slightly longer query execution time.
Lightning Connect is conceptually very easy to understand, but this is deceptive. Accessing external data inside Salesforce has been the goal of countless custom integrations over the years. What makes Lightning Connect different, however, is its ease of use. Point-and-click tools to establish such integrations is what sets Lightning Connect apart. Unfortunately, the point-and-click nature of Lightning Connect's magic extends only so far; and like all great products version one has several limitations and assumptions baked in. Chief amongst the limitations of Lightning Connect is that it's currently read-only. While you can easily surface data inside Salesforce with Lightning Connect, you cannot modify it and save it back to the external data source. Future versions of oData may support read-write data connections, but as application architects, it may not always be in our best interest to establish such read-write connections.
Like many other features of the Force.com platform, there are governor limits in place to ensure that no one org is able to destabilize the multitenant environment. Most of the governor limits around Lightning Connect are focused on the amount of data passed around. For instance, there is a maximum request size of 8 MB limiting the amount of data each query can return. Other limits are focused on usage. For instance, there are governor limits related to the number of queries you can make in a given hour. For the Enterprise edition and above, it's 10,000 queries an hour, and for developer edition orgs, you can build out and test Lightning Connect with 1,000 requests an hour. Interestingly, these query limits can be disabled, albeit with some tradeoffs. If you designate an external data source as high data volume, you can avoid most of the rate limits at the expense of having these objects available to you in Salesforce1 and Chatter. If your use case is hitting rate limits and you don't need access to your external objects in Salesforce1 or Chatter, this is a viable option. Governor limits for Lightning Connect are listed partially here, but the full list of governor limits can be found on the success community:
If your company uses SAP as the system of record for orders and manufacturing, but uses Salesforce for sales, support, and community management, it's likely beneficial to know what a customer may have ordered in the past inside Salesforce. Surfacing that SAP data via Lightning Connect can help support quickly determine whether a malfunctioning part was in the same batch as similar support calls. In such a situation, the support team identifies a trend of failing parts across multiple clients. Support would have the ability to run a report using standard reporting tools to identify other clients who have parts from the bad batch, but they wouldn't be able to write data back to SAP about which clients were affected.