Last Friday, the Salesforce Platform Developer Evangelism Team ran a (mostly) internal hackday, bringing together evangelists, support staff, product management, R&D engineers and a couple of special community guests for a day of exploratory hacking. Although the theme for the day was ‘Mobile’, this wasn’t a constraint, and I teamed up with sales support engineer Henry Liu to explore, a ‘declarative, data-retrieval and aggregation gateway for quickly consuming HTTP APIs’ created by eBay’s platform engineering group, in use (among other places) at Kinvey for integrating with third-party data sources. In this blog entry (the first in a three part series) I’ll describe how we got started, creating a simple wrapper for a REST API call.

This script from the examples page illustrates a typical use case, mashing up three different web services from two providers:

The inner select uses the eBay Finding API to search for items including the keyword ‘iPad’, while the outer select retrieves geographic coordinates for the items’ locations from the Google Geocoding API and item detail from the eBay Shopping API. ‘Tables’, defined elsewhere, hold the mappings to actual web service requests – the documentation does a good job of explaining how it all fits together. The query results are in JSON format:

Given that the table definitions add only a dozen or so more lines of script, it was clear that’s table abstraction would allow us to quickly integrate a bundle of different web services without writing a mountain of boilerplate code. We had a couple of goals in mind for the day – mashing up the REST API with Google Geocoding to get latitude and longitude for Account records, and filtering Chatter posts on keywords – but the first step was to figure out how to access the REST APIs from

After a couple of false starts trying to configure with user credentials and have it login via OAuth Username-Password Flow, we realized that it’s best to think of as a filter, supplying it with an OAuth access token and instance url rather than configuring it to login itself. Simulating a client app, we obtained the necessary values via curl (parameters modified for this example!):

Now it was straightforward to create a script in that would retrieve a list of Accounts:

With the result:

This is a start, but, clearly, hardcoding access tokens into a web console isn’t a viable solution! It turns out that you can configure script routes in, wrapping select statements as web services, so, after a bit more prodding, poking and reading documentation, we created one file in the server’s tables directory:

And another in the routes directory:

We set those instance_url and authorization parameters via HTTP headers from a client, like this:

Et voilà:

So far, we haven’t done anything you can’t do by accessing the REST API directly, but next time, in part 2, we’ll see how, with a Formula Field and just a few lines more script, we can get the latitude and longitude for each Account from the Google Geocoding API, far quicker than if we implemented an equivalent REST Web Service in Apex, and without consuming any callouts.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS