Salesforce Goes Real-time

February 28 2012


With the recent Spring 12 release of Salesforce very few would have noticed a little unsung feature that will change the way many applications interact with with Salesforce. The Streaming API went GA and allows to listen to changes to objects in the Salesforce platform rather than polling.   Salesforce joins the ranks of other leading APIs such as Twitter, Facebook and Instagram that all offer APIs to enable users to consume data in real-time, as events occur.

Polling isn’t Evil, but…

You might be thinking polling isn’t that bad, but there are some real benefits to real-time APIs.  It all comes down to time and efficiency. Real-time APIs change the traditional HTTP RPC exchange between server and client into an event driven model.  In other words, rather than your app calling in repeatedly, you establish an open channel through an API call and then the server can send events to you as they happen.  This means that your app is not wasting resources polling the server repeatedly and getting empty responses back but it also mean you receive new events as they happen. If you are not familiar with this concept  the PubSubHubBub guys at google do a great job of explaining this.

Real-time API Benefits

  1. Real-time APIs are more secure than other  callback methods such as Webhooks or directly opening an HTTP port to receive events, since most IT folks want to keep ports open to the outside world to an absolute minimum.  Real-time APIs are client initiated, and there is no server socket open to the public.
  2. Salesforce, like all APIs have an API limit.  this means you cannot just poll the API more to get updates more quickly. Sometimes, buying more API calls is an option, but you are just paying more for the same data.
  3. Real-time APIs are more efficient since they reduce the amount of clients concurrently hitting the server and reduces the amount of empty responses sent back to the clients.  I’ve heard that up to 60% of the queries made to Salesforce return an empty response. The benefits to the end user is more about piece of mind that their app is reducing the amount or resources and power an app uses. This makes a big difference if everyone starts doing it.

Waiting for Data

Increasingly, applications cannot wait for updates.  A common example for Salesforce might be a call center application where having the recent view of a customer at the time the customer calls is crucial to completing a call successfully. Integration with with other applications is another area where real-time really matters. Synchronizing CRM with marketing automation, finance and other applications needs to happen immediately so the company is running on a consistent dataset.

Integrating with the Salesforce Real-time API

You’ll be happy to know that Mule has a Salesforce cloud connector that supports the Salesforce API including the Bulk API and the new Real-time API.  Salesforce can be used from Mule ESB or our cloud platform, Mule iON. This means you can integrate gorund to cloud or cloud to cloud, Salesforce is supported directly in Mule Studio too.

The Salesforce real-time APIs is an evolution of the Salesforce API.  Right now its one way (server to client) but you can expect to be able to push data streams to Salesforce too in the near future. I suspect Salesforce will spark a trend in data-centric APIs to offer a real-time option. We’re already seeing this in push services such as PubNub, Pusher,, SuperFeedr and more.  If you are still wondering whether you need real-time APIs, consider that there are no drawbacks and plenty of benefits; can you really afford to wait for data?

Follow: @rossmason, @mulejockey

We'd love to hear your opinion on this post

8 Responses to “Salesforce Goes Real-time”

  1. Awesome. Can’t wait to use this!

  2. Isn’t that an implementation of old plain long polling? What happens if a client gets disconnected – any self-healing protocols?
    Long polling-like messaging code is easy to implement, benefits are great, but it is well-known technology, what is so exciting?
    The article does not make it clear, sorry…

  3. Hi Alex,

    This is the first rev of the Salesforce streaming API, as such the API doesn’t provide durable subscriptions, as I understand, this is on the roadmap.

    Mule does provide self-healing connections and session management for API clients. This is part of the standard cloud connector model that we provide.

    What is exciting is that that streaming APIs mark a wind change to the way you can integrate with SaaS applications. The streaming APIs from Facebook, Salesforce and Twitter are the beginning. We’re seeing providers explore ways to provide more efficient access to data on the Web.

  4. Hi Ross, thank for your input.
    > We’re seeing providers explore ways to provide more efficient access to data on the Web.

    That is what I’m experimenting with for many years now… real-time is an easy one to deal with :-). In my humble SaaS solution it makes about 3-5% of source.

    Technology stack has to be simplier, components smarter and more convinient, HTML-JSP is not an ideal platform – things like that. We need a paradigme change :-).

  5. Great!!. Had looked into this some time back. There seems to be some limitation at that time.
    – No reliable delivery
    I guess it would be ok if a facebook or a tweet gets lost, But for DB updates reliable delivery might be expected.
    – Scalability issues.
    How many can listen for update ? And how much data can be transferred ?

    Can this streaming API be used to sync database in a SaaS environment ?

  6. Reliability is still an issue but our customers use Mule to persist all events before processing them which provides about as good reliability as you’re going to get over HTTP.

    Regarding scale, the Salesforce platform team have done a great job hear building the API for scale. there is a limit right now to 20 topics and I’m pretty sure there is a limit on the number of subscribers, but I can’t remember off hand.

    Yes you could write a SalesForce to database sync. There is actually an example for this:

  7. Just to close out the the limits question. SalesForce do have a limit of concurrent connections at 100, however, if you call them they can lift this. We are currently running pretty large performance tests of the SalesForce streaming API through iON and we had the limit lifted.

  8. On the topic of reliability, you need to get the messages before you can persist them. So how does mule help, in this case?