Practical Salesforce Architecture

Chapter 5. Middleware and Connectivity

We’ve already discussed some of the systems involved in moving data into and out of the Salesforce ecosystem, but in this chapter we will look at the actual endpoints for connecting to that data. The most important thing to know about Salesforce connectivity is that you have to do almost everything with web service calls.

This chapter leans heavily on the concept of APIs. Broadly speaking, an API is any interface used to expose or share an application or system’s data outside of itself in a programmatic fashion. There are many types of APIs: some require running on the same machine as the source system, some can be accessed over the web or HTTP. There are no accessible APIs that allow you to process Salesforce platform data without going through an HTTP-based API. Representational State Transfer (REST) is the preferred HTTP method, but some Simple Object Access Protocol (SOAP) interfaces persist. This can present some interesting challenges for enterprise architects that are accustomed to having a larger suite of patterns at their disposal natively. For example, automated processing of data in file format is not a feature of the core platform. There are many ways to achieve file processing with additional components or purchases, but not natively. (Data Loader, for example, is a free Java application maintained and distributed by Salesforce that can be installed on a server to parse files and push the data in them into Salesforce, using ...