What can we glean from the na14 outage? Will Salesforce protect you? Here’s what you need to know.
The na14 outage on May 10 has raised a lot of discussion around trust in cloud applications, data backup strategies and even outage clauses with SaaS vendors. The analogy that comes to mind for me is an airplane crash. While it’s a tragedy with very graphic scenes, people keep flying since air travel remains one of the safest modes of transportation. And losing transactions for 3.5-4 hours is certainly graphic from a business operations perspective.
In response to the outage, I’m getting asked interesting questions from the Salesforce community and LinkedIn on external data strategy, which is my area of expertise. I actually had not considered this question until after reading the coverage, but can external objects save your organization from future outages?
Salesforce Connect was introduced a couple of years ago to provide seamless real-time access to back office systems, so organizations no longer have to copy data into Salesforce to be treated as native objects. These federated objects are accessible via OData and called external objects.
No. Salesforce connect provides data integration and federation, not high availability.
Yes and No.
We'll start with how it would have helped. Let's say your external objects are setup against an Oracle database behind the firewall and a Postgres database hosted in Heroku. If those transactions were made completely on external objects, the transactions would be persisted to Oracle or Postgres for which external objects were created. So there would have been no data loss on those objects on May 10, unless your external databases were also down. But if both Salesforce and your external databases happened to be down at the same time, there are probably bigger things to worry about than data loss.
Now for how it wouldn't help, at least not from the perspective of any data persisted in the Salesforce platform. Any updates made on standard fields with indirect relationships to external objects would still be lost. However, updates made on external object fields would be preserved in Oracle and Postgres, and you would be able to figure out what parent objects may have been updated from external database transaction records.
We run Salesforce on na13 and I trust Salesforce. Salesforce Connect is not a high availability strategy, and trying to run an entire Salesforce org as external objects just does not make sense. But I am a big proponent of this technology for its intended purpose of allowing flexibility for Salesforce orgs to configure where the data resides for a single version of truth. As a best practice, I continue to recommend that we keep our Salesforce data in Salesforce, and our remote data sources in external databases exposed as external objects.
If you’re new to external objects, you can check out my tutorial published on Salesforce Developers to learn more.
Building a Data Integration Proof of Concept Using Lightning Connect
Technology researcher, thought leader and speaker working to enable enterprises to rapidly adopt new technologies that are adaptive, connected and cognitive. Sumit has been working in the data access infrastructure field for over 10 years servicing web/mobile developers, data engineers and data scientists. His primary areas of focus include cross platform app development, serverless architectures, and hybrid enterprise data management that supports open standards such as ODBC, JDBC, ADO.NET, GraphQL, OData/REST. He has presented dozens of technology sessions at conferences such as Dreamforce, Oracle OpenWorld, Strata Hadoop World, API World, Microstrategy World, MongoDB World, etc.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.