Force.com Utility Belt - Google Chrome Extension for Salesforce.com

Jeff Douglas

The Force.com Utility Belt is a Google Chrome Extension that I wrote to make my life easier. While developing on the Force.com platform I consistently need access to Salesforce documents, message boards, code snippets, etc. and opening PDFs, searching documentation and looking up Visualforce component signatures becomes tedious. The extension evolved out my necessity to make myself more productive.

You can install the Force.com Utility Belt from the Google Chrome Extensions Gallery

Extension Interface

When first activated, the extension display the interface above with the following features and functions:

• Defaults to the Quick Reference Topics interface
• Displays links in the upper right for access to the main functionality of the extension (Quick Reference Topics, Search for Stuff and ID Converter)
• Displays links to open developer.force.com and the Force.com documentation page in a new tab
• Displays the latest feed content from the Force.com blog in the bottom

Quick Reference Topics

The following sections are loaded into the extension with short cuts to topics that I frequently use allowing me quick access to stuff that I typically forget. The sections include:

• Apex
• Visualforce
• Visualforce Components
• SOQL
• AJAX Toolkit
• Web Services API

Once you choose a section you can drill down into a specific topic, view it in the extension and even open the actual page in a new browser tab.

Search for Stuff

Since the Quick Reference Topics don’t include access to every topic in the Salesforce documentation, you need a convenient way to search for stuff. The search interface allows you to select a scope and perform a keyword search against the specific site. The results are displayed in a new browser tab.

Due to popular demand, the following sites are searchable:

• Apex Code Developer Guide
• Apex Discussion Boards
• Visualforce Developer Guide
• Visualforce Discussion Boards
• Web Services API Developer Guide
• AJAX Toolkit Developer Guide
• Metadata API Developer Guide
• Bulk API Developer Guide
• Force.com Cookbook
• Snipplr
• Salesforce Handbook - Delicious Bookmarks
• Code Share
• AppExchange
• Google

ID Converter

The ID Converter is from my original extension so I rolled it into this one for convenience. It allows you to quickly create an 18 digit Salesforce ID from a 15 digit ID. Based upon some feedback I made a small change so that the extension tries to find a 15 digit ID from the tab’s current URL and pre-populate the conversion form field.

Google Chrome Extension: Salesforce.com ID Converter

The Saleforce UI displays 15 digit, case-sensitive IDs for records. However, for Windows machines you will need to use a case-safe version of the ID for data migration, API calls and such. It's not hard to generate these 18 digits IDs but it does take some time. I've been working on a lot of Google Gadgets and Chrome extensions lately so I thought I would throw together a Chrome extension (sorry Firefox users!) to quickly generated an 18 digit Salesforce.com ID. Thanks to Ron Hess for the conversion script!

Building Chrome extensions is fairly simple with a little bit of HTML and Javascript. The Google Code site has some sample "Hello World" code as well as an extension video to get you going.

You can download the extension here.

Using the Salesforce.com OAuth Playground

Jeff Douglas

My article on developer.force.com, Using OAuth to Authorize External Applications, shows how to develop external Java applications that use OAuth to access your Saleforce.com data. But what if you want to do the opposite? What if you need to write an application on the Force.com platform that uses your data from Google, Twitter, LinkedIn or TripIt using OAuth? Luckily Jesper Jorgenson at Salesforce.com posted an open source project called sfdc-oauth-playground which is a generic consumer implementation of OAuth as a Force.com App.

The main purpose of this beta project is to show you how to write OAuth signed requests in Apex. There is a managed packaged you can install into your org but if you really want to dig into the guts of OAuth (and who doesn’t??) you’ll need to download and install the source code from the project. The managed package doesn’t afford you to opportunity to modify code or view granular debug statements.

Jesper doesn’t provide much documentation for the project so I’ve put together a short video showing how to get started using Google Accounts and Blogger. Unfortunately different providers implement OAuth to their own liking so you sometimes have to make modifications to the requests being sent over the wire. I ran into a number of issues so hopefully this will assist you in getting up and running with OAuth.

In case you don’t have time for the video, here are a couple of screenshots outlining the process using the OAuth Consumer Playground application from the managed package.

Create a new OAuth Service (e.g., Blogger) with various URLs for accessing services

Authorize Salesforce access to Blogger

Grant access to Blogger

Authorization confirmation

OAuth Service access tokens

Testing the service

Install the Salesforce Chatter for Android App on Your Phone

Jeff Douglas

Salesforce.com invited me to attend Cloudforce last Tuesday to demo my Salesforce Chatter for Android app. The reception was incredible and there is a big push to get a Salesforce.com app running on Android. Parker Harris (Co-founder & EVP, Technology) even made the statement in the keynote that, "I do have a team working on a native Android Chatter application that will be out later this year....". At that point, Narinder promptly tweeted:

Well that created a lot of buzz so over the last couple of days I've had an amazing number of people email, tweet and post chatter asking me how people can run the Chatter for Android app on their own phones. I checked with Kris Muller at salesforce.com and we've decided to let anyone install the app and try it out. The functionality is limited (you can only view the Chatter feed and post an update) and it is connected to a DE org so you can't really screw anything up.

So here's a little background and how it started. The application is combination of the Force.com platform, Google App Engine and a Google Android mobile handset. It utilizes Force.com Remote Access Applications with 3-legged OAuth for security allowing App Engine to fetch chatter feeds and post new status updates using the Force.com Web Services Connector running on App Engine. The Google App Engine app runs at https://chatter-android-demo.appspot.com.

The Android client makes a request to refresh it's chatter feed and makes a call to this endpoint on App Engine. The WSC queries Salesforce for the chatter feed and returns the feed as a series of JSON objects. The Android client consumes the JSON objects and stores them in the local SQLite database. When the feed list is displayed on the Android client, the images are download lazily from App Engine when needed. You may see a slight lag while new threads are spawned and the images are downloaded. If the images do not display quickly, try scrolling through the list back and forth for them to display. Part of the roadmap is to store these images in the local database instead of downloading them each time.

Installation Instructions

To install the app on your own phone:

• Download either the original 2.1 application or a 1.6+ version that runs on older handsets to your desktop
• On your phone, install eoeAppInstaller from the Android Market.
• Mount your phone to your computer via your USB cable so that you can access the SD card on your phone from Finder.
• Drop the .apk file into the root of your SD card
• Unmount your phone and disconnect your USB cable
• Go to Settings -> Applications and check “Unknown Sources” to allow installation of non-Market applications
• Launch eoeAppInstaller and it should display the Salesforce Chatter app
• Long press the app and select "Install this apk"

When you launch the application, simply click anywhere on the white Android/Chatter logo to display the chatter feed. The first time you run the application there will be no chatter updates. You will need to hit Menu -> Refresh to populate the local database with updates. The app is currently set to only return the last 15 updates. The app runs as the user Scott Thompson and you cannot switch to a different user.

If you want to see Salesforce come to the Android platform, please vote for this idea.

Install Google GO on Mac OS (Snow Leopard)

Google GO is a systems language Google uses on it's own production instances. It's nearly as fast as C++, has garbage collection, and can handle thousands of concurrent "routines". When we started with GO, we followed the installation notes, but noticed a few other steps that needed to take place as well. We hope you find this walk through helpful.

Disclaimer: Hey, this is Appirio, right? Why a systems language? What's that have to do w/ Cloud? The GO team is working w/ the Google App Engine team (no release date yet) and it already has huge ramifications on EC2 environments... we think it'll be a major player down the road. Always healthy to stay ahead of the curve.

Prerequisites:
- Python (Mercurial requires Python)
- Mercurial (Source Control Management)
- XCode
- ~/bin directory with 755 permissions. (mkdir ~/bin then chmod 755 ~bin)

Here's how to check your prerequisites, for reference:

Kyle-Roche-MPB:~ kyleroche$ python -V
Python 2.6.1

Kyle-Roche-MPB:~ kyleroche$ hg version
Mercurial Distributed SCM (version 1.5.4+20100601)
Copyright (C) 2005-2010 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Kyle-Roche-MPB:~ kyleroche$ xcodebuild -version
Xcode 3.2.2
Component versions: DevToolsCore-1648.0; DevToolsSupport-1631.0
BuildVersion: 10M2148

Adjust .bash_profile
Add the following code to your .bash_profile. If you don't have one, create it in your ~ directory.

export GOROOT=$HOME/go
export GOOS=darwin
export GOARCH=386
export GOBIN=$HOME/bin
export PATH=$GOBIN:$PATH

Here's how to check your profile, for reference:

Kyle-Roche-MPB:~ kyleroche$ source .bash_profile

Kyle-Roche-MPB:~ kyleroche$ env | grep ^GO
GOBIN=/Users/kyleroche/bin
GOARCH=386
GOROOT=/Users/kyleroche/go
GOOS=darwin

Pulling down the source package:
You can use Mercurial to pull down the package from Google Code. Run the following command:

Kyle-Roche-MPB:~ kyleroche$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
requesting all changes
adding changesets
adding manifests
adding file changes
added 5632 changesets with 22984 changes to 3660 files
updating to branch default2215 files updated, 0 files merged, 0 files removed, 0 files unresolved

Compile the package.

Final step... change to the $GOROOT/src directory. Run the following command:

Kyle-Roche-MPB:src kyleroche$ ./all.bash

There's way too much output to be useful copying to this article. I noticed a different set of output then described in the installation guide. I think the safest way to test if it was successful is to go ahead and follow the Hello World example. If you're confident that existence = success, you can always run which 8g or which 8l. Both of those files exists after the language is compiled.

Salesforce Chatter for Android

Jeff Douglas

This is an overview and demo of the application that I submitted for the Chatter Developer Challenge. It is a Salesforce Chatter for Android app running on a combination of the Force.com platform, Google App Engine and a Google Android mobile handset. It utilizes Force.com Remote Access Applications with OAuth for security.

The Android application has the following functionality:

• Display your Chatter NewsFeed
• Update your User status
• Refresh your Chatter NewsFeed and store it in the local SQLite database
• Choose a project (custom object) that you are following and view its Chatter Feed
• Update the project’s status
• Refresh the Chatter Feed for the project (including field changes to the record) and store it in the local SQLite database

The app does not include the functionality to reply to posts. Since Chatter is running in a Developer Edition and they are only allowed to have 1 user, it seemed rather pointless to respond to my own posts.

Here are some screenshots of the application in case you want to skip the video.

I use Google App Engine to tie all of this applications together and provide a coherent security model. So I wrote a small App Engine app that uses 3-legged OAuth to authorize access to Force.com and my Chatter feeds using Force.com Remote Access Application. Once authorized the Force.com Web Services Connector, running on App Engine, performs the interactions with SFDC such as submitting new status updates, fetching my feeds and displaying them as JSON objects.

App Engine recently started supporting 2-legged OAuth in combination with Google Accounts so that any App Engine application can become an OAuth service provider. Since OAuth support is baked into the Android platform I tried to hook up the Android handset as an OAuth consumer but could not finish in time to submit my entry to the Developer Challenge.

Since Android doesn’t play well with SOAP-based Web Services I think this approach in combination to JSON makes an appealing option. If you have any ideas, I’d love to hear them.

OpenID + OAuth

Jeff Morgan

What are OpenID and OAuth
Authentication and authorization are commonly grouped together in the same conversation. OpenID and OAuth again are grouped together as they represent authentication and authorization respectively. While both OpenID and OAuth have been available as options to Google developers for a while, they now take on more significance with the introduction of Google Apps Marketplace. In fact, it is a requirement to use these two standards when integrating a web application with the Google Apps Marketplace.

OpenID
OpenID is an emerging standard that provides authentication between a provider and a relying party (typically a web application.) In the context of Google Apps it allows a web application to use Google as the authentication provider. This federated authentication approach is commonly used to provide Single Sign-On (SSO) to another web application. The beautiful part of SSO is once a user has authenticated in their Google Apps domain access to any third-party Marketplace application in their domain is transparent.

OAuth
There are two flavors of OAuth, two-legged and three-legged OAuth. While both are available for use by many Google Data APIs there are important differences that must be understood in order to know the best time to use each. Two-legged OAuth authorizes domain wide access to Google Apps domain user data at an administrator level. Three-legged OAuth authorizes access to only one user’s data by that user. In general, if you understand these main differences then making the decision to which OAuth option to use becomes easier. The Google Apps Marketplace supports two-legged OAuth since it makes sense to authorize access at the domain level by the administrator. Marketplace applications are available to all Google Apps domain users, no need for each user to grant authorization.

OpenID+OAuth
Bringing them both together is now also supported by Google. Sometimes referred to as the Hybrid Protocol, OpenID has been extended to support OAuth. While this may be useful in certain situations, this approach is now less relevant in the Google Apps Marketplace. The Marketplace manifest configuration file supports two-legged OAuth making the need to obtain an OAuth token during the OpenID process unnecessary. It is also important to understand this distinction when writing Marketplace applications because OpenID and OAuth are often grouped together, not just because of the hybrid option but because they by themselves play an important role in developing application on the Google Apps platform.

Learn More

Google IO Session
OpenID-based single sign on and OAuth data access for Google Apps

Resource Links
Implementing OAuth with Federated Login
OAuth Support in Google's Federated Login API