> {quote:title=Jean-Marie Babet wrote:}{quote}
> Hello Dann,
>
> This warning is perfectly safe and has to do more with how WebServices
> standards have changed. Initially WebServices were rpc-oriented. So an
> operation and it parts mapped exactly to a method and parameters. And even
> though the format was XML the encoding use was not XML encoding: SOAP had
> it's own encoding rules that used XML format but the XML conventions.
>
> Then there was a push to shift to XML encoding. That model was not
> rpc-oriented; rather the Service expected a type [described] by a schema and
> it returned another type equally described by XML schema. In order to bridge
> the document/xml schema style to the previous rpc-oriented model the
> *wrapped* document|literal convention was established. In that model if a
> Service exposed an 'Add' operation, say:
>
> {code}
> function Add(I1, I2: Integer): Integer;
> {code}
>
> The XML schema types would actually say that the Add operation takes a type,
> named Add, that contains two integers. Something along the lines of:
>
> {code}
> Add = class private
> published
> property I1: Integer;
> property I2: Integer;
> end;
>
> AddResponse = class(TRemotable)
> published
> property AddResult: Integer:
> end;
>
> function Add(const parameters: Add): AddResponse;
> {code}
>
>
> Of course, no one wanted to deal with that extra layer. You just want to
> pass two integers and get one back - not construct a type with two integers
> and receive back another type that contains the result. So it became
> customary for WSDL importers to *unwrap*.
>
> A set of conventions were adopted on how the service would expose the
> wrappers such that someone looking at the WSDL would be able to tell: "Ah,
> this Service is wrapped... when I write a client for it I can remove that
> extra layer and get a more rpc-centric view of the Service". You can read
> about the conventions here:
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
>
> But then Services started to worry less about exposing an rpc-friend view
> and several of them are simply not using the wrapped conventions. (It's a
> rather heated debate sometimes; you can search online for 'wrapped' vs.
> 'bare' and see the opinions for and against each:)
>
> The messages that you saw were added to the WSDL importer because there was
> a time when most document|literal services were wrapped and if the Delphi
> importer failed to unwrap them (some) users would not be that happy. So, we
> added code to clearly say that we could not unwrap and then we spell out the
> reasons (they usually are because of the conventions mentioned in the link
> above was not adhered to).
>
> Now that there's just as many wrapped and bare services out there it
> probably makes no sense to generate these messages anymore. Just a small
> line to mention that this is not a wrapped service would probably be
> sufficient. I'm making a note to do that.
>
> Please let us know if you need more information or run into problems using
> this Service. You can configure to no unwrap and therefore it won't generate
> the messages because it won't even try.
>
> Cheers,
>
> Bruneau
Thank you for the detailed reply.
I am still having problems though. If I try call any of the declared functions, I receieve errors like this.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/fault</a:Action></s:Header><s:Body><s:Fault><s:Code><s:Value>s:Sender</s:Value><s:Subcode><s:Value>a:ActionMismatch</s:Value></s:Subcode></s:Code><s:Reason><s:Text xml:lang="en-US">The SOAP action specified on the message, '', does not match the HTTP SOAP Action, 'http://www.fastenterprises.com/MFET/SubmissionListBySubmis
sionId'. </s:Text></s:Reason><s:Detail><a:ProblemHeaderQName>a:Action</a:ProblemHeaderQName></s:Detail></s:Fault></s:Body></s:Envelope>
Her eis the function I am calling
SubmissionWS.GetMFET(false,'',httprio2);SubmissionListBySubmissionId('100') ;
The problem is that the SubmissionListBySubmissionId('100') function should have 2 parameters, a Header and the SubmissionID. The '100' that I have coded in there is the SubmissionID. It appears the the WSDL import is not properly creating the function.
Here is the declaration:
MFET = interface(IInvokable)
['{5959790D-89C4-E195-0CF9-C4FC82ADE863}']
// Cannot unwrap:
// - Input message has more than one part
// - The output part is not a complex type
function NewSubmission(const SubmissionType: SubmissionType2; const ReferenceId: ReferenceId; const File_: File_): SubmissionId; stdcall;
// Cannot unwrap:
// - Input message has more than one part
function SubmissionListByDate(const DateFrom: DateFrom; const DateTo: DateTo): SubmissionList; stdcall;
// Cannot unwrap:
// - Input element wrapper name does not match operation's name
function SubmissionListByReferenceId(const ReferenceId: ReferenceId): SubmissionList; stdcall;
// Cannot unwrap:
// - Input element wrapper name does not match operation's name
function SubmissionListBySubmissionId(const SubmissionId: SubmissionId): SubmissionList; stdcall;
end;
So what should I try?
DAN