The Amazon cloud, explained.

Home / Blog / Integrating with SalesForce.com via SQS

Hey guys,

I’ve found that Amazon’s Simple Queue Service is a really great way to ‘glue’ a couple of applications together. My latest integration has been with Salesforce.com.

Just in case you aren’t familiar with it, Salesforce.com is a hosted customer relationship management (CRM) system. It was one of the first ‘cloud’ services available commercially.

I’m building an event management system where people can sign up for events. The client I’m working with wants to create a ‘Lead’ in Salesforce.com for each person that signs up for an event.

I don’t want this operation to interfere too much with my customer’s sign-up experience so I’m going to do my integration Salesforce.com offline.

This is where Simple Queue Service (SQS) is so handy. What I can do is capture the information that I need to generate a lead for my customer.

The message body that I’m going to send will just be in query string format:

picture-48My sendMessage function is defined as follows:

picture-49 This function is obviously really simple, but I do find it really useful.

The great thing about SQS is that your messages persist for up to 4 days. So I’m really in no hurry to write the logic to process these messages.

To work with Salesforce.com from an integration perspective, the first thing you need (assuming you don’t have a full account already) is a developer account; you need a developer account in order to use the API. You can get one from http://developer.force.com/.

Once you login, your next step is to enable the API integration feature. You can enable this from the Setup menu, which is at the very top of your screen.

picture-50

Your next step is to enable the API. This is done by downloading the enterprise WSDL file. As far as I can tell, you don’t actually need the file itself; the act of downloading it enables the API for your account.

picture-52

Your next step is to open up your Personal Setup

picture-51In order to access your account from the API, you have to append a security token to your password. Choose the Reset My Security Token to get this token for the first time.

picture-53

That’s it, your account is all set. Now we just need a library to work with the Salesforce.com API. There is a library available for a wide selection of languages - you can see them all at: http://wiki.apexdevnet.com/index.php/API.

I chose the PHP Toolkit library; this library works really well, the only thing is that it depends on the SOAP module for PHP. You’ll get an error about not being able to find the SoapClient class if you don’t have it. If you don’t have it, you’ll need to install it (i.e. yum install php-soap).

I’m on a Mac and installing php-soap is a bit more complicated. I actually didn’t bother because I was planning on deploying my application to an EC2 server anyways. For my local development I use XAMPP. The version of PHP that is installed with XAMPP has soap installed so I just ran that php interpreter instead (i.e. /Applications/xampp/xamppfiles/bin/php).

Once you have your Salesforce.com account setup and your wrapper configured, the actually coding is pretty straighforward.

I’m using my adaptive poll class to implement my Salesforce integration worker.

PHP makes it really easy to parse a query string with its parse_str function.

picture-54I store the name of the event in my system in SimpleDb, so I do a quick query to get that; and I instantiate my Salesforce client in the code listing below:

picture-55Lastly, it is just a matter of creating the Lead object and saving some information to it:

picture-56

Now when someone signs up for an event, I have an additional line of code to submit their information into my queue. This really doesn’t take very long (I actually do it with AJAX asynchronously) so there is no affect on the users’s experience.

I usually have 1 or more workers running, so as soon as that message ends up in the queue, it is processed and a lead is created in Salesforce.com.

picture-57

There are a few other places in my application where I am gathering user data - I can easily just make a call to my sendMessage function to put their data into Salesforce.com as well.

In my opinion, Salesforce.com and SQS make great partners. With Salesforce.com, you can run CRM without the usual CRM headaches and high costs. SQS gives me an easy, generic way to do offline processing. I simply just dump my information into SQS. I don’t even need to have anything reading from the queue right away; my messages will persist for 4 days. Once I have my worker up and running, I can read each message and process them accordingly. Even if I have applications written in other programming languages, I can still use SQS because all I am doing is making an HTTP request with a string formatted in some way that I have defined.

Thanks!

Eric.


Comments are closed.