This is the third and final post in a series that reviews Social Web-to-Lead, a Node.js Facebook application running on Heroku that integrates with Force.com. My first post covered the basic application use case and its use of the REST API to insert Lead data in Salesforce from the Facebook application. The second post described the use of the Redis Heroku add-on and Apex REST to implement a more efficient design for the application that consumed fewer Force.com API calls. In this post I want to describe how Social Web-to-Lead implemented real time push notifications from Force.com to Heroku using HTML5 WebSockets. The entire application codebase is available here and you can also watch a recording of the Dreamforce 2012 session where I demoed the application.
The primary use case for Social Web-to-Lead was to allow Facebook users to enter their contact information via a ‘Contact Me’ link (typically from the company/brand Facebook Page). That information was then captured as a Lead record in Salesforce via a Force.com REST API call. Imagine a use case where the data flow is reversed. In other words, say that you need to ‘push’ some data updates from Force.com to the Facebook application in real-time. Specifically for Social Web-to-Lead, say that a Force.com Custom Object (Offer__c) stores special customer offers and you want your Facebook application to display new offers as soon as they’re added in Force.com (without requiring a browser refresh). To make it a little more interesting, we’ll display the offers as QR Codes that your Facebook users/fans can print and bring to the physical store. This screenshot shows how this would look like to the Facebook users who click the ‘Exciting Offers’ link on the company/brand Facebook Page (screenshot on the left) .
Every time that a new offer record is added in Salesforce, the offers page shown on the right would automatically display the new QR encoded offer (without requiring a browser refresh). You can also skip to this point in the session recording to see this real-time push notification in action.
Streaming API – where art thou?
Before we dive into the Pusher based architecture described above, lets address an important question. The use case described above requires real-time push notifications from Force.com to an external web application. That’s an ideal use case for using the Force.com Streaming API. There is one thing about this use case however that precludes the use of the Streaming API. Like all other Force.com APIs, the Streaming API requires authentication with Salesforce before a client can start receiving push updates via the API. In our use case however, the client is a Heroku-hosted web page that is surfaced as a Facebook application. None of the Facebook users will have an equivalent Salesforce identity in this use case and so we cannot authenticate with the Streaming API. For such unauthenticated push notification use cases, an intermediary service like Pusher may be considered.
Adding Pusher to the Heroku application
Lets start our deep dive into the integration design by reviewing how you can use the Pusher add-on in a Heroku application. As with all Heroku add-ons, its as simple as running the following command
Sending push notifications to Pusher from Force.com
Lets complete the circle by reviewing how we push new offers to Pusher from Force.com. It starts with a simple trigger on the Offer__c custom object.
As experienced Force.com developers know, you can’t make synchronous callouts directly from an Apex trigger. Instead, you use a @future annotation to execute the callout logic asynchronously from the main trigger execution thread. That’s exactly what the OfferNotificationToPusher class does. Here’s a snippet from that class.
The sendPusherNotification uses the native Apex JSON library and a simple ‘wrapper’ inner class (Offer) to translate the offer data into the appropriate JSON format for the Pusher REST API (lines 14-26). The Pusher API requires a very specific form of authentication and that is what lines 28-45 are doing. Notice also how the authentication code uses a Custom Setting (PusherConfig__c) to store the Pusher App id, key and secret assigned to your application. Once the Apex trigger invokes the above callout logic, Pusher takes care of propagating that offer data to all browser clients that are currently displaying the offers.ejs page of the Heroku application.
Hopefully this blog series have gotten your creative juices flowing on what’s possible when you combine the power of Facebook, Heroku and Force.com. If you have any other interesting use cases for such enterprise-focused social applications, please share them via the comments section.