VW76NC
I've been trying to use the VW tools with
the NetSuite Web Service api (<A
title="https://webservices.netsuite.com/wsdl/v2009_1_0/netsuite.wsdl CTRL + Click to follow link"
href="wlmailhtml:{13603F58-4805-468D-898C-0B4D8716C4A2}mid://00000010/!x-usc:https://webservices.netsuite.com/wsdl/v2009_1_0/netsuite.wsdl">https://webservices.netsuite.com/wsdl/v2009_1_0/netsuite.wsdl),
and I've used the WSDL Wizard to create the WsdlClient and Xml to Object binding
code (and server code for a web service mock/stub). Most things
I've tried have worked fine, with the exception of a service method that
takes an abstract type, SearchRecord, as the aspect of the input object
(SearchRequest>>searchRecord: ) .
The problem that occurs is that when I set the
searchRecord to an instance of one of SearchRecord's subclasses (e.g.,
AccountSearch), the SOAP message body only includes an empty SearchRecord
element. Following is an Http request that is generated when an instance
of AccountSearch is provided as the searchRecord:
What happens, of course, is that on the service
side the searchRecord can't be serialized into anything useful, since it is
abstract.
So my question is: is this a known issue with the
Wsdl binding tools? Or is there some
customizations that I need to make so that the SearchRecord
subclasses are marshaled properly into the request? ... or
both?
Regards,
Todd E. King _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Todd,
tkkg42 wrote: > I've been trying to use the VW tools with the NetSuite Web Service > api (https://webservices.netsuite.com/wsdl/v2009_1_0/netsuite.wsdl), > and I've used the WSDL Wizard to create the WsdlClient and Xml to > Object binding code (and server code for a web service mock/stub). > Most things I've tried have worked fine, with the exception of a > service method that takes an abstract type, SearchRecord, as the > aspect of the input object (SearchRequest>>searchRecord: ) . > > The problem that occurs is that when I set the searchRecord to an > instance of one of SearchRecord's subclasses (e.g., AccountSearch), > the SOAP message body only includes an empty SearchRecord element. > Following is an Http request that is generated when an instance of > AccountSearch is provided as the searchRecord: > So my question is: is this a known issue with the Wsdl binding tools? > Or is there some customizations that I need to make so that the > SearchRecord subclasses are marshaled properly into the request? my guess is, that you have the default settings for derived types. In the main windows menu select System, Settings, Web Services, XML object Marshaling and enable "Allow marshaling derived types in relations". At least for me is a kind of "known issue". Most people do not stumble over it, since most SOAP interfaces are very simplistic. HTH Jan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks very much for the tip, Jan. Enabling that setting fixed the request message, and the derived types are now marshaled properly. However, I have a new problem with un-marshaling the response message(s). During the ComplexObjectMarshaler>>unmarshalFrom:Do call, there is a statement (marshalingContext value respondsTo: #_complete) that results in a DNU. "marshalingContext value" evaluates to an OrderedCollection (), so the call eventually resolves to (within respondsTo: ) "(an OrderedCollection) class canUnderstand: #_complete" that causes a DNU for the OrderedCollection class not understanding the "canUnderstand:" message...this makes no sense to me at all. I can evaluate: o := OrderedCollection new. o class canUnderstand: #_complete. in the same image without any issue. So I can only figure that there is some issue with the Marshaling code. I'm stumped... Todd King > > Hi Todd, > > tkkg42 wrote: >> I've been trying to use the VW tools with the NetSuite Web Service >> api (https://webservices.netsuite.com/wsdl/v2009_1_0/netsuite.wsdl), >> and I've used the WSDL Wizard to create the WsdlClient and Xml to >> Object binding code (and server code for a web service mock/stub). >> Most things I've tried have worked fine, with the exception of a >> service method that takes an abstract type, SearchRecord, as the >> aspect of the input object (SearchRequest>>searchRecord: ) . >> >> The problem that occurs is that when I set the searchRecord to an >> instance of one of SearchRecord's subclasses (e.g., AccountSearch), >> the SOAP message body only includes an empty SearchRecord element. >> Following is an Http request that is generated when an instance of >> AccountSearch is provided as the searchRecord: > >> So my question is: is this a known issue with the Wsdl binding tools? >> Or is there some customizations that I need to make so that the >> SearchRecord subclasses are marshaled properly into the request? > > my guess is, that you have the default settings for derived types. > In the main windows menu select System, Settings, Web Services, > XML object Marshaling and enable "Allow marshaling derived types > in relations". > > At least for me is a kind of "known issue". Most people do not > stumble over it, since most SOAP interfaces are very simplistic. > > HTH > Jan _________________________________________________________________ Insert movie times and more without leaving HotmailĀ®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by toddk42
Hi Todd,
Todd King wrote: > However, I have a new problem with un-marshaling the response > message(s). During the ComplexObjectMarshaler>>unmarshalFrom:Do > call, there is a statement (marshalingContext value respondsTo: > #_complete) that results in a DNU. Since respondsTo: is defined for instances of Object, this is really strange. Guessing about the real DNU message and its parameters, this should only be possible, if #class returned a non-Behaviour. That should only be possible if your objects either define #class to be something non-standard or your image is hosed :). Side note: never try to implement #name on the class side of one of your classes. Funny things will happen to your image. That's one of the consequences of being able to point the gun at everything even at yourself. A stackdump of your DNU would be helpful for diagnosis, e.g. a "context printStack" in the debugger. HTH Jan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I've attached a zip of the stack dump (it is quite verbose and I don't want to explode the list emails). This problem is occurring with a clean visualnc.im plus the Web Services packages loaded only. And the only extra code is that generated by the Wsdl Wizard. Kind Regards, Todd King ---------------------------------------- > Subject: RE: [vwnc] Web Services and abstract wsdl schema types ? > Date: Fri, 15 May 2009 16:43:35 +0200 > From: [hidden email] > To: [hidden email]; [hidden email] > > Hi Todd, > > Todd King wrote: >> However, I have a new problem with un-marshaling the response >> message(s). During the ComplexObjectMarshaler>>unmarshalFrom:Do >> call, there is a statement (marshalingContext value respondsTo: >> #_complete) that results in a DNU. > > Since respondsTo: is defined for instances of Object, this is > really strange. Guessing about the real DNU message and its > parameters, this should only be possible, if #class returned > a non-Behaviour. That should only be possible if your objects > either define #class to be something non-standard or your > image is hosed :). > Side note: never try to implement #name on the class side of one > of your classes. Funny things will happen to your image. That's > one of the consequences of being able to point the gun at > everything even at yourself. > > A stackdump of your DNU would be helpful for diagnosis, e.g. a > "context printStack" in the debugger. > > HTH > Jan HotmailĀ® has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc stack_dump.zip (19K) Download Attachment |
In reply to this post by toddk42
Hi Jan,
You are correct in your diagnosis of the problem. I checked the TransactionSearchRowBasic instance methods, and sure enough, there was an "override" of #class. Actually many of the classes had #class (and #class:) defined as accessors to a "class" instance variable. After much tedious work, I fixed the issue and everything works well. For posterity I include the steps I took to resolve the problem: 1) On the generated Wsdl client (NetSuitePortWsdlClient) class, I did a search and replace on the x2oBinding string to replace all occurrences of { aspect="class" } with { aspect="class_x" } (the braces are not part of the strings). 2) I then executed the following code: WebServices.XMLObjectBinding configure. WebServices.XMLObjectBinding loadBindings: self x2oBinding readStream 3) I picked one of the classes that had the #class: selector defined and renamed it to #class_x. 4) (and now for the tedious part) lastly in each class that defines the #class the selector, I copied #class as #class_x and then deleted the #class definition. It would be nice to find a way to automate all that, especially step #4, since renaming #class is not an option. Even better would be for a bug fix to prevent this problem from occurring at all; so I'll look for the proper channel to submit a bug to CINCOM on their web site. Thanks for all you help with this, Jan. Kind regards, Todd King Jan Weerts wrote: > Hi Todd > > Todd King wrote: >> I've attached a zip of the stack dump (it is quite verbose >> and I don't want to explode the list emails). >> This problem is occurring with a clean visualnc.im plus the >> Web Services packages loaded only. >> And the only extra code is that generated by the Wsdl Wizard. > > Unhandled exception: Message not understood: #canUnderstand: > OrderedCollection(Object)>>doesNotUnderstand: > TransactionSearchRowBasic(Object)>>respondsTo: > > Well in my image respondsTo: is defined as > ^ self class canUnderstand: aSymbol > > funnily your TransactionSearchRowBasic class seems to not > return "TransactionSearchRowBasic class" as Object, but some > kind of OrderedCollection. Is there a instance side method > named #class in the hierarchy of TransactionSearchRowBasic, which > is not the implementation of Object <primitive: 111>? > > If so, thats the culprit. Yes, that might come from the wsdl import. > > Searching the web for TransactionSearchRowBasic, I found some xsd > file at www.netsuite.com and they mention a property named "class" > at the TransactionSearchRowBasic object. So that would be a problem. > If that is your case, I guess that qualifies as a bug report for > Cincom, that wsdl generated code must not override "essential" > methods. > > Hope that helps a bit, and I am off for the weekend. > Kind regards > Jan > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by toddk42
One small correction to step three in my previous message. There is a typo
that makes it appear that the setter selector was renamed to a getter. Step three should read: 3) I picked one of the classes that had the #class: selector defined and renamed it to #class_x: Regards, Todd King _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |