Missing namespace in soap body
Erik F. Andersen
I have a problem with the SOAP body generated by my Delphi 2007 RAD.
The body generated by delphi looks like this:
<SOAP xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:default="http://medcom.dk>
<SOAP-ENV Body>
<default:getPersonInformationIn xmlns="http://medcom.dk>
<default:PersonCivilRegistrationIdentifier>2512484916</default:PersonCivilRegistrationIdentifier>
</default:getPersonInformationIn xmlns="http://medcom.dk>
<SOAP-ENV Body>
the problem is however that it should look like this:
<SOAP xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:default="http://medcom.dk>
<SOAP-ENV Body>
<default:getPersonInformationIn xmlns="http://medcom.dk>
<PersonCivilRegistrationIdentifier
xmlns="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18">2512484916</default:PersonCivilRegistrationIdentifier>
</default:getPersonInformationIn xmlns="http://medcom.dk>
<SOAP-ENV Body>
The namespace for PersonCivilRegistrationIdentifier should be different from
the one that Delphi assigns. How can I fix this?
The WSDL for the webservice is
http://83.90.36.36/DetGodeCprOpslag/DetGodeCprOpslag.asmx?wsdl.
Thanks!
Erik
Jean-Marie Babet
Do you have the patches posted here applied:
http://cc.codegear.com/Item/24535
There are a few element namespace related issues addressed in that patch. In
particular, see the 'FIX_ELEM_NODE_NS' define.
If this does not address the issue, I'll be happy to investigate. (Seems
that this is EventCentral's WSDL, right?. Our SOAP unit tests interact with
EventCentral although we invoke just a few methods: prodFindAll and
something else that I cannot remember right now).
Cheers,
Bruneau.
Erik F. Andersen
I did try the patch and it made no difference. I have D2007 and really
didn't think that I needed that patch but maby I'm wrong?
I'm not sure what EventCentral is but I did log a case with you earlier
regarding the types problem with the WSDL importer and later on the problem
with internal error URW4590. During our following conversation I might have
e-mailed you this WSDL as well.
Should I log another case at your self-service support pages? I have a very
prestigious project coming up which involves parts of the danish government
and I'm stuck at the integration testing level at the moment :-( I need a
work around!! I already manipulate the Delphi generated SOAP in order to add
WS Security information to the SOAP header, so a generic patch at the XML
level will do nicely (I have webservices with 100's of methods like this one
so it mush be a completely generic patch).
Regards,
Erik
"Jean-Marie Babet" <bba...@borland.com> skrev i en meddelelse
news:472f734b$1...@newsgroups.borland.com...
Jean-Marie Babet
> I did try the patch and it made no difference. I have D2007 and really
> didn't think that I needed that patch but maby I'm wrong?
Correct, you don't need the patch if you're using D2007. The patch is
derived from the D2007 codebase for users of earlier versions of Delphi.
> I'm not sure what EventCentral is but I did log a case with you earlier
> regarding the types problem with the WSDL importer and later on the
problem
> with internal error URW4590. During our following conversation I might
have
> e-mailed you this WSDL as well.
Thank you for the reminder. I do recall the URW4590 (with strong alias of
enumerations).
> Should I log another case at your self-service support pages? I have a
very
> prestigious project coming up which involves parts of the danish
government
> and I'm stuck at the integration testing level at the moment :-( I need a
> work around!! I already manipulate the Delphi generated SOAP in order to
add
> WS Security information to the SOAP header, so a generic patch at the XML
> level will do nicely (I have webservices with 100's of methods like this
one
> so it mush be a completely generic patch).
You may log a case or you can wait for me to investigate a little. There are
two cases that I know of regarding incorrect element namespaces:
#1. When a 'property' does not correspond to an xsd:element in the schema
(There's a thread on this issue regarding WSSE headers currently).
#2. When there's an array and the namespace of the array differs from the
namespace of the element of the array.
Neither of these sounds related to what you reported but I'll need to
investigate further to confirm.
More as soon as I have investigated.
Cheers,
Bruneau.
Erik F. Andersen
FYI I tested from C#.Net and the SOAP code generated here look fine.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getPersonInformationIn xmlns="http://medcom.dk">
<PersonCivilRegistrationIdentifier
xmlns="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18">2512484916</PersonCivilRegistrationIdentifier>
</getPersonInformationIn>
<soap:Body>
Very nice soap I think... And correct!
Regerds,
Erik
"Jean-Marie Babet" <bba...@borland.com> skrev i en meddelelse
news:4730ec79$1...@newsgroups.borland.com...
Jean-Marie Babet
Thank you for the update.
I've investigated and it's similar to another issue that I investigated
recently
(
http://groups.google.com/group/borland.public.delphi.webservices.soap/msg/0b4013c715119f25 )
. Basically the Delphi SOAP runtime needs to handle cases where the element
does not inherit the namespace of the complextype in which its declared.
In your particular case, because the class contains only one property if
you turn off the {$DEFINE FIX_ELEM_NODE_NS} in OPToSOAPDomConv.pas (line 22)
and rebuild with that, then the XML serialized will be:
<?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>
<getPersonInformationIn xmlns="http://medcom.dk/">
<PersonCivilRegistrationIdentifier
xmlns="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/">2512484916</Pe
rsonCivilRegistrationIdentifier>
</getPersonInformationIn></SOAP-ENV:Body>
</SOAP-ENV:Envelope>
But doing that is not safe as there are probably cases in that WSDL when the
previous behaviour is called for (I did not look at all the schemas). And
you can easily run into cases where a class has both types of elements
declared.
Bottom line is that we need support to handle both cases as dictated by the
schema.
What I'll probably do is add a tweak to the runtime to look for a bit on the
property declaration to determine which way to go. Then we would need to
change the code generated by the importer to add this bit to the property as
in:
getPersonInformationIn = class(TRemotable)
property PersonCivilRegistrationIdentifier:
PersonCivilRegistrationIdentifier Index (IS_OPTN or $40 ) read
FPersonCivilRegistrationIdentifier write
SetPersonCivilRegistrationIdentifier stored
PersonCivilRegistrationIdentifier_Specified;
end;
Long term we need to fix the importer to identify and request the proper
behaviour from the runtime.
Let me run the above by some folks and then I'll post more...
Cheers,
Bruneau.
Jean-Marie Babet
Just a follow up to mentioned that I've checked in the tweak I mentioned in
my previous post. The importer now generates the following:
//
************************************************************************ //
// XML : getPersonInformationIn, global, <element>
// Serializtn: [xoLiteralParam]
// Info : Wrapper
//
************************************************************************ //
getPersonInformationIn = class(TRemotable)
private
{...}
published
property PersonCivilRegistrationIdentifier:
PersonCivilRegistrationIdentifier Index (IS_OPTN or IS_REF) read ...;
end;
The runtime looks at the 'IS_REF' bit in the index and switches to the
type's namespace yielding the following:
<?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>
<getPersonInformationIn xmlns="http://medcom.dk/">
<PersonCivilRegistrationIdentifier
xmlns=http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/>2512484916</Pers
onCivilRegistrationIdentifier>
</getPersonInformationIn>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Cheers,
Bruneau,.
PS: NOTE Contratry to what I posted before, the value of IS_REF is $0080
as$0040 was already used by the importer to flag <xsd:any> type - another
thing that the runtime ignores still but should be addressed in the future.