Oct 10, 2014

From Admin to Developer: Learning to Code on Force.com Resources

From Admin to Developer: Learning to Code on Force.com
Are you an Administrator interested in learning more about how and when to use the programmatic tools in Salesforce? Join us for an introduction to Apex and Visualforce that is geared towards Salesforce Administrators. This session will include best practices, real life experiences with using code in Salesforce, and useful resources. You will leave this session with a foundation to start learning how to code in Salesforce and develop on the Force.com platform.

Use the links below to get started on your path to become a Developer!


  1. Guided Do-It-Yourself
  2. Follow Along
  3. Reading Documentation
  4. Independent Practice
  5. Advanced Learning

Best of luck on your journey!  Let us know how it is going @mgsherms @Scott_VS

Oct 9, 2014

Integrating Salesforce to the Carvoyant API

The Internet of Things. IoT. The connected world. A paradigm shift known by many different names. While how exactly it will look may be unclear, it is quite clear that the technological world as we know it is undergoing a rapid and dynamic change. Pick a vertical, and we see the evolution. For instance, consider transportation, or more specifically cars. We've come a long way from the horseless carriages of yore; every modern car has a computer in it that controls it's oprations called the Electronic Control Module (ECM). Not only does this control many of the car's functions, but it also digitizes these actions. While the ECM is specific to a particular manufacturer or vehicle, there is an interface called the 'On Board Diagnostic' (OBD) connector that serves as a universal gateway to the digitized data of a car's inner workings.

Taking advantage of this interface are devices such as Carvoyant's connector, which plugs in to the OBD device and collects your car's data for your use through their API. This allows you to retrieve details such as your cars movements and position, fuel usage, maintenance needs, and much more. For companies whose businesses revolve around many or a fleet of cars, the prospect of accessing their data on-demand and/or near real-time can be very attractive.

 Setting up Carvoyant

1. Refer to Carvoyant's getting started and documentation here: http://confluence.carvoyant.com/display/PUBDEV/Getting+Started

2. Go to http://developer.carvoyant.com and register for a user account.

3. You will fill out some information for the application you create. The "Register Callback URL" field is very important -- this must be the page on which your web app performing the OAuth2 authentication is located and process the authorization code to exchange for the access token.

4. Now that you have an account, we need some data. go to https://sandbox-driver.carvoyant.com/ . Here you must register for a driver account (different from the user account you set up earlier).

5. Create a few cars. Either use your own cars' VIN numbers or search the web for some of your favorite cars and use those. Don't tell them I sent you.

6. Now let's make some trip data. Go to https://sandbox-simulator.carvoyant.com/ and login once again using your driver account. Click on two points on the map and a series of waypoints will be created between them. You can add more color to your data with the properties to the left, such as fuel usage and engine temperature.

7. That's it! We now have some data that we can use in Salesforce once we perform our integration.

 Salesforce Development

 The API uses the standard server side OAuth2 authorization flow. This involves passing an application key and client secret to the API, getting back an authorization code, and exchanging this code for a token from the API. Authentication is complete and this token is then stored and used for subsequent callouts to the API.

 Let's do a simple callout to the API to get our vehicles and their positions. We will then store them as records in Salesforce and map their position on a Visualforce page with Google Maps. This is what we will end up with (or something similar for the data you create):

The code below consists of a few components. We performed our authentication and saved our token and credentials in a custom setting. The class "CarvoyantIntegration" builds our HTTP request for us by using the results from authentication, the target API endpoint (https://sandbox-api.carvoyant.com/sandbox/api), and the resource/HTTP method passed in from our loadVehicles method. We deserialize the response from the Carvoyant API using the Vehicles/Vehicle inner classes, and thereby have the properties of the vehicle for our use later in the processVehicles method, where we take their values and create records in Salesforce.

 The class below contains a getter that merely fetches the vehicle data created from our callouts for use in our visualforce page.

We will use some of the properties in our table of vehicle information, and use the last waypoint latitude/longitude to map the last known location of the vehicles. The page has code for displaying vehicle record information as well as creating markers for the vehicles we queried for inthe controller above. Check out http://blog.crmscience.com/2014/09/lab-coat-lesson-google-maps-api.html for more detailed information about the Google Maps Javascript API.

What's next? Maybe you want to go in the direction of getting data for your vehicles when there is a change. You can use Carvoyant's subscription service and the Salesforce Streaming API as they have described here to do that http://confluence.carvoyant.com/display/PUBDEV/Force.com Perhaps you want to send emails when something goes wrong with a car, or better yet perform some preventative actions when a car hits certain threshold data points during their usage, such as mileage and engine temperatures. Or maybe you want to be able to know when certain cars enter certain areas you demarcate known as Geofences.

While we are only beginning our journey into the connected world, steps like these will prove to be instrumental in guiding that course and our expectations of it. Do we want cars to communicate with eachother? Perhaps leading to more efficient routing and a final end to traffic jams? Can we optimize our infrastructure through analysis of this data? Will this sort of thing help us keep an eye out on our autonomous cars? Control them even? There is a plethora of ideas in this realm that are waiting to be implemented. And what's next... you decide.

Oct 5, 2014

Lab Coat Lesson: Salesforce Arduino Gateway

The maker movement is alive, well, and has been very much reinvigorated over the last few years. Makers and tinkerers have been creating amazing projects and supporting each other in a large online community, not all too different from our own Salesforce community. The tail end of 2013 and 2014 brought a wave of "smart" wearable tech - 2015 will be no different (check out some of the ideas on Kickstarter).

The contributions to hobby electronics made by companies like Arduino, Adafruit, and Sparkfun make it possible for anyone (yes, anyone - including you) to create a physical working version of something you thought would be a great idea.  Think web controlled pet bowls, smart fishtanks, web-enabled weather logging stations, sun tracking window blinds...

Adafruit created the CC3000, a Wi-Fi enabled breakout board (also, available as a shield), featuring a Texas Instrument chips that allowed you to add Wi-Fi capabilities to your projects.  You could now send web requests to servers or even treat your device as a basic web server to receive requests.    

Then along came the Arduino Yún (Chinese for "cloud", by the way) board - the best of the Arduino you may already know and love with a bridge over to an embedded linux chip.  Now you've got more flexibility in you data processing and web handling.  You could easily a Raspberry Pi (fairly inexpensive embedded linux board) for the project in this post, but then you lose out on the fun of working with the new Yún.  If it were up to me, I'd be saying in my best Oprah voice, "You get a Yún!... and you get a Yún!... and you get a Yún!...) while living in a house made of Yúns - big fan Massimo Banzi, big fan.

So what are we going to build?   How about a little switch box to help quickly destroy all the evidence?

Alright - let's not be destructive, so let's create a few test records via the push of a button.

Sure, you could always execute the same script anonymously, but let's be honest, this seems like more fun!

How's this going to work?  We'll wire together an Arduino Yún and connect to it an LCD and a rotary knob.  Users will twist the rotary knob clockwise or couter-clockwise to select an object (Account, Contact, Lead, Opportunity, or Case).  The user will then push the knob (hooray, built in switch!) which will send a request across the Yún's bridge to the linux side to kick off a Python script.  This script will callout to your Salesforce Org, which will be using an Apex Rest class to kick off the destruction create copious amounts of test data and send back a response to the board.

Not so pretty.

What You'll Need:


  1. Arduino Yún (1)
  2. Rotary Encoder Switch
  3. LCD w/ Serial Backpack (backpack allows for LCD use with only 5V, ground, and one data lead instead of the normal rats nest)


  1. A Dev Org (or sandbox, but definitely not production)
  2. Arduino 1.5.5 (beta or later - support for Yún necessary)


Note:  I'm using the LCD Backpack (linked above) that uses 3 wires.  The above locations on the LCD are not correct and don't represent the use of the backpack.

Apex Class:  ArduinoGateway

Debug Log Output

Connected App

We'll use a Connected App to provide us with an endpoint to authenticate against so we can securely use our custom Apex Rest classes.
  1. Setup --> Build --> Create --> Apps
  2. Scroll down to the "Connected Apps" section
  3. Click on the "New" button
  4. Populate the "Connected App" details
  5. Check the "Enable OAuth Settings" checkbox and provide the following details:
  6. Click on the "Save" button
  7. Copy the Consumer Key and the Consumer Secret - you'll need these for the Python script below

Arduino Sketch:  ArduinoGateway.ino
Overview:  Our sketch is very simple - in a nutshell, when we flipping our final switch runs a Python script.  More verbosely, after the Yún board boots, it will be listening for a signal on the switchPin (13).  The switchPin will be hot after our final safety toggle is flipped (and illuminated!).  At that moment, we'll use the Yún's bridge from the Arduino side to the linux side to kick off a new Python process to run our script to call out to our Salesforce endpoint.

After you've uploaded the Arduino sketch to the Yun, using the Arduino IDE, you'll need to create the Python script.  Here are the general steps to do so:
  1. ssh <username>@<yun_ip_address> (IE:  root@
  2. If prompted, enter your password (Default:  arduino)
  3. "Yes" if prompted to add RSA key to list of known hosts
  4. cd /
  5. ls
  6. mkdir -p /home/root/ArduinoGateway/
  7. vi /home/root/ArduinoGateway/CallSalesforce.py

Python Script:  CallSalesforce.py                                               

So there you have it - with all those pieces in place, you should be able to twist the knob and cycle through the various sObject types.  Within the Apex Class above, we only handle Lead and Account scenarios - but you can just as freely modify all of the code to kick off any Apex code via the webservice class.  Likewise, within the Python script, you'll see that it's currently configured to take two parameters, one for the object type and one for the number of records to create.  The Arduino sketch can be modified to allow for the selection of an sObject type, then the number of records to create, before sending the request to the web service.

Have fun and please share any projects you have in mind or have done!