I’m a rank beginner with Ruby and Sinatra, but have managed to come up with a web service that works pretty well, running on Heroku. I access this web service from Salesforce.com.
The HTTPRequest class that I use in Salesforce/Apex has a maximum timeout of 60s. If I hit that timeout (or, when I hit a 1 second timeout I’m using for testing purposes), I get an exception on the Salesforce side, which I can easily handle. What I’m interested in is how to handle this on the Sinatra side.
If my client gets a timeout, and somehow closes the connection, is there a way to “sense” this in my Sintra app? I’d like to note client timeout, continue doing the work the app had started, and then send an email to let the user know the job had finished after the timeout.
I should note that when I do get the timeout now, the Sinatra app happily finishes what it was doing, and, I’m guessing, returns the JSON data that it is supposed to. Only there’s nothing on the client side to get that data.
Any thoughts?
Fun problem. As a stateless protocol, I do not believe HTTP includes a method of “sensing” when a client closes a connection. I really don’t know anything about what SalesForce does, but here’s some standard HTTP solutions (I’m assuming Web Sockets are out).
Easiest, but prone to false positives
Since you know the max timeout, time your Sinatra request. If it took longer than 60 sec, assume it timed out and send an email. Obviously this is prone to error anywhere around 59-61 seconds, and you may get some false positives and false negatives.
Harder, but prone to perfection
You could implement a “read receipt.” Your JSON response would include a UID. If your SalesForce request doesn’t timeout, send the UID back as a receipt. Then Sinatra would know everything was okay.
If the Sinatra app doesn’t receive the receipt within n seconds/minutes (because SalesForce timed out and you never got the UID), the Sinatra app could send an email (or whatever) after n seconds/minutes.
This could be implemented several ways. The simplest probably involves a database, a script, and cron. The most difficult probably involves HTTP streaming (now trivial in Sinatra 1.3) and possibly multi-threaded or evented servers like Thin or Zbattery. I’d be happy to elaborate.