Problems with namespace prefixes in D7...?
Thomas Eg Jørgensen
I'm having problems using the SOAP implementation in D7...
The following XML is generated:
<?xml version="1.0"?>
<SOAP-ENV:Envelope [-SNIP-]>
<SOAP-ENV:Body [-SNIP-]>
<NS1:Connect xmlns:NS1="xxxx">
<agreementNumber xsi:type="xsd:int">xxxx</agreementNumber>
<userName xsi:type="xsd:string">xxxx</userName>
<password xsi:type="xsd:string">xxxx</password>
</NS1:Connect>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
But the server does not accept that the childs of "Connect" isn't prefixed
with NS1...Either the NS1 must be included on all elements or none...Both of
the following works fine if i test them in my requestbuilder:
*** With NS1 on all elements: ***
<?xml version="1.0"?>
<SOAP-ENV:Envelope [-SNIP-]>
<SOAP-ENV:Body [-SNIP-]>
<NS1:Connect xmlns:NS1="xxxx">
<NS1:agreementNumber xsi:type="xsd:int">xxxx</NS1:agreementNumber>
<NS1:userName xsi:type="xsd:string">xxxx</NS1:userName>
<NS1:password xsi:type="xsd:string">xxxx</NS1:password>
</NS1:Connect>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
AND
*** With no prefix at all: ***
<?xml version="1.0"?>
<SOAP-ENV:Envelope [-SNIP-]>
<SOAP-ENV:Body [-SNIP-]>
<Connect xmlns:NS1="xxxx">
<agreementNumber xsi:type="xsd:int">xxxx</agreementNumber>
<userName xsi:type="xsd:string">xxxx</userName>
<password xsi:type="xsd:string">xxxx</password>
</Connect>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
But how can i tell Delphi to use one of the two?
Thanks in advance!
/Thomas
Jean-Marie Babet
I can't tell without looking at the WSDL but it seems to me that you might
have a document|literal service that D7 is thinking of/treating as an
rpc|encoded one. In classic SOAP encoding, the namespace of elements do not
matter (matter of fact they are unqualified) and the xsi:type attribute is
what matters. If it's possible to post or point us to the WSDL, I'll be
happy to confirm whether that's the issue.
Alternatively, you can also download the updates posted here:
http://cc.codegear.com/Item/24535
The updates contains a command line importer that remedies problems with
D7/D2005/D2006 not always properly detecting doc|lit services. The runtime
also addresses element namespaces.
Cheers,
Bruneau
Thomas Eg Jørgensen
news:481604f8$1...@newsgroups.borland.com...
> I can't tell without looking at the WSDL but it seems to me that you might
> have a document|literal service that D7 is thinking of/treating as an
> rpc|encoded one. In classic SOAP encoding, the namespace of elements do
> not
> matter (matter of fact they are unqualified) and the xsi:type attribute is
> what matters. If it's possible to post or point us to the WSDL, I'll be
> happy to confirm whether that's the issue.
>
hmm, ok. The WSDL is public available here:
https://www.e-conomic.com/secure/api1/EconomicWebService.asmx?wsdl
> Alternatively, you can also download the updates posted here:
>
> http://cc.codegear.com/Item/24535
>
> The updates contains a command line importer that remedies problems with
> D7/D2005/D2006 not always properly detecting doc|lit services. The runtime
> also addresses element namespaces.
>
I've already downloaded and "installed" this update (i just made a backup
copy of the original files in Delphi and then overwrote them with the ones
in the ZIP-file and finally rebuild "everything")...
It did seem to help on some problems(when importing from e.g. WCF)...but
this problem with the namespace-prefixes persists:-(
Thanks for your input!
/Thomas
Jean-Marie Babet
My apologies for the delay. I was away from the newsgroup most of last week.
Let me try the WSDL you pointed me and relay my findings.
Cheers,
Bruneau
Jean-Marie Babet
I just investigated the XML generated for the call to Connect and it seems
fine to me:
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<Connect xmlns="http://e-conomic.com">
<agreementNumber>123456</agreementNumber>
<userName>Usr</userName>
<password>Pass</password>
</Connect>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you see above, we don't use any prefixes (at least, we try not) when
talking to a document|style service.
Question
======
Can you go to the registration section of the file generated by the importer
and confirm that you copy reads as follows?:
InvRegistry.RegisterInterface(TypeInfo(EconomicWebServiceSoap),
'http://e-conomic.com', 'utf-8');
InvRegistry.RegisterDefaultSOAPAction(TypeInfo(EconomicWebServiceSoap),
'http://e-conomic.com/%operationName%');
InvRegistry.RegisterInvokeOptions(TypeInfo(EconomicWebServiceSoap),
ioDocument);
The relevant line is the last one. I have the feeling that's missing in your
copy, maybe??
Please let me know.
Cheers,
Bruneau
Thomas Eg Jørgensen
>> But the server does not accept that the childs of "Connect" isn't
>> prefixed
>> with NS1...Either the NS1 must be included on all elements or none...Both
>> of
>> the following works fine if i test them in my requestbuilder:
>
> importer
> and confirm that you copy reads as follows?:
>
>
> InvRegistry.RegisterInterface(TypeInfo(EconomicWebServiceSoap),
> 'http://e-conomic.com', 'utf-8');
> InvRegistry.RegisterDefaultSOAPAction(TypeInfo(EconomicWebServiceSoap),
> 'http://e-conomic.com/%operationName%');
> InvRegistry.RegisterInvokeOptions(TypeInfo(EconomicWebServiceSoap),
> ioDocument);
>
>
> The relevant line is the last one. I have the feeling that's missing in
> your
> copy, maybe??
>
Voila! You were right, it solved the problem! I just added the
"ioDocument"-line and it worked...
Thank you very much!
But, i'm wondering why it was missing in the first place? Did i do something
wrong during the import?
/Thomas
Jean-Marie Babet
> But, i'm wondering why it was missing in the first place? Did i do
something
> wrong during the import?
Earlier versions of the importer missed the 'document' style because of
changes in WSDL format. I don't know if this is related to your case but,
for example, from .NET 1.0 to 2.0 there was a change that tripped the
current importer at the time. I posted something about this in the following
message:
http://groups.google.com/group/borland.public.delphi.webservices.soap/msg/80cd0981c7018e5b
http://tinyurl.com/yxotfb
(See issue #1).
I suspect you might have used an earlier importer. It's possible to tell by
looking at the $Rev emitted by later versions of the importer in the binding
file.
Cheers,
Bruneau
Thomas Eg Jørgensen
>> But, i'm wondering why it was missing in the first place? Did i do
> something
>> wrong during the import?
>
> Earlier versions of the importer missed the 'document' style because of
> changes in WSDL format. I don't know if this is related to your case but,
> for example, from .NET 1.0 to 2.0 there was a change that tripped the
> current importer at the time. I posted something about this in the
> following
> message:
>
> http://groups.google.com/group/borland.public.delphi.webservices.soap/msg/80cd0981c7018e5b
> http://tinyurl.com/yxotfb
>
> (See issue #1).
Yeah, it seems to be the problem. I've ealier given up on making D7 consume
another .NET 2.0 service in another project, but i think i will give it
another go with this "new" information in mind...
> I suspect you might have used an earlier importer. It's possible to tell
> by
> looking at the $Rev emitted by later versions of the importer in the
> binding
> file.
>
This?
// ************************************************************************
//
// The types declared in this file were generated from data read from the
// WSDL File described below:
// WSDL :
https://www.e-conomic.com/secure/api1/EconomicWebService.asmx?wsdl
// Encoding : utf-8
// Version : 1.0
// (20-04-2008 17:31:29 - 1.33.2.5)
// ************************************************************************
//
The versioninfo on "WSDLImp.exe" is 11.0.2811.27992 ...
Thanks!
/Thomas
Jean-Marie Babet
> This?
> //
************************************************************************
> //
> // The types declared in this file were generated from data read from the
> // WSDL File described below:
> // WSDL :
> https://www.e-conomic.com/secure/api1/EconomicWebService.asmx?wsdl
> // Encoding : utf-8
> // Version : 1.0
> // (20-04-2008 17:31:29 - 1.33.2.5)
> //
************************************************************************
Yes, this was an old importer. I can't easily track back this version (well
I could but it would require going to either CVS or StarTeam archives). The
reason I can tell is because we switched to Subversion a couple years back
(2006, I think) and the newer importers have the Subversion style $Rev in
the header - as in:
// (5/5/2008 7:16:05 PM - - $Rev: 12980 $)
The n.n.n.n seems like a StarTeam $revision.
While we don't yet support all XML constructs we've done a lot in that area
in the later versions and typically the importer emits constructs that the
runtime uses... so it's a good idea to keep them pretty much in sync and use
the later importer when upgrading the runtime.
Cheers,
Bruneau