ryan.carter on Thursday, August 23, 2012

Connector Callback Testing – Local

3

using an external API can be a PITA, especially if the API uses any HTTP Callbacks or redirects such as OAuth or WebHooks. If your using any callback functionality like this then the Service Provider needs a way to callback your application and therefore be accessible to the public Internet.

When you start integrating these APIs, it’s much easier to work on your local development machine, but these are usually behind firewalls, NAT, or are otherwise not able to provide a public URL and it’s not really feasible to push to a staging environment every time you want to test something.

So we need a way to make our local applications available to the Internet; there are a few good services and tools out there to help with this such as: Tunnlr, ProxyLocal, showoff.io or you can setup your own reverse SSH Tunnel if you already have a remote system to forward you requests.

In this post, I am going to use a service called LocalTunnel and show how we can share a local Mule application with the world and customize some Connectors to receive Callbacks locally.

Installing Localtunnel

Ruby, Ruby, Ruby!

LocalTunnel can be installed by using RubyGems.

Mac - If you are using a Mac then your all set as it’s installed by default.

Linux – If you are on a Linux machine, you can run the following command to install rubygems:
$ sudo apt-get install ruby ruby1.8-dev rubygems1.8 libopenssl-ruby

Windows – Windows is a different animal, full instructions on installing RubyGems and LocalTunnel can be found here: http://blog.wearemammoth.com/2011/09/localtunnel-windows.html

Once RubyGems installed, either operating sytem can install LocalTunnel via the following command:
sudo gem install localtunnel

Drop the sudo if your using Windows.

Creating public and private keys

All these handy services for creating tunnels require a private and public key pair to enable your computer to securely communicate with theirs.To generate your public/private key pair, you can run the following command:

ssh-keygen

You should get output similar to the following:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/Ryan/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

First it will prompt you for a location to store the keys, and then a passphrase and confirmation of the passphrase. Here we have just hit enter 3 times, excepting the default location and using an empty passphrase.

First run with LocalTunnel

The first time you ever use LocalTunnel, you will have to upload the public key we generated earlier.

As you can see from the previous output, my key is stored in /Users/Ryan/.ssh/id_rsa. Using this path we can run localtunnel and upload they key using the following command:

localtunnel -k /Users/kevin/.ssh/id_rsa.pub 8081

-k indicates the key to upload followed by the path of the key. The last parameter “8081” is the local port we want localtunnel to forward to. So whatever port your app is running on should replace this value.

Future Runs

You only have to specify the key the first time you run localtunnel. Future tunnels can be setup as simple as the following command:

localtunnel 8081

Each time you run the command you should get output similar to the following:

This localtunnel service is brought to you by <a href="http://www.mulesoft.com/cloud-connectors/twilio-integration-connector"target="_blank" title="Twilio Integration Connector" >Twilio</a>.
Port 8081 is now publicly accessible from http://Rj1z.localtunnel.com ...

Take note of the URL provided as we’ll use this later to configure our callbacks.

Configuring the Callback

As Localtunnel is kindly provided by Twilio, to demonstrate I will use the Twilio Cloud Connector.  Twilio has an awesome WebHook implementation with great debugging tools. Twilio uses callbacks to tell you about the status of your requests; When you use Twilio to a place a phone call or send an SMS the Twilio API allows you to send a URL where you’ll receive information about the phone call once it ends or the status of the outbound SMS message after it’s processed.


3 Responses to “Connector Callback Testing – Local”

Mariano Gonzalez August 30th, 2012, 9:17 am

Great post Ryan, thank you!

One additional tip: In order for any gem install operation to work in a Mac, XCode and Command Line Tools for XCode need to be installed.

Cheers,

Ross Mason August 31st, 2012, 3:17 pm

Good post Ryan, I aslo realised that you can pretty easily set up local callbacks with CloudHub and the secure data gateway to tunnel requests. The nice thing about that approach is you don’t need to keep updating your callback URI.

Ryan Carter September 3rd, 2012, 3:29 am

Thanks. Yes, one of the main downfalls with services like these are that you have to regenerate the callback URI and update it everywhere, especially for some service providers like Bilty, where you cannot update the callback URI for an application after the original setup. I have since taken a look at the SDG from CloudHub and it looks a much more sustainable solution. Maybe a follow up post…

Leave a Comment