Heroku is a cloud platform as a service(PaaS) that let companies build, deliver, monitor and scale apps — we’re the fastest way to go from idea to URL, bypassing all those infrastructure headaches.
Heroku supporting several programming languages that are used as a web application deployment model. Heroku, one of the first cloud platforms has been in development since June 2007, when it supported only the ruby programming language, but now it supports Java, Python, Node.js, Scala, PHP and GO. For this reason, Heroku is said to be a polyglot platform as it lets the developer build, run and scale applications in a similar manner across all the languages.
Dynos: the heart of the Heroku platform
App developers rely on software abstractions to simplify development and enhance productivity. When it comes to running apps, containerization abstracts away the burden of managing hardware or virtual machines. Instead of hardware management, you deploy an app to Heroku, which packages the app’s code and dependencies into containers — lightweight, isolated environments that provide compute, memory, an OS, and an ephemeral filesystem. Containers are typically run on a shared host, yet are completely isolated from each other.
The Heroku Platform uses the container model to run and scale all Heroku apps. The containers used at Heroku are called “dynos.” Dynos are isolated, virtualized Linux containers that are designed to execute code based on a user-specified command. Your app can scale to any specified number of dynos based on its resource demands. Heroku’s container management capabilities provide you with an easy way to scale and manage the number, size, and type of dynos your app may need at any given time.
Dynos are the building blocks that power any Heroku app, from simple to sophisticated. Deploying to dynos, and relying on Heroku’s dyno management, makes it easy for you to build and run flexible, scalable apps – freeing you from managing infrastructure, so you can focus on building and running great apps.
Worker Dynos: Background jobs are key to building scalable web apps as they transfer both time and computationally intensive tasks from the web layer to a background process. This ensures that web requests can always return immediately and reduce performance issues that occur when requests become backlogged.
In Heroku, this is achieved by Worker dynos. Worker dynos are typically used for background jobs, queuing systems, and timed jobs(jobs that take much time). Worker dynos run asynchronously to web dynos. Moving more processing to the worker will free up your web dyno to handle more requests. Handling long-running work with background workers has many benefits. It avoids tying up your web dynos, preventing them from serving other requests, and keeps your site snappy. In the above example, if the uploaded image needs further processing, web dynos pass it to worker dynos.
More examples of background jobs include fetching data from remote APIs, reading RSS (Rich Site Summary) feeds, resizing images, and uploading data to S3 (simple storage service). You can have multiple kinds of worker dynos in your application. For example, one for urgent jobs and another for long-running jobs.
At the heart of the slug, compiler is a collection of scripts called a build pack that handles different languages. Heroku’s officially supported build packs accept applications written in Ruby, Python, Java, Clojure, Node.js, Scala, Go and PHP.
These build packs are open-source and available on GitHub. Also, Heroku supports custom build packs. For example, you have a code written in the language other than Heroku supported languages, then for the compilation of that code, Heroku allows you to design your own build pack.
Some enterprises go even further – storing and integrating with customer data in Salesforce enables full-cycle CRM engagement. Heroku provides seamless Heroku Postgres and Salesforce Data synchronization, enabling organizations to go beyond the usual data architectures and combine the capabilities of the Force.com and Heroku platforms.
Imagine building modern applications that selectively sync data to Salesforce, enabling Service Cloud and Sales Cloud workflows.
Reasons for Integrating Salesforce and Heroku:
Modern enterprise systems are composed of many different parts with different interfaces for a variety of types of users. These interfaces often pull together data from a variety of data sources. The microservices architecture has emerged as a way to decouple the pieces of a system into more easily maintainable, independently deployable services to provide endpoints that bring disparate systems together. Heroku is a great place to run apps and micro services that you can use with Salesforce through a variety of integration methods.
Four common reasons to integrate apps on Heroku with Salesforce are:
- Data Replication
- Data Proxies
- Custom User Interfaces
- External Processes
Integration Through Data Replication
Data replication is copying or synchronizing data between Salesforce and another system. You can use data replication for data warehousing to enable cross-data source reporting and analysis. You can also use it to work with legacy systems that either need data from Salesforce or feed data into Salesforce. The most common use case with Heroku and Salesforce is to provide a high-throughput, low-latency interface for customer-facing applications built with open-source technologies.
Seamless Heroku and Salesforce data synchronization:
Heroku Connect makes it easy for you to build Heroku apps that share data with your Salesforce deployment. Using bi-directional synchronization between Salesforce and Heroku Postgres, Heroku Connect unifies the data in your Postgres database with the contacts, accounts and other custom objects in the Salesforce database. Easily configured with a point and click UI, it’s simple to get the service up and running in minutes – no
Integration Through Data Proxies:
Data proxies aggregate different data stores, but unlike data replication, the data isn’t copied. The data can be read only on demand. This approach enables data science, business intelligence, reporting, and dashboarding tools to collate data across multiple data stores without worrying about data synchronization challenges like storage and staleness. You can integrate legacy systems and external systems through data proxies to provide data to Salesforce, or Salesforce can provide its data to other external systems.
If a Salesforce user needs to run inventory reports that correlate product data in Salesforce with warehouse data from an external system, data proxies can provide that information without using slower methods like extract transform and load (ETL). When the report is run, Salesforce fetches the necessary data from the external system without ever storing the data. The same also works in the opposite direction — an app running on Heroku is a data proxy for Salesforce to another system providing a security and transformation layer. We’ll touch on that shortly.
Integration Through Custom User Interfaces:
You can easily create custom user interfaces for Salesforce using a variety of technologies, such as Visualforce and Lightning Components, to name two. When interfaces are built with open-source technologies like Java, Node.js, PHP, and so on, they can run on Heroku and be integrated into the Salesforce UI or just with Salesforce data. Other times, a legacy or external system provides a user interface that needs to be surfaced in the Salesforce UI.
For example, a company that uses Salesforce for CRM acquires another company with a custom system built in Java. An easy first method of integrating those systems is simply to run the Java system on Heroku and render it in Salesforce. Running the Java system on Heroku can alleviate the scaling and ops burdens while standardizing on a deployment architecture for custom systems. Standalone user interfaces that run on Heroku and integrate with Salesforce data can provide back-office extensions to Salesforce as well as customer-facing web and mobile apps. Custom user interfaces might have libraries, features, or developer skill sets that drive the decision to use Heroku and open-source technologies over the native Force.com options.
Integration Through External Processes:
External processes can offload batch processing or workflow and trigger event handling to apps on Heroku. This method can be helpful depending on the type of job that needs to be done and the amount of effort involved. Data science, machine learning, image and video processing, and integration with legacy or external systems can be reasons to offload external processes to Heroku.
As an example, let’s say your real estate company uploads photos for each house it lists for sale. These photos are huge, so you need a way to resize them to reduce loading times and storage costs. You can easily offload this job to an external process on Heroku. Each time a photo is uploaded to Salesforce, it is sent to an app on Heroku for processing, and the resized image is saved back into Salesforce. The app on Heroku that handles the external process could be responsible only for that one piece of the system. In that case, the app is likely considered a micro service that can be deployed separately without any other system dependencies.
Integration Methods Overview
So now you know that data replication, data proxies, custom user interfaces, and external processes are all great reasons to combine Heroku and Salesforce. But how do you do this? Several methods to accomplish these types of integrations are available, such as:
- Heroku Connect
- Salesforce Connect
- Salesforce REST APIs
Here’s a quick overview of all the Methods Overview:
Heroku Connect provides both data replication and data proxies for Salesforce. Data replication synchronizes data between Salesforce and a Heroku Postgres database. Depending on how it’s configured, the synchronization is either one way or bi-directional. To get hands on with Heroku Connect, check out the Connect Trailhead project. Heroku Connect also provides a data proxy to Salesforce through the OData protocol using Heroku External Objects. Heroku External Objects provides an OData wrapper for the Heroku Postgres database that Heroku Connect maintains a connection for. This feature allows other web services to retrieve data from within the specified Heroku Postgres database using RESTful endpoints generated by the wrapper.
One of the biggest benefits of using Heroku Connect for data replication is that a subset of Salesforce data is quickly and easily accessible to an app on Heroku. As an app developer, you simply write standard SQL for queries as you normally would. Heroku Connect and Postgres provide a low-latency and high-throughput access to Salesforce data.
You can use Salesforce Connect (formerly called Lightning Connect) as a data proxy to pull OData or other data sources into Salesforce on demand. No data is copied to the Salesforce database. You can run endpoints that expose OData 2.0 on Heroku or as provided by external systems. As mentioned previously, Heroku Connect can expose a Heroku Postgres database as OData for consumption by Salesforce Connect. Alternatively, Salesforce Connect custom adapters allow Salesforce to proxy any data source that Apex can talk to, including REST with XML or JSON and SOAP.
The primary benefit of Salesforce Connect is that it brings external data into the Salesforce UI and makes it look as if the data resides in Salesforce, although it’s just proxied on demand from an external data source. This process makes it easy to collate disparate data sources for Salesforce users.
Salesforce REST APIs:
The Salesforce REST APIs provide apps on Heroku access to Salesforce data through simple JSON-formatted HTTP requests. You can use this integration for data proxies and custom user interfaces. Applications built with open-source technologies that are running on Heroku can use OAuth to authorize users in a custom user interface and then interact with Salesforce data on their behalf. Integration use cases without a user interface can broker data between Salesforce and external systems.
You can use callouts from Salesforce to call external processes on Heroku. You write the callouts in Apex or use workflow outbound messages to have events on Salesforce trigger the execution of a process on Heroku. That process often uses one of the previously mentioned integration methods to get the result of the process back into Salesforce.
Comparing Integration Methods:
Each Salesforce and Heroku integration method has a place depending on developer skill sets and the use case at hand. Here are some basic differences between the integration options.
|Heroku Connect||Salesforce Connect||REST APIs||Callouts||Canvas|
|Security Model||Integration user||Various (including integration user and named principal)||OAuth||App user||App user|
|Limits||Excluded from limits||Max # of sources, objects, and fields||API limits||API limits||Request limits|
|SObject Features||All standard features||Read only
No formula and roll-up summary fields
No triggers, workflow, approvals process
No Validation Rules
Field history tracking
No notes, attachments
|All standard features||N/A||All standard features|
|Data Strategy||Real-time BiDi sync or OData||OData or proxy||Read & copy||Payload||Canvas API|
|End Users||Anonymous, customers||Salesforce users||Any||No||Salesforce users|
Below are some suggestions for integrations:
- To replicate data between Salesforce and Heroku, use Heroku Connect.
- To expose a Heroku Postgres database to Salesforce, use Heroku Connect External Object.
- To proxy OData, SOAP, XML, or JSON data sources into Salesforce, use Salesforce Connect.
- If Heroku Connect doesn’t fit the bill, like when you have a custom UI on Heroku where users log in via Salesforce, use the Salesforce REST APIs.
- To offload or extend the processing of Salesforce data events, use callouts from Salesforce to Heroku.
- To embed a custom UI from Heroku (or other external web apps) into Salesforce, use Canvas.