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.

Error Handling

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.

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

Pretty awesome.

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.

The complete code can be found in client.rb. The error itself is parsed in soap_error.rb – SOAP faults come in standard format.

Parsing Responses

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.

require'vcr'VCR.configuredo|c|c.cassette_library_dir='test/cassettes'c.hook_into:webmockc.filter_sensitive_data('api-login-id'){TaxCloud.configuration.api_login_id}c.filter_sensitive_data('api-key'){TaxCloud.configuration.api_key}c.filter_sensitive_data('usps-username'){TaxCloud.configuration.usps_username}enddeftest_ping_with_invalid_credentialsassert_raiseTaxCloud::Errors::ApiErrordoVCR.use_cassette('ping_with_invalid_credentials')doTaxCloud.client.pingendendenddeftest_ping_with_invalid_responsee=assert_raiseTaxCloud::Errors::UnexpectedSoapResponsedoVCR.use_cassette('ping_with_invalid_response')doTaxCloud.client.pingendendassert_equal"Expected a value for `ping_result`.",e.problemenddeftest_pingVCR.use_cassette('ping')doresponse=TaxCloud.client.pingassert_equal"OK",responseendend