Implementation of table and profile extension

[florrain]

Dear team,

Here are a few changes made to the repo to welcome tables and profile extension tables. Because I needed new features, I changed some little things. Below you'll find a summary of my work.

API

• New QueryColumn API object.
• Raising exceptions when not manipulating properly the api objects (FieldType, QueryColumn)
• Now using to_api instead of to_hash because sometimes objects return a simple string

Client

• Changed response handling. Old handling can be called by passing the last param of api_method to :result.

Examples of the hash returned :

# Failure
{ status: "failure", error: { http_status_code: 500, code: "RECORD_NOT_FOUND", message: "No records found in the list for given ids" } }

# Ok
{ status: "ok", data: [{ "EMAIL_ADDRESS_": "user1@email.com", MOBILE_NUMBER_: "0000000001" }, { EMAIL_ADDRESS_: "user2@email.com", MOBILE_NUMBER_: nil }, { EMAIL_ADDRESS_: "user3@email.com", MOBILE_NUMBER_: "0000000000" }] }

• By default api_method returns a hash with status, errors, data
• Debug mode is an option that can be passed when configuring the gem. Default value is false.

Responsys.configure do |config|
  config.settings = {
    username: "your_responsys_username",
    password: "your_responsys_password",
    wsdl: "https://wsxxxx.responsys.net/webservices/wsdl/ResponsysWS_Level1.wsdl",
    debug: true
  }
end

Tests

• Integrated VCR and storing responses in spec/fixtures/vcr_cassettes

Other

• Added dependencies in the gemspec. Made version selecting less restrictive.
• Fixed the hash rocket syntax and param naming using the _ instead of camel case.
• Internationalization for internal messages. Used the i18n gem which is a copy of Rails one. The language is english by default and messages are in /responsys/i18n/en.yml

Notes

• The error handling in the helper is not the right way to do it because there is no standard response message returned by all API methods. I'm thinking about describing the error handling in each API file (list, table, ...) or a description of all errors in a file that could be used by the helper in case of errors.

Thanks for your comments !

[florrain]

Would you check the types of object passed to each function ?

For instance take retrieve_profile_extension_records(interact_object, query_column, field_list, ids_to_retrieve). At the beginning of the function there would a check of all params : interact_object.is_a? InteractObject and query_column.is_a? .....

I know it's generating a large amount of code if we do it so for all functions. Also Ruby has not been thought for type checking. My question is : should we check params of all functions and handle/raise exceptions if so. Related to this I coded a raised exception in FieldType and QueryColumn API objects if the constructor param is not an accepted type/column.

[florrain]

Now closing, everything's been pushed to master.