Before starting at Torrent, I didn’t associate the word “architecture” with Salesforce integrations. I didn’t know what middleware was, didn’t know the difference between loosely and tightly coupled, didn’t know what an API was. (Apparently that last one is embarrassing; when I told my girlfriend, she said, “Oh, that’s cute”).
Thankfully, I tend to be pretty curious. I like to ask questions about things I don’t understand — especially tech.
Recently, I chatted with one of our technical architects about some key concepts and technologies involved in integrating Salesforce with other applications. In the end, I got an extraordinarily useful vocabulary lesson. Here’s what I learned — and what you absolutely need to know before your company tackles a major integration.
API stands for application programming interface, though I can never seem to remember that. Essentially, an API is “a software intermediary that allows two applications to talk to each other.” In other words, APIs are the connectors that make integrations possible.
To complicate things just slightly, there are two main types of APIs: SOAP and REST. SOAP stands for simple object access protocol, while REST stands for representational state transfer (don’t worry, there isn’t going to be a quiz). SOAP is the original standard, and relies solely on XML to provide messaging services. REST tends to be easier to use and can output data in other formats, including CSV, JSON and RSS.
Loosely Coupled vs. Tightly Coupled
Let’s start with the idea of loosely and tightly coupled integrations. A tightly coupled integration is one that creates a dependent relationship between Salesforce and whatever systems it’s being linked to by spreading the integration business logic across those systems. While a tightly coupled integration could function just fine, it will inevitably cause scalability and maintenance problems in the long term. A loosely coupled integration, on the other hand, keeps the integration business logic separate from each system, typically in a middleware platform, which is concerned strictly with handling the integration. This allows you to more easily modify your integration logic and to make changes to each individual system without fear of breaking any existing functionality.
Enterprise Service Bus (ESB)
An enterprise service bus — a type of middleware — is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. Third party services, such as Mulesoft, provide ESB solutions. They are a great way to create loosely coupled integrations, since all of the necessary processes exist in a centralized platform.
Point to point integrations typically require custom code. In a point-to-point integration, each system must contain the logic and processes to send or receive data to or from the other systems, as well as to transform that data into the proper format. Since all of this business logic is spread out over each system, it creates a tight coupling. While no third-party platform is needed in a P2P integration, they’re difficult to maintain as the number of integration points grow. (Our technical architect isn’t a big fan.)
A workflow rule is a point-and-click tool inside of Salesforce that lets you easily automate simple business processes. Example: If a record is updated in Salesforce, then update a field or send a message to an external system.
An outbound message is a specific type of action that can be used in the then part of a workflow rule. It sends data over the internet to a designated endpoint. For example, an outbound message could send new contact information to an ERP whenever a contact record is created in Salesforce.
Apex Triggers are basically the custom-code version of workflow rules. They allow you to do more, but the idea is the same: When something happens to a record in Salesforce (an update, say), the trigger makes sure the same thing happens to the corresponding record in your integrated platform. Similar to workflow outbound messages, Apex triggers can be useful for sending data to an external system whenever a record is changed in Salesforce.
An Apex Job is a regularly scheduled task built with custom code. Where an Apex Trigger runs every time a certain condition is met, an Apex Job simply runs at predefined intervals. They’re often used for batch updates, and can be useful for passing data from Salesforce to some other system at a pre-defined interval.
Okay, that was a lot to cover in a limited number of words. If you’ve got questions, we’re here to help. And if you’re looking for a tips on how to handle a Salesforce integration like an expert, check out our free eBook: