Intro

This article will be useful to anyone who is integrating to a large web service API. It covers concepts of using caching to improve performance and auto-generating an adapter supporting – Create Read Update Delete – ‘CRUD’ operations for the application. This article is based on a talk I gave September 24th at our third annual user conference in Toronto.

The techniques in here would be helpful for our vendor customers that are looking to make it easy to connect up their own applications with good web APIs.

The highly popular salesforce.com CRM application has been coming up on our radar a lot lately. We’ve had a number of existing customers and prospects that have had projects where they needed to interface with it.

It turns out that salesforce.com itself has huge ambitions in healthcare. The CEO of salesforce.com, Marc Benioff, has been quoted as saying that healthcare will be their next billion dollar business. Since signing up for my developer account I learned that they have an entire healthcare cloud application which I have to admit does look pretty smooth. Watch out Epic, Cerner and McKesson! Yet another big player is coming to healthcare!

So anyway – back to interfacing. This article is focused on the core salesforce.com CRM application. A couple of weeks ago I found myself sitting in a customer’s office needing to help them connect up salesforce.com with their application. So that got me started. Afterwards I went a bit further and wrote a much better adapter and used it as the basis for my presentation at our user conference.

This article addresses solving three main problems with making a good adapter:

1. Firstly getting the credentials set up to connect to the saleforce.com API. I found this a little hard to follow the first time, but I think you will find it easy to follow my instructions to get yourself set up.
2. Secondly saleforce.com is a big application. There are over 100 built in objects with lots of properties that you will want to alter with their RESTful web api. I found a great way to code-generate an entire ‘CRUD’ API (Create Read Update Delete) using the meta data supplied by some helpful API calls into their API.
3. Thirdly like any web service API there is latency. Web queries can take a few seconds to return, which is fine for production, but it doesn’t play that nicely with being able to get quick annotations, auto-completion etc. writing the code in the translator IDE. By using caching with the store module I was able to make the whole user experience delightfully responsive in terms of writing code for the integration.

The techniques I show in points 2 and 3 I think will be of great use to anyone who is building out an adapter for any web API in Iguana. A lot of our folks in our vendor community were excited at the conference about the idea of leveraging the same techniques I use here to make adapters for their own applications.