I’ve been working on the the tax_cloud gem for the past couple of days and am happy to announce version 0.2.0, released today. The gem was started by @tempelmeyer and is now a mature wrapper for the TaxCloud US Sales Tax calculation service.
This library is also a nice example of a generic SOAP client wrapper in Ruby. I wanted to point out several successful patterns for this integration, which I cannot take credit for, for the most part.
I borrowed error handling from @modetojoy’s Mongoid. Today someone said: “I had a bug in a spec and Durran told me how to fix it in an error message.” True story. To accomplish this we define a base error that holds the problem, summary and resolution. In tax_cloud’s case this is TaxCloud::Errors::TaxCloudError paired with config/locales/en.yml, a locale file that does the error formatting. There’re two things to do in order for the error code to find the message: add the locale file to the load path, in tax_cloud.rb, and do a bit of formatting with I18n.
What does an error in tax_cloud look like?
Problem: Missing configuration. Summary: TaxCloud requires an API login ID and key. Resolution: Create a TaxCloud merchant account at http://www.taxcloud.net. Add a website to your TaxCloud account. This will generate an API ID and API Key that you will need to use the service. Configure the TaxCloud gem. For example, add the following to `config/initializers/tax_cloud.rb`. TaxCloud.configure do |config| config.api_login_id = 'your_tax_cloud_api_login_id' config.api_key = 'your_tax_cloud_api_key' config.usps_username = 'your_usps_username' # optional end
Safe SOAP Requests
The tax_cloud gem uses Savon to make SOAP requests. “Savon” is French for “Soap”, which confuses the French speakers like myself trying to explain that SOAP is Savon. Anyway, a client is initialized with its WSDL.
First, we need to add authentication to every request, which is required by the API. We can override request.
Second, we want to handle SOAP errors, and give a detailed explanation for SOAP faults, Mongoid-style. This is your typical block with yield.
We will now raise a good-looking exception on SOAP failures, but we still must protect ourselves from unexpected data or successful SOAP requests that return API errors. That possibility is the thing I detest most about SOAP (vs. REST) – it makes programming a client unnecessarily complicated. The TaxCloud service returns a SOAP body with different values in key_response/key_result/response_type, where the key will be the name of the method invoked (eg. ping_response). A bit of meta-programming can make a base class, which can parse a response and match an XML path, raising errors where appropriate. It can be subclassed into a generic response type and, finally, into specific declarative implementations such as ping or authorized.
Most services have a common response pattern, generalizing it yields a very productive framework where adding support for new calls requires very little to no code. And you must never, ever expose to the user that you’re making SOAP requests and return any kind of raw SOAP object. Return domain-specific classes with attributes on success and raise exceptions otherwise.
Testing SOAP Requests
The tax_cloud gem uses VCR to test SOAP requests. It’s surprisingly easy: use a cassette (a YAML file), which records it the first time you make a request. Second time around the file contents are used and no HTTP requests are made. You can filter out sensitive keys in the configuration.
You can see the rest of the tests here.
Let me know if you use some of these ideas, post your comments and suggestions and please help improve the tax_cloud gem on Github.