Monday, April 02, 2007

One last hitch

According to this, friendly errors such as

/opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/mapping.rb:520:in `class_schema_variable': undefined method `class_variables' for nil:NilClass (NoMethodError)
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/mapping.rb:353:in `schema_ns_definition'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/mapping.rb:380:in `schema_definition_classdef'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/registry.rb:198:in `schema_definition_from_class'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/literalregistry.rb:73:in `any2soap'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/literalregistry.rb:37:in `obj2soap'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/literalregistry.rb:127:in `stubobj2soap'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/literalregistry.rb:114:in `each'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/mapping/literalregistry.rb:114:in `stubobj2soap'
... 15 levels...
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/rpc/proxy.rb:126:in `call'
from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.5.20061022/lib/soap/rpc/driver.rb:179:in `call'
from (eval):6:in `search'


prohibit the following default generated objects from correctly mapping when invoking the NetSuite searches:

  • OpportunitySearchBasic

  • EmployeeSearchBasic

  • PartnerSearchBasic

  • ItemSearchBasic

  • TimeBillSearchBasic


Each of which contain an entity named 'class', and while soap4r intelligently generates an attribute 'v_class', it also erroneously generates accessor methods that override Object.class. Big woops. Extremely easy fix just by renaming those methods.

3 comments:

  1. Incidentally, how did you invoke these searches? I've been trying with the latest copy of soap4r, and it's not catching the subclass of the abstract SearchRecord class when it comes time to obj2soap() any of the *SearchBasic classes.

    ReplyDelete
  2. Perhaps this sample code for CustomerSearchBasic with soap4r (1.5.5.20061022) will be helpful:

    entity = SearchStringField.new("Vandalay Industries")
    entity.xmlattr_operator = SearchStringFieldOperator::Contains

    search = CustomerSearchBasic.new()
    search.entityId = entity
    customer = driver.search(SearchRequest.new(search))

    ReplyDelete
  3. Odd - I've been using soap4r trunk, and when I send what you have there, I get the same result as what's described here:

    http://groups.google.com/group/soap4r/browse_thread/thread/b52b48c7f77c81d1

    ReplyDelete